[linux-yocto] [yocto-kernel-cache]: bcm-2xxx-rpi: enable CONFIG_BROADCOM_PHY for raspberry pi4 platform

2020-07-21 Thread Meng Li
From: Limeng 

Hi Bruce,

Could you please help to merge this patch into yocto-kernel-cache, branches are 
master and yocto-5.4?
It is need to enable phy driver for raspberry pi4 platform

diffstat info ad below:

 bcm-2xxx-rpi.cfg |1 +
 1 file changed, 1 insertion(+)


thanks,
Limeng
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8851): 
https://lists.yoctoproject.org/g/linux-yocto/message/8851
Mute This Topic: https://lists.yoctoproject.org/mt/75719085/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


[linux-yocto] [PATCH] bcm-2xxx-rpi: enable CONFIG_BROADCOM_PHY for raspberry pi4 platform

2020-07-21 Thread Meng Li
From: Limeng 

Enable phy driver for raspberry pi4 platform.

Signed-off-by: Meng Li 
---
 bsp/bcm-2xxx-rpi/bcm-2xxx-rpi.cfg | 1 +
 1 file changed, 1 insertion(+)

diff --git a/bsp/bcm-2xxx-rpi/bcm-2xxx-rpi.cfg 
b/bsp/bcm-2xxx-rpi/bcm-2xxx-rpi.cfg
index a5060364..a80ea331 100644
--- a/bsp/bcm-2xxx-rpi/bcm-2xxx-rpi.cfg
+++ b/bsp/bcm-2xxx-rpi/bcm-2xxx-rpi.cfg
@@ -56,6 +56,7 @@ CONFIG_MTD_BLOCK=m
 # Ethernet devices
 CONFIG_NET=y
 CONFIG_BCMGENET=y
+CONFIG_BROADCOM_PHY=y
 
 # Serial drivers
 CONFIG_SERIAL_8250=y
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8850): 
https://lists.yoctoproject.org/g/linux-yocto/message/8850
Mute This Topic: https://lists.yoctoproject.org/mt/75719084/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


[yocto] [meta-security][PATCH] ibmswtpm2: upgrade 1563 -> 1628

2020-07-21 Thread Yi Zhao
Signed-off-by: Yi Zhao 
---
 .../recipes-tpm2/ibmswtpm2/ibmswtpm2_1563.bb  | 27 ---
 .../recipes-tpm2/ibmswtpm2/ibmswtpm2_1628.bb  | 26 ++
 2 files changed, 26 insertions(+), 27 deletions(-)
 delete mode 100644 meta-tpm/recipes-tpm2/ibmswtpm2/ibmswtpm2_1563.bb
 create mode 100644 meta-tpm/recipes-tpm2/ibmswtpm2/ibmswtpm2_1628.bb

diff --git a/meta-tpm/recipes-tpm2/ibmswtpm2/ibmswtpm2_1563.bb 
b/meta-tpm/recipes-tpm2/ibmswtpm2/ibmswtpm2_1563.bb
deleted file mode 100644
index 8054226..000
--- a/meta-tpm/recipes-tpm2/ibmswtpm2/ibmswtpm2_1563.bb
+++ /dev/null
@@ -1,27 +0,0 @@
-SUMMARY = "IBM's Software TPM 2.0"
-LICENSE = "BSD"
-SECTION = "securty/tpm"
-LIC_FILES_CHKSUM = "file://../LICENSE;md5=1e023f61454ac828b4aa1bc4293f7d5f"
-
-DEPENDS = "openssl"
-
-SRC_URI = "https://sourceforge.net/projects/ibmswtpm2/files/ibmtpm${PV}.tar.gz 
\
-   file://remove_optimization.patch \
-   "
-SRC_URI[md5sum] = "13013612b3a13dc935fefe1a5684179c"
-SRC_URI[sha256sum] = 
"fc3a17f8315c1f47670764f2384943afc0d3ba1e9a0422dacb08d455733bd1e9"
-SRC_URI[sha1sum] = "a2a5335024a2edc1739f08b99e716fa355be627d"
-SRC_URI[sha384sum] = 
"b1f278acabe2198aa79c0fe8aa0182733fe701336cbf54a88058be0b574cab768f59f9315882d0e689e634678d05b79f"
-SRC_URI[sha512sum] = 
"ff0b9e5f0d0070eb572b23641f7a0e70a8bc65cbf4b59dca1778be3bb014124011221a492147d4c492584e87af23e2f842ca6307641b3919f67a3f27f09312c0"
-
-S = "${WORKDIR}/src"
-
-do_compile () {
-   make CC='${CC}'
-}
-
-do_install () {
-   install -d ${D}/${bindir}
-   install -m 0755 tpm_server  ${D}/${bindir}
-}
-
diff --git a/meta-tpm/recipes-tpm2/ibmswtpm2/ibmswtpm2_1628.bb 
b/meta-tpm/recipes-tpm2/ibmswtpm2/ibmswtpm2_1628.bb
new file mode 100644
index 000..3373a30
--- /dev/null
+++ b/meta-tpm/recipes-tpm2/ibmswtpm2/ibmswtpm2_1628.bb
@@ -0,0 +1,26 @@
+SUMMARY = "IBM's Software TPM 2.0"
+LICENSE = "BSD"
+SECTION = "securty/tpm"
+LIC_FILES_CHKSUM = "file://../LICENSE;md5=1e023f61454ac828b4aa1bc4293f7d5f"
+
+DEPENDS = "openssl"
+
+SRC_URI = "https://sourceforge.net/projects/ibmswtpm2/files/ibmtpm${PV}.tar.gz 
\
+   file://remove_optimization.patch \
+   "
+SRC_URI[md5sum] = "bfd3eca2411915f24de628b9ec36f259"
+SRC_URI[sha256sum] = 
"a8e874e7a1ae13a1290d7679d846281f72d0eb6a5e4cfbafca5297dbf4e29ea3"
+SRC_URI[sha1sum] = "7c8241a4e97a801eace9f0eea8cdda7c58114f7f"
+SRC_URI[sha384sum] = 
"eec25cc8ba0e3cb27d41ba4fa4c71d8158699953ccb61bb6d440236dcbd8f52b6954eaae9d640a713186e0b99311fd91"
+SRC_URI[sha512sum] = 
"ab47caa4406ba57c0afc6fadae304fc9ef5e3e125be0f2fb1955a419cf93cd5e9176e103f0b566825abc16cca00b795f98d2b407f0a2bf7b141ef4b025d907d0"
+
+S = "${WORKDIR}/src"
+
+do_compile () {
+   make CC='${CC}'
+}
+
+do_install () {
+   install -d ${D}/${bindir}
+   install -m 0755 tpm_server  ${D}/${bindir}
+}
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#50058): https://lists.yoctoproject.org/g/yocto/message/50058
Mute This Topic: https://lists.yoctoproject.org/mt/75718233/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


