Date   

Re: CMake based recipes and defining CMAKE_BUILD_TYPE

Mikko Rapeli
 

Hi,

From my experience, what CMAKE_BUILD_TYPE means varies between SW components.
Thus I think the current approach of not setting it is correct. SW components
must set their own defaults in either CMakeLists.txt or in the bitbake recipe.

Also, building with debug info is separate from CMAKE_BUILD_TYPE. The default
compile flags from yocto will include -g for debug symbols and this is provided
to CMake compile flags too.

Cheers,

-Mikko


Re: SDK install w/ CMake

Bach, Pascal <pascal.bach@...>
 

Hi Eric

I don't think your issue has something do to with CMake.

-----Original Message-----
From: yocto-bounces@yoctoproject.org <yocto-bounces@yoctoproject.org>
On Behalf Of Eric Schwarz
Sent: Freitag, 1. Februar 2019 09:51
To: yocto@yoctoproject.org
Subject: [yocto] SDK install w/ CMake

Hello,

we have got the problem that w/ the Yocto recipe and CMake install targets
as below always everything (headers and library or binary
respectively) is installed in the SDK.
The binary also goes into the SDK even though we just add it to
IMAGE_INSTALL based on a XILINX yocto build (rel-v2018.3).
I'm not sure I understand what you are trying to do. If you add something to IMAGE_INSTALL it gets installed to the target.
That usually includes binaries and libraries.

If you only want libraries but not binaries it's probably best to split them into multiple packages as described in https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#package-splitting-dev-environment

This way you can have the binaries in a different package like ${PN}-tools.

Pascal

For sure we only want headers to be installed when "<library_name>-dev"
is added to TOOLCHAIN_TARGET_TASK_append and the binary should not
be installed at all when it is just added to IMAGE_INSTALL.

For sure we studied Yocto and CMake recipes from other libraries where it
works like pugixml but weren't able to figure out what's going wrong.


Yocto recipe
============

DESCRIPTION = "C++ reflection library"
SECTION = "libs"
LICENSE = "CLOSED"

SRCREV = "${AUTOREV}"
SRCBRANCH = "next"
SRC_URI =
"git://gitlab.company.de/psg/${PN}.git;branch=${SRCBRANCH};protocol=ssh
"

DEPENDS = "catch2"

inherit cmake
S = "${WORKDIR}/git"
FILES_${PN}-dev += "${libdir}/cmake"

# The following are needed because the library is unversioned.
# See
https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Librari
es#Non-versioned_Libraries
SOLIBS = ".so"
FILES_SOLIBSDEV = ""


CMake library install part
==========================

# Shared client library target.
add_library(shared SHARED $<TARGET_OBJECTS:objects>)
target_include_directories(shared PUBLIC
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include>
$<INSTALL_INTERFACE:${CMAKE_INSTALL_INCLUDEDIR}>
)

set_target_properties(shared
PROPERTIES
ARCHIVE_OUTPUT_DIRECTORY lib/shared
LIBRARY_OUTPUT_DIRECTORY lib/shared
RUNTIME_OUTPUT_DIRECTORY lib/shared
OUTPUT_NAME ${LIBRARY_NAME}
)

# Install target.
install(TARGETS shared static
EXPORT ${LIBRARY_NAME}-config
DESTINATION ${CMAKE_INSTALL_LIBDIR})
install(DIRECTORY include/reflect DESTINATION
${CMAKE_INSTALL_INCLUDEDIR})
install(EXPORT ${LIBRARY_NAME}-config
NAMESPACE ${LIBRARY_NAME}-
DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/${LIBRARY_NAME})


CMake binary install part
=========================

install(TARGETS ${EXECUTABLE_NAME} DESTINATION
${CMAKE_INSTALL_BINDIR})


Many thanks for any hints
Eric
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


do_populate_lic fail from scratch build but succed after clean

Jonas Andersson
 

Hi

I have an recipe based on serialport npm package created with devtool.

I added some custom licenses in my layer with LICENSE_PATH:

# Additional license directories.
LICENSE_PATH += "${LAYERDIR}/files/common-licenses"

After this I get some inconsistent build result (or i dont understand ).

Te steps I make is the following, build from scratch then bitbake fails, clean recipe and build recipe and it succed:

1. bitbake myLayer -> 

