date:20201005

[yocto] M+ & H bugs with Milestone Movements WW40

2020-10-05 Thread Stephen Jolley

All,

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


Priority

Bug ID

Short Description

Changer

Owner

Was

Became


Medium+

  5322

Global DNS fallback mechanism not present in poky distro

kai.k...@windriver.com

kai.k...@windriver.com

3.2 M3

3.2 M4


 

  10693

Add a testcase for multilib eSDK on the autobuilder

qi.c...@windriver.com

qi.c...@windriver.com

3.2 M3

3.3


 

  11385

poky-container: clarify that meta-data should be checked out using native tools 
that run the host and not with tools in container

timothy.t.orl...@intel.com

timothy.t.orl...@intel.com

3.99

3.3 M1


 

  12060

It is possible to specify a PACKAGE and a PKG_ rename that conflict

kai.k...@windriver.com

kai.k...@windriver.com

3.2 M3

3.3 M1


 

  12342

lib32-core-image-sato -ctestimage failed due to wrong package names

kai.k...@windriver.com

kai.k...@windriver.com

3.2 M3

3.2 M4


 

  12917

Warnings from nightly-multilib builds (build-deps)

kai.k...@windriver.com

kai.k...@windriver.com

3.2 M3

3.2 M4


 

  13182

Inconsistency detected by ld.so: dl-open.c: 274: dl_open_worker: Assertion xxx 
failed

qi.c...@windriver.com

qi.c...@windriver.com

3.2 M3

3.3


 

  13288

pseudo should not follow symlinks in /proc

randy.macl...@windriver.com

sakib.sa...@windriver.com

3.2 M3

3.2 M4


 

  13581

Line wrapping over prompt in BASH

randy.macl...@windriver.com

jason.wes...@windriver.com

3.2 M3

3.2 M4


 

  13589

Document sstate cache mirror best practices

randy.macl...@windriver.com

mark.mor...@windriver.com

3.2 M3

3.2 M4


 

  13631

core-image-full-cmdline qemumips systemd boot failure

kai.k...@windriver.com

kai.k...@windriver.com

3.2 M3

3.2 M4


 

  13646

runtime tests sometimes can't login to the serial console on systemd images 
(generates warning)

kai.k...@windriver.com

richard.pur...@linuxfoundation.org

3.2 M3

3.2 M4


 

  13666

[QA 3.0.1 RC3] valgrind.drd failure in ptest

randy.macl...@windriver.com

stacy.gaikov...@windriver.com

3.2 M3

3.2 M4


 

  13838

[QA 3.1 M3 RC1] failure in ptest: valgrind.drd/tests/bar_bad and 
valgrind.drd/tests/bar_bad_xml

randy.macl...@windriver.com

stacy.gaikov...@windriver.com

3.2 M3

3.2 M4


 

  13841

quilt ptest intermittent failure

joe.sla...@windriver.com

joe.sla...@windriver.com

3.2 M3

3.2 M4


 

  13904

do_prepare_recipe_sysroot: postinst-useradd-* does not run in order of 
dependency and sometimes fails

randy.macl...@windriver.com

sakib.sa...@windriver.com

3.2 M3

3.2 M4


 

  13997

[QA 3.2 M2 RC1] failure in ptest : libinput.libinput-test-suite

randy.macl...@windriver.com

sakib.sa...@windriver.com

3.2 M3