[linux-yocto] [linux-yocto kernel][v5.4/standard/bcm-2xxx-rpi]: bcm-2xxx-rpi: bcm2711-rpi-4-b.dts: Do not power off the SD card after boot

2020-07-21 Thread Meng Li
From: Limeng 

Hi Bruce,

Could you please help to merge this patch into linux-yocto kernel, branch is 
v5.4/standard/bcm-2xxx-rpi?

diffstat info ad below:

 bcm2711-rpi-4-b.dts |1 +
 1 file changed, 1 insertion(+)


thanks,
Limeng
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8848): 
https://lists.yoctoproject.org/g/linux-yocto/message/8848
Mute This Topic: https://lists.yoctoproject.org/mt/75717851/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


[yocto] Yocto support

2020-07-21 Thread JH
Hi,

Does Flextronics https://flex.com support Yocto or not?

Thank you.

Kind regards.

-- 
"A man can fail many times, but he isn't a failure until he begins to
blame somebody else."
-- John Burroughs
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#50057): https://lists.yoctoproject.org/g/yocto/message/50057
Mute This Topic: https://lists.yoctoproject.org/mt/75717382/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


[yocto] How to enable network connection of CUPS ? #cups #yocto

2020-07-21 Thread Soi, Sheng Leong
Hi,

The CUPS in Yocto image has its network connection to be closed by checking
through "curl -I http://localhost:631; ; mentioning connection status is close,
which cause the printer unable to be shared.

Is there any method to enable CUPS network connection so that the printer can
be shared?

