from:"Pascal Bach"

[OE-core] [PATCH] bin_package: install into base_prefix

2022-07-12 Thread Pascal Bach

From: Pascal Bach 

This makes the bin_package.bbclass work properly with the native class.


Signed-off-by: Pascal Bach 
---
 meta/classes/bin_package.bbclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/classes/bin_package.bbclass b/meta/classes/bin_package.bbclass
index c3aca20443..f0407e1329 100644
--- a/meta/classes/bin_package.bbclass
+++ b/meta/classes/bin_package.bbclass
@@ -30,8 +30,9 @@ bin_package_do_install () {
 bbfatal bin_package has nothing to install. Be sure the SRC_URI 
unpacks into S.
 fi
 cd ${S}
+install -d ${D}${base_prefix}
 tar --no-same-owner --exclude='./patches' --exclude='./.pc' -cpf - . \
-| tar --no-same-owner -xpf - -C ${D}
+| tar --no-same-owner -xpf - -C ${D}${base_prefix}
 }
 
 FILES:${PN} = "/"
-- 
2.37.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#167916): 
https://lists.openembedded.org/g/openembedded-core/message/167916
Mute This Topic: https://lists.openembedded.org/mt/92329425/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] cmake: 3.15.5 -> 3.16.1

2019-12-12 Thread Pascal Bach

Patches have been refreshed and all of meta-oe and oe-core was sucessfully 
built.

Signed-off-by: Pascal Bach 
---
 ...cmake-native_3.15.5.bb => cmake-native_3.16.1.bb} |  0
 meta/recipes-devtools/cmake/cmake.inc|  4 ++--
 ...rmineSystem-use-oe-environment-vars-to-load.patch |  2 +-
 .../0002-cmake-Prevent-the-detection-of-Qt5.patch| 12 ++--
 ...-support-OpenEmbedded-Qt4-tool-binary-names.patch |  4 ++--
 ...ilently-if-system-Qt-installation-is-broken.patch |  4 ++--
 .../cmake/{cmake_3.15.5.bb => cmake_3.16.1.bb}   |  0
 7 files changed, 13 insertions(+), 13 deletions(-)
 rename meta/recipes-devtools/cmake/{cmake-native_3.15.5.bb => 
cmake-native_3.16.1.bb} (100%)
 rename meta/recipes-devtools/cmake/{cmake_3.15.5.bb => cmake_3.16.1.bb} (100%)

diff --git a/meta/recipes-devtools/cmake/cmake-native_3.15.5.bb 
b/meta/recipes-devtools/cmake/cmake-native_3.16.1.bb
similarity index 100%
rename from meta/recipes-devtools/cmake/cmake-native_3.15.5.bb
rename to meta/recipes-devtools/cmake/cmake-native_3.16.1.bb
diff --git a/meta/recipes-devtools/cmake/cmake.inc 
b/meta/recipes-devtools/cmake/cmake.inc
index 24190dec02..9d14c14b54 100644
--- a/meta/recipes-devtools/cmake/cmake.inc
+++ b/meta/recipes-devtools/cmake/cmake.inc
@@ -22,7 +22,7 @@ SRC_URI = 
"https://cmake.org/files/v${CMAKE_MAJOR_VERSION}/cmake-${PV}.tar.gz \
file://0004-Fail-silently-if-system-Qt-installation-is-broken.patch 
\
 "
 
-SRC_URI[md5sum] = "5fe3ebca627b4c3dcc2f127fbcfbceba"
-SRC_URI[sha256sum] = 
"fbdd7cef15c0ced06bb13024bfda0ecc0dedbc6b8a5d368c75255243beb4"
+SRC_URI[md5sum] = "142cf11cd9a7c298cf875604cee96434"
+SRC_URI[sha256sum] = 
"a275b3168fa8626eca4465da7bb159ff07c8c6cb0fb7179be59e12cbdfa725fd"
 
 UPSTREAM_CHECK_REGEX = "cmake-(?P\d+(\.\d+)+)\.tar"
diff --git 
a/meta/recipes-devtools/cmake/cmake/0001-CMakeDetermineSystem-use-oe-environment-vars-to-load.patch
 
b/meta/recipes-devtools/cmake/cmake/0001-CMakeDetermineSystem-use-oe-environment-vars-to-load.patch
index 3720833d3e..e2a58d25e2 100644
--- 
a/meta/recipes-devtools/cmake/cmake/0001-CMakeDetermineSystem-use-oe-environment-vars-to-load.patch
+++ 
b/meta/recipes-devtools/cmake/cmake/0001-CMakeDetermineSystem-use-oe-environment-vars-to-load.patch
@@ -1,4 +1,4 @@
-From 1e67c3fe52c6c51c00cf1ebb0bfc30c7a5ef9fdb Mon Sep 17 00:00:00 2001
+From ab272d703ce77f323aa1285526559c9efbf85834 Mon Sep 17 00:00:00 2001
 From: Cody P Schafer 
 Date: Thu, 27 Apr 2017 11:35:05 -0400
 Subject: [PATCH] CMakeDetermineSystem: use oe environment vars to load default
diff --git 
a/meta/recipes-devtools/cmake/cmake/0002-cmake-Prevent-the-detection-of-Qt5.patch
 
b/meta/recipes-devtools/cmake/cmake/0002-cmake-Prevent-the-detection-of-Qt5.patch
index db229e63e2..61c8f27cd6 100644
--- 
a/meta/recipes-devtools/cmake/cmake/0002-cmake-Prevent-the-detection-of-Qt5.patch
+++ 
b/meta/recipes-devtools/cmake/cmake/0002-cmake-Prevent-the-detection-of-Qt5.patch
@@ -1,4 +1,4 @@
-From 5cb6c86696f842274043e7d406f84b3ead1c36e0 Mon Sep 17 00:00:00 2001
+From 5a86c7fa987bd407f228176df2abeffd015be9ea Mon Sep 17 00:00:00 2001
 From: Otavio Salvador 
 Date: Wed, 17 Jan 2018 10:02:14 -0200
 Subject: [PATCH] cmake: Prevent the detection of Qt5
@@ -38,10 +38,10 @@ index cb89d19..9e68981 100644
include_directories(${Qt5Widgets_INCLUDE_DIRS})
add_definitions(${Qt5Widgets_DEFINITONS})
 diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
-index e73b277..91b8b67 100644
+index 57fa7fc..d50c146 100644
 --- a/Tests/CMakeLists.txt
 +++ b/Tests/CMakeLists.txt
-@@ -1348,7 +1348,7 @@ ${CMake_SOURCE_DIR}/Utilities/Release/push.bash --dir 
dev -- '${CMake_BUILD_NIGH
+@@ -1329,7 +1329,7 @@ ${CMake_SOURCE_DIR}/Utilities/Release/push.bash --dir 
dev -- '${CMake_BUILD_NIGH
  set(CMake_TEST_Qt5 1)
endif()
if(CMake_TEST_Qt5)
@@ -96,11 +96,11 @@ index c08efc4..87e25d9 100644
  set(CMAKE_CXX_STANDARD 11)
  set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/output/bin)
 diff --git a/Tests/RunCMake/CMakeLists.txt b/Tests/RunCMake/CMakeLists.txt
-index 69f8162..f389523 100644
+index 6b2f117..1002005 100644
 --- a/Tests/RunCMake/CMakeLists.txt
 +++ b/Tests/RunCMake/CMakeLists.txt
-@@ -334,7 +334,7 @@ add_RunCMake_test(configure_file)
- add_RunCMake_test(CTestTimeoutAfterMatch)
+@@ -376,7 +376,7 @@ else()
+ endif()
  
  find_package(Qt4 QUIET)
 -find_package(Qt5Core QUIET)
diff --git 
a/meta/recipes-devtools/cmake/cmake/0003-cmake-support-OpenEmbedded-Qt4-tool-binary-names.patch
 
b/meta/recipes-devtools/cmake/cmake/0003-cmake-support-OpenEmbedded-Qt4-tool-binary-names.patch
index d7d87a5256..e30dc51e4a 100644
--- 
a/meta/recipes-devtools/cmake/cmake/0003-cmake-support-OpenEmbedded-Qt4-tool-binary-names.patch
+++ 
b/meta/recipes-devtools/cmake/cmake/0003-cmake-support-OpenEmbedded-Qt4-tool-binary-names.patch
@@ -1,4 +1,4 @@
-From b003857d3481105c473e2e75bad4e9e2c6e70004 Mon Sep 17 00:00:00 2001
+From e528861

[OE-core] [PATCH] cmake: 3.14.5 -> 3.15.2

2019-08-08 Thread Pascal Bach

The patches were refreshed with devtool.

I rebuilt all cmake recipes from poky and meta-oe without issue.

Signed-off-by: Pascal Bach 
---
 ...ake-native_3.14.5.bb => cmake-native_3.15.2.bb} |  0
 meta/recipes-devtools/cmake/cmake.inc  |  4 +--
 ...ineSystem-use-oe-environment-vars-to-load.patch | 13 -
 .../0002-cmake-Prevent-the-detection-of-Qt5.patch  | 33 +++---
 ...upport-OpenEmbedded-Qt4-tool-binary-names.patch | 11 +++-
 ...ently-if-system-Qt-installation-is-broken.patch | 11 +++-
 .../cmake/{cmake_3.14.5.bb => cmake_3.15.2.bb} |  0
 7 files changed, 31 insertions(+), 41 deletions(-)
 rename meta/recipes-devtools/cmake/{cmake-native_3.14.5.bb => 
cmake-native_3.15.2.bb} (100%)
 rename meta/recipes-devtools/cmake/{cmake_3.14.5.bb => cmake_3.15.2.bb} (100%)

diff --git a/meta/recipes-devtools/cmake/cmake-native_3.14.5.bb 
b/meta/recipes-devtools/cmake/cmake-native_3.15.2.bb
similarity index 100%
rename from meta/recipes-devtools/cmake/cmake-native_3.14.5.bb
rename to meta/recipes-devtools/cmake/cmake-native_3.15.2.bb
diff --git a/meta/recipes-devtools/cmake/cmake.inc 
b/meta/recipes-devtools/cmake/cmake.inc
index da3aadcc0a..4cbe26ed60 100644
--- a/meta/recipes-devtools/cmake/cmake.inc
+++ b/meta/recipes-devtools/cmake/cmake.inc
@@ -18,7 +18,7 @@ SRC_URI = 
"https://cmake.org/files/v${CMAKE_MAJOR_VERSION}/cmake-${PV}.tar.gz \
file://0004-Fail-silently-if-system-Qt-installation-is-broken.patch 
\
 "
 
-SRC_URI[md5sum] = "a8cbfc3510b95ea686b4059d8b1f765c"
-SRC_URI[sha256sum] = 
"505ae49ebe3c63c595fa5f814975d8b72848447ee13b6613b0f8b96ebda18c06"
+SRC_URI[md5sum] = "9ecf167edadb87e2d75cc89fded7aadb"
+SRC_URI[sha256sum] = 
"539088cb29a68e6d6a8fba5c00951e5e5b1a92c68fa38a83e1ed2f355933f768"
 
 UPSTREAM_CHECK_REGEX = "cmake-(?P\d+(\.\d+)+)\.tar"
diff --git 
a/meta/recipes-devtools/cmake/cmake/0001-CMakeDetermineSystem-use-oe-environment-vars-to-load.patch
 
b/meta/recipes-devtools/cmake/cmake/0001-CMakeDetermineSystem-use-oe-environment-vars-to-load.patch
index cdeea647fe..3720833d3e 100644
--- 
a/meta/recipes-devtools/cmake/cmake/0001-CMakeDetermineSystem-use-oe-environment-vars-to-load.patch
+++ 
b/meta/recipes-devtools/cmake/cmake/0001-CMakeDetermineSystem-use-oe-environment-vars-to-load.patch
@@ -1,9 +1,8 @@
-From 71085723f8028b3e1c4029fc1abe1243ac49ffc6 Mon Sep 17 00:00:00 2001
+From 1e67c3fe52c6c51c00cf1ebb0bfc30c7a5ef9fdb Mon Sep 17 00:00:00 2001
 From: Cody P Schafer 
 Date: Thu, 27 Apr 2017 11:35:05 -0400
-Subject: [PATCH 1/5] CMakeDetermineSystem: use oe environment vars to load
- default toolchain file in sdk
-Organization: O.S. Systems Software LTDA.
+Subject: [PATCH] CMakeDetermineSystem: use oe environment vars to load default
+ toolchain file in sdk
 
 Passing the toolchain by:
 
@@ -20,12 +19,13 @@ because '-D' options are cache entries themselves.
 Upstream-Status: Inappropriate [oe-core specific]
 Signed-off-by: Cody P Schafer 
 Signed-off-by: Otavio Salvador 
+
 ---
  Modules/CMakeDetermineSystem.cmake | 7 +++
  1 file changed, 7 insertions(+)
 
 diff --git a/Modules/CMakeDetermineSystem.cmake 
b/Modules/CMakeDetermineSystem.cmake
-index 600d5580e..32d7f1945 100644
+index dc208c6..e0af4ca 100644
 --- a/Modules/CMakeDetermineSystem.cmake
 +++ b/Modules/CMakeDetermineSystem.cmake
 @@ -81,6 +81,13 @@ else()
@@ -42,6 +42,3 @@ index 600d5580e..32d7f1945 100644
  # if a toolchain file is used, the user wants to cross compile.
  # in this case read the toolchain file and keep the CMAKE_HOST_SYSTEM_*
  # variables around so they can be used in CMakeLists.txt.
--- 
-2.18.0
-
diff --git 
a/meta/recipes-devtools/cmake/cmake/0002-cmake-Prevent-the-detection-of-Qt5.patch
 
b/meta/recipes-devtools/cmake/cmake/0002-cmake-Prevent-the-detection-of-Qt5.patch
index 8d2dc10ce5..db229e63e2 100644
--- 
a/meta/recipes-devtools/cmake/cmake/0002-cmake-Prevent-the-detection-of-Qt5.patch
+++ 
b/meta/recipes-devtools/cmake/cmake/0002-cmake-Prevent-the-detection-of-Qt5.patch
@@ -1,7 +1,8 @@
-From b4b6e9b1be33213ede3f612e87840c0045824d9e Mon Sep 17 00:00:00 2001
+From 5cb6c86696f842274043e7d406f84b3ead1c36e0 Mon Sep 17 00:00:00 2001
 From: Otavio Salvador 
 Date: Wed, 17 Jan 2018 10:02:14 -0200
-Subject: [PATCH 2/5] cmake: Prevent the detection of Qt5
+Subject: [PATCH] cmake: Prevent the detection of Qt5
+
 Organization: O.S. Systems Software LTDA.
 
 CMake doesn't have dependency on qt4/qt5, so these tests usually fail
@@ -12,6 +13,7 @@ while running the test in cmake)
 Upstream-Status: Inappropriate [configuration]
 
 Signed-off-by: Otavio Salvador 
+
 ---
  Source/QtDialog/CMakeLists.txt | 2 +-
  Tests/CMakeLists.txt   | 2 +-
@@ -23,12 +25,12 @@ Signed-off-by: Otavio Salvador 
  7 files changed, 8 insertions(+), 9 deletions(-)
 
 diff --git a/Source/QtDialog/CMakeLists.txt b/Source/QtDialog/CMakeLists.txt
-index 9ce0323844.

[OE-core] [PATCH] cmake: 3.14.5 -> 3.15.1

2019-08-08 Thread Pascal Bach

The patches were refreshed with devtool.

I rebuilt all cmake recipes from poky and meta-oe without issue.

Signed-off-by: Pascal Bach 
---
 ...ake-native_3.14.5.bb => cmake-native_3.15.1.bb} |  0
 meta/recipes-devtools/cmake/cmake.inc  |  4 +--
 ...ineSystem-use-oe-environment-vars-to-load.patch | 13 -
 .../0002-cmake-Prevent-the-detection-of-Qt5.patch  | 33 +++---
 ...upport-OpenEmbedded-Qt4-tool-binary-names.patch | 11 +++-
 ...ently-if-system-Qt-installation-is-broken.patch | 11 +++-
 .../cmake/{cmake_3.14.5.bb => cmake_3.15.1.bb} |  0
 7 files changed, 31 insertions(+), 41 deletions(-)
 rename meta/recipes-devtools/cmake/{cmake-native_3.14.5.bb => 
cmake-native_3.15.1.bb} (100%)
 rename meta/recipes-devtools/cmake/{cmake_3.14.5.bb => cmake_3.15.1.bb} (100%)

diff --git a/meta/recipes-devtools/cmake/cmake-native_3.14.5.bb 
b/meta/recipes-devtools/cmake/cmake-native_3.15.1.bb
similarity index 100%
rename from meta/recipes-devtools/cmake/cmake-native_3.14.5.bb
rename to meta/recipes-devtools/cmake/cmake-native_3.15.1.bb
diff --git a/meta/recipes-devtools/cmake/cmake.inc 
b/meta/recipes-devtools/cmake/cmake.inc
index da3aadcc0a..d818a0116f 100644
--- a/meta/recipes-devtools/cmake/cmake.inc
+++ b/meta/recipes-devtools/cmake/cmake.inc
@@ -18,7 +18,7 @@ SRC_URI = 
"https://cmake.org/files/v${CMAKE_MAJOR_VERSION}/cmake-${PV}.tar.gz \
file://0004-Fail-silently-if-system-Qt-installation-is-broken.patch 
\
 "
 
-SRC_URI[md5sum] = "a8cbfc3510b95ea686b4059d8b1f765c"
-SRC_URI[sha256sum] = 
"505ae49ebe3c63c595fa5f814975d8b72848447ee13b6613b0f8b96ebda18c06"
+SRC_URI[md5sum] = "fc6ffc06e6c356e8ab55fd353d7c260b"
+SRC_URI[sha256sum] = 
"18dec548d8f8b04d53c60f9cedcebaa6762f8425339d1e2c889c383d3ccdd7f7"
 
 UPSTREAM_CHECK_REGEX = "cmake-(?P\d+(\.\d+)+)\.tar"
diff --git 
a/meta/recipes-devtools/cmake/cmake/0001-CMakeDetermineSystem-use-oe-environment-vars-to-load.patch
 
b/meta/recipes-devtools/cmake/cmake/0001-CMakeDetermineSystem-use-oe-environment-vars-to-load.patch
index cdeea647fe..3720833d3e 100644
--- 
a/meta/recipes-devtools/cmake/cmake/0001-CMakeDetermineSystem-use-oe-environment-vars-to-load.patch
+++ 
b/meta/recipes-devtools/cmake/cmake/0001-CMakeDetermineSystem-use-oe-environment-vars-to-load.patch
@@ -1,9 +1,8 @@
-From 71085723f8028b3e1c4029fc1abe1243ac49ffc6 Mon Sep 17 00:00:00 2001
+From 1e67c3fe52c6c51c00cf1ebb0bfc30c7a5ef9fdb Mon Sep 17 00:00:00 2001
 From: Cody P Schafer 
 Date: Thu, 27 Apr 2017 11:35:05 -0400
-Subject: [PATCH 1/5] CMakeDetermineSystem: use oe environment vars to load
- default toolchain file in sdk
-Organization: O.S. Systems Software LTDA.
+Subject: [PATCH] CMakeDetermineSystem: use oe environment vars to load default
+ toolchain file in sdk
 
 Passing the toolchain by:
 
@@ -20,12 +19,13 @@ because '-D' options are cache entries themselves.
 Upstream-Status: Inappropriate [oe-core specific]
 Signed-off-by: Cody P Schafer 
 Signed-off-by: Otavio Salvador 
+
 ---
  Modules/CMakeDetermineSystem.cmake | 7 +++
  1 file changed, 7 insertions(+)
 
 diff --git a/Modules/CMakeDetermineSystem.cmake 
b/Modules/CMakeDetermineSystem.cmake
-index 600d5580e..32d7f1945 100644
+index dc208c6..e0af4ca 100644
 --- a/Modules/CMakeDetermineSystem.cmake
 +++ b/Modules/CMakeDetermineSystem.cmake
 @@ -81,6 +81,13 @@ else()
@@ -42,6 +42,3 @@ index 600d5580e..32d7f1945 100644
  # if a toolchain file is used, the user wants to cross compile.
  # in this case read the toolchain file and keep the CMAKE_HOST_SYSTEM_*
  # variables around so they can be used in CMakeLists.txt.
--- 
-2.18.0
-
diff --git 
a/meta/recipes-devtools/cmake/cmake/0002-cmake-Prevent-the-detection-of-Qt5.patch
 