WARNING: serialport-6.2.2-r0 do_populate_lic: Could not copy license file /home/jonas/yocto/build/tmp/work/cortexa9hf-neon-goerlix-linux-gnueabi/serialport/6.2.2-r0/npmpkg/node_modules/prompt-list/node_modules/prompt-radio/node_modules/prompt-checkbox/node_modules/prompt-base/node_modules/readline-ui/node_modules/debug/LICENSE to /home/jonas/yocto/build/tmp/work/cortexa9hf-neon-goerlix-linux-gnueabi/serialport/6.2.2-r0/license-destdir/serialport/LICENSE.3: [Errno 2] No such file or directory: '/home/jonas/yocto/build/tmp/work/cortexa9hf-neon-goerlix-linux-gnueabi/serialport/6.2.2-r0/npmpkg/node_modules/prompt-list/node_modules/prompt-radio/node_modules/prompt-checkbox/node_modules/prompt-base/node_modules/readline-ui/node_modules/debug/LICENSE'
.
//
.
ERROR: serialport-6.2.2-r0 do_populate_lic: QA Issue: serialport: LIC_FILES_CHKSUM points to an invalid file: /home/jonas/yocto/build/tmp/work/cortexa9hf-neon-goerlix-linux-gnueabi/serialport/6.2.2-r0/npmpkg/node_modules/prompt-list/node_modules/prompt-radio/node_modules/prompt-checkbox/node_modules/prompt-base/node_modules/readline-ui/node_modules/debug/LICENSE [license-checksum]
.
//
.
ERROR: serialport-6.2.2-r0 do_populate_lic: Fatal QA errors found, failing task.
ERROR: serialport-6.2.2-r0 do_populate_lic: Function failed: populate_lic_qa_checksum

2. bitbake serialport -c clean
3. bitbake serialport -> success

In my view it feels like different tasks is executed in different order, like the npm recipe is missing some dependency but before I adden LICENSE_PATH to the layer config I had no problem..
______________________________________________________________________________________________
Build Configuration:
BB_VERSION           = "1.40.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "universal"

TUNE_FEATURES        = "arm armv7a vfp neon callconvention-hard cortexa9"
TARGET_FPU           = "hard"
meta                 = "thud:3541f019a505d18263fad0b46b88d470e3fd9d62"
meta-oe              
meta-python          
meta-networking      
meta-filesystems     = "thud:6094ae18c8a35e5cc9998ac39869390d7f3bb1e2"
meta-yocto-bsp       = "thud:3541f019a505d18263fad0b46b88d470e3fd9d62"
meta-microservicebus-node = "thud:cab931199236b5bdeeb660f64aea55c2e0c09c2b"

Best regards
Jonas



Python default libraries

Emily Smith <easmith5@...>
 

Hi -

I’ve been working with yocto and with some code running on my OS, however I’m seeing errors that seem to indicate that default python libraries are no longer included (specifically logging and importlib). Has something about the default python libraries changed?

Thanks!
Emily Smith


[PATCH] ruby: remove CVE-2018-1000073.patch as already fixed

Grandbois, Brett <brett.grandbois@...>
 

rubygems 2.7.6 which is in ruby 2.5.3 has this fix and as currently
applied all gem extraction fails as the realpath check is done against
the full path including the file to be extracted which will always fail
as the file hasnt been extracted yet

Signed-off-by: Brett Grandbois <brett.grandbois@opengear.com>
---
.../ruby/ruby/CVE-2018-1000073.patch | 34 -------------------
meta/recipes-devtools/ruby/ruby_2.5.3.bb | 1 -
2 files changed, 35 deletions(-)
delete mode 100644 meta/recipes-devtools/ruby/ruby/CVE-2018-1000073.patch

diff --git a/meta/recipes-devtools/ruby/ruby/CVE-2018-1000073.patch b/meta/recipes-devtools/ruby/ruby/CVE-2018-1000073.patch
deleted file mode 100644
index 22fa1b5f4d..0000000000
--- a/meta/recipes-devtools/ruby/ruby/CVE-2018-1000073.patch
+++ /dev/null
@@ -1,34 +0,0 @@
-From 1b931fc03b819b9a0214be3eaca844ef534175e2 Mon Sep 17 00:00:00 2001
-From: Jonathan Claudius <jclaudius@mozilla.com>
-Date: Wed, 7 Feb 2018 23:54:52 -0500
-Subject: [PATCH] Non-working patch for deducing symlinked base-dirs
-
----
-CVE: CVE-2018-1000073
-
-Fixed in ruby 2.7.6.
-
-Upstream-Status: Backport [github.com/rubygems/rubygems/commit/1b931fc...]
-
-Signed-off-by: Joe Slater <joe.slater@windriver.com>
-
----
- lib/rubygems/package.rb | 2 ++
- 1 file changed, 2 insertions(+)
-
-diff --git a/lib/rubygems/package.rb b/lib/rubygems/package.rb
-index dede959..cb9c74a 100644
---- a/lib/rubygems/package.rb
-+++ b/lib/rubygems/package.rb
-@@ -421,6 +421,8 @@ EOM
- destination_dir = File.expand_path destination_dir
-
- destination = File.join destination_dir, filename
-+ destination = File.realpath destination if
-+ File.respond_to? :realpath
- destination = File.expand_path destination
-
- raise Gem::Package::PathError.new(destination, destination_dir) unless
---
-1.7.9.5
-
diff --git a/meta/recipes-devtools/ruby/ruby_2.5.3.bb b/meta/recipes-devtools/ruby/ruby_2.5.3.bb
index e9f0453788..3fb427e90e 100644
--- a/meta/recipes-devtools/ruby/ruby_2.5.3.bb
+++ b/meta/recipes-devtools/ruby/ruby_2.5.3.bb
@@ -3,7 +3,6 @@ require ruby.inc
SRC_URI += " \
file://ruby-CVE-2017-9226.patch \
file://ruby-CVE-2017-9228.patch \
- file://CVE-2018-1000073.patch \
"

