Date   

Re: Strange error

Rudolf J Streif
 

Did you edit the recipe while a build was running?

:rjs

On 6/10/20 10:48 AM, Mauro Ziliani wrote:
Hi all.

This error

NOTE: Executing RunQueue Tasks
ERROR: When reparsing <recipe_of_image>.do_rootfs, the basehash value changed from 7419bfc242fa2eee9ce87b18ebf40d25 to 5b2654046d2ac406f3484b3286de0acd. The metadata is not deterministic and this needs to be fixed.


Why?


Best regards,

  MZ



    
-- 
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700


Strange error

Mauro Ziliani
 

Hi all.

This error

NOTE: Executing RunQueue Tasks
ERROR: When reparsing <recipe_of_image>.do_rootfs, the basehash value changed from 7419bfc242fa2eee9ce87b18ebf40d25 to 5b2654046d2ac406f3484b3286de0acd. The metadata is not deterministic and this needs to be fixed.


Why?


Best regards,

  MZ


[yocto-autobuilder-helper][dunfell] config.json: add steve@sakoman.com to QA email list

Steve Sakoman
 

---
config.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config.json b/config.json
index 17acc09..9636ea1 100644
--- a/config.json
+++ b/config.json
@@ -16,7 +16,7 @@
"TRASH_DIR" : "${BASE_HOMEDIR}/git/trash",

"QAMAIL_TO" : "yocto@lists.yoctoproject.org",
- "QAMAIL_CC" : "otavio@ossystems.com.br, yi.zhao@windriver.com, apoorv.sangal@intel.com, ee.peng.yeoh@intel.com, aaron.chun.yew.chan@intel.com, richard.purdie@linuxfoundation.org, akuster808@gmail.com, sjolley.yp.pm@gmail.com, sangeeta.jain@intel.com",
+ "QAMAIL_CC" : "otavio@ossystems.com.br, yi.zhao@windriver.com, apoorv.sangal@intel.com, ee.peng.yeoh@intel.com, aaron.chun.yew.chan@intel.com, richard.purdie@linuxfoundation.org, akuster808@gmail.com, sjolley.yp.pm@gmail.com, sangeeta.jain@intel.com, steve@sakoman.com",
"WEBPUBLISH_DIR" : "${BASE_SHAREDDIR}/",
"WEBPUBLISH_URL" : "https://autobuilder.yocto.io/",

--
2.17.1


llvm native

Damien LEFEVRE
 

Hi, 

I'm trying to build a native package which uses llvm. I never used llvm before, so time to learn

I've added 
DEPENDS += "llvm-native"

to my recipe but I still get errors

LLVM_CONFIG:
| CMake Error at data/shiboken_helpers.cmake:146 (message):
|   Unable to detect CLANG location by checking LLVM_INSTALL_DIR,
|   CLANG_INSTALL_DIR or running llvm-config.
| Call Stack (most recent call first):
|   CMakeLists.txt:37 (setup_clang)

I looked at the llvm_git.bb file
do_install_class-native() {
install -D -m 0755 ${B}/bin/llvm-tblgen ${D}${bindir}/llvm-tblgen${PV}
install -D -m 0755 ${B}/bin/llvm-config ${D}${bindir}/llvm-config${PV}
install -D -m 0755 ${B}/lib/libLLVM-${MAJOR_VERSION}.so ${D}${libdir}/libLLVM-${MAJOR_VERSION}.so
}

so I would expect to see llvm-config8.0.0 in the recipe-sysroot-native/usr/bin/ inside my package folder but nothing llvm related.

What am I missing?
Thanks,


Re: minutes for Yocto Project Technical Team Meeting / Engineering Sync - June 9 2020

Tim Orling
 



On Tue, Jun 9, 2020 at 2:16 PM Trevor Woerner <twoerner@...> wrote:
Yocto Technical Team Minutes, Engineering Sync, for June 9 2020
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit

== disclaimer ==
Best efforts are made to ensure the below is accurate and valid. However,
errors sometimes happen. If any errors or omissions are found, please feel
free to reply to this email with any corrections.