b/meta/recipes-devtools/cmake/cmake/0002-cmake-Prevent-the-detection-of-Qt5.patch
index 8d2dc10ce5..db229e63e2 100644
--- 
a/meta/recipes-devtools/cmake/cmake/0002-cmake-Prevent-the-detection-of-Qt5.patch
+++ 
b/meta/recipes-devtools/cmake/cmake/0002-cmake-Prevent-the-detection-of-Qt5.patch
@@ -1,7 +1,8 @@
-From b4b6e9b1be33213ede3f612e87840c0045824d9e Mon Sep 17 00:00:00 2001
+From 5cb6c86696f842274043e7d406f84b3ead1c36e0 Mon Sep 17 00:00:00 2001
 From: Otavio Salvador 
 Date: Wed, 17 Jan 2018 10:02:14 -0200
-Subject: [PATCH 2/5] cmake: Prevent the detection of Qt5
+Subject: [PATCH] cmake: Prevent the detection of Qt5
+
 Organization: O.S. Systems Software LTDA.
 
 CMake doesn't have dependency on qt4/qt5, so these tests usually fail
@@ -12,6 +13,7 @@ while running the test in cmake)
 Upstream-Status: Inappropriate [configuration]
 
 Signed-off-by: Otavio Salvador 
+
 ---
  Source/QtDialog/CMakeLists.txt | 2 +-
  Tests/CMakeLists.txt   | 2 +-
@@ -23,12 +25,12 @@ Signed-off-by: Otavio Salvador 
  7 files changed, 8 insertions(+), 9 deletions(-)
 
 diff --git a/Source/QtDialog/CMakeLists.txt b/Source/QtDialog/CMakeLists.txt
-index 9ce0323844.

[OE-core] [PATCH] cmake: 3.14.1 -> 3.14.5

2019-06-24 Thread Pascal Bach

Fixes:

- A bug with Visual Studio 2019
- An issue with target_link_libraries and PRIVATE
- An issue with include_directories

Signed-off-by: Pascal Bach 
---
 .../cmake/{cmake-native_3.14.1.bb => cmake-native_3.14.5.bb}  | 0
 meta/recipes-devtools/cmake/cmake.inc | 4 ++--
 meta/recipes-devtools/cmake/{cmake_3.14.1.bb => cmake_3.14.5.bb}  | 0
 3 files changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-devtools/cmake/{cmake-native_3.14.1.bb => 
cmake-native_3.14.5.bb} (100%)
 rename meta/recipes-devtools/cmake/{cmake_3.14.1.bb => cmake_3.14.5.bb} (100%)

diff --git a/meta/recipes-devtools/cmake/cmake-native_3.14.1.bb 
b/meta/recipes-devtools/cmake/cmake-native_3.14.5.bb
similarity index 100%
rename from meta/recipes-devtools/cmake/cmake-native_3.14.1.bb
rename to meta/recipes-devtools/cmake/cmake-native_3.14.5.bb
diff --git a/meta/recipes-devtools/cmake/cmake.inc 
b/meta/recipes-devtools/cmake/cmake.inc
index 5b0bce6808..da3aadcc0a 100644
--- a/meta/recipes-devtools/cmake/cmake.inc
+++ b/meta/recipes-devtools/cmake/cmake.inc
@@ -18,7 +18,7 @@ SRC_URI = 
"https://cmake.org/files/v${CMAKE_MAJOR_VERSION}/cmake-${PV}.tar.gz \
file://0004-Fail-silently-if-system-Qt-installation-is-broken.patch 
\
 "
 
-SRC_URI[md5sum] = "7efe5394e85c3292ad020b8b70e55669"
-SRC_URI[sha256sum] = 
"7321be640406338fc12590609c42b0fae7ea12980855c1be363d25dcd76bb25f"
+SRC_URI[md5sum] = "a8cbfc3510b95ea686b4059d8b1f765c"
+SRC_URI[sha256sum] = 
"505ae49ebe3c63c595fa5f814975d8b72848447ee13b6613b0f8b96ebda18c06"
 
 UPSTREAM_CHECK_REGEX = "cmake-(?P\d+(\.\d+)+)\.tar"
diff --git a/meta/recipes-devtools/cmake/cmake_3.14.1.bb 
b/meta/recipes-devtools/cmake/cmake_3.14.5.bb
similarity index 100%
rename from meta/recipes-devtools/cmake/cmake_3.14.1.bb
rename to meta/recipes-devtools/cmake/cmake_3.14.5.bb
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/1] insane.bbclass: Add QA package check for mixed bins and libs

2019-04-30 Thread Pascal Bach

On 30.04.2019 12:26, Richard Purdie wrote:
>
> Merging a QA test which causes hundreds of warnings isn't really going
> to help unless we have a strategy for fixing it.
I agree merging this only makes sense if we commit to fixing the issue.

In my opinion the strategy for fixing it would be to always split packages that 
consists of both binaries and libs into two.
This is already done for many like sqlite3 (sqlite3 vs libsqlite3). This check 
would just ensure that this rule is always followed.

This would make it easier to separate the two. Let's take the example that you 
have two applications A (32bit) and B (64bit) both using sqlite3.
In this case the two would link to lib32-libsqlite3 and libsqlite3.

If the package contained both the library and the binary you would end up with 
both libs but one of the two binaries (not sure this is deterministic).
If the packages are only lib and only binary then you would explicitly need to 
select either the 32bit or the 64bit variant.

In practice this would not only benefit the multilib case. It would also help 
with avoiding unnecessarily installed binaries just because somebody is using a 
library
bundled in the same package.

>
> As I understand it, if you install python 32bit and 64 bit, you should
> get the libraries from both but only the binaries from the one that
> wins. That should mean anything linking to the lib should work?
>
> What am I missing? Is something not working like that? Is this with the
> rpm or opkg implementation? (they're very different)
I think the issue with scripting languages (especially python) is different 
from the general case above (sqlite3).
And maybe the insane check in the current form is not covering all cases.

Pascal
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] cmake: 3.14.0 -> 3.14.1

2019-04-01 Thread Pascal Bach

The FindFontconfig module added by 3.14.0 accidentally used uppercase
FONTCONFIG_* variable names that do not match our conventions.
3.14.1 revises the module to use Fontconfig_* variable names.
This is incompatible with 3.14.0 but since the module is new in the
3.14 series usage should not yet be widespread.

Signed-off-by: Pascal Bach 
---
 .../cmake/{cmake-native_3.14.0.bb => cmake-native_3.14.1.bb}  | 0
 meta/recipes-devtools/cmake/cmake.inc | 4 ++--
 meta/recipes-devtools/cmake/{cmake_3.14.0.bb => cmake_3.14.1.bb}  | 0
 3 files changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-devtools/cmake/{cmake-native_3.14.0.bb => 
cmake-native_3.14.1.bb} (100%)
 rename meta/recipes-devtools/cmake/{cmake_3.14.0.bb => cmake_3.14.1.bb} (100%)

diff --git a/meta/recipes-devtools/cmake/cmake-native_3.14.0.bb 
b/meta/recipes-devtools/cmake/cmake-native_3.14.1.bb
similarity index 100%
rename from meta/recipes-devtools/cmake/cmake-native_3.14.0.bb
rename to meta/recipes-devtools/cmake/cmake-native_3.14.1.bb
diff --git a/meta/recipes-devtools/cmake/cmake.inc 
b/meta/recipes-devtools/cmake/cmake.inc
index f787851e2d..5b0bce6808 100644
--- a/meta/recipes-devtools/cmake/cmake.inc
+++ b/meta/recipes-devtools/cmake/cmake.inc
@@ -18,7 +18,7 @@ SRC_URI = 
"https://cmake.org/files/v${CMAKE_MAJOR_VERSION}/cmake-${PV}.tar.gz \
file://0004-Fail-silently-if-system-Qt-installation-is-broken.patch 
\
 "
 
-SRC_URI[md5sum] = "7504e4f3e05b59e083f2127e07059d5d"
-SRC_URI[sha256sum] = 
"aa76ba67b3c2af1946701f847073f4652af5cbd9f141f221c97af99127e75502"
+SRC_URI[md5sum] = "7efe5394e85c3292ad020b8b70e55669"
+SRC_URI[sha256sum] = 
"7321be640406338fc12590609c42b0fae7ea12980855c1be363d25dcd76bb25f"
 
 UPSTREAM_CHECK_REGEX = "cmake-(?P\d+(\.\d+)+)\.tar"
diff --git a/meta/recipes-devtools/cmake/cmake_3.14.0.bb 
b/meta/recipes-devtools/cmake/cmake_3.14.1.bb
similarity index 100%
rename from meta/recipes-devtools/cmake/cmake_3.14.0.bb
rename to meta/recipes-devtools/cmake/cmake_3.14.1.bb
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] cmake: 3.13.4 -> 3.14.0

2019-03-27 Thread Pascal Bach

The copyright date changed in the license file, thus the hash change.

CMake 3.14 fixes some issues with implicit include path that lead to
errors with gcc not finding "stdlib.h" etc in include_next.

Signed-off-by: Pascal Bach 
---
 ...ake-native_3.13.4.bb => cmake-native_3.14.0.bb} |  0
 meta/recipes-devtools/cmake/cmake.inc  |  6 ++--
 ...ineSystem-use-oe-environment-vars-to-load.patch |  2 +-
 .../0002-cmake-Prevent-the-detection-of-Qt5.patch  | 39 +++---
 ...upport-OpenEmbedded-Qt4-tool-binary-names.patch |  4 +--
 ...ently-if-system-Qt-installation-is-broken.patch |  2 +-
 .../cmake/{cmake_3.13.4.bb => cmake_3.14.0.bb} |  0
 7 files changed, 27 insertions(+), 26 deletions(-)
 rename meta/recipes-devtools/cmake/{cmake-native_3.13.4.bb => 
cmake-native_3.14.0.bb} (100%)
 rename meta/recipes-devtools/cmake/{cmake_3.13.4.bb => cmake_3.14.0.bb} (100%)

diff --git a/meta/recipes-devtools/cmake/cmake-native_3.13.4.bb 
b/meta/recipes-devtools/cmake/cmake-native_3.14.0.bb
similarity index 100%
rename from meta/recipes-devtools/cmake/cmake-native_3.13.4.bb
rename to meta/recipes-devtools/cmake/cmake-native_3.14.0.bb
diff --git a/meta/recipes-devtools/cmake/cmake.inc 
b/meta/recipes-devtools/cmake/cmake.inc
index 68a71e9139..f787851e2d 100644
--- a/meta/recipes-devtools/cmake/cmake.inc
+++ b/meta/recipes-devtools/cmake/cmake.inc
@@ -6,7 +6,7 @@ HOMEPAGE = "http://www.cmake.org/;
 BUGTRACKER = "http://public.kitware.com/Bug/my_view_page.php;
 SECTION = "console/utils"
 LICENSE = "BSD"
-LIC_FILES_CHKSUM = "file://Copyright.txt;md5=f61f5f859bc5ddba2b050eb10335e013 \
+LIC_FILES_CHKSUM = "file://Copyright.txt;md5=622747147b46f22e1953876a7cba3323 \
 
file://Source/cmake.h;md5=4494dee184212fc89c469c3acd555a14;beginline=1;endline=3
 \
 "
 
@@ -18,7 +18,7 @@ SRC_URI = 
"https://cmake.org/files/v${CMAKE_MAJOR_VERSION}/cmake-${PV}.tar.gz \
file://0004-Fail-silently-if-system-Qt-installation-is-broken.patch 
\
 "
 
-SRC_URI[md5sum] = "b5a544ffc73f6922a6cf371fcb6bae22"
-SRC_URI[sha256sum] = 
"fdd928fee35f472920071d1c7f1a6a2b72c9b25e04f7a37b409349aef3f20e9b"
+SRC_URI[md5sum] = "7504e4f3e05b59e083f2127e07059d5d"
+SRC_URI[sha256sum] = 
"aa76ba67b3c2af1946701f847073f4652af5cbd9f141f221c97af99127e75502"
 
 UPSTREAM_CHECK_REGEX = "cmake-(?P\d+(\.\d+)+)\.tar"
diff --git 
a/meta/recipes-devtools/cmake/cmake/0001-CMakeDetermineSystem-use-oe-environment-vars-to-load.patch
 
b/meta/recipes-devtools/cmake/cmake/0001-CMakeDetermineSystem-use-oe-environment-vars-to-load.patch
index f690720870..cdeea647fe 100644
--- 
a/meta/recipes-devtools/cmake/cmake/0001-CMakeDetermineSystem-use-oe-environment-vars-to-load.patch
+++ 
b/meta/recipes-devtools/cmake/cmake/0001-CMakeDetermineSystem-use-oe-environment-vars-to-load.patch
@@ -28,7 +28,7 @@ diff --git a/Modules/CMakeDetermineSystem.cmake 
b/Modules/CMakeDetermineSystem.c
 index 600d5580e..32d7f1945 100644
 --- a/Modules/CMakeDetermineSystem.cmake
 +++ b/Modules/CMakeDetermineSystem.cmake
-@@ -82,6 +82,13 @@ else()
+@@ -81,6 +81,13 @@ else()
endif()
  endif()
  
diff --git 
a/meta/recipes-devtools/cmake/cmake/0002-cmake-Prevent-the-detection-of-Qt5.patch
 
b/meta/recipes-devtools/cmake/cmake/0002-cmake-Prevent-the-detection-of-Qt5.patch
index 3bea6935b7..8d2dc10ce5 100644
--- 
a/meta/recipes-devtools/cmake/cmake/0002-cmake-Prevent-the-detection-of-Qt5.patch
+++ 
b/meta/recipes-devtools/cmake/cmake/0002-cmake-Prevent-the-detection-of-Qt5.patch
@@ -1,4 +1,4 @@
-From 7a1f4e724f9c68498f401244c2938e784a2e6fbd Mon Sep 17 00:00:00 2001
+From b4b6e9b1be33213ede3f612e87840c0045824d9e Mon Sep 17 00:00:00 2001
 From: Otavio Salvador 
 Date: Wed, 17 Jan 2018 10:02:14 -0200
 Subject: [PATCH 2/5] cmake: Prevent the detection of Qt5
@@ -16,14 +16,14 @@ Signed-off-by: Otavio Salvador 
  Source/QtDialog/CMakeLists.txt | 2 +-
  Tests/CMakeLists.txt   | 2 +-
  Tests/Qt4And5Automoc/CMakeLists.txt| 4 ++--
- Tests/QtAutogen/AutogenTest.cmake  | 2 +-
+ Tests/QtAutogen/AutogenGuiTest.cmake   | 3 +--
  Tests/QtAutogen/MacOsFW/CMakeLists.txt | 2 +-
  Tests/RunCMake/CMakeLists.txt  | 2 +-
  Tests/RunCMake/IncompatibleQt/IncompatibleQt.cmake | 2 +-
- 7 files changed, 8 insertions(+), 8 deletions(-)
+ 7 files changed, 8 insertions(+), 9 deletions(-)
 
 diff --git a/Source/QtDialog/CMakeLists.txt b/Source/QtDialog/CMakeLists.txt
-index 330b74729..e7709dee6 100644
+index 9ce0323844..06c86d63eb 100644
 --- a/Source/QtDialog/CMakeLists.txt
 +++ b/Source/QtDialog/CMakeLists.txt
 @@ -6,7 +6,7 @@ if(POLICY CMP0020)
@@ -36,10 +36,10 @@ index 330b74729..e7709dee6 100644
include_directories(${Qt5Widgets_INCLUDE_DIRS})
add_definitions(${Qt5Widgets_DEFINITONS})
 diff --git a/Tests/CMakeLists

[OE-core] [PATCH] nfs-utils: build tools with target compiler

2019-02-14 Thread Pascal Bach

Some tools were built with CC_FOR_BUILD which points to the target
compiler. The current patch avoided issues by deleting some of the
binaries during install.

This patch replaces the CC_FOR_BUILD with CC so the tools are built with
the target compiler. This means the binaries no longer need to be
deleted.

I stumbled upon this by trying to globally add "--ffile-prefix-map", which
is not supported by my host GCC, to get rid of some "buildpaths" QA Warnings.

Cc: Robert Yang 
Signed-off-by: Pascal Bach 
---
 .../0001-Don-t-build-tools-with-CC_FOR_BUILD.patch | 40 +
 ...-Do-not-pass-CFLAGS-to-gcc-while-building.patch | 42 --
 .../nfs-utils/nfs-utils_2.3.3.bb   |  7 +---
 3 files changed, 41 insertions(+), 48 deletions(-)
 create mode 100644 
meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Don-t-build-tools-with-CC_FOR_BUILD.patch
 delete mode 100644 
meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-utils-Do-not-pass-CFLAGS-to-gcc-while-building.patch

diff --git 
a/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Don-t-build-tools-with-CC_FOR_BUILD.patch
 
b/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Don-t-build-tools-with-CC_FOR_BUILD.patch
new file mode 100644
index 00..23bc3eaf72
--- /dev/null
+++ 
b/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Don-t-build-tools-with-CC_FOR_BUILD.patch
@@ -0,0 +1,40 @@
+From 79019d976584c598f8d0a9d8de43c989946f974b Mon Sep 17 00:00:00 2001
+From: Pascal Bach 
+Date: Wed, 13 Feb 2019 09:28:07 +0100
+Subject: [PATCH] Don't build tools with CC_FOR_BUILD
+
+The tools are intended for the target not for the host.
+
+Upstream-Status: Pending
+
+Signed-off-by: Pascal Bach 
+---
+ tools/locktest/Makefile.am | 1 -
+ tools/rpcgen/Makefile.am   | 1 -
+ 2 files changed, 2 deletions(-)
+
+diff --git a/tools/locktest/Makefile.am b/tools/locktest/Makefile.am
+index 3156815..87d0bac 100644
+--- a/tools/locktest/Makefile.am
 b/tools/locktest/Makefile.am
+@@ -1,6 +1,5 @@
+ ## Process this file with automake to produce Makefile.in
+ 
+-CC=$(CC_FOR_BUILD)
+ LIBTOOL = @LIBTOOL@ --tag=CC
+ 
+ noinst_PROGRAMS = testlk
+diff --git a/tools/rpcgen/Makefile.am b/tools/rpcgen/Makefile.am
+index 8a9ec89..3e092c9 100644
+--- a/tools/rpcgen/Makefile.am
 b/tools/rpcgen/Makefile.am
+@@ -1,6 +1,5 @@
+ ## Process this file with automake to produce Makefile.in
+ 
+-CC=$(CC_FOR_BUILD)
+ LIBTOOL = @LIBTOOL@ --tag=CC
+ 
+ noinst_PROGRAMS = rpcgen
+-- 
+2.11.0
+
diff --git 
a/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-utils-Do-not-pass-CFLAGS-to-gcc-while-building.patch
 
b/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-utils-Do-not-pass-CFLAGS-to-gcc-while-building.patch
deleted file mode 100644
index 993f1e5ea5..00
--- 
a/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-utils-Do-not-pass-CFLAGS-to-gcc-while-building.patch
+++ /dev/null
@@ -1,42 +0,0 @@
-nfs-utils: Do not pass CFLAGS to gcc while building
-
-Do not pass CFLAGS/LDFLAGS to gcc while building, The needed flags has
-been passed by xxx_CFLAGS=$(CFLAGS_FOR_BUILD).
-
-Upstream-Status: Pending
-
-Signed-off-by: Chong Lu 

- tools/locktest/Makefile.am |2 ++
- tools/rpcgen/Makefile.am   |2 ++
- 2 files changed, 4 insertions(+)
-
-diff --git a/tools/locktest/Makefile.am b/tools/locktest/Makefile.am
-index 3156815..1729fd1 100644
 a/tools/locktest/Makefile.am
-+++ b/tools/locktest/Makefile.am
-@@ -1,6 +1,8 @@
- ## Process this file with automake to produce Makefile.in
- 
- CC=$(CC_FOR_BUILD)
-+CFLAGS=
-+LDFLAGS=
- LIBTOOL = @LIBTOOL@ --tag=CC
- 
- noinst_PROGRAMS = testlk
-diff --git a/tools/rpcgen/Makefile.am b/tools/rpcgen/Makefile.am
-index 8a9ec89..8bacdaa 100644
 a/tools/rpcgen/Makefile.am
-+++ b/tools/rpcgen/Makefile.am
-@@ -1,6 +1,8 @@
- ## Process this file with automake to produce Makefile.in
- 
- CC=$(CC_FOR_BUILD)
-+CFLAGS=
-+LDFLAGS=
- LIBTOOL = @LIBTOOL@ --tag=CC
- 
- noinst_PROGRAMS = rpcgen
--- 
-1.7.9.5
-
diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils_2.3.3.bb 
b/meta/recipes-connectivity/nfs-utils/nfs-utils_2.3.3.bb
index 84530f698b..ac4437b925 100644
--- a/meta/recipes-connectivity/nfs-utils/nfs-utils_2.3.3.bb
+++ b/meta/recipes-connectivity/nfs-utils/nfs-utils_2.3.3.bb
@@ -26,7 +26,6 @@ SRC_URI = 
"${KERNELORG_MIRROR}/linux/utils/nfs-utils/${PV}/nfs-utils-${PV}.tar.x
file://nfs-mountd.service \
file://nfs-statd.service \
file://proc-fs-nfsd.mount \
-   file://nfs-utils-Do-not-pass-CFLAGS-to-gcc-while-building.patch \
file://nfs-utils-debianize-start-statd.patch \
file://bugfix-adjust-statd-service-name.patch \
file://nfs-utils-musl-limits.patch \
@@ -35,6 +34,7 @@ SRC_URI = 
"${KERNELORG_MIRROR}/linux/utils/nfs-utils/${PV}/nfs-utils-${PV}.tar.x
file://clang-format-string.patch \
file://0001-Makefile.am-update-the-path-of-libnfs.a.patch \
file://