SRC_URI[md5sum] = "20c85b67846d49622ef3b24230803fef"
--
2.17.1


Re: CMake based recipes and defining CMAKE_BUILD_TYPE

Matthew Z Schuckmann
 

Aright thank you for checking into this, you went farther then I expected.
I will take the approach of setting it for the recipes I really care about and leave the rest alone.

Matt S.
________________________________________
From: Andreas Müller <schnitzeltony@gmail.com>
Sent: Wednesday, February 6, 2019 3:11 PM
To: Matt Schuckmann
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] CMake based recipes and defining CMAKE_BUILD_TYPE

On Wed, Feb 6, 2019 at 11:53 PM Andreas Müller <schnitzeltony@gmail.com> wrote:

On Wed, Feb 6, 2019 at 11:24 PM Andreas Müller <schnitzeltony@gmail.com> wrote:

On Wed, Feb 6, 2019 at 11:05 PM Matt Schuckmann
<Matt.Schuckmann@planar.com> wrote:

Hi Andreas,

Thanks for the response, do you set build type in each recipe individually or is there some central .conf file or other other location that you set it?

Matt S.
Honestly: I do not set them yet because I thought RelWithDebInfo is
default. That assumption was based on some projects but I checked now:
it does not seem to be something to rely on...
Will build-/run-test this with my 'world':

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index fd40a9863e..a8e08e6d6f 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -153,6 +153,7 @@ cmake_do_configure() {
-DCMAKE_TOOLCHAIN_FILE=${WORKDIR}/toolchain.cmake \
-DCMAKE_VERBOSE_MAKEFILE=1 \
-DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 \
+ -DCMAKE_BUILD_TYPE=${@d.getVar(oe.utils.vartrue('DEBUG_BUILD',
'Debug', 'RelWithDebInfo', d))} \
${EXTRA_OECMAKE} \
-Wno-dev
}

Takes a while...
Not exactly: After short build I saw:

* There are some sed on '*-noconfig.cmake' they are going to break
* libeigen fails because it supports 'Debug' and 'Release' only (and I
bet there are more)

Will skip further tests and get the feeling that a common solution won't do...

Andreas


Re: CMake based recipes and defining CMAKE_BUILD_TYPE

Andreas Müller
 

On Wed, Feb 6, 2019 at 11:53 PM Andreas Müller <schnitzeltony@gmail.com> wrote:

On Wed, Feb 6, 2019 at 11:24 PM Andreas Müller <schnitzeltony@gmail.com> wrote:

On Wed, Feb 6, 2019 at 11:05 PM Matt Schuckmann
<Matt.Schuckmann@planar.com> wrote:

Hi Andreas,

Thanks for the response, do you set build type in each recipe individually or is there some central .conf file or other other location that you set it?

Matt S.
Honestly: I do not set them yet because I thought RelWithDebInfo is
default. That assumption was based on some projects but I checked now:
it does not seem to be something to rely on...
Will build-/run-test this with my 'world':

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index fd40a9863e..a8e08e6d6f 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -153,6 +153,7 @@ cmake_do_configure() {
-DCMAKE_TOOLCHAIN_FILE=${WORKDIR}/toolchain.cmake \
-DCMAKE_VERBOSE_MAKEFILE=1 \
-DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 \
+ -DCMAKE_BUILD_TYPE=${@d.getVar(oe.utils.vartrue('DEBUG_BUILD',
'Debug', 'RelWithDebInfo', d))} \
${EXTRA_OECMAKE} \
-Wno-dev
}

Takes a while...
Not exactly: After short build I saw:

* There are some sed on '*-noconfig.cmake' they are going to break
* libeigen fails because it supports 'Debug' and 'Release' only (and I
bet there are more)

Will skip further tests and get the feeling that a common solution won't do...

Andreas


Re: [PATCH 00/10] Misc fixes (cover letter only)

Paul Eggleton
 

Oops, yes, I forgot the [layerindex-web], my apologies.

I can cc the oe-devel list if people really want to see it there as well; up
to this point we've been using this list only. The other option would be a
dedicated list but I suspect that would have a very limited subscription.

Cheers,
Paul

On Thursday, 7 February 2019 11:24:24 AM NZDT akuster wrote:

Hello Paul.

On 2/6/19 2:00 PM, Paul Eggleton wrote:
The following changes since commit
61e9b048591adab88d1996646286e1d7df024bea:

Fix drop-down alignment on duplicates page (2018-11-20 11:58:42 +1300)

are available in the Git repository at:

git://git.yoctoproject.org/layerindex-web paule/fixes12
http://git.yoctoproject.org/cgit.cgi/layerindex-web/log/?h=paule/fixes12

Paul Eggleton (10):
Send people an email when another user adds them as a maintainer
Add links to other branch recipes in recipe detail
Fix errors due to races deleting bitbake temp files
local.conf: allow for upstream_tracking.inc to be missing
Use try...finally or with to ensure files get closed
Replace use of assert with exceptions
docker: add wget to dependencies
RRS: fix sorting arrow positioning
rrs_maintainer_history: check out layer branch before looking for
maintainers.inc
RRS: add tool to import/export upstream history data
Thanks for the updates and fixes. This is a very useful tool to both YP
and OE.

I had to look at what was actual changes to figure out what this patch
set was against. Should we change the "subject" to help clarify? ie
[layer-index][PATCH ...?

The layer index is hosted on OE. Should one of the OE mailing be CC'ed??

Yes I realize the sources are hosted on YP but the url for the tool is
http://layers.openembedded.org. can be confusing.

kind regards,
Armin

Dockerfile | 1 +
conf/local.conf | 2 +-
layerindex/bulkchange.py | 18 +-
layerindex/update.py | 4 +-
layerindex/update_layer.py | 14 +-
layerindex/utils.py | 21 ++-
layerindex/views.py | 70 ++++++--
rrs/tools/historytool.py | 196 +++++++++++++++++++++
rrs/tools/rrs_distros.py | 19 +-
rrs/tools/rrs_maintainer_history.py | 45 ++---
rrs/tools/rrs_upgrade_history.py | 4 +-
rrs/tools/rrs_upstream_history.py | 3 +-
rrs/tools/upgrade_history_internal.py | 3 +-
rrs/views.py | 2 +
templates/layerindex/maintemail.txt | 9 +
templates/layerindex/maintemailsubject.txt | 1 +
templates/layerindex/recipedetail.html | 27 +++
templates/rrs/maintainers.html | 2 +-
templates/rrs/recipedetail.html | 27 +++
templates/rrs/recipes.html | 2 +-
20 files changed, 392 insertions(+), 78 deletions(-)
create mode 100755 rrs/tools/historytool.py
create mode 100644 templates/layerindex/maintemail.txt
create mode 100644 templates/layerindex/maintemailsubject.txt

--

Paul Eggleton
Intel Open Source Technology Centre


Re: CMake based recipes and defining CMAKE_BUILD_TYPE

Andreas Müller
 

On Wed, Feb 6, 2019 at 11:24 PM Andreas Müller <schnitzeltony@gmail.com> wrote:

On Wed, Feb 6, 2019 at 11:05 PM Matt Schuckmann
<Matt.Schuckmann@planar.com> wrote:

Hi Andreas,

Thanks for the response, do you set build type in each recipe individually or is there some central .conf file or other other location that you set it?

Matt S.
Honestly: I do not set them yet because I thought RelWithDebInfo is
default. That assumption was based on some projects but I checked now:
it does not seem to be something to rely on...
Will build-/run-test this with my 'world':

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index fd40a9863e..a8e08e6d6f 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -153,6 +153,7 @@ cmake_do_configure() {
-DCMAKE_TOOLCHAIN_FILE=${WORKDIR}/toolchain.cmake \
-DCMAKE_VERBOSE_MAKEFILE=1 \
-DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 \
+ -DCMAKE_BUILD_TYPE=${@d.getVar(oe.utils.vartrue('DEBUG_BUILD',
'Debug', 'RelWithDebInfo', d))} \
${EXTRA_OECMAKE} \
-Wno-dev
}

Takes a while...

Andreas


Re: [PATCH 00/10] Misc fixes (cover letter only)

Armin Kuster
 

Hello Paul.

On 2/6/19 2:00 PM, Paul Eggleton wrote:
The following changes since commit 61e9b048591adab88d1996646286e1d7df024bea:

Fix drop-down alignment on duplicates page (2018-11-20 11:58:42 +1300)

are available in the Git repository at:

git://git.yoctoproject.org/layerindex-web paule/fixes12
http://git.yoctoproject.org/cgit.cgi/layerindex-web/log/?h=paule/fixes12

Paul Eggleton (10):
Send people an email when another user adds them as a maintainer
Add links to other branch recipes in recipe detail
Fix errors due to races deleting bitbake temp files
local.conf: allow for upstream_tracking.inc to be missing
Use try...finally or with to ensure files get closed
Replace use of assert with exceptions
docker: add wget to dependencies
RRS: fix sorting arrow positioning
rrs_maintainer_history: check out layer branch before looking for
maintainers.inc
RRS: add tool to import/export upstream history data
Thanks for the updates and fixes. This is  a very useful tool to both YP
and OE. 

I had to look at what was actual changes to figure out what this patch
set was against.  Should we change the "subject" to help clarify? ie
[layer-index][PATCH ...?

The layer index is hosted on OE. Should one of the  OE mailing be CC'ed??

Yes I realize the sources are hosted on YP but the url for the tool is
http://layers.openembedded.org. can be confusing.

kind regards,
Armin

Dockerfile | 1 +
conf/local.conf | 2 +-
layerindex/bulkchange.py | 18 +-
layerindex/update.py | 4 +-
layerindex/update_layer.py | 14 +-
layerindex/utils.py | 21 ++-
layerindex/views.py | 70 ++++++--
rrs/tools/historytool.py | 196 +++++++++++++++++++++
rrs/tools/rrs_distros.py | 19 +-
rrs/tools/rrs_maintainer_history.py | 45 ++---
rrs/tools/rrs_upgrade_history.py | 4 +-
rrs/tools/rrs_upstream_history.py | 3 +-
rrs/tools/upgrade_history_internal.py | 3 +-
rrs/views.py | 2 +
templates/layerindex/maintemail.txt | 9 +
templates/layerindex/maintemailsubject.txt | 1 +
templates/layerindex/recipedetail.html | 27 +++
templates/rrs/maintainers.html | 2 +-
templates/rrs/recipedetail.html | 27 +++
templates/rrs/recipes.html | 2 +-
20 files changed, 392 insertions(+), 78 deletions(-)
create mode 100755 rrs/tools/historytool.py
create mode 100644 templates/layerindex/maintemail.txt
create mode 100644 templates/layerindex/maintemailsubject.txt


Re: CMake based recipes and defining CMAKE_BUILD_TYPE

Andreas Müller
 

On Wed, Feb 6, 2019 at 11:05 PM Matt Schuckmann
<Matt.Schuckmann@planar.com> wrote:

Hi Andreas,

Thanks for the response, do you set build type in each recipe individually or is there some central .conf file or other other location that you set it?

Matt S.
Honestly: I do not set them yet because I thought RelWithDebInfo is
default. That assumption was based on some projects but I checked now:
it does not seem to be something to rely on...

Andreas


Re: CMake based recipes and defining CMAKE_BUILD_TYPE

Matthew Z Schuckmann
 

Hi Andreas,

Thanks for the response, do you set build type in each recipe individually or is there some central .conf file or other other location that you set it?

Matt S.
________________________________________
From: Andreas Müller <schnitzeltony@gmail.com>
Sent: Wednesday, February 6, 2019 1:31 PM
To: Matt Schuckmann
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] CMake based recipes and defining CMAKE_BUILD_TYPE

On Wed, Feb 6, 2019 at 7:39 PM Matt Schuckmann
<Matt.Schuckmann@planar.com> wrote:

I'm trying to understand why the cmake.bbclass doesn't make any attempt to set CMAKE_BUILD_TYPE and what the design philosophy behind that is?

On the surface I would expect that the default build type would be Release but I can see how that might not always be the right choice. I'm really surprised that there isn't a global variable that can be set for this, am I missing something, or is it really expected that each recipe provide it if they care?


FYI I started looking into this when I realized that NDEBUG is not set for many (if not all) of my CMake based recipes and thus asserts are still enabled in my production code. This appears to be known behavior for CMake if CMAKE_BUILD_TYPE is not set.


Matt S.
Hi Matt,

This is not a full answer but Release is not a common target for us:
cmake will produce not containing debug info. With these debugging is
useless (and you'll get package qa warnings). If there is a default
target for us it is RelWithDebInfo.

Andreas


[PATCH 00/10] Misc fixes (cover letter only)

Paul Eggleton
 

The following changes since commit 61e9b048591adab88d1996646286e1d7df024bea:

Fix drop-down alignment on duplicates page (2018-11-20 11:58:42 +1300)

are available in the Git repository at:

git://git.yoctoproject.org/layerindex-web paule/fixes12
http://git.yoctoproject.org/cgit.cgi/layerindex-web/log/?h=paule/fixes12

Paul Eggleton (10):
Send people an email when another user adds them as a maintainer
Add links to other branch recipes in recipe detail
Fix errors due to races deleting bitbake temp files
local.conf: allow for upstream_tracking.inc to be missing
Use try...finally or with to ensure files get closed
Replace use of assert with exceptions
docker: add wget to dependencies
RRS: fix sorting arrow positioning
rrs_maintainer_history: check out layer branch before looking for
maintainers.inc
RRS: add tool to import/export upstream history data

Dockerfile | 1 +
conf/local.conf | 2 +-
layerindex/bulkchange.py | 18 +-
layerindex/update.py | 4 +-
layerindex/update_layer.py | 14 +-
layerindex/utils.py | 21 ++-
layerindex/views.py | 70 ++++++--
rrs/tools/historytool.py | 196 +++++++++++++++++++++
rrs/tools/rrs_distros.py | 19 +-
rrs/tools/rrs_maintainer_history.py | 45 ++---
rrs/tools/rrs_upgrade_history.py | 4 +-
rrs/tools/rrs_upstream_history.py | 3 +-
rrs/tools/upgrade_history_internal.py | 3 +-
rrs/views.py | 2 +
templates/layerindex/maintemail.txt | 9 +
templates/layerindex/maintemailsubject.txt | 1 +
templates/layerindex/recipedetail.html | 27 +++
templates/rrs/maintainers.html | 2 +-
templates/rrs/recipedetail.html | 27 +++
templates/rrs/recipes.html | 2 +-
20 files changed, 392 insertions(+), 78 deletions(-)
create mode 100755 rrs/tools/historytool.py
create mode 100644 templates/layerindex/maintemail.txt
create mode 100644 templates/layerindex/maintemailsubject.txt

--
2.17.2


Re: CMake based recipes and defining CMAKE_BUILD_TYPE

Andreas Müller
 

On Wed, Feb 6, 2019 at 7:39 PM Matt Schuckmann
<Matt.Schuckmann@planar.com> wrote:

I'm trying to understand why the cmake.bbclass doesn't make any attempt to set CMAKE_BUILD_TYPE and what the design philosophy behind that is?

On the surface I would expect that the default build type would be Release but I can see how that might not always be the right choice. I'm really surprised that there isn't a global variable that can be set for this, am I missing something, or is it really expected that each recipe provide it if they care?


FYI I started looking into this when I realized that NDEBUG is not set for many (if not all) of my CMake based recipes and thus asserts are still enabled in my production code. This appears to be known behavior for CMake if CMAKE_BUILD_TYPE is not set.


Matt S.
Hi Matt,

This is not a full answer but Release is not a common target for us:
cmake will produce not containing debug info. With these debugging is
useless (and you'll get package qa warnings). If there is a default
target for us it is RelWithDebInfo.

Andreas


CMake based recipes and defining CMAKE_BUILD_TYPE

Matthew Z Schuckmann
 

I'm trying to understand why the cmake.bbclass doesn't make any attempt to set CMAKE_BUILD_TYPE and what the design philosophy behind that is? 

On the surface I would expect that the default build type would be Release but I can see how that might not always be the right choice. I'm really surprised that there isn't a global variable that can be set for this, am I missing something, or is it really expected that each recipe provide it if they care?


FYI I started looking into this when I realized that NDEBUG is not set for many (if not all) of my CMake based recipes and thus asserts are still enabled in my production code. This appears to be known behavior for CMake if CMAKE_BUILD_TYPE is not set. 


Matt S. 


Re: Proper Use of KERNEL_MODULE_AUTOLOAD variable

Ulf Samuelsson
 

Maybe it would be good to have a working example in the tree.

Best Regards,
Ulf Samuelsson

6 feb. 2019 kl. 02:22 skrev Khem Raj <raj.khem@...>:



On Sat, Feb 2, 2019 at 7:17 PM Ken Sloat <ken.sloat@...> wrote:
On Sat, Feb 2, 2019 at 10:03 PM Bruce Ashfield
<bruce.ashfield@...> wrote:
>
> On 2019-02-02 9:59 p.m., Ken Sloat wrote:
> > Hello,
> >
> > I have an out of tree kernel module which I want autoloaded at startup
> > on my system. Looking at the Yocto project manual, I see that one way
> > I can do this is to add the module name to the KERNEL_MODULE_AUTOLOAD
> > variable within my custom module recipe.
> >
> > What I have found is that the module-split class is indeed generating
> > the "/etc/modules-load.d/mymodule.conf" file, however this file is not
> > actually being installed. To be more precise it is appearing in the
> > "package" directory (i.e.
> > tmp/work/**/mymodule/package/etc/modules-load.d/mymodule.conf) but not
> > within the "image" directory (nor in my final rootfs).
> >
> > Is there something I'm missing in the usage of KERNEL_MODULE_AUTOLOAD?
> > Is the intention for this variable I add extra steps to manually
> > install this file in my recipe? FYI I'm using Morty.
>
> Can you provide your recipe ? It would make suggestions easier. For
> example, my first question is: Is the module being installed to your
> image via IMAGE_INSTALL, or some other similar variable ?
>
> Bruce
>
> >
> > Thanks,
> > Ken Sloat
> >
>

Hi Bruce,

Thanks for your quick reply. Yes the module is being installed via
image_install. Module is installed but generated conf file is not. See
recipe below:

require mymodule.inc

inherit module kernel-module-split

DEPENDS = "virtual/kernel"

EXTRA_OEMAKE_append = " \
    KERNELDIR=${STAGING_KERNEL_DIR} \
    "

MAKE_TARGETS = "module"

MODULE_NAME = "mymodule"

PKG_${PN} = "kernel-module-${MODULE_NAME}"

module_do_install() {
    install -d ${D}/lib/modules/${KERNEL_VERSION}/kernel/${MODULE_NAME}
    install -m 0644 ${MODULE_NAME}.ko \
    ${D}/lib/modules/${KERNEL_VERSION}/kernel/${MODULE_NAME}/${MODULE_NAME}.ko
}

FILES_${PN} = " \
    /lib/modules/${KERNEL_VERSION}/kernel/${MODULE_NAME} \
"

Your recipe is overwriting common stuff which otherwise should be provided by module bbclass 
I would suggest that you append to the variables instead of over writing them above and try to reuse
The primitives from bbclass as much as you can for best results 


KERNEL_MODULE_AUTOLOAD += "${MODULE_NAME}"
--
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto
--
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Re: Proper Use of KERNEL_MODULE_AUTOLOAD variable

Khem Raj
 



On Sat, Feb 2, 2019 at 7:17 PM Ken Sloat <ken.sloat@...> wrote:
On Sat, Feb 2, 2019 at 10:03 PM Bruce Ashfield
<bruce.ashfield@...> wrote:
>
> On 2019-02-02 9:59 p.m., Ken Sloat wrote:
> > Hello,
> >
> > I have an out of tree kernel module which I want autoloaded at startup
> > on my system. Looking at the Yocto project manual, I see that one way
> > I can do this is to add the module name to the KERNEL_MODULE_AUTOLOAD
> > variable within my custom module recipe.
> >
> > What I have found is that the module-split class is indeed generating
> > the "/etc/modules-load.d/mymodule.conf" file, however this file is not
> > actually being installed. To be more precise it is appearing in the
> > "package" directory (i.e.
> > tmp/work/**/mymodule/package/etc/modules-load.d/mymodule.conf) but not
> > within the "image" directory (nor in my final rootfs).
> >
> > Is there something I'm missing in the usage of KERNEL_MODULE_AUTOLOAD?
> > Is the intention for this variable I add extra steps to manually
> > install this file in my recipe? FYI I'm using Morty.
>
> Can you provide your recipe ? It would make suggestions easier. For
> example, my first question is: Is the module being installed to your
> image via IMAGE_INSTALL, or some other similar variable ?
>
> Bruce
>
> >
> > Thanks,
> > Ken Sloat
> >
>

Hi Bruce,

Thanks for your quick reply. Yes the module is being installed via
image_install. Module is installed but generated conf file is not. See
recipe below:

require mymodule.inc

inherit module kernel-module-split

DEPENDS = "virtual/kernel"

EXTRA_OEMAKE_append = " \
    KERNELDIR=${STAGING_KERNEL_DIR} \
    "

MAKE_TARGETS = "module"

MODULE_NAME = "mymodule"

PKG_${PN} = "kernel-module-${MODULE_NAME}"

module_do_install() {
    install -d ${D}/lib/modules/${KERNEL_VERSION}/kernel/${MODULE_NAME}
    install -m 0644 ${MODULE_NAME}.ko \
    ${D}/lib/modules/${KERNEL_VERSION}/kernel/${MODULE_NAME}/${MODULE_NAME}.ko
}

FILES_${PN} = " \
    /lib/modules/${KERNEL_VERSION}/kernel/${MODULE_NAME} \
"

Your recipe is overwriting common stuff which otherwise should be provided by module bbclass 
I would suggest that you append to the variables instead of over writing them above and try to reuse
The primitives from bbclass as much as you can for best results 


KERNEL_MODULE_AUTOLOAD += "${MODULE_NAME}"
--
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Re: Proper Use of KERNEL_MODULE_AUTOLOAD variable

Ken Sloat <ken.sloat@...>
 

On Mon, Feb 4, 2019 at 10:50 AM Robert Berger
<yocto.user.mailinglist@gmail.com> wrote:

Hi Ken,

Is there any particular reason you don't use the sample[1] for an out of
tree kernel module?

[1]
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-skeleton/recipes-kernel/hello-mod

Regards,

Robert
Hi Robert,

We are running an older version of Yocto (Morty) for a customer. I
redacted the recipe name for the example I posted, but the recipe is
basically an identical copy of another recipe from newer versions of
Poky not present in Morty.

I might try to debug this more at some point, but the FILES statement
seems to make it work. Thanks for all the help everyone, I really
appreciate it.


Re: YPTM minutes

Scott Rifenbark <srifenbark@...>
 



On Tue, Feb 5, 2019 at 1:05 PM akuster808 <akuster808@...> wrote:


On 2/5/19 10:24 AM, Joshua Watt wrote:
On Tue, 2019-02-05 at 10:11 -0800, Scott Rifenbark wrote:


On Tue, Feb 5, 2019 at 8:37 AM <sjolley.yp.pm@...> wrote:

Yocto Technical Team Minutes for Feb. 5, 2019.

 

Attendees: Armin, David, Joshua, Randy, Tim, Richard G., Stephen, Jan-Simon, Manjukum, Tracey, Trevor, Nick, Richard P, Mark, Kate, Michael,

 

YP 2.6.1 was released on Feb. 4, 2019.

YP 2.7 M2 was built and is in QA and is 79% done.  See: https://wiki.yoctoproject.org/wiki/2.7_QA_Status

 

Armin agreed to add Ubuntu 18.4 to YP 2.6 series and we will use in for YP 2.7

We discussed that the YP 2.6 manual doesn’t have an upgrading to YP 2.6.  Tracey will look into this.



Can I get some clarification on this.  Ubuntu 18.04 seems to be an LTS.  I don't have "LTS" listed in the 2.6 ref-manual (https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#detailed-supported-distros) but do have Ubuntu 18.04 listed as a supported distro.  What is meant by "... the YP 2.6 manual doesn't have an upgrading to YP 2.6."?  - Thanks Scott

I think there is a little confusion here. There are actually 2 issues:

1) The Yocto 2.6 manual doesn't have the "Moving to the Yocto Project 2.6 Release" section to describe the changes that have been made from 2.5 -> 2.6 (https://www.yoctoproject.org/docs/2.6/mega-manual/mega-manual.html#moving-to-the-yocto-project-2.5-release). Oddly, this section *is* present in the "latest" mega manual.

2) The second (unrelated) issue has to do with reporting 18.04 as a supported host distro. I'm not as familiar with this one, so I'll let someone else chime in.

This is in thud-next:

http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta-poky/conf/distro/poky.conf?h=thud-next&id=263cf203bd363a6b9d58524ff5862d23c76e6390

Once I get sumo stabilized, the same will be validated and back ported.

Once poky.conf is legit for a release, I have a script that extracts these repos out and that is what I use for the manuals.
Thanks


- armin


 

We discussed the status of YP 2.7 upgrades and we are doing OK there.  We are struggling on new features YP 2.7.  Richard is primarily working to stabilize the autobuilder to produce an automated QA report to allow QA to transition from Intel.

 

Richard discussed maintainers of OE-Core.  AUH is sending requests but not getting feedback.

 

Richard discussed that we have issues with some products and need support from the community to fix.

 

Tim discussed ptest issues Richard has identified.

 

Richard asked if there were ideas about how to better communicate with the community. No specific suggestions.

 

Thanks,

 

Stephen K. Jolley

Yocto Project Project Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 

--
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto
-- 
Joshua Watt <JPEWhacker@...>



Re: YPTM minutes

Armin Kuster
 



On 2/5/19 10:24 AM, Joshua Watt wrote:
On Tue, 2019-02-05 at 10:11 -0800, Scott Rifenbark wrote:


On Tue, Feb 5, 2019 at 8:37 AM <sjolley.yp.pm@...> wrote:

Yocto Technical Team Minutes for Feb. 5, 2019.

 

Attendees: Armin, David, Joshua, Randy, Tim, Richard G., Stephen, Jan-Simon, Manjukum, Tracey, Trevor, Nick, Richard P, Mark, Kate, Michael,

 

YP 2.6.1 was released on Feb. 4, 2019.

YP 2.7 M2 was built and is in QA and is 79% done.  See: https://wiki.yoctoproject.org/wiki/2.7_QA_Status

 

Armin agreed to add Ubuntu 18.4 to YP 2.6 series and we will use in for YP 2.7

We discussed that the YP 2.6 manual doesn’t have an upgrading to YP 2.6.  Tracey will look into this.



Can I get some clarification on this.  Ubuntu 18.04 seems to be an LTS.  I don't have "LTS" listed in the 2.6 ref-manual (https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#detailed-supported-distros) but do have Ubuntu 18.04 listed as a supported distro.  What is meant by "... the YP 2.6 manual doesn't have an upgrading to YP 2.6."?  - Thanks Scott

I think there is a little confusion here. There are actually 2 issues:

1) The Yocto 2.6 manual doesn't have the "Moving to the Yocto Project 2.6 Release" section to describe the changes that have been made from 2.5 -> 2.6 (https://www.yoctoproject.org/docs/2.6/mega-manual/mega-manual.html#moving-to-the-yocto-project-2.5-release). Oddly, this section *is* present in the "latest" mega manual.

2) The second (unrelated) issue has to do with reporting 18.04 as a supported host distro. I'm not as familiar with this one, so I'll let someone else chime in.

This is in thud-next:

http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta-poky/conf/distro/poky.conf?h=thud-next&id=263cf203bd363a6b9d58524ff5862d23c76e6390

Once I get sumo stabilized, the same will be validated and back ported.

- armin


 

We discussed the status of YP 2.7 upgrades and we are doing OK there.  We are struggling on new features YP 2.7.  Richard is primarily working to stabilize the autobuilder to produce an automated QA report to allow QA to transition from Intel.

 

Richard discussed maintainers of OE-Core.  AUH is sending requests but not getting feedback.

 

Richard discussed that we have issues with some products and need support from the community to fix.

 

Tim discussed ptest issues Richard has identified.

 

Richard asked if there were ideas about how to better communicate with the community. No specific suggestions.

 

Thanks,

 

Stephen K. Jolley

Yocto Project Project Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 

--
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto
-- 
Joshua Watt <JPEWhacker@...>


9861 - 9880 of 53908