Thanks
Sheng Leong
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#50056): https://lists.yoctoproject.org/g/yocto/message/50056
Mute This Topic: https://lists.yoctoproject.org/mt/75716759/21656
Mute #cups: https://lists.yoctoproject.org/g/yocto+yocto/mutehashtag/cups
Mute #yocto: https://lists.yoctoproject.org/g/yocto+yocto/mutehashtag/yocto
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [yocto] Linker error undefined reference to `_rtld_global_ro'

2020-07-21 Thread Khem Raj



On 7/21/20 8:07 AM, Robert Varga wrote:

Hi Khem,

Do you have any ideas, whether the passed compiler parameters ("-pie" or 
"-fpie") are the origin of this linker issues?


Does anyone know if glibc is compiled with "--enable-static-pie" if the 
passed compiler parameters include those "-pie" or "-fpie"? Or are they 
unrelated?




can you try setting GLIBCPIE = "" in local.conf and see if that helps


Thanks a lot for your support.

--
Rob



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#50055): https://lists.yoctoproject.org/g/yocto/message/50055
Mute This Topic: https://lists.yoctoproject.org/mt/75474633/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


[yocto][meta-mingw][PATCH] gdb-cross-canadian: Stop statically linking

2020-07-21 Thread Joshua Watt
gdb was configured to statically link, presumably so it could find the
static libexpat library. Since libexpat has been updated, it no longer
builds a static library, so remove the flag to make GDB look for one.

Signed-off-by: Joshua Watt 
---
 recipes-devtools/gdb/gdb-cross-canadian_%.bbappend | 1 -
 1 file changed, 1 deletion(-)

diff --git a/recipes-devtools/gdb/gdb-cross-canadian_%.bbappend 
b/recipes-devtools/gdb/gdb-cross-canadian_%.bbappend
index 067b614..c33a9ce 100644
--- a/recipes-devtools/gdb/gdb-cross-canadian_%.bbappend
+++ b/recipes-devtools/gdb/gdb-cross-canadian_%.bbappend
@@ -1,4 +1,3 @@
-LDFLAGS_append_sdkmingw32 = " -Wl,-static"
 EXEEXT_sdkmingw32 = ".exe"
 DEPENDS_remove_sdkmingw32 = "nativesdk-ncurses nativesdk-readline 
nativesdk-python"
 RDEPENDS_${PN}_remove_sdkmingw32 = "nativesdk-python-core 
nativesdk-python-lang nativesdk-python-re nativesdk-python-codecs 
nativesdk-python-netclient"
-- 
2.27.0

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#50054): https://lists.yoctoproject.org/g/yocto/message/50054
Mute This Topic: https://lists.yoctoproject.org/mt/75709150/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


[yocto][meta-mingw][PATCH] cmake: Remove toolchain append

2020-07-21 Thread Joshua Watt
Now that cmake.bbclass in OE-core correctly accounts for MinGW hosts, it
is no longer necessary to manually specify that CMAKE_SYSTEM_NAME as
"Windows"

Signed-off-by: Joshua Watt 
---
 recipes-devtools/cmake/cmake_%.bbappend | 6 --
 1 file changed, 6 deletions(-)

diff --git a/recipes-devtools/cmake/cmake_%.bbappend 
b/recipes-devtools/cmake/cmake_%.bbappend
index d9d7ceb..42d36ac 100644
--- a/recipes-devtools/cmake/cmake_%.bbappend
+++ b/recipes-devtools/cmake/cmake_%.bbappend
@@ -1,7 +1 @@
 DEPENDS_remove_mingw32 = "ncurses"
-
-cmake_do_generate_toolchain_file_append_mingw32() {
-cat >> ${WORKDIR}/toolchain.cmake <-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#50053): https://lists.yoctoproject.org/g/yocto/message/50053
Mute This Topic: https://lists.yoctoproject.org/mt/75709145/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [yocto] Yocto Dunfell: package.class --> dwarfsrcfiles

2020-07-21 Thread Khem Raj



On 7/21/20 3:45 AM, Jan Hannig wrote:

Hello,

with the upgrade from Yocto Zeus → Dunfell, we observe lots of messages 
when building our product which seem heavy to be understood or to debug.


Actually, it's the failure of the "do_package" task of a proprietary 
module written in C with following message:


ERROR: eds-1.0-r0 do_package: dwarfsrcfiles failed with exit code 1 (cmd 
was ['dwarfsrcfiles', 
'/home/jhannig/workspace/build/mguard3_tmp/work/aarch64-mguard-linux/eds/1.0-r0/package/usr/lib/libhdb.a']):


dwarfsrcfiles: 
/home/jhannig/workspace/build/mguard3_tmp/work/aarch64-mguard-linux/eds/1.0-r0/package/usr/lib/libhdb.a: 
not a valid ELF file


ERROR: Logfile of failure stored in: 
/home/jhannig/workspace/build/mguard3_tmp/work/aarch64-mguard-linux/eds/1.0-r0/temp/log.do_package.13957


ERROR: Task 
(/home/jhannig/workspace/mguard/meta-mguard/recipes-core/eds/eds_1.0.bb:do_package) 
failed with exit code '1'


Following information to understand the problem:

- The code of this module wasn't changed, and it compiled errorless with 
release "Zeus"


- The examination of the file "libhdb.a" brings following results:

- It is possible to unpack the archive-file "libhdb.a": 
  jhannig@jhannig:~/Archiv/MG-2436$ ar x libhdb.a


- The Examination of the content with "file *.o" 
[jhannig@jhannig:~/Archiv/MG-2436$ file *.o] brings following results:


hdb.o: ELF 64-bit LSB relocatable, ARM aarch64, version 1 
(SYSV), not stripped


hdbschema.o:   ELF 64-bit LSB relocatable, ARM aarch64, version 1 
(SYSV), not stripped


hdbstaticschema.o: ELF 64-bit LSB relocatable, ARM aarch64, version 1 
(SYSV), not stripped


utils.o:   ELF 64-bit LSB relocatable, ARM aarch64, version 1 
(SYSV), not stripped


- This corresponds with the expectation and the intended character of 
the file


- Minor changes in the makefile command line didn't change anything in 
the result [EXTRA_OEMAKE += 'CC="${CC}" CPPFLAGS="${CPPFLAGS}" 
CFLAGS="${CFLAGS}" LDFLAGS="${LDFLAGS}" AR="${AR}" EDS_XML="${EDS_XML}"']


- Searching the internet for "dwarfsrcfiles" doesn't bring any 
informative or documentative result, so it doesn't become clear, what 
this tool exactly does.


Following questions asked to the community:

- Which cases of errors result in this error message?


something goes amiss in the ELF object generation, it could be many 
reasons like corrupt files or additional information in these objects 
which can confuse the dwarf reader




- What changed with the new yocto release, that "suddenly" a build 
result is analyzed as failure?


packages get upgraded and in this particular case elfutils is the main 
package and it would have got upgraded to new revision which can bring 
additional behavior.




- Where exactly in the tool code is this error thrown? The message "not 
a valid ELF file" isn't available in the code



its coming from dwarf reader provided by libdwfl from elfutils package.



- What should be done with the archive file and its content to eliminate 
the error?


its not clear as to what might be going here so hard to say, but perhaps 
you can debug dwarfsrcfiles tool using gdb and your .a file as input and 
see why it things its a bad ELF object. It will perhaps give more 
insights. Its a native tool so should be easy to debug through. May be 
share stack trace etc. when it reaches the error state.


Secondly, it will be good to look at the build options used to create 
this .a and see if something stands out.




- Is this behavior well known, and is there any documentation to get 
information about the tool?


its not well known, but its an error state that can happen.



Thanks a lot for help,

kind regards

Jan Hannig

Reasearch and Development

jhan...@phoenixcontact.com 

www.phoenixcontact.com 

...

PHOENIX CONTACT Cyber Security GmbH 

Richard-Willstätter-Straße 6  

D-12489 Berlin  

 

Register Court: AG Charlottenburg, HR B 202908 

Geschäftsführer/General Manager: Kilian Golm

//



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#50052): https://lists.yoctoproject.org/g/yocto/message/50052
Mute This Topic: https://lists.yoctoproject.org/mt/75700982/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [yocto] meta-kirkwood layer #yocto

2020-07-21 Thread Khem Raj



On 7/7/20 10:25 AM, jjvazha via lists.yoctoproject.org wrote:
I saw this message thread ( 
https://lists.yoctoproject.org/g/yocto/topic/61257317)  and wondering 
how can I get this yocto compatible  layer  for marwell kirkwood ?
I want to build a linux ketnel for marwell kirk wood  ( using the 
sheevaplug.conf for machine) using yocto 2.7.3
I down loaded this layer 
(https://github.com/kelvinlawson/meta-kirkwood)   this is opnembedded 
based , however upon building in yocto  it failed with the following message


Entering directory 
`/home/jojan.vazhaeparampil/workspace/distro/build_zion/tmp/work-shared/sheevaplug/kernel-source'
|   GEN 
/home/jojan.vazhaeparampil/workspace/distro/build_zion/tmp/work/sheevaplug-poky-linux-gnueabi/linux-kirkwood/2.6.35-rc1-r14/build/Makefile