[OE-core] [PATCHv2] cmake: update to 3.13.4

2019-02-12 Thread Pascal Bach

All patches have been rebased on top of the 3.13.4 release.

I successfully built all CMake recipes in oe-core and meta-oe.


Signed-off-by: Pascal Bach 
Cc: Otavio Salvador 
---
 .../cmake/{cmake-native_3.12.2.bb => cmake-native_3.13.4.bb}  | 0
 meta/recipes-devtools/cmake/cmake.inc | 4 ++--
 .../cmake/cmake/0002-cmake-Prevent-the-detection-of-Qt5.patch | 8 
 ...005-Disable-use-of-ext2fs-ext2_fs.h-by-cmake-s-internal-.patch | 2 +-
 meta/recipes-devtools/cmake/{cmake_3.12.2.bb => cmake_3.13.4.bb}  | 0
 5 files changed, 7 insertions(+), 7 deletions(-)
 rename meta/recipes-devtools/cmake/{cmake-native_3.12.2.bb => 
cmake-native_3.13.4.bb} (100%)
 rename meta/recipes-devtools/cmake/{cmake_3.12.2.bb => cmake_3.13.4.bb} (100%)

diff --git a/meta/recipes-devtools/cmake/cmake-native_3.12.2.bb 
b/meta/recipes-devtools/cmake/cmake-native_3.13.4.bb
similarity index 100%
rename from meta/recipes-devtools/cmake/cmake-native_3.12.2.bb
rename to meta/recipes-devtools/cmake/cmake-native_3.13.4.bb
diff --git a/meta/recipes-devtools/cmake/cmake.inc 
b/meta/recipes-devtools/cmake/cmake.inc
index 09e28b73dd..68a71e9139 100644
--- a/meta/recipes-devtools/cmake/cmake.inc
+++ b/meta/recipes-devtools/cmake/cmake.inc
@@ -18,7 +18,7 @@ SRC_URI = 
"https://cmake.org/files/v${CMAKE_MAJOR_VERSION}/cmake-${PV}.tar.gz \
file://0004-Fail-silently-if-system-Qt-installation-is-broken.patch 
\
 "
 
-SRC_URI[md5sum] = "6e7c550cfa1c2e216b35903dc70d80af"
-SRC_URI[sha256sum] = 
"0f97485799e51a7070cc11494f3e02349b0fc3a24cc12b082e737bf67a0581a4"
+SRC_URI[md5sum] = "b5a544ffc73f6922a6cf371fcb6bae22"
+SRC_URI[sha256sum] = 
"fdd928fee35f472920071d1c7f1a6a2b72c9b25e04f7a37b409349aef3f20e9b"
 
 UPSTREAM_CHECK_REGEX = "cmake-(?P\d+(\.\d+)+)\.tar"
diff --git 
a/meta/recipes-devtools/cmake/cmake/0002-cmake-Prevent-the-detection-of-Qt5.patch
 
b/meta/recipes-devtools/cmake/cmake/0002-cmake-Prevent-the-detection-of-Qt5.patch
index 6f788ada00..3bea6935b7 100644
--- 
a/meta/recipes-devtools/cmake/cmake/0002-cmake-Prevent-the-detection-of-Qt5.patch
+++ 
b/meta/recipes-devtools/cmake/cmake/0002-cmake-Prevent-the-detection-of-Qt5.patch
@@ -39,7 +39,7 @@ diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
 index b8b724ed8..63f6bb6d2 100644
 --- a/Tests/CMakeLists.txt
 +++ b/Tests/CMakeLists.txt
-@@ -1322,7 +1322,7 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P 
${CMake_SOURCE_DIR}/Utilities/Release
+@@ -1297,7 +1297,7 @@ ${CMake_BINARY_DIR}/bin/cmake -DDIR=dev -P 
${CMake_SOURCE_DIR}/Utilities/Release
  set(CMake_TEST_Qt5 1)
endif()
if(CMake_TEST_Qt5)
@@ -70,10 +70,10 @@ diff --git a/Tests/QtAutogen/AutogenTest.cmake 
b/Tests/QtAutogen/AutogenTest.cma
 index 8c0a14fca..e9923b21a 100644
 --- a/Tests/QtAutogen/AutogenTest.cmake
 +++ b/Tests/QtAutogen/AutogenTest.cmake
-@@ -22,7 +22,7 @@ if (QT_TEST_VERSION STREQUAL 4)
+@@ -22,7 +22,7 @@ if (QT_TEST_VERSION EQUAL 4)
endmacro()
  
- elseif(QT_TEST_VERSION STREQUAL 5)
+ elseif(QT_TEST_VERSION EQUAL 5)
 -  find_package(Qt5Widgets REQUIRED)
 +  #find_package(Qt5Widgets REQUIRED)
  
@@ -96,7 +96,7 @@ diff --git a/Tests/RunCMake/CMakeLists.txt 
b/Tests/RunCMake/CMakeLists.txt
 index 637c5c2cb..c0376effc 100644
 --- a/Tests/RunCMake/CMakeLists.txt
 +++ b/Tests/RunCMake/CMakeLists.txt
-@@ -291,7 +291,7 @@ add_RunCMake_test(configure_file)
+@@ -310,7 +310,7 @@ add_RunCMake_test(configure_file)
  add_RunCMake_test(CTestTimeoutAfterMatch)
  
  find_package(Qt4 QUIET)
diff --git 
a/meta/recipes-devtools/cmake/cmake/0005-Disable-use-of-ext2fs-ext2_fs.h-by-cmake-s-internal-.patch
 
b/meta/recipes-devtools/cmake/cmake/0005-Disable-use-of-ext2fs-ext2_fs.h-by-cmake-s-internal-.patch
index 23ce8e9e4a..ad42d409d9 100644
--- 
a/meta/recipes-devtools/cmake/cmake/0005-Disable-use-of-ext2fs-ext2_fs.h-by-cmake-s-internal-.patch
+++ 
b/meta/recipes-devtools/cmake/cmake/0005-Disable-use-of-ext2fs-ext2_fs.h-by-cmake-s-internal-.patch
@@ -20,7 +20,7 @@ diff --git a/Utilities/cmlibarchive/CMakeLists.txt 
b/Utilities/cmlibarchive/CMak
 index 206f3c6a5..642fb0dd9 100644
 --- a/Utilities/cmlibarchive/CMakeLists.txt
 +++ b/Utilities/cmlibarchive/CMakeLists.txt
-@@ -400,12 +400,8 @@ LA_CHECK_INCLUDE_FILE("copyfile.h" HAVE_COPYFILE_H)
+@@ -430,12 +430,8 @@ LA_CHECK_INCLUDE_FILE("copyfile.h" HAVE_COPYFILE_H)
  LA_CHECK_INCLUDE_FILE("direct.h" HAVE_DIRECT_H)
  LA_CHECK_INCLUDE_FILE("dlfcn.h" HAVE_DLFCN_H)
  LA_CHECK_INCLUDE_FILE("errno.h" HAVE_ERRNO_H)
diff --git a/meta/recipes-devtools/cmake/cmake_3.12.2.bb 
b/meta/recipes-devtools/cmake/cmake_3.13.4.bb
similarity index 100%
rename from meta/recipes-devtools/cmake/cmake_3.12.2.bb
rename to meta/recipes-devtools/cmake/cmake_3.13.4.bb
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] cmake: update to 3.13.4

2019-02-12 Thread Pascal Bach

All patches have been rebased on top of the 3.13.4 release.

I successfully built all CMake recipes in oe-core and meta-oe.


Signed-off-by: Pascal Bach 
---
 ...ake-native_3.12.2.bb => cmake-native_3.13.4.bb} |  0
 meta/recipes-devtools/cmake/cmake.inc  |  4 ++--
 ...ineSystem-use-oe-environment-vars-to-load.patch |  7 +++---
 .../0002-cmake-Prevent-the-detection-of-Qt5.patch  | 27 +++---
 ...upport-OpenEmbedded-Qt4-tool-binary-names.patch |  7 +++---
 ...ently-if-system-Qt-installation-is-broken.patch |  7 +++---
 ...-of-ext2fs-ext2_fs.h-by-cmake-s-internal-.patch |  9 
 .../cmake/{cmake_3.12.2.bb => cmake_3.13.4.bb} |  0
 8 files changed, 28 insertions(+), 33 deletions(-)
 rename meta/recipes-devtools/cmake/{cmake-native_3.12.2.bb => 
cmake-native_3.13.4.bb} (100%)
 rename meta/recipes-devtools/cmake/{cmake_3.12.2.bb => cmake_3.13.4.bb} (100%)

diff --git a/meta/recipes-devtools/cmake/cmake-native_3.12.2.bb 
b/meta/recipes-devtools/cmake/cmake-native_3.13.4.bb
similarity index 100%
rename from meta/recipes-devtools/cmake/cmake-native_3.12.2.bb
rename to meta/recipes-devtools/cmake/cmake-native_3.13.4.bb
diff --git a/meta/recipes-devtools/cmake/cmake.inc 
b/meta/recipes-devtools/cmake/cmake.inc
index 09e28b73dd..68a71e9139 100644
--- a/meta/recipes-devtools/cmake/cmake.inc
+++ b/meta/recipes-devtools/cmake/cmake.inc
@@ -18,7 +18,7 @@ SRC_URI = 
"https://cmake.org/files/v${CMAKE_MAJOR_VERSION}/cmake-${PV}.tar.gz \
file://0004-Fail-silently-if-system-Qt-installation-is-broken.patch 
\
 "
 
-SRC_URI[md5sum] = "6e7c550cfa1c2e216b35903dc70d80af"
-SRC_URI[sha256sum] = 
"0f97485799e51a7070cc11494f3e02349b0fc3a24cc12b082e737bf67a0581a4"
+SRC_URI[md5sum] = "b5a544ffc73f6922a6cf371fcb6bae22"
+SRC_URI[sha256sum] = 
"fdd928fee35f472920071d1c7f1a6a2b72c9b25e04f7a37b409349aef3f20e9b"
 
 UPSTREAM_CHECK_REGEX = "cmake-(?P\d+(\.\d+)+)\.tar"
diff --git 
a/meta/recipes-devtools/cmake/cmake/0001-CMakeDetermineSystem-use-oe-environment-vars-to-load.patch
 
b/meta/recipes-devtools/cmake/cmake/0001-CMakeDetermineSystem-use-oe-environment-vars-to-load.patch
index f690720870..13234240bf 100644
--- 
a/meta/recipes-devtools/cmake/cmake/0001-CMakeDetermineSystem-use-oe-environment-vars-to-load.patch
+++ 
b/meta/recipes-devtools/cmake/cmake/0001-CMakeDetermineSystem-use-oe-environment-vars-to-load.patch
@@ -1,9 +1,8 @@
-From 71085723f8028b3e1c4029fc1abe1243ac49ffc6 Mon Sep 17 00:00:00 2001
+From a072ad261b717b054c2deeb3eba1b206370e088e Mon Sep 17 00:00:00 2001
 From: Cody P Schafer 
 Date: Thu, 27 Apr 2017 11:35:05 -0400
 Subject: [PATCH 1/5] CMakeDetermineSystem: use oe environment vars to load
  default toolchain file in sdk
-Organization: O.S. Systems Software LTDA.
 
 Passing the toolchain by:
 
@@ -25,7 +24,7 @@ Signed-off-by: Otavio Salvador 
  1 file changed, 7 insertions(+)
 
 diff --git a/Modules/CMakeDetermineSystem.cmake 
b/Modules/CMakeDetermineSystem.cmake
-index 600d5580e..32d7f1945 100644
+index 600d5580e1..32d7f19459 100644
 --- a/Modules/CMakeDetermineSystem.cmake
 +++ b/Modules/CMakeDetermineSystem.cmake
 @@ -82,6 +82,13 @@ else()
@@ -43,5 +42,5 @@ index 600d5580e..32d7f1945 100644
  # in this case read the toolchain file and keep the CMAKE_HOST_SYSTEM_*
  # variables around so they can be used in CMakeLists.txt.
 -- 
-2.18.0
+2.11.0
 
diff --git 
a/meta/recipes-devtools/cmake/cmake/0002-cmake-Prevent-the-detection-of-Qt5.patch
 
b/meta/recipes-devtools/cmake/cmake/0002-cmake-Prevent-the-detection-of-Qt5.patch
index 6f788ada00..aa21aa54a2 100644
--- 
a/meta/recipes-devtools/cmake/cmake/0002-cmake-Prevent-the-detection-of-Qt5.patch
+++ 
b/meta/recipes-devtools/cmake/cmake/0002-cmake-Prevent-the-detection-of-Qt5.patch
@@ -1,8 +1,7 @@
-From 7a1f4e724f9c68498f401244c2938e784a2e6fbd Mon Sep 17 00:00:00 2001
+From 1df23cf04e19be465cc25b0bc068fbccd4e92d5b Mon Sep 17 00:00:00 2001
 From: Otavio Salvador 
 Date: Wed, 17 Jan 2018 10:02:14 -0200
 Subject: [PATCH 2/5] cmake: Prevent the detection of Qt5
-Organization: O.S. Systems Software LTDA.
 
 CMake doesn't have dependency on qt4/qt5, so these tests usually fail
 but still can cause undeterministic results or build failures (when
@@ -23,7 +22,7 @@ Signed-off-by: Otavio Salvador 
  7 files changed, 8 insertions(+), 8 deletions(-)
 
 diff --git a/Source/QtDialog/CMakeLists.txt b/Source/QtDialog/CMakeLists.txt
-index 330b74729..e7709dee6 100644
+index 330b747290..e7709dee67 100644
 --- a/Source/QtDialog/CMakeLists.txt
 +++ b/Source/QtDialog/CMakeLists.txt
 @@ -6,7 +6,7 @@ if(POLICY CMP0020)
@@ -36,10 +35,10 @@ index 330b74729..e7709dee6 100644
include_directories(${Qt5Widgets_INCLUDE_DIRS})
add_definitions(${Qt5Widgets_DEFINITONS})
 diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
-index b8b724ed8..63f6bb6d2 100644
+index 0de6c416e5..6a37ffa02c 100644
 --- a/Tests/CMakeLists.txt
 +++ b/Tests/CMakeLists.txt
-@@ -1322,7 +1322,7 @@ $

[OE-core] [PATCH] util-linux: make alternatives for rev and ionice work with busybox

2018-11-08 Thread Pascal Bach

Busybox can provide ionice and rev. They are both installed to /bin
The corresponding util-linux variant is installed to /usr/bin

This causes the following error during the do_rootfs task:

> update-alternatives: renaming ionice link from /bin/ionice to /usr/bin/ionice
> mv: cannot stat '/bin/ionice': No such file or directory

Moving the util-linux binaries to /bin avoids this error.

Signed-off-by: Andrej Valek 
Signed-off-by: Pascal Bach 
---
 meta/recipes-core/util-linux/util-linux.inc | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-core/util-linux/util-linux.inc 
b/meta/recipes-core/util-linux/util-linux.inc
index a05c1cabbe..b018b1365c 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -158,7 +158,7 @@ do_install () {
 
 sbinprogs="agetty ctrlaltdel cfdisk vipw vigr"
 sbinprogs_a="pivot_root hwclock mkswap mkfs.minix fsck.minix losetup 
swapon swapoff fdisk fsck blkid blockdev fstrim sulogin switch_root nologin"
-binprogs_a="dmesg getopt kill more umount mount login su mountpoint"
+binprogs_a="dmesg getopt kill more umount mount login su mountpoint 
ionice rev"
 
 if [ "${base_sbindir}" != "${sbindir}" ]; then
mkdir -p ${D}${base_sbindir}
@@ -221,7 +221,7 @@ ALTERNATIVE_LINK_NAME[pivot_root] = 
"${base_sbindir}/pivot_root"
 ALTERNATIVE_LINK_NAME[cal] = "${bindir}/cal"
 ALTERNATIVE_LINK_NAME[eject] = "${bindir}/eject"
 ALTERNATIVE_LINK_NAME[fallocate] = "${bindir}/fallocate"
-ALTERNATIVE_LINK_NAME[rev] = "${bindir}/rev"
+ALTERNATIVE_LINK_NAME[rev] = "${base_bindir}/rev"
 ALTERNATIVE_LINK_NAME[fsfreeze] = "${sbindir}/fsfreeze"
 ALTERNATIVE_LINK_NAME[nologin] = "${base_sbindir}/nologin"
 
@@ -296,7 +296,7 @@ ALTERNATIVE_util-linux-unshare = "unshare"
 ALTERNATIVE_LINK_NAME[unshare] = "${bindir}/unshare"
 
 ALTERNATIVE_util-linux-ionice = "ionice"
-ALTERNATIVE_LINK_NAME[ionice] = "${bindir}/ionice"
+ALTERNATIVE_LINK_NAME[ionice] = "${base_bindir}/ionice"
 
 ALTERNATIVE_util-linux-switch-root = "switch_root"
 ALTERNATIVE_LINK_NAME[switch_root] = "${base_sbindir}/switch_root"
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v4 0/4] cmake.bbclass improvements

2018-10-19 Thread Pascal Bach



On 18.10.2018 17:28, Khem Raj wrote:
> On Thu, Oct 18, 2018 at 7:58 AM Pascal Bach  wrote:
>>
>> On 17.10.2018 20:50, Khem Raj wrote:
>>> On Wed, Oct 17, 2018 at 3:43 AM Pascal Bach  wrote:
>>>> This patchset is unmodified from v3. It is just rebased on top of master 
>>>> which
>>>> already includes a fixed version of libproxy and piglit.
>>>>
>>>> I built all cmake based recipes in oe-core (qemuarm64) and did not find 
>>>> any more issues.
>>>>
>>> Can you run world builds on meta-openembedded repositories with
>>> this series applied and also compile some other large projects which
>>> use cmake like meta-browser
>> I can try but usually I get into trouble with the proxy because there are 
>> always some recipes that fetch from some location via some protocol that 
>> doesn't work.
> Once the current cycle of builds is done on OE
> builders I will try to schedule this in OE builds and
> see where it ends up. hopefully by this weekend.
I was able to do a world build with all layers of meta-oe and there are a few 
failures:

Two of wich I think are related to cmake:
- libyui-ncurses => messing around with hardcoded path in their cmake setup
- civetweb => still trying to figure out what exactly goes wrong

The following I was unable to build due to fetch problems:
- oscam

I will try to send patches for these two recipes.

>>>> Pascal Bach (4):
>>>>   cmake.bbclass: use CMAKE_SYSTEM_LIBRARY_PATH instead of
>>>> CMAKE_LIBRARY_PATH
>>>>   cmake.bbclass: search both sysroot-native and host for native packages
>>>>   cmake.bbclass: move CMAKE_NO_SYSTEM_FROM_IMPORTED to toolchain.cmake
>>>>   cmake.bbclass: allow cmake to find hosttools
>>>>
>>>>  meta/classes/cmake.bbclass | 24 +++-
>>>>  1 file changed, 15 insertions(+), 9 deletions(-)
>>>>
>>>> --
>>>> 2.11.0
>>>>
>>>> --
>>>> ___
>>>> Openembedded-core mailing list
>>>> Openembedded-core@lists.openembedded.org
>>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v4 2/4] cmake.bbclass: search both sysroot-native and host for native packages

2018-10-18 Thread Pascal Bach



On 17.10.2018 18:24, Burton, Ross wrote:
> I think I figured out why we're seeing odd failures on the
> autobuilder, such as
> https://autobuilder.yoctoproject.org/typhoon/#/builders/15/builds/125.
>
> The important bit of the log is:
>
> File 
> "/home/pokybuild/yocto-worker/poky-tiny/build/build/tmp/work/qemux86-poky-linux-musl/core-image-minimal/1.0-r0/recipe-sysroot-native/usr/lib/python3.5/site-packages/libcomps/__init__.py",
> line 1, in 
> from ._libpycomps import *
> ImportError: libpython3.6m.so.1.0: cannot open shared object file: No
> such file or directory
>
> The smoking gun is that oe-core doesn't have Python 3.6, but 3.5.
>
> My suspicion is that for systems where the host has python3-devel
> installed, libcomp-native's cmake is using the host python instead of
> the native python in the sysroot.  I'm not sure yet if BOTH means it
> searches the host before the sysroots, or if it is finding the python
> binary in HOSTTOOLS and then asking that what the paths are.  Either
> way, it ends up linking to the host libpython3.5.so and going into
> sstate.  Another machine in the pool reuses this sstate but it doesn't
> have Python 3.6 installed, so the library link is broken.
That is definitively not the intention here.