== attendees ==
Trevor Woerner, Jan-Simon Möller, Stephen Jolly, Trevor Gamblin, Bruce
Ashfield, Scott Murray, Paul Barker, Michael Halstead, Jon Mason, Richard
Purdie, Joshua Watt, Armin Kuster, Tim Orling, Sathishkumar Duraisamy,
henriknj, Ross Burton, Jeremy Puhlman

== notes ==
- 2.7.4 released last week
- 3.1.1 built, but has issues, not sent to QA yet
- M1 early next week (to build)
- thanks to AlexK for lots of fixes

== general ==
RP:
    problems with 3.1.1. qemu(-mips?) failed with taskhash mismatches, not
    sure why


RP:
    devtool, patchtest, patchwork, and wic looking for maintainers
PaulB:
    patchtest/patchwork still on python2, needs 2→3 update. patchtest
    should be moved to OE-core so it can be noticed by more people


RP:
    lots of recipe upgrades, happy with where master is (wrt to recipe
    versions), still need to update qemu to 5


JPEW:
    did RP see my patch to mc-depends to make it backwards compatible?
RP:
    dismayed it was more complex than hoped, but looks okay
JPEW:
    i’m using a proxy object otherwise we need to duplicate a lot of code
    with a lot of if’s
RP:
    saw the BBMASK thing for multiconfig that needed index checking, sad
    that we’ll be stuck with that going forward (in command.py) mostly for
    backwards compatibility (e.g. file checking). another option is to have
    a new API and append a ‘2’ to the end so callers will call the right
    things (old or new). the code’s probably going to get worse and worse
    with every new parameter we want to add (in the future)

JPEW:
    re multiconfig, sometimes the old full “multiconfig” string
    doesn’t work but the new “mc” string does, can we drop
    “multiconfig”? changed in 2.7? or 3.0? there’s a bugzilla somewhere.
    some code handles both, some doesn’t
RP:
    we can get rid of it, despite the expected screaming


RP:
    re devtool, reports on mailing list that devtool isn’t mc-compliant
RP:
    we have a horrible hack for PRserver
RP:
    highlights the need for a dedicated maintainer


PaulB:
    re patchwork, kernel.org are using a newer version of patchwork that is
    python3-compatible, is maintained, but missing some things we need
Timo:
    i looked at freedesktop.org’s gitlab, they’ve made a lot of changes
    from where we forked from them, they’re also using python3 and django2.
    going with mainline will miss features that we’re used to
PaulB:
    make a list of the gap items, then decide if we can live without these
    things
Timo:
    i looked at the fd.o’s patchwork and saw that many of the things we
    added to our fork have been added (but differently) in fd.o’s. e.g. we
    added a superseded feature, doesn’t seem to be on any other patchworks
PaulB:
    would like to spin up concurrent patchworks to see how the react to the
    mailing list
Timo:
    good idea, maybe we can work together on that
PaulB:
    for patchtest it seems obvious what steps are required, patchwork less
    clear
Timo:
    https://gitlab.freedesktop.org/patchwork-fdo
Timo:
    might be a lot of work to compare ours with fd.o’s patch by patch to
    see
PaulB:
    we need to figure out if we can live with some upstream version, to cut
    down on the effort of having our own fork
RP:
    but it’ll cause a lot of pain if, for example, the superceded feature is
    missing
Timo:
    we’re better off putting resources elsewhere. upstream looks hard, but
    i think patchwork-fdo looks like it might work, maybe easier to submit to
    patchwork-fdo rather than upstream?
TrevorW:
    maybe fdo would really like a superceded feature, they split from
    upstream for same reasons as us, they probably share the same frustrations
Timo:
    agreed, we should reach out to them
RP:
    we should get a list first before reaching out
Timo:
    we probably have about 30 patches on top of upstream, although most of
    them of them are probably just to add the supercede feature

Captured notes and recent research/discovery in the bug:
We have 49 commits since forking from patchwork-fdo.
Upstream patchwork-fdo has 166 commits since we forked.


PaulB:
    is there anything in bugzilla? 13684 is a django update
PaulB:
    to take action to capture this discussion in bugzilla
Timo:
    Amber working on layerindex, but maybe we can have her work on this too
    (not a promise), she has a lot of django experience