| make[2]: *** No rule to make target `oldnoconfig'.  Stop.
| make[1]: *** [oldnoconfig] Error 2
| make: *** [sub-make] Error 2
| make: Leaving directory 
`/home/jojan.vazhaeparampil/workspace/distro/build_zion/tmp/work-shared/sheevaplug/kernel-source'

| ERROR: oe_runmake failed


When I checked the "sheevaplug/kernel-source' directory it is empty ?



meta-kirkwood is kind of stale, last commit was 7 years, 9 months ago, 
perhaps look around for another machine layer or fix this one





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#50050): https://lists.yoctoproject.org/g/yocto/message/50050
Mute This Topic: https://lists.yoctoproject.org/mt/75700683/21656
Mute #yocto: https://lists.yoctoproject.org/g/yocto+yocto/mutehashtag/yocto
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [yocto] Linker error undefined reference to `_rtld_global_ro'

2020-07-21 Thread Robert Varga
Hi Khem,

Do you have any ideas, whether the passed compiler parameters (" -pie " or " 
-fpie ") are the origin of this linker issues?

Does anyone know if glibc is compiled with "--enable-static-pie" if the passed 
compiler parameters include those " -pie " or " -fpie "? Or are they unrelated?

Thanks a lot for your support.

--
Rob
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#50049): https://lists.yoctoproject.org/g/yocto/message/50049
Mute This Topic: https://lists.yoctoproject.org/mt/75474633/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


[yocto] Yocto Project Status WW29'20

2020-07-21 Thread Stephen Jolley
Current Dev Position: YP 3.2 M2

Next Deadline: YP 3.2 M2 build date 2020/7/27

 

Next Team Meetings:

*   Bug Triage meeting Thursday July 23th at 7:30am PDT (
 https://zoom.us/j/454367603)
*   Monthly Project Meeting Tuesday Aug. 4th at 8am PDT (
 https://zoom.us/j/990892712)
*   Weekly Engineering Sync Tuesday July 21st  at 8am PDT (
 https://zoom.us/j/990892712)
*   Twitch -  See https://www.twitch.tv/theyoctojester

 

Key Status/Updates:

*   The number of intermittent race issues is reduced however we are
still seeing some recurring issues and some new issues too. You can see the
list of failures we're continuing to see by searching for the "AB-INT" tag
in bugzilla:

https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

Help with any of these would be much appreciated.

*   We are planning to do a build of 3.1.2 this week as the project
appears to be in reasonable shape after the recent race fixes that were
backported.
*   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.
*   Another way to help the project is to help us with bugs that are
currently unassigned but ideally needed during 3.2. See:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_3.2_Unassigned_Enhan
cements.2FBugs
*   Help with any of the recent failed AUH recipe upgrades would also be
appreciated.

 

YP 3.2 Milestone Dates:

*   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 3.0.4 build date 2020/8/10
*   YP 3.0.4 release date 2020/8/21
*   YP 3.1.2 build date 2020/7/20
*   YP 3.1.2 release date 2020/7/31
*   YP 3.1.3 build date 2020/9/14
*   YP 3.1.3 release date 2020/9/25

 

Tracking Metrics:

*   WDD 2450 (last week 2465) (

https://wiki.yoctoproject.org/charts/combo.html)
*   Poky Patch Metrics  

*   Total patches found: 1275 (last week 1269)
*   Patches in the Pending State: 498 (39%) [last week 498 (39%)]

 

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...@gmail.com
 

 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#50048): https://lists.yoctoproject.org/g/yocto/message/50048
Mute This Topic: https://lists.yoctoproject.org/mt/75704938/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [yocto] Adding libgpiod to Yocto Warrior 4.19.35 image?

2020-07-21 Thread Scott Whitney
Thanks, Quentin,  I'll take a look at Jozef's videos as time permits.  Getting 
lots of time pressure to get something working, and even our SoM vendor 
provides examples that modify local.conf... so much for helping us with the 
"right" way to do things.  I appreciate your advice, and can now see gpiod.h 
and libgpiod.so in my image.

Best regards,
Scott
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#50046): https://lists.yoctoproject.org/g/yocto/message/50046
Mute This Topic: https://lists.yoctoproject.org/mt/75620505/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [yocto] Adding libgpiod to Yocto Warrior 4.19.35 image?

2020-07-21 Thread Quentin Schulz
Hi Scott,

On Mon, Jul 20, 2020 at 10:48:52AM -0700, Scott Whitney wrote:
> Thanks for the tip, Joel.  I'm still new to this.  How should libgpiod-dev be 
> added to my local.conf?
> Do I just need to add it to EXTRA_IMAGE_FEATURES?  Do I still need to add 
> libgpiod to IMAGE_INSTALL_append?
> 

IMAGE_INSTALL is the way to go.

I recommend spending some time on watching
https://www.youtube.com/playlist?list=PLD4M5FoHz-TxMfBFrDKfIS_GLY25Qsfyj

Here you'll learn that you shouldn't really use local.conf for that
purpose and how to add packages to your image (and many other things).
Consider to subscribe, Jozef streams on Twitch every month or so and
then uploads the videos to the Youtube channel.

Cheers,
Quentin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#50045): https://lists.yoctoproject.org/g/yocto/message/50045
Mute This Topic: https://lists.yoctoproject.org/mt/75620505/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


[yocto] Yocto Dunfell: package.class --> dwarfsrcfiles

2020-07-21 Thread Jan Hannig
Hello,



with the upgrade from Yocto Zeus → Dunfell, we observe lots of messages when 
building our product which seem heavy to be understood or to debug.

Actually, it's the failure of the "do_package" task of a proprietary module 
written in C with following message:



ERROR: eds-1.0-r0 do_package: dwarfsrcfiles failed with exit code 1 (cmd was 
['dwarfsrcfiles', 
'/home/jhannig/workspace/build/mguard3_tmp/work/aarch64-mguard-linux/eds/1.0-r0/package/usr/lib/libhdb.a']):

dwarfsrcfiles: 
/home/jhannig/workspace/build/mguard3_tmp/work/aarch64-mguard-linux/eds/1.0-r0/package/usr/lib/libhdb.a:
 not a valid ELF file



ERROR: Logfile of failure stored in: 
/home/jhannig/workspace/build/mguard3_tmp/work/aarch64-mguard-linux/eds/1.0-r0/temp/log.do_package.13957

ERROR: Task 
(/home/jhannig/workspace/mguard/meta-mguard/recipes-core/eds/eds_1.0.bb:do_package)
 failed with exit code '1'



Following information to understand the problem:

- The code of this module wasn't changed, and it compiled errorless with 
release "Zeus"

- The examination of the file "libhdb.a" brings following results:

- It is possible to unpack the archive-file "libhdb.a":  
jhannig@jhannig:~/Archiv/MG-2436$ ar x libhdb.a

- The Examination of the content with "file *.o" 
[jhannig@jhannig:~/Archiv/MG-2436$ file *.o] brings following results:

hdb.o: ELF 64-bit LSB relocatable, ARM aarch64, version 1 (SYSV), 
not stripped

hdbschema.o:   ELF 64-bit LSB relocatable, ARM aarch64, version 1 (SYSV), 
not stripped

hdbstaticschema.o: ELF 64-bit LSB relocatable, ARM aarch64, version 1 (SYSV), 
not stripped

utils.o:   ELF 64-bit LSB relocatable, ARM aarch64, version 1 (SYSV), 
not stripped

- This corresponds with the expectation and the intended character of the file

- Minor changes in the makefile command line didn't change anything in the 
result [EXTRA_OEMAKE += 'CC="${CC}" CPPFLAGS="${CPPFLAGS}" CFLAGS="${CFLAGS}" 
LDFLAGS="${LDFLAGS}" AR="${AR}" EDS_XML="${EDS_XML}"']

- Searching the internet for "dwarfsrcfiles" doesn't bring any informative or 
documentative result, so it doesn't become clear, what this tool exactly does.



Following questions asked to the community:

- Which cases of errors result in this error message?

- What changed with the new yocto release, that "suddenly" a build result is 
analyzed as failure?

- Where exactly in the tool code is this error thrown? The message "not a valid 
ELF file" isn't available in the code

- What should be done with the archive file and its content to eliminate the 
error?

- Is this behavior well known, and is there any documentation to get 
information about the tool?



Thanks a lot for help,

kind regards



Jan Hannig

Reasearch and Development



jhan...@phoenixcontact.com

www.phoenixcontact.com





...
PHOENIX CONTACT Cyber Security GmbH 
Richard-Willstätter-Straße 6  
D-12489 Berlin  
 
Register Court: AG Charlottenburg, HR B 202908 
Geschäftsführer/General Manager: Kilian Golm
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#50044): https://lists.yoctoproject.org/g/yocto/message/50044
Mute This Topic: https://lists.yoctoproject.org/mt/75700982/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [yocto] [meta-mingw][PATCH] expat: Switch platform to Windows in CMake toolchain file

2020-07-21 Thread Oleksandr via lists.yoctoproject.org
Hello Joshua,

On Mon, Jul 20, 2020 at 8:47 PM Joshua Watt  wrote:
>
> Hmm, this seems like the kind of thing that should be set for all
> mingw32 builds
>

Do you mean "set for all CMake-based recipes by default"? Maybe this is a better
option than adding the same function manually.

But then next question appears:
Should this be done by duplicating already existing "cmake.bbclass"
file to "meta-mingw"
layer and making changes there, or creating new class that inherits
"cmake.bbclass" and
adds necessary changes?
If there is a better way to achieve this goal, I`ll be glad to check it out.