For target builds it is pretty clear that there should be no usage of host 
dependencies.
For native it is not so clear to me. There seems to be some dependencies like 
the compiler and associated libs.

Maybe there is a way to bring this in a different way that is more selective 
instead of a general fallback to host as it would be with this patch?

What I'm traying to solve here was to get rid of these two lines in the 
wireshark recipe [1]:

-DM_INCLUDE_DIR=${includedir} \
-DM_LIBRARY=${libdir} \

As they effectively add /usr/include and /usr/lib to the search path of cmake.

Any toughts?

Pascal

[1] 
http://cgit.openembedded.org/meta-openembedded/tree/meta-networking/recipes-support/wireshark/wireshark_2.6.2.bb?h=master#n62
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v4 0/4] cmake.bbclass improvements

2018-10-18 Thread Pascal Bach



On 17.10.2018 20:50, Khem Raj wrote:
> On Wed, Oct 17, 2018 at 3:43 AM Pascal Bach  wrote:
>> This patchset is unmodified from v3. It is just rebased on top of master 
>> which
>> already includes a fixed version of libproxy and piglit.
>>
>> I built all cmake based recipes in oe-core (qemuarm64) and did not find any 
>> more issues.
>>
> Can you run world builds on meta-openembedded repositories with
> this series applied and also compile some other large projects which
> use cmake like meta-browser
I can try but usually I get into trouble with the proxy because there are 
always some recipes that fetch from some location via some protocol that 
doesn't work.

>
>> Pascal Bach (4):
>>   cmake.bbclass: use CMAKE_SYSTEM_LIBRARY_PATH instead of
>> CMAKE_LIBRARY_PATH
>>   cmake.bbclass: search both sysroot-native and host for native packages
>>   cmake.bbclass: move CMAKE_NO_SYSTEM_FROM_IMPORTED to toolchain.cmake
>>   cmake.bbclass: allow cmake to find hosttools
>>
>>  meta/classes/cmake.bbclass | 24 +++-
>>  1 file changed, 15 insertions(+), 9 deletions(-)
>>
>> --
>> 2.11.0
>>
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v4 4/4] cmake.bbclass: allow cmake to find hosttools

2018-10-17 Thread Pascal Bach

Currently the generated toolchain file is unable to find hosttools as they
do not appear in the search paths.

Just adding HOSTTOOLS_DIR is not enough as binaries are located directly under
${HOSTTOOLS_DIR}. Like ${HOSTTOOLS_DIR}/git for example.
CMake however only searches in [s]bin sub directories of the paths specified in
CMAKE_FIND_ROOT_PATH. Explicitly adding / to CMAKE_SYSTEM_PROGRAM_PATH makes
CMake look in the right location.

Signed-off-by: Pascal Bach 
---
 meta/classes/cmake.bbclass | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index 0ef63795eb..c8a079c417 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -89,7 +89,7 @@ set( CMAKE_CXX_LINK_FLAGS "${OECMAKE_CXX_LINK_FLAGS}" CACHE 
STRING "LDFLAGS" )
 
 # only search in the paths provided so cmake doesnt pick
 # up libraries and tools from the native build machine
-set( CMAKE_FIND_ROOT_PATH ${STAGING_DIR_HOST} ${STAGING_DIR_NATIVE} 
${CROSS_DIR} ${OECMAKE_PERLNATIVE_DIR} ${OECMAKE_EXTRA_ROOT_PATH} 
${EXTERNAL_TOOLCHAIN})
+set( CMAKE_FIND_ROOT_PATH ${STAGING_DIR_HOST} ${STAGING_DIR_NATIVE} 
${CROSS_DIR} ${OECMAKE_PERLNATIVE_DIR} ${OECMAKE_EXTRA_ROOT_PATH} 
${EXTERNAL_TOOLCHAIN} ${HOSTTOOLS_DIR})
 set( CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ${OECMAKE_FIND_ROOT_PATH_MODE} )
 set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ${OECMAKE_FIND_ROOT_PATH_MODE} )
 set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ${OECMAKE_FIND_ROOT_PATH_MODE} )
@@ -108,6 +108,10 @@ list(APPEND CMAKE_MODULE_PATH 
"${STAGING_DATADIR}/cmake/Modules/")
 # add for non /usr/lib libdir, e.g. /usr/lib64
 set( CMAKE_SYSTEM_LIBRARY_PATH ${libdir} ${base_libdir})
 
+# by default CMake only looks in [s]bin subdirectories of CMAKE_FIND_ROOT_PATH
+# adding / makes CMake look for binaries in hosttools too.
+set( CMAKE_SYSTEM_PROGRAM_PATH /)
+
 # avoid treating imports as system includes
 set( CMAKE_NO_SYSTEM_FROM_IMPORTED ON)
 
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v4 0/4] cmake.bbclass improvements

2018-10-17 Thread Pascal Bach

This patchset is unmodified from v3. It is just rebased on top of master which
already includes a fixed version of libproxy and piglit.

I built all cmake based recipes in oe-core (qemuarm64) and did not find any 
more issues.

Pascal Bach (4):
  cmake.bbclass: use CMAKE_SYSTEM_LIBRARY_PATH instead of
CMAKE_LIBRARY_PATH
  cmake.bbclass: search both sysroot-native and host for native packages
  cmake.bbclass: move CMAKE_NO_SYSTEM_FROM_IMPORTED to toolchain.cmake
  cmake.bbclass: allow cmake to find hosttools

 meta/classes/cmake.bbclass | 24 +++-
 1 file changed, 15 insertions(+), 9 deletions(-)

-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v4 3/4] cmake.bbclass: move CMAKE_NO_SYSTEM_FROM_IMPORTED to toolchain.cmake

2018-10-17 Thread Pascal Bach

The setting influences the build like other settings already in toolchain.cmake.
It is more appropriate to set it there instead of providing it as a random
command line parameter to CMake.

It also makes it easier to use the toolchain.cmake file independent of bitbake.
Like the devshell for example.

Signed-off-by: Pascal Bach 
---
 meta/classes/cmake.bbclass | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index ce3c0278ff..0ef63795eb 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -108,6 +108,9 @@ list(APPEND CMAKE_MODULE_PATH 
"${STAGING_DATADIR}/cmake/Modules/")
 # add for non /usr/lib libdir, e.g. /usr/lib64
 set( CMAKE_SYSTEM_LIBRARY_PATH ${libdir} ${base_libdir})
 
+# avoid treating imports as system includes
+set( CMAKE_NO_SYSTEM_FROM_IMPORTED ON)
+
 EOF
 }
 
@@ -152,7 +155,6 @@ cmake_do_configure() {
  -DCMAKE_INSTALL_SO_NO_EXE=0 \
  -DCMAKE_TOOLCHAIN_FILE=${WORKDIR}/toolchain.cmake \
  -DCMAKE_VERBOSE_MAKEFILE=1 \
- -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 \
  ${EXTRA_OECMAKE} \
  -Wno-dev
 }
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v4 2/4] cmake.bbclass: search both sysroot-native and host for native packages

2018-10-17 Thread Pascal Bach

Certain headers and libraries like `math.h` an `-m` are only available on the
host as they are provided by the host toolchain.

This leads to issues that a find_library in CMake doesn't find the `m` library
of a find_path doesn't find `math.h`. This issue occurred in the wireshark 
recipe
for example.

This change enables CMake to also look on the host for libraries and includes 
when
building a native package.

Signed-off-by: Pascal Bach 
---
 meta/classes/cmake.bbclass | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index 86b1d0e9aa..ce3c0278ff 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -43,8 +43,8 @@ OECMAKE_RPATH ?= ""
 OECMAKE_PERLNATIVE_DIR ??= ""
 OECMAKE_EXTRA_ROOT_PATH ?= ""
 
-OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM = "ONLY"
-OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM_class-native = "BOTH"
+OECMAKE_FIND_ROOT_PATH_MODE = "ONLY"
+OECMAKE_FIND_ROOT_PATH_MODE_class-native = "BOTH"
 
 EXTRA_OECMAKE_append = " ${PACKAGECONFIG_CONFARGS}"
 
@@ -90,10 +90,10 @@ set( CMAKE_CXX_LINK_FLAGS "${OECMAKE_CXX_LINK_FLAGS}" CACHE 
STRING "LDFLAGS" )
 # only search in the paths provided so cmake doesnt pick
 # up libraries and tools from the native build machine
 set( CMAKE_FIND_ROOT_PATH ${STAGING_DIR_HOST} ${STAGING_DIR_NATIVE} 
${CROSS_DIR} ${OECMAKE_PERLNATIVE_DIR} ${OECMAKE_EXTRA_ROOT_PATH} 
${EXTERNAL_TOOLCHAIN})
-set( CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY )
-set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ${OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM} )
-set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY )
-set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY )
+set( CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ${OECMAKE_FIND_ROOT_PATH_MODE} )
+set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ${OECMAKE_FIND_ROOT_PATH_MODE} )
+set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ${OECMAKE_FIND_ROOT_PATH_MODE} )
+set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ${OECMAKE_FIND_ROOT_PATH_MODE} )
 
 # Use qt.conf settings
 set( ENV{QT_CONF_PATH} ${WORKDIR}/qt.conf )
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v4 1/4] cmake.bbclass: use CMAKE_SYSTEM_LIBRARY_PATH instead of CMAKE_LIBRARY_PATH

2018-10-17 Thread Pascal Bach

CMAKE_LIBRARY_PATH is intended to be set by projects.
CMAKE_SYSTEM_LIBRARY_PATH is better suited to be used in a toolchain
file.

Signed-off-by: Pascal Bach 
---
 meta/classes/cmake.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index fd40a9863e..86b1d0e9aa 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -106,7 +106,7 @@ set( CMAKE_INSTALL_RPATH ${OECMAKE_RPATH} )
 list(APPEND CMAKE_MODULE_PATH "${STAGING_DATADIR}/cmake/Modules/")
 
 # add for non /usr/lib libdir, e.g. /usr/lib64
-set( CMAKE_LIBRARY_PATH ${libdir} ${base_libdir})
+set( CMAKE_SYSTEM_LIBRARY_PATH ${libdir} ${base_libdir})
 
 EOF
 }
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] libproxy: disable python2 and python3 support

2018-10-10 Thread Pascal Bach

The option WITH_PYTHON got replaced by
WITH_PYTHON2 and WITH_PYTHON3.

Signed-off-by: Pascal Bach 
---
 meta/recipes-support/libproxy/libproxy_0.4.15.bb | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-support/libproxy/libproxy_0.4.15.bb 
b/meta/recipes-support/libproxy/libproxy_0.4.15.bb
index 991c9d8320..4633ca5781 100644
--- a/meta/recipes-support/libproxy/libproxy_0.4.15.bb
+++ b/meta/recipes-support/libproxy/libproxy_0.4.15.bb
@@ -26,7 +26,8 @@ EXTRA_OECMAKE += " \
 -DWITH_MOZJS=no \
 -DWITH_NM=no \
 -DWITH_PERL=no \
--DWITH_PYTHON=no \
+-DWITH_PYTHON2=no \
+-DWITH_PYTHON3=no \
 -DWITH_WEBKIT=no \
 -DLIB_INSTALL_DIR=${libdir} \
 -DLIBEXEC_INSTALL_DIR=${libexecdir} \
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCHv3 1/4] cmake.bbclass: use CMAKE_SYSTEM_LIBRARY_PATH instead of CMAKE_LIBRARY_PATH

2018-10-10 Thread Pascal Bach

On 10.10.2018 14:36, Richard Purdie wrote:
> On Wed, 2018-10-10 at 10:10 +0200, Pascal Bach wrote:
>> CMAKE_LIBRARY_PATH is intended to be set by projects.
>> CMAKE_SYSTEM_LIBRARY_PATH is better suited to be used in a toolchain
>> file.
>>
>> Signed-off-by: Pascal Bach 
>> ---
>>  meta/classes/cmake.bbclass | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
> I have a feeling something in this series may have caused:
>
> https://autobuilder.yoctoproject.org/typhoon/api/v2/logs/42753/raw
>
> but haven't bisected to confirm it is the cmake changes yet (it is from
> something in master-next).
>
The problem is "cmake.bbclass: allow cmake to find hosttools" it has the side 
effect of making all hosttools available to all recipes.
In the case of libproxy this leads to it finding python, which is included in 
hosttools, and thus building it's bindings.

This kind of defeats the purpose of having recipe specific sysroots.
Is there a way to make only selected hosttools available to a recipe. Like for 
example git? Maybe use git-native?

I think the patch "cmake.bbclass: allow cmake to find hosttools" in this form 
does more harm then good. The rest of the series should be fine.
Should I resubmit the series without this specific patch?

One more thing for libproxy. It currently disables python explicitly via 
`-WITH_PYTHON=no`. But this option doesn't exist anymore as it got replaces
by `-WITH_PYTHON2=no` `-WITH_PYTHON3=no`. This is why the auto detection kicks 
in. I will submit a patch to clean this recipe up too.

Pascal
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCHv3 1/4] cmake.bbclass: use CMAKE_SYSTEM_LIBRARY_PATH instead of CMAKE_LIBRARY_PATH

2018-10-10 Thread Pascal Bach




On 10.10.2018 14:36, Richard Purdie wrote:
> On Wed, 2018-10-10 at 10:10 +0200, Pascal Bach wrote:
>> CMAKE_LIBRARY_PATH is intended to be set by projects.
>> CMAKE_SYSTEM_LIBRARY_PATH is better suited to be used in a toolchain
>> file.
>>
>> Signed-off-by: Pascal Bach 
>> ---
>>  meta/classes/cmake.bbclass | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
> I have a feeling something in this series may have caused:
>
> https://autobuilder.yoctoproject.org/typhoon/api/v2/logs/42753/raw
>
> but haven't bisected to confirm it is the cmake changes yet (it is from
> something in master-next).
You are right the recipe is using cmake. I will investigate the issue.

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] cmake.bbclass: search both sysroot-native and host for native packages

2018-10-10 Thread Pascal Bach

I re submitted all 4 patches a series.

Sorry for the inconvenience, I miss-judged the conflicts between the patches.

Passcal


On 09.10.2018 17:07, Burton, Ross wrote:
> All but this one apply now... weird.
>
> If you can rebase on top of poky-contrib:ross/thud then that would be great.
>
> Ross
>
> On Tue, 9 Oct 2018 at 15:07, Pascal Bach  <mailto:pascal.b...@siemens.com>> wrote:
>
> Certain headers and libraries like `math.h` an `-m` are only available on 
> the
> host as they are provided by the host toolchain.
>
> This leads to issues that a find_library in CMake doesn't find the `m` 
> library
> of a find_path doesn't find `math.h`. This issue occurred in the 
> wireshark recipe
> for example.
>
> This change enables CMake to also look on the host for libraries and 
> includes when
> building a native package.
>
> Signed-off-by: Pascal Bach  <mailto:pascal.b...@siemens.com>>
> ---
>  meta/classes/cmake.bbclass | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
> index 6e2c34e4c6..89a2a77a50 100644
> --- a/meta/classes/cmake.bbclass
> +++ b/meta/classes/cmake.bbclass
> @@ -43,8 +43,8 @@ OECMAKE_RPATH ?= ""
>  OECMAKE_PERLNATIVE_DIR ??= ""
>  OECMAKE_EXTRA_ROOT_PATH ?= ""
>
> -OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM = "ONLY"
> -OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM_class-native = "BOTH"
> +OECMAKE_FIND_ROOT_PATH_MODE = "ONLY"
> +OECMAKE_FIND_ROOT_PATH_MODE_class-native = "BOTH"
>
>  EXTRA_OECMAKE_append = " ${PACKAGECONFIG_CONFARGS}"
>
> @@ -93,10 +93,10 @@ set( CMAKE_CXX_LINK_FLAGS "${OECMAKE_CXX_LINK_FLAGS}" 
> CACHE STRING "LDFLAGS" )
>  # only search in the paths provided so cmake doesnt pick
>  # up libraries and tools from the native build machine
>  set( CMAKE_FIND_ROOT_PATH ${STAGING_DIR_HOST} ${STAGING_DIR_NATIVE} 
> ${CROSS_DIR} ${OECMAKE_PERLNATIVE_DIR} ${OECMAKE_EXTRA_ROOT_PATH} 
> ${EXTERNAL_TOOLCHAIN})
> -set( CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY )
> -set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM 
> ${OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM} )
> -set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY )
> -set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY )
> +set( CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ${OECMAKE_FIND_ROOT_PATH_MODE} )
> +set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ${OECMAKE_FIND_ROOT_PATH_MODE} )
> +set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ${OECMAKE_FIND_ROOT_PATH_MODE} )
> +set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ${OECMAKE_FIND_ROOT_PATH_MODE} )
>
>  $cmake_sysroot
>
> -- 
> 2.11.0
>
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org 
> <mailto:Openembedded-core@lists.openembedded.org>
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCHv3 2/4] cmake.bbclass: search both sysroot-native and host for native packages

2018-10-10 Thread Pascal Bach

Certain headers and libraries like `math.h` an `-m` are only available on the
host as they are provided by the host toolchain.

This leads to issues that a find_library in CMake doesn't find the `m` library
of a find_path doesn't find `math.h`. This issue occurred in the wireshark 
recipe
for example.

This change enables CMake to also look on the host for libraries and includes 
when
building a native package.

Signed-off-by: Pascal Bach 
---
 meta/classes/cmake.bbclass | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index 86b1d0e9aa..ce3c0278ff 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -43,8 +43,8 @@ OECMAKE_RPATH ?= ""
 OECMAKE_PERLNATIVE_DIR ??= ""
 OECMAKE_EXTRA_ROOT_PATH ?= ""
 
-OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM = "ONLY"
-OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM_class-native = "BOTH"
+OECMAKE_FIND_ROOT_PATH_MODE = "ONLY"
+OECMAKE_FIND_ROOT_PATH_MODE_class-native = "BOTH"
 
 EXTRA_OECMAKE_append = " ${PACKAGECONFIG_CONFARGS}"
 
@@ -90,10 +90,10 @@ set( CMAKE_CXX_LINK_FLAGS "${OECMAKE_CXX_LINK_FLAGS}" CACHE 
STRING "LDFLAGS" )
 # only search in the paths provided so cmake doesnt pick
 # up libraries and tools from the native build machine
 set( CMAKE_FIND_ROOT_PATH ${STAGING_DIR_HOST} ${STAGING_DIR_NATIVE} 
${CROSS_DIR} ${OECMAKE_PERLNATIVE_DIR} ${OECMAKE_EXTRA_ROOT_PATH} 
${EXTERNAL_TOOLCHAIN})
-set( CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY )
-set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ${OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM} )
-set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY )
-set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY )
+set( CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ${OECMAKE_FIND_ROOT_PATH_MODE} )
+set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ${OECMAKE_FIND_ROOT_PATH_MODE} )
+set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ${OECMAKE_FIND_ROOT_PATH_MODE} )
+set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ${OECMAKE_FIND_ROOT_PATH_MODE} )
 
 # Use qt.conf settings
 set( ENV{QT_CONF_PATH} ${WORKDIR}/qt.conf )
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCHv3 3/4] cmake.bbclass: move CMAKE_NO_SYSTEM_FROM_IMPORTED to toolchain.cmake

2018-10-10 Thread Pascal Bach

The setting influences the build like other settings already in toolchain.cmake.
It is more appropriate to set it there instead of providing it as a random
command line parameter to CMake.

It also makes it easier to use the toolchain.cmake file independent of bitbake.
Like the devshell for example.

Signed-off-by: Pascal Bach 
---
 meta/classes/cmake.bbclass | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index ce3c0278ff..0ef63795eb 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -108,6 +108,9 @@ list(APPEND CMAKE_MODULE_PATH 
"${STAGING_DATADIR}/cmake/Modules/")
 # add for non /usr/lib libdir, e.g. /usr/lib64
 set( CMAKE_SYSTEM_LIBRARY_PATH ${libdir} ${base_libdir})
 
+# avoid treating imports as system includes
+set( CMAKE_NO_SYSTEM_FROM_IMPORTED ON)
+
 EOF
 }
 
@@ -152,7 +155,6 @@ cmake_do_configure() {
  -DCMAKE_INSTALL_SO_NO_EXE=0 \
  -DCMAKE_TOOLCHAIN_FILE=${WORKDIR}/toolchain.cmake \
  -DCMAKE_VERBOSE_MAKEFILE=1 \
- -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 \
  ${EXTRA_OECMAKE} \
  -Wno-dev
 }
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCHv3 4/4] cmake.bbclass: allow cmake to find hosttools

2018-10-10 Thread Pascal Bach

Currently the generated toolchain file is unable to find hosttools as they
do not appear in the search paths.