Timo:
    re perl dependency. there’s an existing oe-package-data util script,
    i’m using almost exact same code in a bitbake task, should this be
    refactored to lib/oe?
RP:
    sounds good, but depends on the implementation, in general i’m in favour
    of strong APIs in lib/oe. e.g. “packagedata” is too generic. the
    history was that packagedata.py was created as a way of pulling code out
    of a bbclass


minutes for Yocto Project Technical Team Meeting / Engineering Sync - June 9 2020

Trevor Woerner
 

Yocto Technical Team Minutes, Engineering Sync, for June 9 2020
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit

== disclaimer ==
Best efforts are made to ensure the below is accurate and valid. However,
errors sometimes happen. If any errors or omissions are found, please feel
free to reply to this email with any corrections.

== attendees ==
Trevor Woerner, Jan-Simon Möller, Stephen Jolly, Trevor Gamblin, Bruce
Ashfield, Scott Murray, Paul Barker, Michael Halstead, Jon Mason, Richard
Purdie, Joshua Watt, Armin Kuster, Tim Orling, Sathishkumar Duraisamy,
henriknj, Ross Burton, Jeremy Puhlman

== notes ==
- 2.7.4 released last week
- 3.1.1 built, but has issues, not sent to QA yet
- M1 early next week (to build)
- thanks to AlexK for lots of fixes

== general ==
RP:
problems with 3.1.1. qemu(-mips?) failed with taskhash mismatches, not
sure why


RP:
devtool, patchtest, patchwork, and wic looking for maintainers
PaulB:
patchtest/patchwork still on python2, needs 2→3 update. patchtest
should be moved to OE-core so it can be noticed by more people


RP:
lots of recipe upgrades, happy with where master is (wrt to recipe
versions), still need to update qemu to 5


JPEW:
did RP see my patch to mc-depends to make it backwards compatible?
RP:
dismayed it was more complex than hoped, but looks okay
JPEW:
i’m using a proxy object otherwise we need to duplicate a lot of code
with a lot of if’s
RP:
saw the BBMASK thing for multiconfig that needed index checking, sad
that we’ll be stuck with that going forward (in command.py) mostly for
backwards compatibility (e.g. file checking). another option is to have
a new API and append a ‘2’ to the end so callers will call the right
things (old or new). the code’s probably going to get worse and worse
with every new parameter we want to add (in the future)

JPEW:
re multiconfig, sometimes the old full “multiconfig” string
doesn’t work but the new “mc” string does, can we drop
“multiconfig”? changed in 2.7? or 3.0? there’s a bugzilla somewhere.
some code handles both, some doesn’t
RP:
we can get rid of it, despite the expected screaming


RP:
re devtool, reports on mailing list that devtool isn’t mc-compliant
RP:
we have a horrible hack for PRserver
RP:
highlights the need for a dedicated maintainer


PaulB:
re patchwork, kernel.org are using a newer version of patchwork that is
python3-compatible, is maintained, but missing some things we need
Timo:
i looked at freedesktop.org’s gitlab, they’ve made a lot of changes
from where we forked from them, they’re also using python3 and django2.
going with mainline will miss features that we’re used to
PaulB:
make a list of the gap items, then decide if we can live without these
things
Timo:
i looked at the fd.o’s patchwork and saw that many of the things we
added to our fork have been added (but differently) in fd.o’s. e.g. we
added a superseded feature, doesn’t seem to be on any other patchworks
PaulB:
would like to spin up concurrent patchworks to see how the react to the
mailing list
Timo:
good idea, maybe we can work together on that
PaulB:
for patchtest it seems obvious what steps are required, patchwork less
clear
Timo:
https://gitlab.freedesktop.org/patchwork-fdo
Timo:
might be a lot of work to compare ours with fd.o’s patch by patch to
see
PaulB:
we need to figure out if we can live with some upstream version, to cut
down on the effort of having our own fork
RP:
but it’ll cause a lot of pain if, for example, the superceded feature is
missing
Timo:
we’re better off putting resources elsewhere. upstream looks hard, but
i think patchwork-fdo looks like it might work, maybe easier to submit to
patchwork-fdo rather than upstream?
TrevorW:
maybe fdo would really like a superceded feature, they split from
upstream for same reasons as us, they probably share the same frustrations
Timo:
agreed, we should reach out to them
RP:
we should get a list first before reaching out
Timo:
we probably have about 30 patches on top of upstream, although most of
them of them are probably just to add the supercede feature
PaulB:
is there anything in bugzilla? 13684 is a django update
PaulB:
to take action to capture this discussion in bugzilla
Timo:
Amber working on layerindex, but maybe we can have her work on this too
(not a promise), she has a lot of django experience


