Yocto Project Status WW25

Yocto Project Status WW25

[Jolley, Stephen K]

[-- Attachment #1: Type: text/plain, Size: 1612 bytes --]

NOTE: M1 cut off next week


Current Dev Position: 1.9 Milestone 1 (M1)

Next Deadline: M1 cut off of June 23rd noon GMT


SWAT team rotation: Alejandro -> Beth

https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team


Key Status/Updates:

Datastore changes for getVar default expansion options proposed

Little feedback on datastore changes

Stability issues in MUT delaying patch merging


Key YP 1.9 Dates:

M2 Cut off July 27, 2015 noon GMT

1.9 Feature Freeze Date/M3 Cut off: Aug. 24, 2015 noon GMT

M4 Cut off: Sept. 28, 2015 noon GMT

1.9 M1 Release Target: Before July 10, 2015

1.9 M2 Release Target: Before Aug. 14, 2015

1.9 M3 Release Target: Before Sept. 11 2015

1.9 final Release Target: Before Oct. 30, 2015


Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.9_Status

https://wiki.yoctoproject.org/wiki/Yocto_1.9_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_1.9_Features


Tracking Metrics:

            WDD 1757 (last week 1745)

(https://wiki.yoctoproject.org/charts/combo.html)

      Performance Benchmarks stable compared to last week although one machine is having OS issues.


[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
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
*   Work Telephone:          (503) 712-0534
*    Cell:                                (208) 244-4460
* Email:                             stephen.k.jolley@intel.com


[-- Attachment #2: Type: text/html, Size: 14936 bytes --]

Yocto Project Status WW25

[Jolley, Stephen K]

[-- Attachment #1: Type: text/plain, Size: 3286 bytes --]

Current Dev Position: YP 2.2 M1 [still not in QA]

Next Deadline: YP 2.2 M2 cut off would be: 7/18/16


SWAT team rotation: Maxin -> Joshua

https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team


Key Status/Updates:

*        GTK+3 and Sato rework have merged

*        A rework of taskdata and runqueue was merged to bitbake which should make the code easier to understand more easier to debug.

*        This week we're supposed to have provided the M1 build for QA. Sadly as yet this hasn't happened. There are multiple problematic issues which mean it's not worth starting QA :(

*        There is a problem with recent glibc, older glibc, pseudo and glibc IFUNC symbols breaking the SDK [bug #9761]

*        build-appliance-image is broken due to python2/python3 issues. This is about the fifth different piece of breakage we've fixed there [bug #9758].

*        The autobuilder is having artefact publishing problems. Sadly Beth has left Intel so others are coming up to speed on fixing such issues.

*        We need to resolve the confusion in bug #9520 and figure out if the issues are resolved

*        Need to check that #9716 is resolved

*        There was a space issue in a nightly-x86-64 image which is unexplained at this point and didn't reproduce.

*        OE-Core "nodistro" broke due to GTK+3 requirements on opengl. We can work around this for now but GTK+3 without GL is not sustainable in the medium to long term.

*        There are multiple new "random" failures occurring on the AB again which we're struggling to debug as they're hard to reproduce being potentially timing or load related

*        There is a multilib issue related to the layout of the host libraries leaking into python's build process which we're struggling to debug

*        Only the known still to be unfixed issues are listed here, there are many times this number which have been fixed in the past few days.

*        There are some patches which have not made M1 due to risk or issues being found close to the deadline. The progress patches from Paul and Ross' build changes to bitbake will merge early M2.


Key YP 2.2 Dates:

*        YP 2.2 M1 cut off would be: 6/13/16

*        YP 2.2 M1 release would be: 6/24/16

*        YP 2.2 M2 cut off would be: 7/18/16

*        YP 2.2 M2 release would be: 7/29/16

*        YP 2.2 M3 cut off would be: 8/29/16

*        YP 2.2 M3 release would be: 9/9/16

*        YP 2.2 M4 cut off would be: 10/3/16

*        YP 2.2 M4 release would be: 10/28/16


Tracking Metrics:

            WDD 2678 (last week 2599)

(https://wiki.yoctoproject.org/charts/combo.html)


Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.2_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.2_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.2_Features

[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
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
*   Work Telephone:        (503) 712-0534
*    Cell:               (208) 244-4460
* Email:                            stephen.k.jolley@intel.com

[-- Attachment #2: Type: text/html, Size: 33847 bytes --]

Re: Yocto Project Status WW25

[Christopher Larson]

[-- Attachment #1: Type: text/plain, Size: 1190 bytes --]

On Fri, Jun 17, 2016 at 8:31 AM, Jolley, Stephen K <
stephen.k.jolley@intel.com> wrote:

> ·        There is a multilib issue related to the layout of the host
> libraries leaking into python’s build process which we’re struggling to
> debug


Could I get some details on this? I've seen something like this where cmake
and automake are relying on sys.lib from python3-native/python-native to
determine the sitepackages directory, is that the behavior others are
hitting? So python modules end up in /usr/lib/ rather than /usr/lib64/, for
example?

If that's the issue in question, the issue is the mismatch between the
native sys.lib and target. We already patch automake to fall back to using
our libdir + python version to determine the path, but only if it wasn't
able to use sys.lib to do so. If we change that to always use libdir+python
version, it should fix the automake packages. Then we might need to patch
FindPythonLibs in cmake to do the same. I'm testing the automake change
locally now.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 1867 bytes --]

Re: Yocto Project Status WW25

[Christopher Larson]

[-- Attachment #1: Type: text/plain, Size: 1383 bytes --]

On Fri, Jun 17, 2016 at 2:42 PM, Christopher Larson <clarson@kergoth.com>
wrote:

> On Fri, Jun 17, 2016 at 8:31 AM, Jolley, Stephen K <
> stephen.k.jolley@intel.com> wrote:
>
>> ·        There is a multilib issue related to the layout of the host
>> libraries leaking into python’s build process which we’re struggling to
>> debug
>
>
> Could I get some details on this? I've seen something like this where
> cmake and automake are relying on sys.lib from python3-native/python-native
> to determine the sitepackages directory, is that the behavior others are
> hitting? So python modules end up in /usr/lib/ rather than /usr/lib64/, for
> example?
>
> If that's the issue in question, the issue is the mismatch between the
> native sys.lib and target. We already patch automake to fall back to using
> our libdir + python version to determine the path, but only if it wasn't
> able to use sys.lib to do so. If we change that to always use libdir+python
> version, it should fix the automake packages. Then we might need to patch
> FindPythonLibs in cmake to do the same. I'm testing the automake change
> locally now.
>

Hmm, nevermind, seems that was fixed in oe-core already, huzzah :)
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 2310 bytes --]

Re: Yocto Project Status WW25

[Richard Purdie]

On Fri, 2016-06-17 at 14:42 -0700, Christopher Larson wrote:
> On Fri, Jun 17, 2016 at 8:31 AM, Jolley, Stephen K <
> stephen.k.jolley@intel.com> wrote:
> > ·        There is a multilib issue related to the layout of the
> > host libraries leaking into python’s build process which we’re
> > struggling to debug
> Could I get some details on this? I've seen something like this where
> cmake and automake are relying on sys.lib from python3-native/python
> -native to determine the sitepackages directory, is that the behavior
> others are hitting? So python modules end up in /usr/lib/ rather than
> /usr/lib64/, for example?
> 
> If that's the issue in question, the issue is the mismatch between
> the native sys.lib and target. We already patch automake to fall back
> to using our libdir + python version to determine the path, but only
> if it wasn't able to use sys.lib to do so. If we change that to
> always use libdir+python version, it should fix the automake
> packages. Then we might need to patch FindPythonLibs in cmake to do
> the same. I'm testing the automake change locally now.

https://bugzilla.yoctoproject.org/show_bug.cgi?id=9717 is the bug

Cheers,

Richard

Re: [yocto] Yocto Project Status WW25

[Leonardo Sandoval]

On 06/17/2016 05:10 PM, Richard Purdie wrote:
> On Fri, 2016-06-17 at 14:42 -0700, Christopher Larson wrote:
>> On Fri, Jun 17, 2016 at 8:31 AM, Jolley, Stephen K <
>> stephen.k.jolley@intel.com> wrote:
>>> ·        There is a multilib issue related to the layout of the
>>> host libraries leaking into python’s build process which we’re
>>> struggling to debug
>> Could I get some details on this? I've seen something like this where
>> cmake and automake are relying on sys.lib from python3-native/python
>> -native to determine the sitepackages directory, is that the behavior
>> others are hitting? So python modules end up in /usr/lib/ rather than
>> /usr/lib64/, for example?
>>
>> If that's the issue in question, the issue is the mismatch between
>> the native sys.lib and target. We already patch automake to fall back
>> to using our libdir + python version to determine the path, but only
>> if it wasn't able to use sys.lib to do so. If we change that to
>> always use libdir+python version, it should fix the automake
>> packages. Then we might need to patch FindPythonLibs in cmake to do
>> the same. I'm testing the automake change locally now.
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=9717 is the bug
Proposed fixed for this problem:

http://lists.openembedded.org/pipermail/openembedded-core/2016-June/123061.html 

> Cheers,
>
> Richard