Just adding HOSTTOOLS_DIR is not enough as binaries are located directly under
${HOSTTOOLS_DIR}. Like ${HOSTTOOLS_DIR}/git for example.
CMake however only searches in [s]bin sub directories of the paths specified in
CMAKE_FIND_ROOT_PATH. Explicitly adding / to CMAKE_SYSTEM_PROGRAM_PATH makes
CMake look in the right location.

Signed-off-by: Pascal Bach 
---
 meta/classes/cmake.bbclass | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index 0ef63795eb..c8a079c417 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -89,7 +89,7 @@ set( CMAKE_CXX_LINK_FLAGS "${OECMAKE_CXX_LINK_FLAGS}" CACHE 
STRING "LDFLAGS" )
 
 # only search in the paths provided so cmake doesnt pick
 # up libraries and tools from the native build machine
-set( CMAKE_FIND_ROOT_PATH ${STAGING_DIR_HOST} ${STAGING_DIR_NATIVE} 
${CROSS_DIR} ${OECMAKE_PERLNATIVE_DIR} ${OECMAKE_EXTRA_ROOT_PATH} 
${EXTERNAL_TOOLCHAIN})
+set( CMAKE_FIND_ROOT_PATH ${STAGING_DIR_HOST} ${STAGING_DIR_NATIVE} 
${CROSS_DIR} ${OECMAKE_PERLNATIVE_DIR} ${OECMAKE_EXTRA_ROOT_PATH} 
${EXTERNAL_TOOLCHAIN} ${HOSTTOOLS_DIR})
 set( CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ${OECMAKE_FIND_ROOT_PATH_MODE} )
 set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ${OECMAKE_FIND_ROOT_PATH_MODE} )
 set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ${OECMAKE_FIND_ROOT_PATH_MODE} )
@@ -108,6 +108,10 @@ list(APPEND CMAKE_MODULE_PATH 
"${STAGING_DATADIR}/cmake/Modules/")
 # add for non /usr/lib libdir, e.g. /usr/lib64
 set( CMAKE_SYSTEM_LIBRARY_PATH ${libdir} ${base_libdir})
 
+# by default CMake only looks in [s]bin subdirectories of CMAKE_FIND_ROOT_PATH
+# adding / makes CMake look for binaries in hosttools too.
+set( CMAKE_SYSTEM_PROGRAM_PATH /)
+
 # avoid treating imports as system includes
 set( CMAKE_NO_SYSTEM_FROM_IMPORTED ON)
 
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCHv3 1/4] cmake.bbclass: use CMAKE_SYSTEM_LIBRARY_PATH instead of CMAKE_LIBRARY_PATH

2018-10-10 Thread Pascal Bach

CMAKE_LIBRARY_PATH is intended to be set by projects.
CMAKE_SYSTEM_LIBRARY_PATH is better suited to be used in a toolchain
file.

Signed-off-by: Pascal Bach 
---
 meta/classes/cmake.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index fd40a9863e..86b1d0e9aa 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -106,7 +106,7 @@ set( CMAKE_INSTALL_RPATH ${OECMAKE_RPATH} )
 list(APPEND CMAKE_MODULE_PATH "${STAGING_DATADIR}/cmake/Modules/")
 
 # add for non /usr/lib libdir, e.g. /usr/lib64
-set( CMAKE_LIBRARY_PATH ${libdir} ${base_libdir})
+set( CMAKE_SYSTEM_LIBRARY_PATH ${libdir} ${base_libdir})
 
 EOF
 }
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCHv2] cmake.bbclass: allow cmake to find hosttools

2018-10-09 Thread Pascal Bach

Currently the generated toolchain file is unable to find hosttools as they
do not appear in the search paths.

One example where this is useful is for projects that query git for their 
version
number as git is usually provided via HOSTTOOLS.

Just adding HOSTTOOLS_DIR is not enough as binaries are located directly under
${HOSTTOOLS_DIR}. Like ${HOSTTOOLS_DIR}/git for example.
CMake however only searches in [s]bin sub directories of the paths specified in
CMAKE_FIND_ROOT_PATH. Explicitly adding / to CMAKE_SYSTEM_PROGRAM_PATH makes
CMake look in the right location.

Signed-off-by: Pascal Bach 
---
 meta/classes/cmake.bbclass | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index fd40a9863e..0dd6f6e6de 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -89,7 +89,7 @@ set( CMAKE_CXX_LINK_FLAGS "${OECMAKE_CXX_LINK_FLAGS}" CACHE 
STRING "LDFLAGS" )
 
 # only search in the paths provided so cmake doesnt pick
 # up libraries and tools from the native build machine
-set( CMAKE_FIND_ROOT_PATH ${STAGING_DIR_HOST} ${STAGING_DIR_NATIVE} 
${CROSS_DIR} ${OECMAKE_PERLNATIVE_DIR} ${OECMAKE_EXTRA_ROOT_PATH} 
${EXTERNAL_TOOLCHAIN})
+set( CMAKE_FIND_ROOT_PATH ${STAGING_DIR_HOST} ${STAGING_DIR_NATIVE} 
${CROSS_DIR} ${OECMAKE_PERLNATIVE_DIR} ${OECMAKE_EXTRA_ROOT_PATH} 
${EXTERNAL_TOOLCHAIN} ${HOSTTOOLS_DIR})
 set( CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY )
 set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ${OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM} )
 set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY )
@@ -108,6 +108,10 @@ list(APPEND CMAKE_MODULE_PATH 
"${STAGING_DATADIR}/cmake/Modules/")
 # add for non /usr/lib libdir, e.g. /usr/lib64
 set( CMAKE_LIBRARY_PATH ${libdir} ${base_libdir})
 
+# by default CMake only looks in [s]bin subdirectories of CMAKE_FIND_ROOT_PATH
+# adding / makes CMake look for binaries in hosttools too.
+set( CMAKE_SYSTEM_PROGRAM_PATH /)
+
 EOF
 }
 
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] cmake.bbclass: allow cmake to find hosttools

2018-10-09 Thread Pascal Bach

On 09.10.2018 16:06, Burton, Ross wrote:
> The hashes don't match anything public and git isn't happy:
>
> Applying: cmake.bbclass: allow cmake to find hosttools
> error: sha1 information is lacking or useless (meta/classes/cmake.bbclass).
> error: could not build fake ancestor
> Patch failed at 0001 cmake.bbclass: allow cmake to find hosttools

I noticed too, the patch was based on another patch I sent. Should have sent 
these as a patch set even tough
they are not really related.

I will resubmit.

Pascal

>
> Ross
>
> On Tue, 9 Oct 2018 at 14:36, Pascal Bach  <mailto:pascal.b...@siemens.com>> wrote:
>
> Currently the generated toolchain file is unable to find hosttools as they
> do not appear in the search paths.
>
> One example where this is useful is for projects that query git for their 
> version
> number as git is usually provided via HOSTTOOLS.
>
> Just adding HOSTTOOLS_DIR is not enough as binaries are located directly 
> under
> ${HOSTTOOLS_DIR}. Like ${HOSTTOOLS_DIR}/git for example.
> CMake however only searches in [s]bin sub directories of the paths 
> specified in
> CMAKE_FIND_ROOT_PATH. Explicitly adding / to CMAKE_SYSTEM_PROGRAM_PATH 
> makes
> CMake look in the right location.
>
> Signed-off-by: Pascal Bach  <mailto:pascal.b...@siemens.com>>
> ---
>  meta/classes/cmake.bbclass | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
> index 684f71299a..421d85fd9d 100644
> --- a/meta/classes/cmake.bbclass
> +++ b/meta/classes/cmake.bbclass
> @@ -92,7 +92,7 @@ set( CMAKE_CXX_LINK_FLAGS "${OECMAKE_CXX_LINK_FLAGS}" 
> CACHE STRING "LDFLAGS" )
>
>  # only search in the paths provided so cmake doesnt pick
>  # up libraries and tools from the native build machine
> -set( CMAKE_FIND_ROOT_PATH ${STAGING_DIR_HOST} ${STAGING_DIR_NATIVE} 
> ${CROSS_DIR} ${OECMAKE_PERLNATIVE_DIR} ${OECMAKE_EXTRA_ROOT_PATH} 
> ${EXTERNAL_TOOLCHAIN})
> +set( CMAKE_FIND_ROOT_PATH ${STAGING_DIR_HOST} ${STAGING_DIR_NATIVE} 
> ${CROSS_DIR} ${OECMAKE_PERLNATIVE_DIR} ${OECMAKE_EXTRA_ROOT_PATH} 
> ${EXTERNAL_TOOLCHAIN} ${HOSTTOOLS_DIR})
>  set( CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ${OECMAKE_FIND_ROOT_PATH_MODE} )
>  set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ${OECMAKE_FIND_ROOT_PATH_MODE} )
>  set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ${OECMAKE_FIND_ROOT_PATH_MODE} )
> @@ -113,6 +113,10 @@ list(APPEND CMAKE_MODULE_PATH 
> "${STAGING_DATADIR}/cmake/Modules/")
>  # add for non /usr/lib libdir, e.g. /usr/lib64
>  set( CMAKE_SYSTEM_LIBRARY_PATH ${libdir} ${base_libdir})
>
> +# by default CMake only looks in [s]bin subdirectories of 
> CMAKE_FIND_ROOT_PATH
> +# adding / makes CMake look for binaries in hosttools too.
> +set( CMAKE_SYSTEM_PROGRAM_PATH /)
> +
>  # avoid treating imports as system includes
>  set( CMAKE_NO_SYSTEM_FROM_IMPORTED ON)
>
> -- 
> 2.11.0
>
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org 
> <mailto:Openembedded-core@lists.openembedded.org>
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] cmake.bbclass: use CMAKE_SYSTEM_LIBRARY_PATH instead of CMAKE_LIBRARY_PATH

2018-10-09 Thread Pascal Bach

CMAKE_LIBRARY_PATH is intended to be set by projects.
CMAKE_SYSTEM_LIBRARY_PATH is better suited to be used in a toolchain
file.

Signed-off-by: Pascal Bach 
---
 meta/classes/cmake.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index 251ddd9afe..6e2c34e4c6 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -111,7 +111,7 @@ set( CMAKE_INSTALL_RPATH ${OECMAKE_RPATH} )
 list(APPEND CMAKE_MODULE_PATH "${STAGING_DATADIR}/cmake/Modules/")
 
 # add for non /usr/lib libdir, e.g. /usr/lib64
-set( CMAKE_LIBRARY_PATH ${libdir} ${base_libdir})
+set( CMAKE_SYSTEM_LIBRARY_PATH ${libdir} ${base_libdir})
 
 EOF
 }
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] cmake.bbclass: search both sysroot-native and host for native packages

2018-10-09 Thread Pascal Bach

Certain headers and libraries like `math.h` an `-m` are only available on the
host as they are provided by the host toolchain.

This leads to issues that a find_library in CMake doesn't find the `m` library
of a find_path doesn't find `math.h`. This issue occurred in the wireshark 
recipe
for example.

This change enables CMake to also look on the host for libraries and includes 
when
building a native package.

Signed-off-by: Pascal Bach 
---
 meta/classes/cmake.bbclass | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index 6e2c34e4c6..89a2a77a50 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -43,8 +43,8 @@ OECMAKE_RPATH ?= ""
 OECMAKE_PERLNATIVE_DIR ??= ""
 OECMAKE_EXTRA_ROOT_PATH ?= ""
 
-OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM = "ONLY"
-OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM_class-native = "BOTH"
+OECMAKE_FIND_ROOT_PATH_MODE = "ONLY"
+OECMAKE_FIND_ROOT_PATH_MODE_class-native = "BOTH"
 
 EXTRA_OECMAKE_append = " ${PACKAGECONFIG_CONFARGS}"
 
@@ -93,10 +93,10 @@ set( CMAKE_CXX_LINK_FLAGS "${OECMAKE_CXX_LINK_FLAGS}" CACHE 
STRING "LDFLAGS" )
 # only search in the paths provided so cmake doesnt pick
 # up libraries and tools from the native build machine
 set( CMAKE_FIND_ROOT_PATH ${STAGING_DIR_HOST} ${STAGING_DIR_NATIVE} 
${CROSS_DIR} ${OECMAKE_PERLNATIVE_DIR} ${OECMAKE_EXTRA_ROOT_PATH} 
${EXTERNAL_TOOLCHAIN})
-set( CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY )
-set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ${OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM} )
-set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY )
-set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY )
+set( CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ${OECMAKE_FIND_ROOT_PATH_MODE} )
+set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ${OECMAKE_FIND_ROOT_PATH_MODE} )
+set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ${OECMAKE_FIND_ROOT_PATH_MODE} )
+set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ${OECMAKE_FIND_ROOT_PATH_MODE} )
 
 $cmake_sysroot
 
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] cmake.bbclass: move CMAKE_NO_SYSTEM_FROM_IMPORTED to toolchain.cmake

2018-10-09 Thread Pascal Bach

The setting influences the build like other settings already in toolchain.cmake.
It is more appropriate to set it there instead of providing it as a random
command line parameter to CMake.

It also makes it easier to use the toolchain.cmake file independent of bitbake.
Like the devshell for example.

Signed-off-by: Pascal Bach 
---
 meta/classes/cmake.bbclass | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index 89a2a77a50..684f71299a 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -113,6 +113,9 @@ list(APPEND CMAKE_MODULE_PATH 
"${STAGING_DATADIR}/cmake/Modules/")
 # add for non /usr/lib libdir, e.g. /usr/lib64
 set( CMAKE_SYSTEM_LIBRARY_PATH ${libdir} ${base_libdir})
 
+# avoid treating imports as system includes
+set( CMAKE_NO_SYSTEM_FROM_IMPORTED ON)
+
 EOF
 }
 
@@ -157,7 +160,6 @@ cmake_do_configure() {
  -DCMAKE_INSTALL_SO_NO_EXE=0 \
  -DCMAKE_TOOLCHAIN_FILE=${WORKDIR}/toolchain.cmake \
  -DCMAKE_VERBOSE_MAKEFILE=1 \
- -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 \
  ${EXTRA_OECMAKE} \
  -Wno-dev
 }
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] cmake.bbclass: allow cmake to find hosttools

2018-10-09 Thread Pascal Bach

Currently the generated toolchain file is unable to find hosttools as they
do not appear in the search paths.

One example where this is useful is for projects that query git for their 
version
number as git is usually provided via HOSTTOOLS.

Just adding HOSTTOOLS_DIR is not enough as binaries are located directly under
${HOSTTOOLS_DIR}. Like ${HOSTTOOLS_DIR}/git for example.
CMake however only searches in [s]bin sub directories of the paths specified in
CMAKE_FIND_ROOT_PATH. Explicitly adding / to CMAKE_SYSTEM_PROGRAM_PATH makes
CMake look in the right location.

Signed-off-by: Pascal Bach 
---
 meta/classes/cmake.bbclass | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index 684f71299a..421d85fd9d 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -92,7 +92,7 @@ set( CMAKE_CXX_LINK_FLAGS "${OECMAKE_CXX_LINK_FLAGS}" CACHE 
STRING "LDFLAGS" )
 
 # only search in the paths provided so cmake doesnt pick
 # up libraries and tools from the native build machine
-set( CMAKE_FIND_ROOT_PATH ${STAGING_DIR_HOST} ${STAGING_DIR_NATIVE} 
${CROSS_DIR} ${OECMAKE_PERLNATIVE_DIR} ${OECMAKE_EXTRA_ROOT_PATH} 
${EXTERNAL_TOOLCHAIN})
+set( CMAKE_FIND_ROOT_PATH ${STAGING_DIR_HOST} ${STAGING_DIR_NATIVE} 
${CROSS_DIR} ${OECMAKE_PERLNATIVE_DIR} ${OECMAKE_EXTRA_ROOT_PATH} 
${EXTERNAL_TOOLCHAIN} ${HOSTTOOLS_DIR})
 set( CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ${OECMAKE_FIND_ROOT_PATH_MODE} )
 set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ${OECMAKE_FIND_ROOT_PATH_MODE} )
 set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ${OECMAKE_FIND_ROOT_PATH_MODE} )
@@ -113,6 +113,10 @@ list(APPEND CMAKE_MODULE_PATH 
"${STAGING_DATADIR}/cmake/Modules/")
 # add for non /usr/lib libdir, e.g. /usr/lib64
 set( CMAKE_SYSTEM_LIBRARY_PATH ${libdir} ${base_libdir})
 
+# by default CMake only looks in [s]bin subdirectories of CMAKE_FIND_ROOT_PATH
+# adding / makes CMake look for binaries in hosttools too.
+set( CMAKE_SYSTEM_PROGRAM_PATH /)
+
 # avoid treating imports as system includes
 set( CMAKE_NO_SYSTEM_FROM_IMPORTED ON)
 
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/2] piglit: inherit pkgconfig

2018-10-04 Thread Pascal Bach

The CMakeLists.txt of piglit uses pkgconfig internally.
This makes sure pkgconfig-native is available in any case.

Signed-off-by: Pascal Bach 
---
 meta/recipes-graphics/piglit/piglit_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/piglit/piglit_git.bb 
b/meta/recipes-graphics/piglit/piglit_git.bb
index 3292d4cad0..9e45751648 100644
--- a/meta/recipes-graphics/piglit/piglit_git.bb
+++ b/meta/recipes-graphics/piglit/piglit_git.bb
@@ -18,7 +18,7 @@ S = "${WORKDIR}/git"
 
 DEPENDS = "libpng virtual/libx11 libxkbcommon libxrender waffle virtual/libgl 
libglu python3-mako-native python3-numpy-native python3-six-native virtual/egl"
 
-inherit cmake python3native distro_features_check bash-completion
+inherit cmake pkgconfig python3native distro_features_check bash-completion
 # depends on virtual/libx11
 REQUIRED_DISTRO_FEATURES = "x11"
 
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/2] piglit: correctly find wayland include dirs

2018-10-04 Thread Pascal Bach

Builds include host /usr/include as the wrong wayland variable was used.
The issue only surfaces if CMAKE_SYSROOT is properly set.

Signed-off-by: Pascal Bach 
---
 ...-use-proper-WAYLAND_INCLUDE_DIRS-variable.patch | 32 ++
 meta/recipes-graphics/piglit/piglit_git.bb |  1 +
 2 files changed, 33 insertions(+)
 create mode 100644 
meta/recipes-graphics/piglit/piglit/0001-cmake-use-proper-WAYLAND_INCLUDE_DIRS-variable.patch

diff --git 
a/meta/recipes-graphics/piglit/piglit/0001-cmake-use-proper-WAYLAND_INCLUDE_DIRS-variable.patch
 
b/meta/recipes-graphics/piglit/piglit/0001-cmake-use-proper-WAYLAND_INCLUDE_DIRS-variable.patch
new file mode 100644
index 00..5d6ec368ba
--- /dev/null
+++ 
b/meta/recipes-graphics/piglit/piglit/0001-cmake-use-proper-WAYLAND_INCLUDE_DIRS-variable.patch
@@ -0,0 +1,32 @@
+From 3bf1beee1ddd19bc536ff2856e04ac269d43daa2 Mon Sep 17 00:00:00 2001
+From: Pascal Bach 
+Date: Thu, 4 Oct 2018 14:43:17 +0200
+Subject: [PATCH] cmake: use proper WAYLAND_INCLUDE_DIRS variable
+
+WAYLAND_wayland-client_INCLUDEDIR is an internal variable and is not correctly
+set when cross compiling. WAYLAND_INCLUDE_DIRS includes the correct path even
+when cross compiling.
+
+Signed-off-by: Pascal Bach 
+
+Upstream-Status: Submitted [pig...@lists.freedesktop.org]
+---
+ tests/util/CMakeLists.txt | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/tests/util/CMakeLists.txt b/tests/util/CMakeLists.txt
+index a5f080156..a303a9f58 100644
+--- a/tests/util/CMakeLists.txt
 b/tests/util/CMakeLists.txt
+@@ -97,7 +97,7 @@ if(PIGLIT_USE_WAFFLE)
+   piglit-framework-gl/piglit_wl_framework.c
+   )
+   list(APPEND UTIL_GL_INCLUDES
+-  ${WAYLAND_wayland-client_INCLUDEDIR}
++  ${WAYLAND_INCLUDE_DIRS}
+   )
+   endif()
+   if(PIGLIT_HAS_X11)
+-- 
+2.11.0
+
diff --git a/meta/recipes-graphics/piglit/piglit_git.bb 
b/meta/recipes-graphics/piglit/piglit_git.bb
index df810a33b4..3292d4cad0 100644
--- a/meta/recipes-graphics/piglit/piglit_git.bb
+++ b/meta/recipes-graphics/piglit/piglit_git.bb
@@ -5,6 +5,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=b2beded7103a3d8a442a2a0391d607b0"
 SRC_URI = "git://anongit.freedesktop.org/piglit \
file://0001-cmake-install-bash-completions-in-the-right-place.patch 
\
file://0001-tests-Use-FE_UPWARD-only-if-its-defined-in-fenv.h.patch 
\
+   file://0001-cmake-use-proper-WAYLAND_INCLUDE_DIRS-variable.patch \
"
 UPSTREAM_CHECK_COMMITS = "1"
 
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] cmake: add CMAKE_SYSROOT to generated toolchain file