Timo:
re perl dependency. there’s an existing oe-package-data util script,
i’m using almost exact same code in a bitbake task, should this be
refactored to lib/oe?
RP:
sounds good, but depends on the implementation, in general i’m in favour
of strong APIs in lib/oe. e.g. “packagedata” is too generic. the
history was that packagedata.py was created as a way of pulling code out
of a bbclass


minutes for Yocto Project Technical Team Meeting / Engineering Sync - June 2 2020

Trevor Woerner
 

Yocto Technical Team Minutes, Engineering Sync, for June 2 2020
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit

== disclaimer ==
Best efforts are made to ensure the below is accurate and valid. However,
errors sometimes happen. If any errors or omissions are found, please feel
free to reply to this email with any corrections.

== attendees ==
Trevor Woerner, Stephen Jolly, Joshua Watt, Mark Morton, Richard Purdie, Steve
Sakoman, Randy MacLeod, Trevor Gamblin, Bruce Ashfield, Jan-Simon Möller,
Jeremy Puhlmann, Jon Mason, Mark Van de Vyver, Michael Halstead, Paul Barker,
Ross Burton, Scott Murray, Tim Orling, Armin Kuster, Peter Kjellerstedt, David
Reyna, Denys Dmytriyenko

== notes ==
- YP 3.0.3 has been released
- YP 2.7.4 is awaiting final approval and likely to be released today
- YP 3.1.1 later this week or early next
- AB up on Fedora 32 and Ubuntu 20.04

== general ==
Randy: how do we feel about the build quality
RP: better, but it looks like there’s new races (e.g. icu-data) especially
when multiple builds are run in parallel, not “panic” yet, but
“concerned”
TrevorG: haven’t had success with logrotate yet
RP: on a good day there’s a 50% chance of a build failing
Randy: that’s not good, we see ~1% internally at WR

RP: Steve: we need to look at the ltp-release issue
Steve: okay
RP: upstream recommends removing some of the tests and using at least 1GB of
RAM

RP: Joshua sent invasive bitbake patches, something we probably should have
done a while back, but taking them makes LTS diverge significantly from
master, should we put it in LTS?
JPEW: maybe put it in master for a while, but ideally it would be in LTS
eventually

RP: python module issue for dunfell (LTS): upgrading to LTS
requires meta-openembedded because of meta-arm see:
https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg136914.html
(various): conflicted on whether this is good or not
Steve: including meta-oe is pretty much standard, hard to believe a production
system can build without it
RP+Timo: we see people who would rather cherry pick from meta-oe (and forking)
than importing meta-oe entirely
Paul: how does this cause breakage?
RP: versions and layer priorities
JPEW: happens when people already have meta-python and upgrade one but not
another
Scott: doesn’t the build fail?
JPEW: yes, it could, or they get the wrong versions
RP: if they upgrade oe-core but not meta-oe then it fails
JPEW: if we move them, do we also upgrade them?
RP: given the security issues, we should. i suggest punting to TSC
Timo: do we do the upgrade also on meta-oe dunfell branch?
RP: yes, but it needs to be clear that this is an exceptional circumstance,
this isn’t something we’ll do regularly
Steve: do we do it now, or 3.1.1?
RP: 3.1.1.
Ross: lots of overlap between OE and Yocto TSC, but I think this is mostly an
OE TSC issue
Timo: if this had happened a few months ago, this wouldn’t be an issue, so i
think it should go in
RP: agreed. JPEW and Bruce: thoughts?
JPEW + Bruce: sounds good
Paul: to clarify if oe-core is updated but meta-oe isn’t the wrong recipe is
used
RP: an older version of a recipe is used, so it succeeds but has the wrong
version
Paul: maybe we should add sanity checks
RP: don’t think we should
Scott: will dunfell be updated
Steve: have to dig into the issue to understand it