Thanks for your attention.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#50035): https://lists.yoctoproject.org/g/yocto/message/50035
Mute This Topic: https://lists.yoctoproject.org/mt/75687157/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


[yocto] [meta-java] compile and configure openjdk-8-jre-headless

2020-07-21 Thread srijan . nandi
Hello Everyone,

I have successfully compiled openjdk-8 with a zeus build. But I want to compile 
openjdk-8 headless. Can anyone tell me how and where to enable options such as 
headless, disable CUPS and disable X11.

-=Srijan Nandi
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#50042): https://lists.yoctoproject.org/g/yocto/message/50042
Mute This Topic: https://lists.yoctoproject.org/mt/75700685/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [yocto] How to completely uninstall a pre-installed package in Yocto #linux #yocto

2020-07-21 Thread srijan . nandi
What I did was, ran the following command to see what all gets installed..

bitbake  -e |grep -v ^# |grep "^DISTRO_FEATURES=\|^IMAGE_FEATURES="

Then used DISTRO_FEATURES_remove in the local.conf to removed the unnecessary 
package. Hope this helps.

-=Srijan Nandi
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#50039): https://lists.yoctoproject.org/g/yocto/message/50039
Mute This Topic: https://lists.yoctoproject.org/mt/75515307/21656
Mute #yocto: https://lists.yoctoproject.org/g/yocto+yocto/mutehashtag/yocto
Mute #linux: https://lists.yoctoproject.org/g/yocto+yocto/mutehashtag/linux
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