2018-08-24 Thread Pascal Bach

This already got fixed in the toolchain file that is used during development
in 
https://github.com/openembedded/openembedded-core/commit/cb42802f2fe1760f894a435b07286bca3a220364

The toolchain file generated by the cmake.bbclass however does not set
CMAKE_SYSROOT. Under certain circumstances this also leads to the error:
`"stdlib.h: No such file or directory #include_next "`
during the build of a recipe.

An example where this accured was during the upgrade of the Apache Thrift
recipe in meta-openembedded to 0.11.0. With this change the build works out of
the box.

CMAKE_SYSROOT must only be set when crosscompiling, otherwise it will interfere
with the native compiler headers.

Signed-off-by: Pascal Bach 
---
 meta/classes/cmake.bbclass | 5 +
 1 file changed, 5 insertions(+)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index fd40a9863e..251ddd9afe 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -64,9 +64,12 @@ def map_target_arch_to_uname_arch(target_arch):
 return "ppc64"
 return target_arch
 
+
 cmake_do_generate_toolchain_file() {
if [ "${BUILD_SYS}" = "${HOST_SYS}" ]; then
cmake_crosscompiling="set( CMAKE_CROSSCOMPILING FALSE )"
+   else
+   cmake_sysroot="set( CMAKE_SYSROOT \"${RECIPE_SYSROOT}\" )"
fi
cat > ${WORKDIR}/toolchain.cmake <http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] kbd: avoid conflict with busybox

2018-03-08 Thread Pascal Bach

showkey can also be provided by busybox

Signed-off-by: Pascal Bach <pascal.b...@siemens.com>
---
 meta/recipes-core/kbd/kbd_2.0.4.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/kbd/kbd_2.0.4.bb 
b/meta/recipes-core/kbd/kbd_2.0.4.bb
index 80808af135..4af3256fff 100644
--- a/meta/recipes-core/kbd/kbd_2.0.4.bb
+++ b/meta/recipes-core/kbd/kbd_2.0.4.bb
@@ -58,7 +58,7 @@ RDEPENDS_${PN}-ptest = "make"
 
 inherit update-alternatives
 
-ALTERNATIVE_${PN} = "chvt deallocvt fgconsole openvt"
+ALTERNATIVE_${PN} = "chvt deallocvt fgconsole openvt showkey"
 ALTERNATIVE_PRIORITY = "100"
 
 BBCLASSEXTEND = "native"
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] bmap-tools: add missing runtime dependencies

2017-10-18 Thread Pascal Bach

On 16.10.2017 12:27, Alexander Kanavin wrote:
> On 10/14/2017 09:11 AM, Tim Orling wrote:
>>
>>> On Oct 13, 2017, at 4:14 AM, Pascal Bach <pascal.b...@siemens.com> wrote:
>>>
>>> When running bmap on a target device the added dependncies are required.
>>>
>>> Signed-off-by: Pascal Bach <pascal.b...@siemens.com>
>>> ---
>>> meta/recipes-support/bmap-tools/bmap-tools_3.4.bb | 12 +++-
>>> 1 file changed, 11 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/meta/recipes-support/bmap-tools/bmap-tools_3.4.bb 
>>> b/meta/recipes-support/bmap-tools/bmap-tools_3.4.bb
>>> index 7454f9d..348c9e8 100644
>>> --- a/meta/recipes-support/bmap-tools/bmap-tools_3.4.bb
>>> +++ b/meta/recipes-support/bmap-tools/bmap-tools_3.4.bb
>>> @@ -14,7 +14,17 @@ SRCREV = "9dad724104df265442226972a1e310813f9ffcba"
>>>
>>> S = "${WORKDIR}/git"
>>>
>>> -RDEPENDS_${PN} = "python-core python-compression python-mmap"
>>> +RDEPENDS_${PN} = "\
>>> +    python-core \
>>> +    python-compression \
>>> +    python-argparse \
>>> +    python-shell \
>>> +    python-fcntl \
>>> +    python-threading \
>>> +    python-xml \
>>> +    python-subprocess \
>>> +    python-mmap \
>>> +    “
>>>
>>
>> These should all be the python3- version or ${PYTHON_PN}- (e.g. 
>> python3-core) should they not? Or is that an artifact of how the python 
>> module splitting is happening in oe-core?
>
> That is correct. This was forgotten when the recipe was moved to python3:
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-support/bmap-tools/bmap-tools_3.4.bb?id=04ef46e2b2b753321408db02a2df3753b85ac0dd
>
> Pascal, can you modify everything to python3-*, check that it still works, 
> and resend the patch please?

I will do that and send a new patch.

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] bmap-tools: add missing runtime dependencies

2017-10-13 Thread Pascal Bach

When running bmap on a target device the added dependncies are required.

Signed-off-by: Pascal Bach <pascal.b...@siemens.com>
---
 meta/recipes-support/bmap-tools/bmap-tools_3.4.bb | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-support/bmap-tools/bmap-tools_3.4.bb 
b/meta/recipes-support/bmap-tools/bmap-tools_3.4.bb
index 7454f9d..348c9e8 100644
--- a/meta/recipes-support/bmap-tools/bmap-tools_3.4.bb
+++ b/meta/recipes-support/bmap-tools/bmap-tools_3.4.bb
@@ -14,7 +14,17 @@ SRCREV = "9dad724104df265442226972a1e310813f9ffcba"
 
 S = "${WORKDIR}/git"
 
-RDEPENDS_${PN} = "python-core python-compression python-mmap"
+RDEPENDS_${PN} = "\
+python-core \
+python-compression \
+python-argparse \
+python-shell \
+python-fcntl \
+python-threading \
+python-xml \
+python-subprocess \
+python-mmap \
+"
 
 inherit python3native
 inherit setuptools3
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] ca-certificates: move update-ca-certificates into separate package

2017-10-12 Thread Pascal Bach

This allows using the script in with an other certificate bundle even if
the user doesn't need all the certificates.

The scripts are still installed when the ca-certificates is installed
as it RDEPENDS ca-certificates-scripts.

Signed-off-by: Pascal Bach <pascal.b...@siemens.com>
---
 meta/recipes-support/ca-certificates/ca-certificates_20170717.bb | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-support/ca-certificates/ca-certificates_20170717.bb 
b/meta/recipes-support/ca-certificates/ca-certificates_20170717.bb
index 59e7d51..0413762 100644
--- a/meta/recipes-support/ca-certificates/ca-certificates_20170717.bb
+++ b/meta/recipes-support/ca-certificates/ca-certificates_20170717.bb
@@ -79,6 +79,10 @@ do_install_append_class-native () {
 SYSROOT="${D}${base_prefix}" ${D}${sbindir}/update-ca-certificates
 }
 
-RDEPENDS_${PN} += "openssl"
+# This contains only the update script to be used without custom certificates
+PACKAGES =+ "${PN}-scripts"
+FILES_${PN}-scripts = "${sbindir}/ ${sysconfdir}/ca-certificates"
+RDEPENDS_${PN}-scripts += "openssl"
+RDEPENDS_${PN} += "${PN}-scripts"
 
 BBCLASSEXTEND = "native nativesdk"
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/2] openssl: disable weak ciphers

2017-07-05 Thread Pascal Bach


On 05.07.2017 09:58, kai.k...@windriver.com wrote:
> From: Kai Kang 
>
> Check distro feature 'openssl-no-weak-ciphers' to disable weak ciphers
> provided by openssl:
>
> * des
> * ec
> * ecdh
> * ecdsa
> * md2
> * mdc2
Why are the elliptic curve ciphers considered weak?
I'm wondering because Mozilla 
(https://wiki.mozilla.org/Security/Server_Side_TLS) is recommending ECDSA.

Pascal

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] image.bbclass: allow override of image LICENSE

2017-05-03 Thread Pascal Bach

Currently the LICENSE of every image is hard set to MIT.
This allows this to be overriden in derived images.

Signed-off-by: Pascal Bach <pascal.b...@siemens.com>
---
 meta/classes/image.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 405fd73..0fc8752 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -9,7 +9,7 @@ TOOLCHAIN_TARGET_TASK += "${PACKAGE_INSTALL}"
 TOOLCHAIN_TARGET_TASK_ATTEMPTONLY += "${PACKAGE_INSTALL_ATTEMPTONLY}"
 POPULATE_SDK_POST_TARGET_COMMAND += "rootfs_sysroot_relativelinks; "
 
-LICENSE = "MIT"
+LICENSE ?= "MIT"
 PACKAGES = ""
 DEPENDS += "${MLPREFIX}qemuwrapper-cross depmodwrapper-cross"
 RDEPENDS += "${PACKAGE_INSTALL} ${LINGUAS_INSTALL}"
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Passing additional data from packages to be used during image creation

2017-01-24 Thread Pascal Bach



On 21.01.2017 12:44, Richard Purdie wrote:
> On Thu, 2017-01-19 at 10:16 +0100, Pascal Bach wrote:
>> I would like to pass some additional data generated during the
>> creation of a package to the image creation step.
>> The idea is to use this data to generate a more detailed manifest of
>> what is included in the image. In the concrete case
>> I would like to pass a list of required copyright files that need to
>> be checked for during image creation.
>>
>> My current approach is to add this list as a new variable COPYRIGHTS
>> to the pkgdata of each package.
>> Using the image manifest to determine the package this allows me to
>> compile a list of all required copyrights.
>>
>> The following patch allows to add extra variables to pkgdata and thus
>> allows to pass additional data
>>
>> - [PATCH] package.bbclass: allow additional variables to be added to
>>
>> Is this a valid approach or did a miss a simpler way to access any
>> package data during image creation?
> I'm curious if adding something to PACKAGEVARS would work or if not,
> why not?
Just adding it to PACKAGEVARS is not enough as the list of variables written to 
the pkgdata files is hard coded in emit_pkgdata here: 
https://github.com/openembedded/openembedded-core/blob/master/meta/classes/package.bbclass#L1365

However I notices an issue with the code as it seams the do_package step is not 
triggered if a variable in PACKAGE_EXTRA_PKGDATA changes. I'm not sure why as 
it should be
added as a vardeps to the do_package task. For example if I add "COPYRIGHTS" to 
PACKAGE_EXTRA_PKGDATA and than change the COPYRIGHTS variable in a recipe the 
do_package step doesn't get executed.
I'm trying to figure out why but if somebody can spot what I did wrong this 
would be appreciated.

Pascal


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] package.bbclass: allow additional variables to be added to pkgdata

2017-01-19 Thread Pascal Bach

Adding variable names to the variable PACKAGE_EXTRA_PKGDATA allows including
this variables in the pkgdata file of a package.

For example PACKAGE_EXTRA_PKGDATA = "MACHINE" will add the MACHINE variable to
pkgdata. These fields can be used later in the process by some custom package
processing for example during image creation.

Signed-off-by: Pascal Bach <pascal.b...@siemens.com>
---
 meta/classes/package.bbclass | 8 +++-
 meta/conf/documentation.conf | 1 +
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 568b85c..2ed1ecc 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -1388,6 +1388,11 @@ python emit_pkgdata() {
 write_if_exists(sf, pkg, 'FILERDEPENDS_' + dfile)
 
 sf.write('%s_%s: %d\n' % ('PKGSIZE', pkg, total_size))
+
+# Write additional variables listed in PACKAGE_EXTRA_PKGDATA
+for extra_var in (d.getVar('PACKAGE_EXTRA_PKGDATA') or "").split():
+write_if_exists(sf, pkg, extra_var)
+
 sf.close()
 
 # Symlinks needed for rprovides lookup
@@ -1986,12 +1991,13 @@ python package_depchains() {
 
 # Since bitbake can't determine which variables are accessed during package
 # iteration, we need to list them here:
-PACKAGEVARS = "FILES RDEPENDS RRECOMMENDS SUMMARY DESCRIPTION RSUGGESTS 
RPROVIDES RCONFLICTS PKG ALLOW_EMPTY pkg_postinst pkg_postrm INITSCRIPT_NAME 
INITSCRIPT_PARAMS DEBIAN_NOAUTONAME ALTERNATIVE PKGE PKGV PKGR USERADD_PARAM 
GROUPADD_PARAM CONFFILES SYSTEMD_SERVICE LICENSE SECTION pkg_preinst pkg_prerm 
RREPLACES GROUPMEMS_PARAM SYSTEMD_AUTO_ENABLE"
+PACKAGEVARS = "FILES RDEPENDS RRECOMMENDS SUMMARY DESCRIPTION RSUGGESTS 
RPROVIDES RCONFLICTS PKG ALLOW_EMPTY pkg_postinst pkg_postrm INITSCRIPT_NAME 
INITSCRIPT_PARAMS DEBIAN_NOAUTONAME ALTERNATIVE PKGE PKGV PKGR USERADD_PARAM 
GROUPADD_PARAM CONFFILES SYSTEMD_SERVICE LICENSE SECTION pkg_preinst pkg_prerm 
RREPLACES GROUPMEMS_PARAM SYSTEMD_AUTO_ENABLE PACKAGE_EXTRA_PKGDATA"
 
 def gen_packagevar(d):
 ret = []
 pkgs = (d.getVar("PACKAGES") or "").split()
 vars = (d.getVar("PACKAGEVARS") or "").split()
+vars.extend((d.getVar("PACKAGE_EXTRA_PKGDATA") or "").split())
 for p in pkgs:
 for v in vars:
 ret.append(v + "_" + p)
diff --git a/meta/conf/documentation.conf b/meta/conf/documentation.conf
index 06527cb..e0fb8cf 100644
--- a/meta/conf/documentation.conf
+++ b/meta/conf/documentation.conf
@@ -311,6 +311,7 @@ PACKAGE_BEFORE_PN[doc] = "Enables easily adding packages to 
PACKAGES before ${PN
 PACKAGE_CLASSES[doc] = "This variable specifies the package manager to use 
when packaging data. It is set in the conf/local.conf file in the Build 
Directory."
 PACKAGE_EXCLUDE[doc] = "Packages to exclude from the installation. If a listed 
package is required, an error is generated."
 PACKAGE_EXTRA_ARCHS[doc] = "Specifies the list of architectures compatible 
with the device CPU. This variable is useful when you build for several 
different devices that use miscellaneous processors."
+PACKAGE_EXTRA_PKGDATA[doc] = "Additional variables to be included in a 
packages pkgdata."
 PACKAGE_GROUP[doc] = "Defines one or more packages to include in an image when 
a specific item is included in IMAGE_FEATURES."
 PACKAGE_INSTALL[doc] = "List of the packages to be installed into the image. 
The variable is generally not user-defined and uses IMAGE_INSTALL as part of 
the list."
 PACKAGE_INSTALL_ATTEMPTONLY[doc] = "List of packages attempted to be 
installed. If a listed package fails to install, the build system does not 
generate an error. This variable is generally not user-defined."
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Passing additional data from packages to be used during image creation

2017-01-19 Thread Pascal Bach

I would like to pass some additional data generated during the creation of a 
package to the image creation step.
The idea is to use this data to generate a more detailed manifest of what is 
included in the image. In the concrete case
I would like to pass a list of required copyright files that need to be checked 
for during image creation.

My current approach is to add this list as a new variable COPYRIGHTS to the 
pkgdata of each package.
Using the image manifest to determine the package this allows me to compile a 
list of all required copyrights.

The following patch allows to add extra variables to pkgdata and thus allows to 
pass additional data

- [PATCH] package.bbclass: allow additional variables to be added to

Is this a valid approach or did a miss a simpler way to access any package data 
during image creation?

Pascal
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] The future of qemuarm

2016-10-17 Thread Pascal Bach


>
> Whatever we replace it with has to be part of linux-yocto and the meta data 
> that is
> carried there, so it can be used for the sanity/smoke test machine for arch 
> arm.
>
> As such, it has to be feature compatible (network capabilities, disk boot, 
> etc) with
> the existing arm versatile 926ejs platform
>
> There have been newer variants for ages, but since there's been no compelling
> reason to upgrade, I continue to carry the existing platform support along to 
> the
> new kernels. (In fact, I've had a qemuarma9 around for nearly 3 years now, but
> it lacked some disk controller support).
My main motivation is to get valgrind running. This requires at least armv7 to 
be useful.
Most physical boards are not powerful enough (memory and cpu) to do real work 
with valgrind.
QEMU would be helpful for that.
>
> From the kernel point of view, updating the platform doesn't have any big 
> benefits,
> but for userspace it could shake out issues with toolchains and instructions, 
> so
> there is a gain to be had there.
In order to find more bugs there would be multiple qemuarms (qemuarm = armv5, 
qemuarmv7 = armv7, ...).
Is this what you are suggesting?
>
> If someone is motivated, I'm happy to help work on an update to the core 
> qemuarm
> platform .. it just has to meet the criteria above.
>

Pascal
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] The future of qemuarm

2016-10-17 Thread Pascal Bach


>
> Is the goal to increase the default to a higher arm version?
>
> Is there a bsp layer for other qemuarm variants (cortex-a8, ...)?
>
>
> There is a qemuarm64 in master which is aarch64 based.
>
I'm aware of qemuarm64 but I was more talking about 32-bit arm.

Pascal
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] The future of qemuarm

2016-10-17 Thread Pascal Bach

Hi

I read several discussions about lifting the default qemuarm target to armv7 or 
higher.
On the mailinglist and on the internet I also found several mentions about 
machines qemuarmv7 and qemuarma8, but I didn't find any working machine configs 
for them.

What are the planes here?

Is the goal to increase the default to a higher arm version?

Is there a bsp layer for other qemuarm variants (cortex-a8, ...)?

Regards
Pascal

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [krogoth][PATCH] glibc: fix CVE-2016-1234, CVE-2016-3075, CVE-2016-5417

2016-10-14 Thread Pascal Bach

Only relevant for krogoth since version 2.24+ (master, morty) is not affected.

Signed-off-by: Pascal Bach <pascal.b...@siemens.com>
---
 meta/recipes-core/glibc/glibc/CVE-2016-1234.patch | 427 ++
 meta/recipes-core/glibc/glibc/CVE-2016-3075.patch |  37 ++
 meta/recipes-core/glibc/glibc/CVE-2016-5417.patch |  28 ++
 meta/recipes-core/glibc/glibc_2.23.bb |   3 +
 4 files changed, 495 insertions(+)
 create mode 100644 meta/recipes-core/glibc/glibc/CVE-2016-1234.patch
 create mode 100644 meta/recipes-core/glibc/glibc/CVE-2016-3075.patch
 create mode 100644 meta/recipes-core/glibc/glibc/CVE-2016-5417.patch

diff --git a/meta/recipes-core/glibc/glibc/CVE-2016-1234.patch 
b/meta/recipes-core/glibc/glibc/CVE-2016-1234.patch
new file mode 100644
index 000..e0d45c6
--- /dev/null
+++ b/meta/recipes-core/glibc/glibc/CVE-2016-1234.patch
@@ -0,0 +1,427 @@
+glibc-2.23: Fix CVE-2016-1234
+
+[No upstream tracking] -- https://bugzilla.redhat.com/show_bug.cgi?id=1315647
+
+glob: Do not copy d_name field of struct dirent
+
+Instead, we store the data we need from the return value of
+readdir in an object of the new type struct readdir_result.
+This type is independent of the layout of struct dirent.
+
+Upstream-Status: Backport
+CVE: CVE-2016-1234
+Signed-off-by: Andrej Valek <andrej.va...@siemens.com>
+Signed-off-by: Pascal Bach <pascal.b...@siemens.com>
+
+diff --git a/posix/bug-glob2.c b/posix/bug-glob2.c
+index ddf5ec9..22ea35f 100644
+--- a/posix/bug-glob2.c
 b/posix/bug-glob2.c
+@@ -40,6 +40,17 @@
+ # define PRINTF(fmt, args...)
+ #endif
+ 
++#define LONG_NAME \
++  "xx" \
++  "xx" \
++  "xx" \
++  "xx" \
++  "xx" \
++  "xx" \
++  "xx" \
++  "xx" \
++  "xx" \
++  "xx"
+ 
+ static struct
+ {
+@@ -58,6 +69,7 @@ static struct
+   { ".", 3, DT_DIR, 0755 },
+   { "..", 3, DT_DIR, 0755 },
+   { "a", 3, DT_REG, 0644 },
++  { LONG_NAME, 3, DT_REG, 0644 },
+ { "unreadable", 2, DT_DIR, 0111 },
+   { ".", 3, DT_DIR, 0111 },
+   { "..", 3, DT_DIR, 0755 },
+@@ -75,7 +87,7 @@ typedef struct
+   int level;
+   int idx;
+   struct dirent d;
+-  char room_for_dirent[NAME_MAX];
++  char room_for_dirent[sizeof (LONG_NAME)];
+ } my_DIR;
+ 
+ 
+@@ -193,7 +205,7 @@ my_readdir (void *gdir)
+   return NULL;
+ }
+ 
+-  dir->d.d_ino = dir->idx;
++  dir->d.d_ino = 1; /* glob should not skip this entry.  */
+ 
+ #ifdef _DIRENT_HAVE_D_TYPE
+   dir->d.d_type = filesystem[dir->idx].type;
+diff --git a/posix/glob.c b/posix/glob.c
+index 0c04c3c..6c6612d 100644
+--- a/posix/glob.c
 b/posix/glob.c