Timo: crops broken, worked on getting it working over the weekend, now works
from morty to zeus, but fails on dunfell and master, not sure why
RP: can we run the tests on AB?
Timo: probably just a “pip install”
RP: we do something similar with mingw

Timo: perl dependency, look at all the split packages, run all the files
through perl-req, in order to generate
RP: thanks for update

Scott: noticed <secret> is a platinum member
RP: yes, not quite ready to blog about it, the website updated, but still
finishing the deal, an official announcement is coming. we don’t know
who from their side will be interacting with the community, we’ll have
to see

Scott: is devday sign-up going to be posted?
David: just signed things recently, team has been distracted
Scott: how is it going to work this year?
David: zoom meeting, 500 participants, 3 hands-on, hoping for helpers (as
usual), separate rooms

RP: lots of changes behind the scenes, advocacy Tracy again, Andrew Wafaa on
board

RP: Mark how are things going with docs?
Mark: out last week. Nico has a wiki page setup for the conversion, working on
testing manual
RP: looking forward to first draft of testing manual! (then others can pitch
in)


Re: [meta-openssl102][PATCH] conf/layer.conf: Set layer compatible with dunfell

Fabio Berton
 

Ping

On Fri, Apr 17, 2020 at 9:42 AM Fabio Berton <fabio.berton@...> wrote:
Signed-off-by: Fabio Berton <fabio.berton@...>
---
 conf/layer.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index c7dcd8a..30ef9c9 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -10,7 +10,7 @@ BBFILE_PRIORITY_meta-openssl-one-zero-two = "5"

 LAYERVERSION_meta-openssl-one-zero-two = "1"

-LAYERSERIES_COMPAT_meta-openssl-one-zero-two = "thud warrior zeus"
+LAYERSERIES_COMPAT_meta-openssl-one-zero-two = "thud warrior zeus dunfell"

 LAYERDEPENDS_meta-openssl-one-zero-two = " \
         core \
--
2.26.1


M+ & H bugs with Milestone Movements WW23

Stephen Jolley
 

All,

YP M+ or high bugs which moved to a new milestone in WW23 are listed below:

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

13670

python3: missing standard library module 'pathlib'

timothy.t.orling@...

timothy.t.orling@...

3.2 M1

3.1.1

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Enhancements/Bugs closed WW23!

Stephen Jolley
 

All,

The below were the owners of enhancements or bugs closed during the last week!

Who

Count

trevor.gamblin@...

3

akuster808@...

3

alex.kanavin@...

2

joe.slater@...

1

richard.purdie@...

1

timothy.t.orling@...

1

JPEWhacker@...

1

Grand Total

12

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Current high bug count owners for Yocto Project 3.2

Stephen Jolley
 

All,

Below is the list as of top 50 bug owners as of the end of WW23 of who have open medium or higher bugs and enhancements against YP 3.2.   There are 101 possible work days left until the final release candidates for YP 3.2 needs to be released.

Who

Count

richard.purdie@...

29

david.reyna@...

19

bluelightning@...

17

bruce.ashfield@...

15

akuster808@...

10

kai.kang@...

10

ross@...

9

Qi.Chen@...

9

JPEWhacker@...

9

mark.morton@...

8

randy.macleod@...

7

trevor.gamblin@...

7

changqing.li@...

6

timothy.t.orling@...

5

michael@...

5

rpjday@...

4

pbarker@...

4

mingli.yu@...

4

jon.mason@...

3

hongxu.jia@...

3

raj.khem@...

3

kexin.hao@...

3

yi.zhao@...

3

mostthingsweb@...

2

mark.hatle@...

2

dl9pf@...

2

jaewon@...

2

ycnakajsph@...

2

seebs@...

2

alejandro@...

2

kergoth@...

2

chee.yang.lee@...

2

jpuhlman@...

2

ydirson@...

1

jason.wessel@...

1

yang.wang@...

1

akuster@...

1

matthew.zeng@...

1

kai.ruhnau@...

1

amber.n.elliot@...