[yocto] Query regarding the use of wic image during device upgrades

2020-07-21 Thread mdrizwan827
Hi,

I have been using wic image format lately to create partitioned image for
my device.

I was wondering if wic image format can also be used during the device
upgrade scenarios?

After using wic image, I have an impression that it is mainly used for
initially writing the wic image to sdcard/eMMC but does not support all the
thinkable use cases related to device upgrade.

As in, for example, can we selectively upgrade any single partition in the
device using the wic image?

It would be really helpful if I can get some references or pointers on this
topic.

Thanks.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#50041): https://lists.yoctoproject.org/g/yocto/message/50041
Mute This Topic: https://lists.yoctoproject.org/mt/75700684/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


[yocto] #yocto - mongodb files missing

2020-07-21 Thread srijan . nandi
Hello Everyone,

I have built mongodb on zeus. It seems the mongod.service and mongod.conf files 
are missing. Can anyone show me the procedure to build a .bbappend file to add 
those.

Thanks and Regards,
-=Srijan Nandi
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#50037): https://lists.yoctoproject.org/g/yocto/message/50037
Mute This Topic: https://lists.yoctoproject.org/mt/75700682/21656
Mute #yocto: https://lists.yoctoproject.org/g/yocto+yocto/mutehashtag/yocto
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


[yocto] [meta-mingw][PATCH] expat: Switch platform to Windows in CMake toolchain file