+@@ -24,7 +24,9 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include 
++#include 
+ 
+ /* Outcomment the following line for production quality code.  */
+ /* #define NDEBUG 1 */
+@@ -57,10 +59,8 @@
+ 
+ #if defined HAVE_DIRENT_H || defined __GNU_LIBRARY__
+ # include 
+-# define NAMLEN(dirent) strlen((dirent)->d_name)
+ #else
+ # define dirent direct
+-# define NAMLEN(dirent) (dirent)->d_namlen
+ # ifdef HAVE_SYS_NDIR_H
+ #  include 
+ # endif
+@@ -75,82 +75,8 @@
+ # endif /* HAVE_VMSDIR_H */
+ #endif
+ 
+-
+-/* In GNU systems,  defines this macro for us.  */
+-#ifdef _D_NAMLEN
+-# undef NAMLEN
+-# define NAMLEN(d) _D_NAMLEN(d)
+-#endif
+-
+-/* When used in the GNU libc the symbol _DIRENT_HAVE_D_TYPE is available
+-   if the `d_type' member for `struct dirent' is available.
+-   HAVE_STRUCT_DIRENT_D_TYPE plays the same role in GNULIB.  */
+-#if defined _DIRENT_HAVE_D_TYPE || defined HAVE_STRUCT_DIRENT_D_TYPE
+-/* True if the directory entry D must be of type T.  */
+-# define DIRENT_MUST_BE(d, t) ((d)->d_type == (t))
+-
+-/* True if the directory entry D might be a symbolic link.  */
+-# define DIRENT_MIGHT_BE_SYMLINK(d) \
+-((d)->d_type == DT_UNKNOWN || (d)->d_type == DT_LNK)
+-
+-/* True if the directory entry D might be a directory.  */
+-# define DIRENT_MIGHT_BE_DIR(d)\
+-((d)->d_type == DT_DIR || DIRENT_MIGHT_BE_SYMLINK (d))
+-
+-#else /* !HAVE_D_TYPE */
+-# define DIRENT_MUST_BE(d, t) false
+-# define DIRENT_MIGHT_BE_SYMLINK(d)   true
+-# define DIRENT_MIGHT_BE_DIR(d)   true
+-#endif /* HAVE_D_TYPE */
+-
+-/* If the system has the `struct dirent64' type we use it internally.  */
+-#if defined _LIBC && !defined COMPILE_GLOB64
+-# if def

[OE-core] [PATCH] ptest-runner: allow building from externalsrc

2016-09-14 Thread Pascal Bach

From: Christian Schuler <schuler.christ...@siemens.com>

The ${WORKDIR}/git refers to the source folder S which is different in
the case of an external source build.

Signed-off-by: Christian Schuler <schuler.christ...@siemens.com>
Signed-off-by: Pascal Bach <pascal.b...@siemens.com>
---
 meta/recipes-support/ptest-runner/ptest-runner_2.0.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-support/ptest-runner/ptest-runner_2.0.bb 
b/meta/recipes-support/ptest-runner/ptest-runner_2.0.bb
index 7081afb..aaa7c59 100644
--- a/meta/recipes-support/ptest-runner/ptest-runner_2.0.bb
+++ b/meta/recipes-support/ptest-runner/ptest-runner_2.0.bb
@@ -22,5 +22,5 @@ do_compile () {
 }
 
 do_install () {
-   install -D -m 0755 ${WORKDIR}/git/ptest-runner 
${D}${bindir}/ptest-runner
+   install -D -m 0755 ${S}/ptest-runner ${D}${bindir}/ptest-runner
 }
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] util-linux: make prlimit a separate package

2016-08-04 Thread Pascal Bach

Busybox doesn't provide a similar tool so having it in
a separate package allows to us it in addition to busybox without having
to include all of util-linux.

Before it was part of the top level util-linux package.
Now it is a separate package util-linux-prlimit but the top level package
still RRECOMMENDS it so for most users nothing should change.

Signed-off-by: Pascal Bach <pascal.b...@siemens.com>
---
 meta/recipes-core/util-linux/util-linux.inc | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-core/util-linux/util-linux.inc 
b/meta/recipes-core/util-linux/util-linux.inc
index bac1a37..5236209 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -32,7 +32,7 @@ PACKAGES =+ "util-linux-agetty util-linux-fdisk 
util-linux-cfdisk util-linux-sfd
  util-linux-mkfs util-linux-mcookie util-linux-reset \
  util-linux-mkfs.cramfs util-linux-fsck.cramfs util-linux-fstrim \
  util-linux-partx util-linux-hwclock util-linux-mountpoint \
- util-linux-findfs util-linux-getopt util-linux-sulogin"
+ util-linux-findfs util-linux-getopt util-linux-sulogin 
util-linux-prlimit"
 PACKAGES += "${@bb.utils.contains('PACKAGECONFIG', 'pylibmount', 
'util-linux-pylibmount', '', d)}"
 PACKAGES =+ "${@bb.utils.contains('DISTRO_FEATURES', 'pam', 
'util-linux-runuser', '', d)}"
 
@@ -88,6 +88,7 @@ FILES_util-linux-hwclock = "${base_sbindir}/hwclock.${BPN}"
 FILES_util-linux-findfs = "${sbindir}/findfs"
 FILES_util-linux-getopt = "${base_bindir}/getopt.${BPN}"
 FILES_util-linux-runuser = "${sbindir}/runuser"
+FILES_util-linux-prlimit = "${bindir}/prlimit"
 
 FILES_util-linux-pylibmount = 
"${PYTHON_SITEPACKAGES_DIR}/libmount/pylibmount.so \
${PYTHON_SITEPACKAGES_DIR}/libmount/__init__.* \
@@ -116,7 +117,7 @@ RDEPENDS_util-linux-runuser += "libpam"
 RDEPENDS_${PN} = "util-linux-umount util-linux-swaponoff util-linux-losetup 
util-linux-sulogin"
 RDEPENDS_${PN} += "${@bb.utils.contains('DISTRO_FEATURES', 'pam', 
'util-linux-runuser', '', d)}"
 
-RRECOMMENDS_${PN} = "util-linux-fdisk util-linux-cfdisk util-linux-sfdisk 
util-linux-mount util-linux-readprofile util-linux-mkfs util-linux-mountpoint"
+RRECOMMENDS_${PN} = "util-linux-fdisk util-linux-cfdisk util-linux-sfdisk 
util-linux-mount util-linux-readprofile util-linux-mkfs util-linux-mountpoint 
util-linux-prlimit"
 
 RRECOMMENDS_${PN}_class-native = ""
 RRECOMMENDS_${PN}_class-nativesdk = ""
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [krogoth][PATCH] gcc, qemuppc: Explicitly disable forcing SPE flags for 4.9

2016-08-04 Thread Pascal Bach

Any chance this will be merged to krogoth?


On 15.07.2016 16:43, Pascal Bach wrote:
> Hi Armin
>
> The patch only modifies an existing patch which already has a header.
> I really just did the minimum change by copying and adapting the missing 
> section from the corresponding patch for 5.3. to make qemuppc work again.
>
> Pascal
>
> On 15.07.2016 16:20, akuster808 wrote:
>> Pascal,
>>
>> The "0049-Enable-SPE-AltiVec-generation-on-powepc-linux-target.patch" is
>> missing the OE patch standard header information.
>>
>> please see http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
>>
>> Also, there is no .bb update so this patch will be applied.
>>
>> regards,
>> Armin
>>
>> On 07/15/2016 06:22 AM, Pascal Bach wrote:
>>> This ports the missing changes from commit: 
>>> 7a51776a830167e43cbd185505f62f328704e271
>>> from 5.3 to 4.9 so that qemuppc can be compiled.
>>>
>>> Signed-off-by: Pascal Bach <pascal.b...@siemens.com>
>>> ---
>>>  ...Enable-SPE-AltiVec-generation-on-powepc-linux-target.patch | 11 
>>> +++
>>>  1 file changed, 11 insertions(+)
>>>
>>> diff --git 
>>> a/meta/recipes-devtools/gcc/gcc-4.9/0049-Enable-SPE-AltiVec-generation-on-powepc-linux-target.patch
>>>  
>>> b/meta/recipes-devtools/gcc/gcc-4.9/0049-Enable-SPE-AltiVec-generation-on-powepc-linux-target.patch
>>> index b98f8ff..77fa18a 100644
>>> --- 
>>> a/meta/recipes-devtools/gcc/gcc-4.9/0049-Enable-SPE-AltiVec-generation-on-powepc-linux-target.patch
>>> +++ 
>>> b/meta/recipes-devtools/gcc/gcc-4.9/0049-Enable-SPE-AltiVec-generation-on-powepc-linux-target.patch
>>> @@ -37,6 +37,17 @@ index cb7a94e..d392c2b 100644
>>> extra_options="${extra_options} rs6000/sysv4.opt"
>>> tmake_file="rs6000/t-fprules rs6000/t-ppcos ${tmake_file} 
>>> rs6000/t-ppccomm"
>>> case ${target} in
>>> +Index: gcc-4.9.3/gcc/config/rs6000/linuxspe.h
>>> +===
>>> +--- gcc-4.9.3.orig/gcc/config/rs6000/linuxspe.h
>>>  gcc-4.9.3/gcc/config/rs6000/linuxspe.h
>>> +@@ -27,6 +27,3 @@
>>> + #undefTARGET_DEFAULT
>>> + #define TARGET_DEFAULT MASK_STRICT_ALIGN
>>> + #endif
>>> +-
>>> +-#undef  ASM_DEFAULT_SPEC
>>> +-#define   ASM_DEFAULT_SPEC "-mppc -mspe -me500"
>>>  -- 
>>>  1.7.9.5
>>>  
>>>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [krogoth][PATCH] gcc, qemuppc: Explicitly disable forcing SPE flags for 4.9

2016-07-15 Thread Pascal Bach

Hi Armin

The patch only modifies an existing patch which already has a header.
I really just did the minimum change by copying and adapting the missing 
section from the corresponding patch for 5.3. to make qemuppc work again.

Pascal

On 15.07.2016 16:20, akuster808 wrote:
> Pascal,
>
> The "0049-Enable-SPE-AltiVec-generation-on-powepc-linux-target.patch" is
> missing the OE patch standard header information.
>
> please see http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
>
> Also, there is no .bb update so this patch will be applied.
>
> regards,
> Armin
>
> On 07/15/2016 06:22 AM, Pascal Bach wrote:
>> This ports the missing changes from commit: 
>> 7a51776a830167e43cbd185505f62f328704e271
>> from 5.3 to 4.9 so that qemuppc can be compiled.
>>
>> Signed-off-by: Pascal Bach <pascal.b...@siemens.com>
>> ---
>>  ...Enable-SPE-AltiVec-generation-on-powepc-linux-target.patch | 11 
>> +++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git 
>> a/meta/recipes-devtools/gcc/gcc-4.9/0049-Enable-SPE-AltiVec-generation-on-powepc-linux-target.patch
>>  
>> b/meta/recipes-devtools/gcc/gcc-4.9/0049-Enable-SPE-AltiVec-generation-on-powepc-linux-target.patch
>> index b98f8ff..77fa18a 100644
>> --- 
>> a/meta/recipes-devtools/gcc/gcc-4.9/0049-Enable-SPE-AltiVec-generation-on-powepc-linux-target.patch
>> +++ 
>> b/meta/recipes-devtools/gcc/gcc-4.9/0049-Enable-SPE-AltiVec-generation-on-powepc-linux-target.patch
>> @@ -37,6 +37,17 @@ index cb7a94e..d392c2b 100644
>>  extra_options="${extra_options} rs6000/sysv4.opt"
>>  tmake_file="rs6000/t-fprules rs6000/t-ppcos ${tmake_file} 
>> rs6000/t-ppccomm"
>>  case ${target} in
>> +Index: gcc-4.9.3/gcc/config/rs6000/linuxspe.h
>> +===
>> +--- gcc-4.9.3.orig/gcc/config/rs6000/linuxspe.h
>>  gcc-4.9.3/gcc/config/rs6000/linuxspe.h
>> +@@ -27,6 +27,3 @@
>> + #undef TARGET_DEFAULT
>> + #define TARGET_DEFAULT MASK_STRICT_ALIGN
>> + #endif
>> +-
>> +-#undef  ASM_DEFAULT_SPEC
>> +-#defineASM_DEFAULT_SPEC "-mppc -mspe -me500"
>>  -- 
>>  1.7.9.5
>>  
>>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [krogoth][PATCH] gcc, qemuppc: Explicitly disable forcing SPE flags for 4.9

2016-07-15 Thread Pascal Bach

This ports the missing changes from commit: 
7a51776a830167e43cbd185505f62f328704e271
from 5.3 to 4.9 so that qemuppc can be compiled.

Signed-off-by: Pascal Bach <pascal.b...@siemens.com>
---
 ...Enable-SPE-AltiVec-generation-on-powepc-linux-target.patch | 11 +++
 1 file changed, 11 insertions(+)

diff --git 
a/meta/recipes-devtools/gcc/gcc-4.9/0049-Enable-SPE-AltiVec-generation-on-powepc-linux-target.patch
 
b/meta/recipes-devtools/gcc/gcc-4.9/0049-Enable-SPE-AltiVec-generation-on-powepc-linux-target.patch
index b98f8ff..77fa18a 100644
--- 
a/meta/recipes-devtools/gcc/gcc-4.9/0049-Enable-SPE-AltiVec-generation-on-powepc-linux-target.patch
+++ 
b/meta/recipes-devtools/gcc/gcc-4.9/0049-Enable-SPE-AltiVec-generation-on-powepc-linux-target.patch
@@ -37,6 +37,17 @@ index cb7a94e..d392c2b 100644
extra_options="${extra_options} rs6000/sysv4.opt"
tmake_file="rs6000/t-fprules rs6000/t-ppcos ${tmake_file} 
rs6000/t-ppccomm"
case ${target} in
+Index: gcc-4.9.3/gcc/config/rs6000/linuxspe.h
+===
+--- gcc-4.9.3.orig/gcc/config/rs6000/linuxspe.h
 gcc-4.9.3/gcc/config/rs6000/linuxspe.h
+@@ -27,6 +27,3 @@
+ #undefTARGET_DEFAULT
+ #define TARGET_DEFAULT MASK_STRICT_ALIGN
+ #endif
+-
+-#undef  ASM_DEFAULT_SPEC
+-#define   ASM_DEFAULT_SPEC "-mppc -mspe -me500"
 -- 
 1.7.9.5
 
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] rebuilding external kernel modules when kernel changed

2016-06-21 Thread Pascal Bach


> What version are you using?
I'm using poky, the latest krogoth branch
> Are you using rm_work?
No rm_work is not used.
>
> Check https://bugzilla.yoctoproject.org/show_bug.cgi?id=9352 
I think the issue is relate but not the same. For me the simplest solution i 
found was to make sure do_make_scripts of any kernel module was executed after 
the kernel was rebuilt.
But I didn't find a way to make bitbake do this automatically.

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] rebuilding external kernel modules when kernel changed

2016-06-21 Thread Pascal Bach

Hello

I ran into an issue when working with kernel modules that are not part of the 
kernel source tree.

The issue manifests itself as follows:

1. Build an image containing virtual/kernel and kernel-module-a

2. Do a `bitbake virtual/kernel -c clean`

3. Rebuild the above image again. This causes the kernel do rebuild and it 
seems that the do_compile task of kernel-module-a is also re-exectued.
But this causes an error as there is some configuration missing in the kernel 
source directory that is created by module.bbclass:do_make_scripts.
I think that the issue is that the do_make_scripts task is not re-executed 
prior to the modules do_compile task.


I tried to teach bitbake to execute do_make_scripts too once the kernel was 
rebuilt, but I didn't find a way.

Any hints how this can be done?

Regards
Pascal

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Problematic IMAGE_FEATURES combination for core-image

2016-06-20 Thread Pascal Bach

Hello

It tried to build an image deived from core-image-minimal-dev with the 
following image features:

IMAGE_FEATURES += "ssh-server-dropbear eclipse-debug dev-pkgs"

But it seems like this combination is not possible as the do_rootfs task fails 
with the following message:

ERROR: core-image-minimal-dev-1.0-r0 do_rootfs:

Collected errors:
 
 * check_conflicts_for: The following packages conflict with openssh:
 
 * check_conflicts_for: dropbear *
 
 * opkg_install: Cannot install package openssh-dev.
 
tetime.
 
 
ERROR: core-image-minimal-dev-1.0-r0 do_rootfs: Function failed: do_rootfs


As far as I understand the problem is the following:

1. ssh-server-dropbear installs dropbear on the target
2. eclipse-debug installs openssh-sftp-server to make dropbear support sftp
3. dev-pkgs installs the dev packages, which causes openssh to be installed as 
well
This then leads to a conflict between openssh and dropbear causing the above 
error message.

Is the above image feature combination supported? If yes what is the correct 
way to do this?

Regards
Pascal

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] qemuppc kernel doesn't build with GCC 4.9 on korgoth

2016-06-16 Thread Pascal Bach


>> On Jun 15, 2016, at 5:31 AM, Pascal Bach <pascal.b...@siemens.com> wrote:
>>
>> Hi
>>
>> I tried to build qemuppc on the latest korgoth branch using the GCC 4.9.3 
>> from OE-core.
>>
>> The problem is that i get an error when trying to build the kernel.
>> I was able to trace the issue back to this commit:
>> https://github.com/openembedded/openembedded-core/commit/7a51776a830167e43cbd185505f62f328704e271
>>
>> And i can confirm that removing TARGET_CC_KERNEL_ARCH = "-mno-spe" from 
>> qemuppc.conf makes it work again.
>>
>> The question is how to best solve this?
>> Do the changes for GCC 5.3.0 that done in the commit mentioned above also 
>> need to be applied to 4.9?
>> Or is it just not supported to build qemuppc with GCC 4.9?
>>
> back port the gcc patch to 4.9
I just noticed it is already backported to 4.9 as 
0049-Enable-SPE-AltiVec-generation-on-powepc-linux-target.patch
Is anybody else using a powerpc machine with Yocto2.1 and GCC4.9?

Regards
Pascal
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] qemuppc kernel doesn't build with GCC 4.9 on korgoth

2016-06-15 Thread Pascal Bach

Hi

I tried to build qemuppc on the latest korgoth branch using the GCC 4.9.3 from 
OE-core.

The problem is that i get an error when trying to build the kernel.
I was able to trace the issue back to this commit:
https://github.com/openembedded/openembedded-core/commit/7a51776a830167e43cbd185505f62f328704e271

And i can confirm that removing TARGET_CC_KERNEL_ARCH = "-mno-spe" from 
qemuppc.conf makes it work again.

The question is how to best solve this?
Do the changes for GCC 5.3.0 that done in the commit mentioned above also need 
to be applied to 4.9?
Or is it just not supported to build qemuppc with GCC 4.9?

Thanks for your help

Pascal

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Debugging using sysroots and GDB

2016-03-08 Thread Pascal Bach


> > The only way I could get this to work is to extract both the rootfs and the 
> > rootfs-dbg into the same place and then set sysroot to that location.
> > Is this the way it is supposed to be?
>
> Yes
>
Ok I was hoping to keep them seperate.
This because I'm using the rootfs for NFS and by having the debug symbols in a 
seperate rootfs-dbg directory they would not be visible from the target.
By setting `PACKAGE_DEBUG_SPLIT_STYLE = "debug-file-directory"` I got this 
working.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Debugging using sysroots and GDB

2016-03-08 Thread Pascal Bach