1

naveen.kumar.saini@...

1

anuj.mittal@...

1

Martin.Jansa@...

1

nicolas.dechesne@...

1

sakib.sajal@...

1

ricardo.ribalda@...

1

liu.ming50@...

1

denis@...

1

bunk@...

1

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley
 

All,

 

The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading:

 

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs

 

The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project.  If anyone can help, please take ownership of the bug and send patches!  If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 366 unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out with these.  Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system.  There are also roughly four different "priority" classes right now, “3.1”, “3.2, "3.99" and "Future", the more pressing/urgent issues being in "3.1" and then “3.2”.

 

Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account).  The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Yocto Project Status WW23'20

Stephen Jolley
 

Current Dev Position: YP 3.2 M1

Next Deadline: YP 3.2 M1 build date 2020/6/16

 

Next Team Meetings:

 

Key Status/Updates:

  • YP 2.7.4 was released
  • YP 3.1.1 has been built with two issues being investigated before it enters QA
  • A significant number of upgrades have merged into master and we are up to date with a majority of recipes, particularly due work from Alex, thanks! One which isn’t and is looking slightly more problematic is the qemu upgrade to 5.0.0, help would be welcome there.
  • YP 3.2 M1 is due to build next week so patches for M1 need to be sent for review now in order to make it in.
  • We are struggling with maintainers for some key components of the system/infrastructure such as devtool, wic, buildhistory and patchwork/patchtest. If anyone can help in these areas please contact Richard.
  • There remain a large number of bugs that we’d ideally like to fix in 3.2 M1 (or M2) but they are “unassigned”, there is nobody to work on them. If anyone has time, looking at these bugs would be a great way to help us. See: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_3.2_Unassigned_Enhancements.2FBugs

 

YP 3.2 Milestone Dates:

  • YP 3.2 M1 build date 2020/6/16
  • YP 3.2 M1 Release date 2020/6/26
  • YP 3.2 M2 build date 2020/7/27
  • YP 3.2 M2 Release date 2020/8/7
  • YP 3.2 M3 build date 2020/8/31
  • YP 3.2 M3 Release date 2020/9/11
  • YP 3.2 M4 build date 2020/10/5
  • YP 3.2 M4 Release date 2020/10/30

 

Planned upcoming dot releases:

  • YP 2.7.4 has been released
  • YP 3.1.1 build date 2020/6/09
  • YP 3.1.1 release date 2020/6/20
  • YP 3.0.4 build date 2020/8/10
  • YP 3.0.4 release date 2020/8/21
  • YP 3.1.2 build date 2020/9/14
  • YP 3.1.2 release date 2020/9/25

 

Tracking Metrics:

 

The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Re: OpenRC

 

On Tue, 9 Jun 2020 at 14:49, Mauro Ziliani <mauro@faresoftware.it> wrote:

Hi all.

There is a plan to integrate OpenRC like startup scripts environment?
I know of https://github.com/jsbronder/meta-openrc but I've not tested
it myself.

Thanks,

--
Paul Barker
Konsulko Group


OpenRC

Mauro Ziliani
 

Hi all.

There is a plan to integrate OpenRC like startup scripts environment?


MZ


[meta-security][PATCH] apparmor: pull in coreutils/findutils only when not using systemd as init manager

Alexander Kanavin
 

The utilities from those packages (xargs, comm) are only used in sysvinit
scripts, and so there is no need to pull them in when systemd is in use.
Both are gpl3 licensed, so this is beneficial for builds where gpl3 is not
allowed.

Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
recipes-mac/AppArmor/apparmor_2.13.4.bb | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/recipes-mac/AppArmor/apparmor_2.13.4.bb b/recipes-mac/AppArmor/apparmor_2.13.4.bb
index d6f61b3..552cac7 100644
--- a/recipes-mac/AppArmor/apparmor_2.13.4.bb
+++ b/recipes-mac/AppArmor/apparmor_2.13.4.bb
@@ -191,7 +191,8 @@ PACKAGES += "mod-${PN}"
FILES_${PN} += "/lib/apparmor/ ${sysconfdir}/apparmor ${PYTHON_SITEPACKAGES_DIR}"
FILES_mod-${PN} = "${libdir}/apache2/modules/*"