2020-07-21 Thread Oleksandr via lists.yoctoproject.org
GNU Autotools build system is considered in upstream as potentially 
deprecated (https://github.com/libexpat/libexpat/issues/330), and
expat library will be switched to use CMake.

So this patch depends on "expat: Added ptest" patch for 'meta' layer, 
and fixes CMake toolchain file to work correctly with 'meta-mingw' 
layer.
---
 recipes-core/expat/expat_%.bbappend | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/recipes-core/expat/expat_%.bbappend 
b/recipes-core/expat/expat_%.bbappend
index 626ea5b..0fe3aa0 100644
--- a/recipes-core/expat/expat_%.bbappend
+++ b/recipes-core/expat/expat_%.bbappend
@@ -1,3 +1,9 @@
 
 FILES_${PN}-bin_mingw32 = "${bindir}/*.exe ${sbindir}/*.exe"
 
+cmake_do_generate_toolchain_file_append_mingw32() {
+cat >> ${WORKDIR}/toolchain.cmake <-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#50043): https://lists.yoctoproject.org/g/yocto/message/50043
Mute This Topic: https://lists.yoctoproject.org/mt/75687157/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


[yocto] meta-kirkwood layer #yocto

2020-07-21 Thread jjvazha via lists.yoctoproject.org
I saw this message thread ( 
https://lists.yoctoproject.org/g/yocto/topic/61257317 )  and wondering how can 
I get this yocto compatible  layer  for marwell kirkwood ?
I want to build a linux ketnel for marwell kirk wood  ( using the 
sheevaplug.conf for machine) using yocto 2.7.3
I down loaded this layer ( https://github.com/kelvinlawson/meta-kirkwood )   
this is opnembedded based , however upon building in yocto  it failed with the 
following message

Entering directory 
`/home/jojan.vazhaeparampil/workspace/distro/build_zion/tmp/work-shared/sheevaplug/kernel-source'
|   GEN 
/home/jojan.vazhaeparampil/workspace/distro/build_zion/tmp/work/sheevaplug-poky-linux-gnueabi/linux-kirkwood/2.6.35-rc1-r14/build/Makefile
| make[2]: *** No rule to make target `oldnoconfig'.  Stop.
| make[1]: *** [oldnoconfig] Error 2
| make: *** [sub-make] Error 2
| make: Leaving directory 
`/home/jojan.vazhaeparampil/workspace/distro/build_zion/tmp/work-shared/sheevaplug/kernel-source'
| ERROR: oe_runmake failed

When I checked the "sheevaplug/kernel-source' directory it is empty ?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#50040): https://lists.yoctoproject.org/g/yocto/message/50040
Mute This Topic: https://lists.yoctoproject.org/mt/75700683/21656
Mute #yocto: https://lists.yoctoproject.org/g/yocto+yocto/mutehashtag/yocto
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


[yocto] Image with trustfence

2020-07-21 Thread Adrian Dusiński
Do I have to change the address of loading the image into ram when
trustfence is enabled?
Because after enabling trustfence I have got error:

##  Flattened Device Tree blob at 830

  Booting using the fdt blob at 0x830

  Using Device Tree in place at 830, end 8300b55a

fdt_find_or_add_subnode: chosen: FDT_ERR_BADSTRUCTURE

ERROR: /chosen node create failed

- must RESET the board
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#50036): https://lists.yoctoproject.org/g/yocto/message/50036
Mute This Topic: https://lists.yoctoproject.org/mt/75700681/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [yocto] How to completely uninstall a pre-installed package in Yocto #linux #yocto

2020-07-21 Thread srijan . nandi
What I did was. I ran the following:

bitbake  -e |grep -v ^# |grep "^DISTRO_FEATURES=\|^IMAGE_FEATURES="

Then used DISTRO_FEATURES_remove in local.conf to remove the unwanted packages.

-=Srijan Nandi
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#50038): https://lists.yoctoproject.org/g/yocto/message/50038
Mute This Topic: https://lists.yoctoproject.org/mt/75515307/21656
Mute #yocto: https://lists.yoctoproject.org/g/yocto+yocto/mutehashtag/yocto
Mute #linux: https://lists.yoctoproject.org/g/yocto+yocto/mutehashtag/linux
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [bitbake-devel] [yocto] Stable Warrior branch

2020-07-21 Thread Richard Purdie
On Tue, 2020-07-14 at 16:56 +0300, Adrian Bunk wrote:
> On Thu, Jun 04, 2020 at 09:28:00PM -0700, akuster wrote:
> > Hello,
> > 
> > The Warrior branch of Poky has had its last official dot release.
> > It
> > will be moving to Community support and EOL within 6 weeks if no
> > one
> > steps up.
> > If someone is interested in taking on the responsibilities of
> > maintaining the "Warrior" branch moving forward, please email this
> > list.
> 
> I have an interest in keeping warrior branch alive in poky and meta-
> oe,
> and I'll take this responsibility since noone else seems to be
> interested.
> 
> > Please look at the
> > https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS for what
> > will
> > be expected.
> 
> I have some ideas, but not yet a fixed plan how I will set this up.

Ok. FWIW we are struggling a little with keeping the older releases
building on the autobuilder as the workers change. We do have plans for
handling this with buildtools but its not rolled out on the older
autobuilder-helper branches.

I do have work in progress working with Jeremy for thud
(contrib/rpurdie/thud), much of which should apply to warrior too
(contrib/rpurdie/warrior is a guess). I just really want to highlight
that there may be some initial work to get these older branches to the
point where they continue to work on the infrastructure.

I think we may have to accept backporting a lot of patches in helper to
bring things more into sync with master/dunfell to make all this easier
to maintain/get working.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#50034): https://lists.yoctoproject.org/g/yocto/message/50034
Mute This Topic: https://lists.yoctoproject.org/mt/75699867/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [yocto] Building of warrior branch fails when building with Ubuntu 20.04 LTS #qemu #yocto #linux

2020-07-21 Thread Martin Jansa
You can backport
https://git.openembedded.org/openembedded-core/commit/?h=dunfell=2cca75155baec8358939e2aae822e256bed4cfe0

On Tue, Jul 21, 2020 at 9:07 AM Bernd  wrote:

> Hello,
>
> we are using the warrior branch for our embedded Linux project. Since
> Ubuntu 20.04 LTS has been released we would like to switch from 18.04 to
> 20.04. However, Ubuntu 20.04 now uses glibc-2.31 where the stime function
> has been replaced. Therefore the build process of qmu-native-3.1.1.1 fails
> with the following error code:
>
> /opt/ti/tq-yocto/build/tmp/hosttools/ld.bfd: linux-user/syscall.o: in
> function `do_syscall1': |
> /opt/ti/tq-yocto/build/tmp/work/x86_64-linux/qemu-native/3.1.1.1-r0/qemu-3.1.1.1/linux-user/syscall.c:7404:
> undefined reference to `stime'
>
> Is there a work around?
>
> Thanks a lot for your help,
> Bernd
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#50033): https://lists.yoctoproject.org/g/yocto/message/50033
Mute This Topic: https://lists.yoctoproject.org/mt/75699199/21656
Mute #yocto: https://lists.yoctoproject.org/g/yocto+yocto/mutehashtag/yocto
Mute #linux: https://lists.yoctoproject.org/g/yocto+yocto/mutehashtag/linux
Mute #qemu: https://lists.yoctoproject.org/g/yocto+yocto/mutehashtag/qemu
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [yocto] Building of warrior branch fails when building with Ubuntu 20.04 LTS #qemu #yocto #linux

2020-07-21 Thread Josef Holzmayr-Khosh Amoz
Howdy!

Am Di., 21. Juli 2020 um 09:07 Uhr schrieb Bernd :
>
> Hello,
>
> we are using the warrior branch for our embedded Linux project. Since Ubuntu 
> 20.04 LTS has been released we would like to switch from 18.04 to 20.04. 
> However, Ubuntu 20.04 now uses glibc-2.31 where the stime function has been 
> replaced. Therefore the build process of qmu-native-3.1.1.1 fails with the 
> following error code:
>
> /opt/ti/tq-yocto/build/tmp/hosttools/ld.bfd: linux-user/syscall.o: in 
> function `do_syscall1': | 
> /opt/ti/tq-yocto/build/tmp/work/x86_64-linux/qemu-native/3.1.1.1-r0/qemu-3.1.1.1/linux-user/syscall.c:7404:
>  undefined reference to `stime'
>
> Is there a work around?

The usual approach is to build inside a defined container, like pyrex
or CROPS, for example.

Greetz

>
> Thanks a lot for your help,
> Bernd
>
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#50032): https://lists.yoctoproject.org/g/yocto/message/50032
Mute This Topic: https://lists.yoctoproject.org/mt/75699199/21656
Mute #yocto: https://lists.yoctoproject.org/g/yocto+yocto/mutehashtag/yocto
Mute #linux: https://lists.yoctoproject.org/g/yocto+yocto/mutehashtag/linux
Mute #qemu: https://lists.yoctoproject.org/g/yocto+yocto/mutehashtag/qemu
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


[yocto] Building of warrior branch fails when building with Ubuntu 20.04 LTS #qemu #yocto #linux

2020-07-21 Thread Bernd
Hello ,

we are using the warrior branch for our embedded Linux project. Since Ubuntu 
20.04 LTS has been released we would like to switch from 18.04 to 20.04. 
However, Ubuntu 20.04 now uses glibc-2.31 where the stime function has been 
replaced. Therefore the build process of qmu-native-3.1.1.1 fails with the 
following error code:

/opt/ti/tq-yocto/build/tmp/hosttools/ld.bfd: linux-user/syscall.o: in function 
`do_syscall1': | 
/opt/ti/tq-yocto/build/tmp/work/x86_64-linux/qemu-native/3.1.1.1-r0/qemu-3.1.1.1/linux-user/syscall.c:7404:
 undefined reference to `stime'

Is there a work around?

Thanks a lot for your help,
Bernd
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#50031): https://lists.yoctoproject.org/g/yocto/message/50031
Mute This Topic: https://lists.yoctoproject.org/mt/75699199/21656
Mute #linux: https://lists.yoctoproject.org/g/yocto+yocto/mutehashtag/linux
Mute #qemu: https://lists.yoctoproject.org/g/yocto+yocto/mutehashtag/qemu
Mute #yocto: https://lists.yoctoproject.org/g/yocto+yocto/mutehashtag/yocto
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


[yocto] [prelink-cross] prelink-cross: Add SPDX-License-Identifier: GPL-2.0-or-later to source files

2020-07-21 Thread Sathish V
Signed-off-by: Sathish V 
---
 gelf/gelf.c| 4 +++-
 gelf/gelf.h| 4 +++-
 gelfx/gelfx.h  | 4 +++-
 gelfx32/gelfx.h| 4 +++-
 src/arch-alpha.c   | 4 +++-
 src/arch-arm.c | 4 +++-
 src/arch-cris.c| 4 +++-
 src/arch-i386.c| 4 +++-
 src/arch-ia64.c| 4 +++-
 src/arch-mips.c| 4 +++-
 src/arch-ppc.c | 4 +++-
 src/arch-ppc64.c   | 4 +++-
 src/arch-s390.c| 4 +++-
 src/arch-s390x.c   | 4 +++-
 src/arch-sh.c  | 4 +++-
 src/arch-sparc.c   | 4 +++-
 src/arch-sparc64.c | 4 +++-
 src/arch-x86_64.c  | 4 +++-
 src/cache.c| 4 +++-
 src/checksum.c | 4 +++-
 src/conflict.c | 4 +++-
 src/crc32.c| 4 +++-
 src/cxx.c  | 4 +++-
 src/data.c | 4 +++-
 src/doit.c | 4 +++-
 src/dso.c  | 4 +++-
 src/dwarf2.c   | 4 +++-
 src/dwarf2.h   | 4 +++-
 src/exec.c | 4 +++-
 src/execle_open.c  | 4 +++-
 src/execstack.c| 4 +++-
 src/fptr.c | 4 +++-
 src/fptr.h | 4 +++-
 src/gather.c   | 4 +++-
 src/get.c  | 4 +++-
 src/hashtab.h  | 4 +++-
 src/layout.c   | 4 +++-
 src/layout.h   | 4 +++-
 src/main.c | 4 +++-
 src/md5.c  | 4 +++-
 src/md5.h  | 4 +++-
 src/mdebug.c   | 4 +++-
 src/prelink.c  | 4 +++-
 src/prelink.h  | 4 +++-
 src/prelinktab.h   | 4 +++-
 src/reloc-info.c   | 4 +++-
 src/reloc-info.h   | 4 +++-
 src/reloc.c| 4 +++-
 src/reloc.h| 4 +++-
 src/space.c| 4 +++-
 src/space.h| 4 +++-
 src/stabs.c| 4 +++-
 src/undo.c | 4 +++-
 src/undoall.c  | 4 +++-
 src/verify.c   | 4 +++-
 55 files changed, 165 insertions(+), 55 deletions(-)

diff --git a/gelf/gelf.c b/gelf/gelf.c
index 915cf5b..08b621a 100644
--- a/gelf/gelf.c
+++ b/gelf/gelf.c
@@ -14,7 +14,9 @@
 
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software Foundation,
-   Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
+   Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  
+
+   SPDX-License-Identifier: GPL-2.0-or-later  */
 
 #include 
 #include 
diff --git a/gelf/gelf.h b/gelf/gelf.h
index 6b76a15..3e14e6d 100644
--- a/gelf/gelf.h
+++ b/gelf/gelf.h
@@ -14,7 +14,9 @@
 
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software Foundation,
-   Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
+   Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  
+
+   SPDX-License-Identifier: GPL-2.0-or-later  */
 
 #ifndef GELF_H
 #defineGELF_H
diff --git a/gelfx/gelfx.h b/gelfx/gelfx.h
index c011a57..13bf9fa 100644
--- a/gelfx/gelfx.h
+++ b/gelfx/gelfx.h
@@ -14,7 +14,9 @@
 
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software Foundation,
-   Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
+   Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  
+
+   SPDX-License-Identifier: GPL-2.0-or-later  */
 
 #ifndef GELFX_H
 #defineGELFX_H
diff --git a/gelfx32/gelfx.h b/gelfx32/gelfx.h
index 7668a84..317b28b 100644
--- a/gelfx32/gelfx.h
+++ b/gelfx32/gelfx.h
@@ -14,7 +14,9 @@
 
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software Foundation,
-   Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
+   Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  
+
+   SPDX-License-Identifier: GPL-2.0-or-later  */
 
 #ifndef GELFX_H
 #defineGELFX_H
diff --git a/src/arch-alpha.c b/src/arch-alpha.c
index 7802a3e..d1b897f 100644
--- a/src/arch-alpha.c
+++ b/src/arch-alpha.c
@@ -13,7 +13,9 @@
 
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software Foundation,
-   Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
+   Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  
+
+   SPDX-License-Identifier: GPL-2.0-or-later  */
 
 #include 
 #include 
diff --git a/src/arch-arm.c b/src/arch-arm.c
index eec7c57..eab316f 100644
--- a/src/arch-arm.c
+++ b/src/arch-arm.c
@@ -13,7 +13,9 @@
 
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software Foundation,
-   Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
+   Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  
+
+   SPDX-License-Identifier: GPL-2.0-or-later  */
 
 #include 
 #include 
diff --git a/src/arch-cris.c b/src/arch-cris.c
index 3272779..9987623 100644
--- a/src/arch-cris.c
+++ b/src/arch-cris.c
@@ -13,7 +13,9 @@
 
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software