Hi Andreas
> I am using sysroot for debugging too. I have no
>
> * INHERIT += "rm_work"
>
> and added
>
> INHIBIT_SYSROOT_STRIP = "1"
>
> to my local.conf
>
> I use this approach for very long time now and from my point of view
> it has one BIG advantage: I can use these settings for productive
> images and start remote debug within seconds without further
> rebuilding.
> OK - default compiler optimization sometimes causes headaches but it
> works for solving >80% of my cases. In case I want to debug software
> that I have developed setting optimization recipe wise helps or I
> debug that on PC or target itself.
How do you deal with the case where there is no source in your work dir because 
the package was taken from sstate?
The only solution I found so far is to build without sstate :(

Pascal
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Debugging using sysroots and GDB

2016-03-08 Thread Pascal Bach

Hi Richard
> Using this method is a supported approach. I'm a little surprised
> .debug directories don't work. Have you tried just setting:
>
> set sysroot /home/projects/rootfs-dbg
> set substitute-path /usr/src/debug /home/projects/rootfs
> -bbg/usr/src/debug
This doesn't seem to work (tried only with dizzy).
The only way I could get this to work is to extract both the rootfs and the 
rootfs-dbg into the same place and then set sysroot to that location.
Is this the way it is supposed to be?

>
> as I believe it should work with IMAGE_GEN_DEBUGFS=1 "out the box". If
> it doesn't that is a bug and we should try and look into fixing that.
I'm currently using dizzy. I will give it another try with jethro next week 
maybe it is working there.

Pascal
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Debugging using sysroots and GDB

2016-03-04 Thread Pascal Bach

> It really depends on your view of what the sysroot is used for. We
> intentionally strip a variety of things out of it as things work today
> basically for size/performance reasons. If we start putting debugging
> source in there, it will become huge and this will image the size of
> things like eSDK and affect the speed of operations like building from
> sstate.

>From my point of view debugging from sysroots is not mandatory if I can find a 
>suitable alternative.
One thing I want to avoid is to install -dbg packages to my image.

What I currently do is the following:

1. Enable Debugfs generation using: `IMAGE_GEN_DEBUGFS = "1"`
2. Switch debug split style to: `PACKAGE_DEBUG_SPLIT_STYLE = 
"debug-file-directory"`

After building the image I end up with a rootfs and a rootfs-dbg

3. Extract both rootfs and rootfs-dbg somewhere (/home/projects)
4. Setup gdb with the following .gdbinit:

```
set sysroot /home/projects/rootfs
set debug-file-directory /home/projects/rootfs-dbg/usr/lib/debug
set substitute-path /usr/src/debug /home/projects/rootfs-dbg/usr/src/debug
```

With this setup I'm able to debug trough all libraries on the system.
So so far so good.

However for this to work I need to change the `PACKAGE_DEBUG_SPLIT_STYLE` to a 
non default and this made me wonder if I missed something.
- Is there a way to get this setup working with the default ".debug" style of 
OE?
- If not why is the .debug style the default instead of "debug-file-directory"?
- Is there any documentation? I was unable to find anything more than [1] in 
the Yocto Mega manual.
- Is there some best practice I missed?

[1] 
http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#platdev-gdb-remotedebug-setup


> We don't really support debugging from the sysroot. We could talk about
> changing that but I suspect people wouldn't like the performance
> penalty.
Ok if this is not supported is there any documentation on whats the recommended 
debugging method?
>
> You might ask "ok, can we make it optional?". The trouble with that is
> more code paths which people will complain we're not testing and
> consequently an increased test matrix and even slower patch merging
> cycles.
I agree, there should only be one recommended and supported way to do debugging 
and this way should be well documented.
>
> So the question is, is this something we want to support this way?
>
> Cheers,
>
> Richard
Pascal
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Debugging using sysroots and GDB

2016-03-04 Thread Pascal Bach

ping!
No comment on this topic?

Am 23.02.2016 um 15:09 schrieb Pascal Bach:
> Hi Everybody
>
> Currently debugging using sysroots seems to work as long as the work folder 
> containing the original source is available.
> Once this work dir is gone the debugger is no longer able to find the source 
> code. This is especially confusing if some packages are taken from sstate and 
> others are built in the current projects, because for some libraries the 
> sources can be found and for others not. It is hard at first to figure out 
> the reason why one works and the other not.
>
> In order to make it easier to debug using sysroots I propose to modify the 
> how the sysroots is built to do somethins similar to rootfs:
>
> 1. Changing the source reference in the debug symbols to point to the source 
> under /usr/src/debug
> 2. Copy the sources into /usr/src/debug under sysroots similar to how it is 
> done for a debug rootfs.
> 3. Document that the user needs to add the following to the .gdbinit to make 
> it work:
> ```
> set sysroot /project/oe/build/tmp/sysroots/
> set substitute-path /usr/src/debug 
> /project/oe/build/tmp/sysroots//usr/src/debug
> ```
>
> This would also allow the sysroot to be relocatable as it is kind of 
> standalone and everything required to debug is included.
>
> What do you think? Does this proposal make sense, or did I miss something and 
> this is completly unnecessary and there is an easier way already working?
>
> Regards
> Pascal

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Debugging using sysroots and GDB

2016-02-23 Thread Pascal Bach

Hi Everybody

Currently debugging using sysroots seems to work as long as the work folder 
containing the original source is available.
Once this work dir is gone the debugger is no longer able to find the source 
code. This is especially confusing if some packages are taken from sstate and 
others are built in the current projects, because for some libraries the 
sources can be found and for others not. It is hard at first to figure out the 
reason why one works and the other not.

In order to make it easier to debug using sysroots I propose to modify the how 
the sysroots is built to do somethins similar to rootfs:

1. Changing the source reference in the debug symbols to point to the source 
under /usr/src/debug
2. Copy the sources into /usr/src/debug under sysroots similar to how it is 
done for a debug rootfs.
3. Document that the user needs to add the following to the .gdbinit to make it 
work:
```
set sysroot /project/oe/build/tmp/sysroots/
set substitute-path /usr/src/debug 
/project/oe/build/tmp/sysroots//usr/src/debug
```

This would also allow the sysroot to be relocatable as it is kind of standalone 
and everything required to debug is included.

What do you think? Does this proposal make sense, or did I miss something and 
this is completly unnecessary and there is an easier way already working?

Regards
Pascal
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] lib/oe/terminal: set workdir for konsole terminal

2016-02-12 Thread Pascal Bach

It seems that if the --workdir option is not set konsole does open in the users
home directory. By setting --workdir . konsole opens in the recipes work
directory. This is the same behavior as observed for other consoles.
(Tested with Konsole 2.14.2 on Debian Jessie).


Signed-off-by: Pascal Bach <pascal.b...@siemens.com>
---
 meta/lib/oe/terminal.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oe/terminal.py b/meta/lib/oe/terminal.py
index 1efc06d..634daa9 100644
--- a/meta/lib/oe/terminal.py
+++ b/meta/lib/oe/terminal.py
@@ -83,7 +83,7 @@ class Terminology(XTerminal):
 priority = 2
 
 class Konsole(XTerminal):
-command = 'konsole --nofork -p tabtitle="{title}" -e {command}'
+command = 'konsole --nofork --workdir . -p tabtitle="{title}" -e {command}'
 priority = 2
 
 def __init__(self, sh_cmd, title=None, env=None, d=None):
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] documentation.conf: align the documentation for DEBUG_OPTIMIZATION and FULL_OPTIMIZATION with bitbake.conf

2016-02-02 Thread Pascal Bach

Signed-off-by: Pascal Bach <pascal.b...@siemens.com>
---
 meta/conf/documentation.conf | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/conf/documentation.conf b/meta/conf/documentation.conf
index 1e09b65..00a69da 100644
--- a/meta/conf/documentation.conf
+++ b/meta/conf/documentation.conf
@@ -129,7 +129,7 @@ D[doc] = "The destination directory."
 DATE[doc] = "The date the build was started using YMD format."
 DATETIME[doc] = "The date and time the build was started."
 DEBUG_BUILD[doc] = "Specifies to build packages with debugging information. 
This influences the value of the SELECTED_OPTIMIZATION variable."
-DEBUG_OPTIMIZATION[doc] = "The options to pass in TARGET_CFLAGS and CFLAGS 
when compiling a system for debugging. This variable defaults to '-O 
-fno-omit-frame-pointer -g'."
+DEBUG_OPTIMIZATION[doc] = "The options to pass in TARGET_CFLAGS and CFLAGS 
when compiling a system for debugging. This variable defaults to '-O 
-fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe'."
 DEFAULT_PREFERENCE[doc] = "Specifies a weak bias for recipe selection 
priority."
 DEPENDS[doc] = "Lists a recipe's build-time dependencies (i.e. other recipe 
files)."
 DEPLOY_DIR[doc] = "Points to the general area that the OpenEmbedded build 
system uses to place images, packages, SDKs and other output files that are 
ready to be used outside of the build system."
@@ -177,7 +177,7 @@ FILESPATH[doc] = "The default set of directories the 
OpenEmbedded build system u
 FILESYSTEM_PERMS_TABLES[doc] = "Allows you to define your own file permissions 
settings table as part of your configuration for the packaging process."
 FONT_EXTRA_RDEPENDS[doc] = "When a recipe inherits the fontcache class, this 
variable specifies runtime dependencies for font packages. This variable 
defaults to 'fontconfig-utils'."
 FONT_PACKAGES[doc] = "When a recipe inherits the fontcache class, this 
variable identifies packages containing font files that need to be cached by 
Fontconfig."
-FULL_OPTIMIZATION[doc]= "The options to pass in TARGET_CFLAGS and CFLAGS when 
compiling an optimized system. This variable defaults to 
'-fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2'."
+FULL_OPTIMIZATION[doc]= "The options to pass in TARGET_CFLAGS and CFLAGS when 
compiling an optimized system. This variable defaults to '-O2 -pipe 
${DEBUG_FLAGS}'."
 
 #G
 
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Default value for FULL_OPTIMIZATION

2016-02-02 Thread Pascal Bach



Am 02.02.2016 um 15:26 schrieb Mike Looijmans:
> You'd have to check the GCC documentation to be sure, but I suspect that all 
> of "-fexpensive-optimizations -fomit-frame-pointer -frename-registers" are 
> already in effect at -O2 optimization level, so they're redundant.
>

- "-fexpensive-optimizations" is included in -O2
- "-fomit-frame-pointer" is included in -O but "only on machines where doing so 
does not interfere with debugging", whatever that means ;)
- "-frename-registers" doesn't seem to be included

Soruce: https://gcc.gnu.org/onlinedocs/gcc-5.2.0/gcc/Optimize-Options.html
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Default value for FULL_OPTIMIZATION

2016-02-02 Thread Pascal Bach

Hi everybody

I noticed an inconsistency in oe-core regarding the variable: FULL_OPTIMIZATION

In bitbake.conf the variable is defined as follows:

FULL_OPTIMIZATION = "-O2 -pipe ${DEBUG_FLAGS}"

But if I look into the documentation.conf it tells me the following:

FULL_OPTIMIZATION[doc]= "The options to pass in TARGET_CFLAGS and CFLAGS 
when compiling an optimized system. This variable defaults to 
'-fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2'."

I'm not sure if the documentation is wrong or if the default set in 
bitbake.conf is incorrect.
Maybe somebody can shed some light on this.

Regards
Pascal
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] runqemu: don't complain about conflicting machines if they are equal

2015-09-24 Thread Pascal Bach

When the MACHINE variable was set as an environment variable, via
"export MACHINE=qemuarm" and runqemu was executed as "runqemu qemuarm"

The confusing error message appears:
Error: conflicting MACHINE types [qemuarm] and [qemuarm]

This checks if the two values are equal, in that case there is no problem
and execution can continue.

Signed-off-by: Pascal Bach <pascal.b...@siemens.com>
---
 scripts/runqemu | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 mode change 100755 => 100644 scripts/runqemu

diff --git a/scripts/runqemu b/scripts/runqemu
old mode 100755
new mode 100644
index 23cf5be..5989507
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -111,7 +111,7 @@ while true; do
 case "$arg" in
 "qemux86" | "qemux86-64" | "qemuarm" | "qemuarm64" | "qemumips" | 
"qemumipsel" | \
 "qemumips64" | "qemush4"  | "qemuppc" | "qemumicroblaze" | "qemuzynq")
-[ -z "$MACHINE" ] && MACHINE=$arg || \
+[ -z "$MACHINE" -o "$MACHINE" = "$arg" ] && MACHINE=$arg || \
 error "conflicting MACHINE types [$MACHINE] and [$arg]"
 ;;
 "ext2" | "ext3" | "ext4" | "jffs2" | "nfs" | "btrfs" | "hddimg" | 
"hdddirect" )
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] libpcre: Allow building 16 and 32bit libpcre versions

2015-09-18 Thread Pascal Bach

This change allows selecting the 8, 16 or 32 bit version via PACKAGECONFIG.
By default only the 8bit version is built, this corresponds to the old behavior.

Some packages like Qt5 require the 16 bit version of libpcre.
After this change the corresponding layer can easily enable the version
needed via .bbappend.

Signed-off-by: Pascal Bach <pascal.b...@siemens.com>
---
 meta/recipes-support/libpcre/libpcre_8.37.bb | 5 +
 1 file changed, 5 insertions(+)

diff --git a/meta/recipes-support/libpcre/libpcre_8.37.bb 
b/meta/recipes-support/libpcre/libpcre_8.37.bb
index bcfc9e9..1880639 100644
--- a/meta/recipes-support/libpcre/libpcre_8.37.bb
+++ b/meta/recipes-support/libpcre/libpcre_8.37.bb
@@ -22,6 +22,11 @@ S = "${WORKDIR}/pcre-${PV}"
 PROVIDES += "pcre"
 DEPENDS += "bzip2 zlib"
 
+PACKAGECONFIG ??= "pcre8"
+
+PACKAGECONFIG[pcre8] = "--enable-pcre8,--disable-pcre8"
+PACKAGECONFIG[pcre16] = "--enable-pcre16,--disable-pcre16"
+PACKAGECONFIG[pcre32] = "--enable-pcre32,--disable-pcre32"
 PACKAGECONFIG[pcretest-readline] = 
"--enable-pcretest-libreadline,--disable-pcretest-libreadline,readline,"
 
 BINCONFIG = "${bindir}/pcre-config"
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 21/26] systemd: remove PV from the recipe

2015-07-31 Thread Pascal Bach

Hi

Am 30.07.2015 um 18:35 schrieb Alexander Kanavin:
 On 07/30/2015 07:25 PM, Burton, Ross wrote:

 For the release tag I'd agree with you, but as 219  219-stable we can't
 just change this now (without adding an epoch, and adding epochs are evil).

 Does the RRS have a way of mapping a PV to something that can be used in
 the upstream comparison?

 I just noticed that specifically systemd-stable repository does not have 
 release tags for new versions at all, and just adds branches for newer 
 versions:

 http://cgit.freedesktop.org/systemd/systemd-stable/

New tags for systemd are created but not on the repository above but on their 
git repository:
https://github.com/systemd/systemd

I think this is the now main repository.

Pascal

 RRS does not support branch names as indication of new releases (and it 
 shouldn't IMO), so maybe this patch can be simply dropped, and systemd will 
 not have automatic upstream-check.


 Alex


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 21/26] systemd: remove PV from the recipe

2015-07-31 Thread Pascal Bach


 The idea behind systemd-stable repository is described here:
 http://www.freedesktop.org/wiki/Software/systemd/Backports/

Thanks I didn't know that.

 However, it hasn't received any new commits since early May, and still stuck 
 at v219, so should we update to a new version from the main repository? 
 What's oe-core policy here?

Not sure what would be the right appreoach, I would also be interested to hear 
the policy of oe-core for this.

Pascal
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] nativesdk-qt4-tools: depend on nativesdk-qt4-tools only if DISTRO_FEATURES includes x11

2015-07-27 Thread Pascal Bach

Currently nativesdk-qt4-tools can't be built if the DISTRO_FEATURES doesn't 
contain x11.
To make it build we add a dependency to x11 only if the feature is activated.

Signed-off-by: Pascal Bach pascal.b...@siemens.com
---
 meta/recipes-qt/qt4/nativesdk-qt4-tools.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-qt/qt4/nativesdk-qt4-tools.inc 
b/meta/recipes-qt/qt4/nativesdk-qt4-tools.inc
index 1c9ee2e..1adad31 100644
--- a/meta/recipes-qt/qt4/nativesdk-qt4-tools.inc
+++ b/meta/recipes-qt/qt4/nativesdk-qt4-tools.inc
@@ -1,5 +1,5 @@
 SUMMARY = SDK tools for Qt version 4.x
-DEPENDS = nativesdk-zlib nativesdk-dbus nativesdk-libx11 qt4-native
+DEPENDS = nativesdk-zlib nativesdk-dbus qt4-native 
${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'virtual/nativesdk-libx11', '', 
d)}
 SECTION = libs
 HOMEPAGE = http://qt-project.org/;
 LICENSE = LGPLv2.1 | GPLv3
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] cmake.bbclass: set archiver, linker and ranlib in toolchain.cmake

2015-07-17 Thread Pascal Bach

Setting CMAKE_AR, CMAKE_LINKER and CMAKE_RANLIB correctly in
toolchain.cmake is necessary to correctly build -native packages
using CMake.

The reason is that CMake is not able to find the above utilities by
itself because CMAKE_FIND_ROOT_PATH_MODE_PROGRAM is set to ONLY
so we need to tell it explicitly where to look.

Signed-off-by: Pascal Bach pascal.b...@siemens.com
---
 meta/classes/cmake.bbclass | 8 
 1 file changed, 8 insertions(+)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index 995ddf1..cae0ad2 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -13,6 +13,9 @@ inherit autotools
 # C/C++ Compiler (without cpu arch/tune arguments)
 OECMAKE_C_COMPILER ?= `echo ${CC} | sed 's/^\([^ ]*\).*/\1/'`
 OECMAKE_CXX_COMPILER ?= `echo ${CXX} | sed 's/^\([^ ]*\).*/\1/'`
+OECMAKE_AR ?= `echo ${AR} | sed 's/^\([^ ]*\).*/\1/'`
+OECMAKE_LINKER ?= `echo ${LD} | sed 's/^\([^ ]*\).*/\1/'`
+OECMAKE_RANLIB ?= `echo ${RANLIB} | sed 's/^\([^ ]*\).*/\1/'`
 
 # Compiler flags
 OECMAKE_C_FLAGS ?= ${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${CFLAGS}
@@ -35,6 +38,11 @@ set( CMAKE_SYSTEM_PROCESSOR ${TARGET_ARCH} )
 set( CMAKE_C_COMPILER ${OECMAKE_C_COMPILER} )
 set( CMAKE_CXX_COMPILER ${OECMAKE_CXX_COMPILER} )
 set( CMAKE_ASM_COMPILER ${OECMAKE_C_COMPILER} )
+# Force the use of cache here otherwise the values will be overridden 
(http://www.cmake.org/Bug/view.php?id=13038)
+set( CMAKE_AR ar CACHE FILEPATH Archiver FORCE )
+set( CMAKE_LINKER ld CACHE FILEPATH Linker FORCE )
+set( CMAKE_RANLIB ranlib CACHE FILEPATH Ranlib FORCE )
+
 set( CMAKE_C_FLAGS ${OECMAKE_C_FLAGS} CACHE STRING CFLAGS )
 set( CMAKE_CXX_FLAGS ${OECMAKE_CXX_FLAGS} CACHE STRING CXXFLAGS )
 set( CMAKE_ASM_FLAGS ${OECMAKE_C_FLAGS} CACHE STRING ASM FLAGS )
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] image_types.bbclass: Make ubi depend on ubifs

2014-10-27 Thread Pascal Bach

The ubi command assumes the ubifs file is present.
This makes sure this is really the case.

Signed-off-by: Pascal Bach pascal.b...@siemens.com
---
 meta/classes/image_types.bbclass |2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 99a07da..76190fd 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -96,6 +96,8 @@ IMAGE_CMD_ubi () {
mkfs.ubifs -r ${IMAGE_ROOTFS} -o 
${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubifs ${MKUBIFS_ARGS}
ubinize -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubi ${UBINIZE_ARGS} 
ubinize.cfg
 }
+IMAGE_TYPEDEP_ubi = ubifs
+
 IMAGE_CMD_ubifs = mkfs.ubifs -r ${IMAGE_ROOTFS} -o 
${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubifs ${MKUBIFS_ARGS}
 
 EXTRA_IMAGECMD = 
-- 
1.7.10.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] image.py: Fix error in graph sorting

2014-10-24 Thread Pascal Bach

The graph sorting algorithm for image dependencies does a look for an
occurrence of a searched string instead of comparing the chunk to the
searched string. This leads to the problem that ubifs is recognized as ubi 
aswell.

This fixes this by splitting up the string into chunks.

Signed-off-by: Pascal Bach pascal.b...@siemens.com
---
 meta/lib/oe/image.py |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oe/image.py b/meta/lib/oe/image.py
index c9b9033..5e07187 100644
--- a/meta/lib/oe/image.py
+++ b/meta/lib/oe/image.py
@@ -109,7 +109,7 @@ class ImageDepGraph(object):
 # remove added nodes from deps_array
 for item in group:
 for node in self.graph:
-if item in self.graph[node]:
+if item in self.graph[node].split():
 self.deps_array[node][0] -= 1
 
 self.deps_array.pop(item, None)
-- 
1.7.10.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

78 matches

Mail list logo