-RDEPENDS_${PN} += "coreutils findutils ${@bb.utils.contains('PACKAGECONFIG','python','python3-core python3-modules','', d)}"
+# Add coreutils and findutils only if sysvinit scripts are in use
+RDEPENDS_${PN} += "${@["coreutils findutils", ""][(d.getVar('VIRTUAL-RUNTIME_init_manager') == 'systemd')]} ${@bb.utils.contains('PACKAGECONFIG','python','python3-core python3-modules','', d)}"
RDEPENDS_${PN}_remove += "${@bb.utils.contains('PACKAGECONFIG','perl','','perl', d)}"
RDEPENDS_${PN}-ptest += "perl coreutils dbus-lib bash"

--
2.26.2


Re: [swupdate] RE: [yocto] [PATCH] [meta-swupdate] Fix build error of dependence.

Stefano Babic
 

Hi Zheng,

On 08.06.20 10:49, Zheng, Ruoqin wrote:
Hi Stefano

there is a ML for SWUpdate and meta-swupdate (see CC), we are cross-
posting here:
Thank you, I got it.

openSSL is not the only supported SSL library, the Webserver runs also with
mbedTLS. This patch forces to use openSSL and conflicts in case mbedTLS is
used as signing and crypto library.

if 'CONFIG_JSON=y\n' in features:
depends += ' json-c'
OK, I'll update my patch and send V2 version.
I do not think the issue exists. In fact, CONFIG_MONGOOSESSL is
protected by CONFIG_SSL_IMPL_OPENSSL or CONFIG_SSL_IMPL_MBEDTLS. If you
set CONFIG_MONGOOSESSL, SSL is already set.

The only way to go into the issue is to modify directly your defconfig
file instead of running "bitbake -c menuconfig" and then apply the
diffconfig or the new defconfig. But this is of course a wrong way,
exactly as in kernel.

Try to run "mnuconfig" and then you can apply the fragment to your
diffconfig (fragments are supported, too).

Best regards,
Stefano

--------------------------------------------------
Zheng Ruoqin
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
ADDR.: No.6 Wenzhu Road, Software Avenue,
Nanjing, 210012, China
MAIL : zhengrq.fnst@cn.fujistu.com



-----Original Message-----
From: Stefano Babic <sbabic@denx.de>
Sent: Thursday, June 4, 2020 3:22 PM
To: Zheng, Ruoqin/郑 若钦 <zhengrq.fnst@cn.fujitsu.com>;
yocto@yoctoproject.org
Cc: swupdate <swupdate@googlegroups.com>
Subject: Re: [yocto] [PATCH] [meta-swupdate] Fix build error of dependence.

Hi Zheng,

there is a ML for SWUpdate and meta-swupdate (see CC), we are cross-
posting here:

On 04.06.20 14:26, zhengruoqin wrote:
-c -o mongoose/mongoose.o mongoose/mongoose.c
| mongoose/mongoose.c:4496:10: fatal error: openssl/ssl.h: No such
| file
or directory

Signed-off-by: Zheng Ruoqing <zhengrq.fnst@cn.fujitsu.com>
---
recipes-support/swupdate/swupdate.inc | 3 +++
1 file changed, 3 insertions(+)