3.2 M4

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 (#50932): https://lists.yoctoproject.org/g/yocto/message/50932
Mute This Topic: https://lists.yoctoproject.org/mt/77328624/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-gplv2] [PATCH] gnupg: Make it build with GCC 10 (which uses -fno-common by default)

2020-10-05 Thread Joshua Watt

On 10/5/20 3:36 PM, Peter Kjellerstedt wrote:

-Original Message-
From: yocto@lists.yoctoproject.org  On
Behalf Of Joshua Watt
Sent: den 1 oktober 2020 15:27
To: Khem Raj 
Cc: Peter Kjellerstedt ;
yocto@lists.yoctoproject.org
Subject: Re: [yocto] [meta-gplv2] [PATCH] gnupg: Make it build with GCC
10 (which uses -fno-common by default)

On Wed, Sep 30, 2020 at 4:34 PM Khem Raj  wrote:

On Wed, Sep 30, 2020 at 1:37 PM Joshua Watt 

wrote:

With this patch applied, I get the following errors when using the
latest master branches:

| ../mpi/libmpi.a(mpiutil.o): In function `mpi_alloc_limb_space':
| mpiutil.c:(.text+0x84): undefined reference to `memory_debug_mode'
| ../mpi/libmpi.a(mpiutil.o): In function `mpi_alloc':
| mpiutil.c:(.text+0xda): undefined reference to `memory_debug_mode'
| ../mpi/libmpi.a(mpiutil.o): In function `mpi_alloc_secure':
| mpiutil.c:(.text+0x14a): undefined reference to `memory_debug_mode'
| ../mpi/libmpi.a(mpiutil.o): In function `mpi_free_limb_space':
| mpiutil.c:(.text+0x1c7): undefined reference to `memory_debug_mode'
| ../mpi/libmpi.a(mpiutil.o): In function `mpi_free':
| mpiutil.c:(.text+0x267): undefined reference to `memory_debug_mode'
| ../util/libutil.a(iobuf.o): In function `file_filter':
| iobuf.c:(.text+0x1c0): undefined reference to `iobuf_debug_mode'
| iobuf.c:(.text+0x1ea): undefined reference to `iobuf_debug_mode'
| iobuf.c:(.text+0x2e0): undefined reference to `iobuf_debug_mode'
| iobuf.c:(.text+0x305): undefined reference to `iobuf_debug_mode'
| ../util/libutil.a(iobuf.o): In function `underflow':
| iobuf.c:(.text+0x4b3): undefined reference to `iobuf_debug_mode'
| ../util/libutil.a(iobuf.o):iobuf.c:(.text+0x567): more undefined
references to `iobuf_debug_mode' follow
| collect2: error: ld returned 1 exit status

If I revert this commit, gnupg-native will again build correctly. Any
ideas?

Interesting. I had not considered building the recipes from
meta-gplv2 for native as we only use them for target builds.

does it help if you add -fno-common to native CFLAGS

No. It works in all cases if I remove the patch and use "-fcommon"
though. Oddly enough, in my build having the patch caused the target
recipe to fail one way, and not having it caused it to fail another
way

Are you saying you still have build failures when building gnupg for
target as well, with the patch applied?

Correct. I don't remember exactly, but there was no combination of 
"-fno-common" and the patch that worked for both native and target 
cases. The only way I could get it to work for both was without the 
patch and with "-fcommon"

not sure what's going on there, but I suspect for something
this old, adding "-fcommon" to restore the original behavior makes the
most sense.

Anyway, I get the same errors as above when I try building it for
native using gcc 9.3.1. I'll look into it and see if I can improve
the patch, or if I will have to resort to using -fcommon.

//Peter

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

[yocto] Current high bug count owners for Yocto Project 3.2

2020-10-05 Thread Stephen Jolley

All,

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


Who

Count


richard.pur...@linuxfoundation.org

33


david.re...@windriver.com

22


r...@burtonini.com

20


bluelightn...@bluelightning.org

19


akuster...@gmail.com

18


bruce.ashfi...@gmail.com

18


sakib.sa...@windriver.com

11


mark.mor...@windriver.com

11


timothy.t.orl...@intel.com

10


jpewhac...@gmail.com

10


trevor.gamb...@windriver.com

9


kai.k...@windriver.com

9


qi.c...@windriver.com

7


raj.k...@gmail.com

5


mostthings...@gmail.com

4


rpj...@crashcourse.ca

4


randy.macl...@windriver.com

4


hongxu@windriver.com

4


mingli...@windriver.com

4


stacy.gaikov...@windriver.com

4


yi.z...@windriver.com

3


jon.ma...@arm.com

3


jeanmarie.lemeta...@gmail.com

2


mark.ha...@kernel.crashing.org

2


ydir...@free.fr

2


chee.yang@intel.com

2


jpuhl...@mvista.com

2


alejan...@enedino.org

2


matthew...@posteo.net

2


kerg...@gmail.com

2


mich...@yoctoproject.org

2


jae...@xilinx.com

2


saul.w...@windriver.com

1


matt.ranos...@konsulko.com

1


maxime.roussinbelan...@gmail.com

1


martin.ja...@gmail.com

1


kai.ruh...@live.com

1


jason.wes...@windriver.com

1


apoorvsan...@gmail.com

1


joe.sla...@windriver.com

1


liezhi.y...@windriver.com

1


ankur.tyag...@gmail.com

1


aeh...@gmail.com

1


dl...@gmx.de

1


amber.n.ell...@intel.com

1


changqing...@windriver.com

1


shantanoo_de...@hotmail.com

1


liu.min...@gmail.com

1


anuj.mit...@intel.com

1


kexin@windriver.com

1


Grand Total

270

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 (#50928): https://lists.yoctoproject.org/g/yocto/message/50928
Mute This Topic: https://lists.yoctoproject.org/mt/77328384/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-gplv2] [PATCH] gnupg: Make it build with GCC 10 (which uses -fno-common by default)

2020-10-05 Thread Peter Kjellerstedt

> -Original Message-
> From: yocto@lists.yoctoproject.org  On
> Behalf Of Joshua Watt
> Sent: den 1 oktober 2020 15:27
> To: Khem Raj 
> Cc: Peter Kjellerstedt ;
> yocto@lists.yoctoproject.org
> Subject: Re: [yocto] [meta-gplv2] [PATCH] gnupg: Make it build with GCC
> 10 (which uses -fno-common by default)
> 
> On Wed, Sep 30, 2020 at 4:34 PM Khem Raj  wrote:
> >
> > On Wed, Sep 30, 2020 at 1:37 PM Joshua Watt 
> wrote:
> > >
> > > With this patch applied, I get the following errors when using the
> > > latest master branches:
> > >
> > > | ../mpi/libmpi.a(mpiutil.o): In function `mpi_alloc_limb_space':
> > > | mpiutil.c:(.text+0x84): undefined reference to `memory_debug_mode'
> > > | ../mpi/libmpi.a(mpiutil.o): In function `mpi_alloc':
> > > | mpiutil.c:(.text+0xda): undefined reference to `memory_debug_mode'
> > > | ../mpi/libmpi.a(mpiutil.o): In function `mpi_alloc_secure':
> > > | mpiutil.c:(.text+0x14a): undefined reference to `memory_debug_mode'
> > > | ../mpi/libmpi.a(mpiutil.o): In function `mpi_free_limb_space':
> > > | mpiutil.c:(.text+0x1c7): undefined reference to `memory_debug_mode'
> > > | ../mpi/libmpi.a(mpiutil.o): In function `mpi_free':
> > > | mpiutil.c:(.text+0x267): undefined reference to `memory_debug_mode'
> > > | ../util/libutil.a(iobuf.o): In function `file_filter':
> > > | iobuf.c:(.text+0x1c0): undefined reference to `iobuf_debug_mode'
> > > | iobuf.c:(.text+0x1ea): undefined reference to `iobuf_debug_mode'
> > > | iobuf.c:(.text+0x2e0): undefined reference to `iobuf_debug_mode'
> > > | iobuf.c:(.text+0x305): undefined reference to `iobuf_debug_mode'
> > > | ../util/libutil.a(iobuf.o): In function `underflow':
> > > | iobuf.c:(.text+0x4b3): undefined reference to `iobuf_debug_mode'
> > > | ../util/libutil.a(iobuf.o):iobuf.c:(.text+0x567): more undefined
> > > references to `iobuf_debug_mode' follow
> > > | collect2: error: ld returned 1 exit status
> > >
> > > If I revert this commit, gnupg-native will again build correctly. Any
> > > ideas?

Interesting. I had not considered building the recipes from 
meta-gplv2 for native as we only use them for target builds.

> > does it help if you add -fno-common to native CFLAGS
> 
> No. It works in all cases if I remove the patch and use "-fcommon"
> though. Oddly enough, in my build having the patch caused the target
> recipe to fail one way, and not having it caused it to fail another
> way

Are you saying you still have build failures when building gnupg for 
target as well, with the patch applied?

> not sure what's going on there, but I suspect for something
> this old, adding "-fcommon" to restore the original behavior makes the
> most sense.

Anyway, I get the same errors as above when I try building it for 
native using gcc 9.3.1. I'll look into it and see if I can improve 
the patch, or if I will have to resort to using -fcommon.

//Peter


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

[yocto] Reminder: Yocto Project Technical Team Meeting @ Monthly from 8am on the first Tuesday (PDT)

2020-10-05 Thread Stephen Jolley

All,

 

Just a reminder we will hold the monthly Yocto Project Technical Meeting at
8am PST tomorrow. (10/6)  

 

Yocto Project Technical Team Meeting: We encourage people attending the
meeting to logon and announce themselves on the Yocto Project IRC chancel
during the meeting (optional):

Yocto IRC: http://webchat.freenode.net/?channels=#yocto

 

Wiki: https://www.yoctoproject.org/public-virtual-meetings/

 

WhenMonthly from 8am to 9am on the first Tuesday Pacific Time

Where   Zoom Meeting:
https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09

 

We are tracking the minutes at:
https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9d
DH4/edit?pli=1 Please request access if you want to assist in editing them.
The world should have view access. 

 

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 (#50926): https://lists.yoctoproject.org/g/yocto/message/50926
Mute This Topic: https://lists.yoctoproject.org/mt/77328007/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #yocto #sdk How to add *-dev packages to sdk installer and not to target rootfs

2020-10-05 Thread Leon Woestenberg

Hello Henrik,

On Mon, Oct 5, 2020 at 8:18 AM Henrik Haugaard Jensen 
wrote:

>
> It would be nice if *-dev packages could be specified to included in the
> sdk sysroots only since we do not need them in the taget rootfs.
>
> As far as I known:
- The -dev packages do not end up in target rootfs, unless you specify them
in your target image.
- The -dev packages end up in the standard SDK target sysroot if you have a
DEPENDS on them.

So maybe in your case you do not have a DEPENDS in your image for the
packages you want a -dev for in SDK?
Could it be you specify -dev manually for the target image?

I am not sure what happens if "myapp" mentions a DEPENDS on (say) "libpng"
but not really links against it.
I am not sure if the libpng-dev ends up in the SDK (but I will try this
tomorrow).

Regards,

Leon.

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

Re: [yocto] #yocto #sdk How to add *-dev packages to sdk installer and not to target rootfs

2020-10-05 Thread Khem Raj

Perhaps extensible SDK is a better fit for you when you are building
custom rootfs with SDK.

On Sun, Oct 4, 2020 at 11:18 PM Henrik Haugaard Jensen  
wrote:
>
> The target rootfs is the image which "-c populate_sdk" is build from. I have 
> actually modified the populate_sdk recipe to include the rootfs in the sdk 
> together with the sysroots for target and host. In this way the applications 
> can be added to the rootfs to generate the complete fw for the device - we do 
> not update applications with individual packages but as a complete image. Our 
> rootfs is dd'ed to the partition and is read only for maximum reliability.
> It would be nice if *-dev packages could be specified to included in the sdk 
> sysroots only since we do not need them in the taget rootfs.
>
> -Original Message-
> From: Khem Raj 
> Sent: Friday, 2 October 2020 19.28
> To: Henrik Haugaard Jensen 
> Cc: yocto@lists.yoctoproject.org
> Subject: Re: [yocto] #yocto #sdk How to add *-dev packages to sdk installer 
> and not to target rootfs
>
> On Thu, Oct 1, 2020 at 11:58 PM  wrote:
> >
> > We use the "standard" SDK to provide a basic linux filesystem including 
> > libraries  to be used for application development (based on cmake) in the 
> > SDK. So we need the *-dev packages for the libraries to be available in the 
> > target "sysroot" in the SDK but not in the target rootfs. How can this be 
> > configured?
>
> standard SDK can only build applications and it has -dev packages included in 
> it per your image ( if you built SDK with -cpopulate_sdk) where does target 
> rootfs come from ?
>
> > BR's
> > Henrik
> > 
> >

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

Re: [yocto] #yocto #sdk How to add *-dev packages to sdk installer and not to target rootfs

2020-10-05 Thread Henrik Haugaard Jensen

The target rootfs is the image which "-c populate_sdk" is build from. I have 
actually modified the populate_sdk recipe to include the rootfs in the sdk 
together with the sysroots for target and host. In this way the applications 
can be added to the rootfs to generate the complete fw for the device - we do 
not update applications with individual packages but as a complete image. Our 
rootfs is dd'ed to the partition and is read only for maximum reliability. 
It would be nice if *-dev packages could be specified to included in the sdk 
sysroots only since we do not need them in the taget rootfs.

-Original Message-
From: Khem Raj  
Sent: Friday, 2 October 2020 19.28
To: Henrik Haugaard Jensen 
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #sdk How to add *-dev packages to sdk installer and 
not to target rootfs

On Thu, Oct 1, 2020 at 11:58 PM  wrote:
>
> We use the "standard" SDK to provide a basic linux filesystem including 
> libraries  to be used for application development (based on cmake) in the 
> SDK. So we need the *-dev packages for the libraries to be available in the 
> target "sysroot" in the SDK but not in the target rootfs. How can this be 
> configured?

standard SDK can only build applications and it has -dev packages included in 
it per your image ( if you built SDK with -cpopulate_sdk) where does target 
rootfs come from ?

> BR's
> Henrik
> 
>

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

[yocto] M+ & H bugs with Milestone Movements WW40

Re: [yocto] [meta-gplv2] [PATCH] gnupg: Make it build with GCC 10 (which uses -fno-common by default)

[yocto] Current high bug count owners for Yocto Project 3.2

Re: [yocto] [meta-gplv2] [PATCH] gnupg: Make it build with GCC 10 (which uses -fno-common by default)

[yocto] Reminder: Yocto Project Technical Team Meeting @ Monthly from 8am on the first Tuesday (PDT)

Re: [yocto] #yocto #sdk How to add *-dev packages to sdk installer and not to target rootfs

Re: [yocto] #yocto #sdk How to add *-dev packages to sdk installer and not to target rootfs

Re: [yocto] #yocto #sdk How to add *-dev packages to sdk installer and not to target rootfs

8 matches

Site Navigation

Mail list logo

Footer information