diff --git a/recipes-support/swupdate/swupdate.inc
b/recipes-support/swupdate/swupdate.inc
index 9ea0a8a..3d9a3fa 100644
--- a/recipes-support/swupdate/swupdate.inc
+++ b/recipes-support/swupdate/swupdate.inc
@@ -123,6 +123,9 @@ python () {
elif 'CONFIG_SSL_IMPL_MBEDTLS=y\n' in features:
depends += ' mbedtls'

+ if 'CONFIG_MONGOOSESSL=y\n' in features:
+ depends += ' openssl'
+
openSSL is not the only supported SSL library, the Webserver runs also with
mbedTLS. This patch forces to use openSSL and conflicts in case mbedTLS is
used as signing and crypto library.

if 'CONFIG_JSON=y\n' in features:
depends += ' json-c'




Best regards,
Stefano Babic






--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@denx.de
=====================================================================


Re: [PATCH] [meta-swupdate] Fix build error of dependence.

zhengruoqin
 

Hi Stefano

there is a ML for SWUpdate and meta-swupdate (see CC), we are cross-
posting here:
Thank you, I got it.

openSSL is not the only supported SSL library, the Webserver runs also with
mbedTLS. This patch forces to use openSSL and conflicts in case mbedTLS is
used as signing and crypto library.

if 'CONFIG_JSON=y\n' in features:
depends += ' json-c'
OK, I'll update my patch and send V2 version.

--------------------------------------------------
Zheng Ruoqin
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
ADDR.: No.6 Wenzhu Road, Software Avenue,
Nanjing, 210012, China
MAIL : zhengrq.fnst@cn.fujistu.com



-----Original Message-----
From: Stefano Babic <sbabic@denx.de>
Sent: Thursday, June 4, 2020 3:22 PM
To: Zheng, Ruoqin/郑 若钦 <zhengrq.fnst@cn.fujitsu.com>;
yocto@yoctoproject.org
Cc: swupdate <swupdate@googlegroups.com>
Subject: Re: [yocto] [PATCH] [meta-swupdate] Fix build error of dependence.

Hi Zheng,

there is a ML for SWUpdate and meta-swupdate (see CC), we are cross-
posting here:

On 04.06.20 14:26, zhengruoqin wrote:
-c -o mongoose/mongoose.o mongoose/mongoose.c
| mongoose/mongoose.c:4496:10: fatal error: openssl/ssl.h: No such
| file
or directory

Signed-off-by: Zheng Ruoqing <zhengrq.fnst@cn.fujitsu.com>
---
recipes-support/swupdate/swupdate.inc | 3 +++
1 file changed, 3 insertions(+)

diff --git a/recipes-support/swupdate/swupdate.inc
b/recipes-support/swupdate/swupdate.inc
index 9ea0a8a..3d9a3fa 100644
--- a/recipes-support/swupdate/swupdate.inc
+++ b/recipes-support/swupdate/swupdate.inc
@@ -123,6 +123,9 @@ python () {
elif 'CONFIG_SSL_IMPL_MBEDTLS=y\n' in features:
depends += ' mbedtls'

+ if 'CONFIG_MONGOOSESSL=y\n' in features:
+ depends += ' openssl'
+
openSSL is not the only supported SSL library, the Webserver runs also with
mbedTLS. This patch forces to use openSSL and conflicts in case mbedTLS is
used as signing and crypto library.

if 'CONFIG_JSON=y\n' in features:
depends += ' json-c'




Best regards,
Stefano Babic





License files path

Teemu K.
 

Hi,

Is there a way to determine where the license files are stored? It
would help a lot in automatizing build system when you'd know where to
copy licenses from.

They go to build/tmp/deploy/licenses, but then license.manifest
containing list of all the licenses in an image is under that
directory on directory that changes pretty much every time image is
built. Sometimes also the latest directory contains only
image_license.manifest, but license.manifest and package.manifest is
missing. I haven't been able to track down that issue either.

So is there way to determine which path the licenses were stored in?
And how to generate image so that it will always generate
license.manifest and package.manifest as well?

I noticed that in that licenses - directory there is directory with
image name, but it's not link to latest directory so I can't use that.
Seems that it only lists license/version info for image recipe.

-Teemu


SDK having libraries that are not in image

Teemu K.
 

Hi,

I'm using Warrior - version of Yocto and I have libraries ending up to
SDK that are not in image and it's causing problems because
applications are trying to look for libraries that are not there. This
is not first time this has happened and I'm wondering why it's
happening in the first place.

Here are the libraries that are on SDK, but not on image:

libsmime3.so => not found
libnss3.so => not found
libsoftokn3.so => not found
libnssutil3.so => not found
libplds4.so => not found
libplc4.so => not found
libnspr4.so => not found
libevent-2.1.so.6 => not found

I've used bitbake <image> -c populate_sdk - command to generate SDK.
Is there something I'm missing from configuration or something what's
causing this? To 'fix' this problem I need to separately add those
libraries to image so I get image match SDK and not the other way
around.

-TeemuK

3541 - 3560 of 53147