Date   

Yocto Project Status WW45'20

Stephen Jolley
 

Current Dev Position: YP 3.3 M1 development

Next Deadline: 7th December 2020 YP 3.3 M1 build

 

Next Team Meetings:

 

Key Status/Updates:

  • YP 3.2 has been released
  • Master has now opened up for 3.3 development. Unfortunately there have been a lot of issues showing up with some of the more adventurous patches being proposed, the issues are being worked through.
  • Intermittent autobuilder issues continue to occur. 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
  • A YP 3.3 planning document has been created for ideas about what may happen in the YP 3.3 release (assuming there are people to work on the items):

https://docs.google.com/document/d/1IHiE0NU0XspDocgxZeLQ_W7o-yr0nVeBjbqImQUtH5A/edit Request edit/suggest access if you want to add to it.

  • YP 3.3 dates for builds, milestones and release have been added below.
  • Anuj Mittal has kindly agreed to maintain the YP 3.2 series (gatesgarth), thanks!
  • The SWAT team has been re-established. A new mailing has been created as swat@... to support this and a number of member organisations have agreed to help staff this team. We are in the process of getting the process running again and in due course there will be the option of other community members being able to help too. The tools and processes are under review to allow us to optimise the process. Thanks to the members and everyone participating to make this happen!

 

Ways to contribute:

 

YP 3.2 Milestone Dates:

  • YP 3.2 M4 released

 

YP 3.3 Milestone Dates:

  • YP 3.3 M1 build date 2020/12/07
  • YP 3.3 M1 Release date 2020/12/18
  • YP 3.3 M2 build date 2021/01/18
  • YP 3.3 M2 Release date 2021/01/29
  • YP 3.3 M3 build date 2021/03/01
  • YP 3.3 M3 Release date 2021/03/12
  • YP 3.3 M4 build date 2021/04/05
  • YP 3.3 M4 Release date 2021/04/30

 

Planned upcoming dot releases:

  • YP 3.1.4 build date 2020/11/2
  • YP 3.1.4 release date 2020/11/13
  • YP 3.2.1 build date 2020/11/16
  • YP 3.2.1 release date 2020/12/4
  • YP 3.1.5 build date 2021/01/11
  • YP 3.1.5 release date 2021/01/22
  • YP 3.2.2 build date 2021/02/08
  • YP 3.2.2 release date 2021/02/19
  • YP 3.1.6 build date 2021/02/22
  • YP 3.1.6 release date 2021/03/05
  • YP 3.1.7 build date 2021/03/22
  • YP 3.1.7 release date 2021/04/02

 

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: [gtk+3][zeus] building only with wayland backend, no x11

Adrian
 

Hi Alex,

Thank you for the hint. It led me to the source of the problem, which was libepoxy.

It looks that after changing configuration (DISTRO_FEATURES_remove = " x11"), SSTATE was still populating sysroot of gtk+3 with the older version of libepoxy configuration file (*.pc) creating dependency to 'gl' and 'x11'. In my case I had to call:

bitbake -c cleanall libepoxy

bitbake -c cleanall gtk+3

bitbake gtk+3

In order to avoid such issues in the future, is there any way to force bitbake (after such considerable configuration change like modification of DISTRO_FEATURES) to rebuild sysroot for each recipe if necessary instead of grabbing them from the cache ? I know, one could delete sstate-cache directory, but obviously it will enormously increase rebuild time. I have been wondering whether there is an intermediate solution.

Regards,

Adrian

On 09.11.2020 15:28, Alexander Kanavin wrote:
Do you actually need gtk+3 in your image?

There is a poky configuration that builds core-image-weston without x11, and core-image-weston does pull in gtk+3, and all that happens without errors:
so I'd suggest you reproduce that, get it to build, then investigate where your build diverges.

Alex

On Mon, 9 Nov 2020 at 14:10, Adrian <adrian.fiergolski@...> wrote:

Hi,

I am building an image based on core-image-weston.

I would like to use only wayland backend, thus I defined in my machine's configuration:

DISTRO_FEATURES_append = " wayland"
DISTRO_FEATURES_remove = " x11"

I have a problem with build of gtk+3:

| checking for pango pangocairo gdk-pixbuf-2.0 >= 2.30.0 cairo >= 1.14.0 cairo-gobject >= 1.14.0 gio-unix-2.0 >= 2.53.4  wayland-client >= 1.9.91 wayland-protocols >= 1.12 xkbcommon >= 0.2.0 wayland-cursor >= 1.9.91 wayland-egl   cairo epoxy >= 1.4  fribidi >= 0.19.7... no
| configure: error: Package requirements (pango pangocairo gdk-pixbuf-2.0 >= 2.30.0 cairo >= 1.14.0 cairo-gobject >= 1.14.0 gio-unix-2.0 >= 2.53.4  wayland-client >= 1.9.91 wayland-protocols >= 1.12 xkbcommon >= 0.2.0 wayland-cursor >= 1.9.91 wayland-egl   cairo epoxy >= 1.4  fribidi >= 0.19.7) were not met:
|
| Package 'x11', required by 'gl', not found

The configuration flags in config.log seems to be ok:

  $ ../gtk+-3.24.8/configure --build=x86_64-linux --host=aarch64-poky-linux --target=aarch64-poky-linux --prefix=/usr --exec_prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/libexec --datadir=/usr/share --sysconfdir=/etc --sharedstatedir=/com --localstatedir=/var --libdir=/usr/lib --includedir=/usr/include --oldincludedir=/usr/include --infodir=/usr/share/info --mandir=/usr/share/man --disable-silent-rules --disable-dependency-tracking --with-libtool-sysroot=/home/afiergol/fastree/falcon/poky/build/tmp/work/aarch64-poky-linux/gtk+3/3.24.8-r0/recipe-sysroot --enable-introspection --disable-gtk-doc --disable-glibtest --disable-xinerama --enable-modules --disable-colord --disable-gtk-doc --disable-static --disable-cups --disable-glx --enable-opengl --enable-wayland-backend --disable-x11-backend --enable-nls

Has anybody else experience similar issue? Do you know a fix? I work with the latest zeus (d88d62c20d7d8da85f02edb170dae0280624ad7e) version.

Regards,

Adrian






Re: python3-psycopg2cffi DEPENDS error cffi

Bel Hadj Salem Talel
 

HI,
That's what I did exactly, but failed with the same error.
Here is the python3-cffi-native recipe:

SUMMARY = "Foreign Function Interface for Python calling C code."
HOMEPAGE = "http://cffi.readthedocs.org"
AUTHOR = "Armin Rigo, Maciej Fijalkowski <python-cffi@...>"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://LICENSE;md5=5677e2fdbf7cdda61d6dd2b57df547bf"
SRC_URI = "https://files.pythonhosted.org/packages/cb/ae/380e33d621ae301770358eb11a896a34c34f30db188847a561e8e39ee866/cffi-1.14.3.tar.gz"
SRC_URI[md5sum] = "c2a47ffd5d183b193ac8ed3414dcfd07"
SRC_URI[sha256sum] = "f92f789e4f9241cd262ad7a555ca2c648a98178a953af117ef7fad46aa1d5591"
S = "${WORKDIR}/cffi-1.14.3"
RDEPENDS_${PN} = "python3-pycparser"
BBCLASSEXTEND = "native"
inherit setuptools3

and here is python3-psycopg2cffi recipe

SUMMARY = ".. image:: https://travis-ci.org/chtd/psycopg2cffi.svg?branch=master"
HOMEPAGE = "http://github.com/chtd/psycopg2cffi"
AUTHOR = "Konstantin Lopuhin <konstantin.lopuhin@...>"
LICENSE = "LGPL-2.0"
LIC_FILES_CHKSUM = "file://LICENSE;md5=edf147a599198440160215f8111f5bcf"
SRC_URI = "https://files.pythonhosted.org/packages/95/50/5b94b81a57948ce0350559aad8c20d250ff3b87868a5615efcc79704ba49/psycopg2cffi-2.8.1.tar.gz"
SRC_URI[md5sum] = "f67394d47803dab8a481402754bf83a1"
SRC_URI[sha256sum] = "fcaa4d5477a8205b33e8e9e6707a5c331a0f5d7f4af354529b6564377b678079"
S = "${WORKDIR}/psycopg2cffi-2.8.1"
DEPENDS = "python3-cffi-native"
RDEPENDS_${PN} = ""
inherit setuptools3


Re: python3-psycopg2cffi DEPENDS error cffi

Quentin Schulz
 

Hi Talel,

On Tue, Nov 10, 2020 at 05:23:09AM -0800, Bel Hadj Salem Talel wrote:
HI All,
I created a recipe with pipoe for python3-psycopg2cffi when compiling this error occured:


ERROR: Do not try to fetch `cffi>=1.0' for building. Please add its native
recipe to DEPENDS.
I created a recipe for python3-cffi and I made it native with BBCLASSEXTEND = "native" and it depends also on python3-pycparser which is already native and exist.
Then I added DEPENDS = "python3-cffi" to python3-psycopg2cffi recipe but failed with same error, I tried to rename the python3-cffi to just cffi but same error.
If the native version of python3-cffi is needed, add
DEPENDS = "python3-cffi-native".

Quentin


python3-psycopg2cffi DEPENDS error cffi

Bel Hadj Salem Talel
 

HI All,
I created a recipe with pipoe for python3-psycopg2cffi when compiling this error occured:
ERROR: Do not try to fetch `cffi>=1.0' for building. Please add its native recipe to DEPENDS.
I created a recipe for python3-cffi and I made it native with BBCLASSEXTEND = "native" and it depends also on python3-pycparser which is already native and exist.
Then I added DEPENDS = "python3-cffi" to python3-psycopg2cffi recipe but failed with same error, I tried to rename the python3-cffi to just cffi but same error.

What I'm missing ?
Thanks ,Talel


Re: : When compiling code, how to make a package not hash checked?

Quentin Schulz
 

Hi Byron,

On Tue, Nov 10, 2020 at 09:09:05PM +0800, ouyangxuan10@163.com wrote:
Dear all,


I would like to ask the reasons for the following problems and how to solve them? When compiling a program, how to make a package not hash checked?
Did you execute the commands that were suggested in the log you sent?

Can you send us the content of the log of the second command please?

Basically, two possible ways this happens:
1. you modified the recipe while bitbake was running. Solution => don't
do that.
2. bitbake parses tasks multiple times during a run, therefore, if a
variable changes between parses your task will have a different hash.
This usually happens with DATETIME. If you don't absolutely need this
variable, remove it or find a replacement. If you have to, I think the
vardepsexclude variable flag is the way to do it?

Quentin


: When compiling code, how to make a package not hash checked?

ouyangxuan10@163.com
 

Dear all,

I would like to ask the reasons for the following problems and how to solve them? When compiling a program, how to make a package not hash checked?


thanks,
Byron


 


Re: poky oe-init-build-env doesn't update local.conf with changes from local.conf.sample

 

On Tue, 10 Nov 2020 at 09:56, Andy Basey <a.basey@landguardsystems.com> wrote:

I have an existing build with packages defined in my own layer outside the build directory in the local.conf.sample
I want to add a package so I add it to my local.conf.sample and then source oe-init-build-env again
It doesn't overwrite the local.conf in poky/build/conf as it already exists

Is there a preferred way to make it update?
Or do I just need to manually delete the files in that directory and then run source oe-init-build-env?
I don't want to delete the whole build directory as it takes far too long to do it again from scratch

For reference I am using the local.conf.sample because that is my source controllable config file
If you're adding packages to an image, the best thing to do is to
create your own image recipe and put that in your layer (so it will be
under version control).

--
Paul Barker
Konsulko Group


poky oe-init-build-env doesn't update local.conf with changes from local.conf.sample

Andy Basey
 

I have an existing build with packages defined in my own layer outside the build directory in the local.conf.sample
I want to add a package so I add it to my local.conf.sample and then source oe-init-build-env again
It doesn't overwrite the local.conf in poky/build/conf as it already exists

Is there a preferred way to make it update?
Or do I just need to manually delete the files in that directory and then run source oe-init-build-env?
I don't want to delete the whole build directory as it takes far too long to do it again from scratch

For reference I am using the local.conf.sample because that is my source controllable config file


Re: Error when building eSDK for a `docker load`able tarball

Josef Holzmayr
 

Howdy!

Am Sa., 7. Nov. 2020 um 16:04 Uhr schrieb Manuel Wagesreither
<ManWag@fastmail.fm>:
ERROR: Task linux-dummy.do_fetch attempted to execute unexpectedly
Task /data/proj/poky/build-bora-docker/tmp/work/containerx86_64-poky-linux/bora-container/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-manwag/recipes-core/images/bora-container.bb:do_image_qa, unihash d18d2179024bc6595110c2f10112e7a8e2bd6021d3ea754af30ad9b68ebd9844, taskhash d18d2179024bc6595110c2f10112e7a8e2bd6021d3ea754af30ad9b68ebd9844
Task /data/proj/poky/build-bora-docker/tmp/work/containerx86_64-poky-linux/bora-container/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-manwag/recipes-core/images/bora-container.bb:do_image_complete, unihash c2d86d42a7fc84df5f6ad94b3ed65f6991b3e680d99d40e07ee631aedee9970b, taskhash c2d86d42a7fc84df5f6ad94b3ed65f6991b3e680d99d40e07ee631aedee9970b
This is usually due to missing setscene tasks. Those missing in this build were: {'/data/proj/poky/build-bora-docker/tmp/work/containerx86_64-poky-linux/bora-container/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-manwag/recipes-core/images/bora-container.bb:do_image_complete',
'/data/proj/poky/build-bora-docker/tmp/work/containerx86_64-poky-linux/bora-container/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-manwag/recipes-core/images/bora-container.bb:do_image_qa'}
ERROR: Task (/data/proj/poky/build-bora-docker/tmp/work/containerx86_64-poky-linux/bora-container/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta/recipes-kernel/linux/linux-dummy.bb:do_fetch) failed with exit code 'setscene whitelist'
NOTE: Tasks Summary: Attempted 142 tasks of which 141 didn't need to be rerun and 1 failed.

Summary: 1 task failed:
/data/proj/poky/build-bora-docker/tmp/work/containerx86_64-poky-linux/bora-container/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta/recipes-kernel/linux/linux-dummy.bb:do_fetch
Summary: There was 1 WARNING message shown.
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
ERROR: Logfile of failure stored in: /data/proj/poky/build-bora-docker/tmp/work/containerx86_64-poky-linux/bora-container/1.0-r0/temp/log.do_populate_sdk_ext.8096
ERROR: Task (/data/proj/poky/build-bora-docker/../meta-manwag/recipes-core/images/bora-container.bb:do_populate_sdk_ext) failed with exit code '1'
NOTE: Tasks Summary: Attempted 2358 tasks of which 2356 didn't need to be rerun and 1 failed.

Summary: 1 task failed:
/data/proj/poky/build-bora-docker/../meta-manwag/recipes-core/images/bora-container.bb:do_populate_sdk_ext
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
```
I can reproduce it, the issue being caused by the combination of
linux-dummy as kernel provider and the esdk. While there is no obvious
fix at the moment, Bruce (CCed) knows about it and will have a look.
Additionally it might be worth filing a bug.

Greetz


Re: Yoctoproject.org cgit tags CSS

Anders Montonen
 

Hi,

The previous change also seems to have broken the tag highlighting for the light theme.

Regards,
Anders Montonen

On 10 Nov 2020, at 10:52, Anders Montonen <Anders.Montonen@...> wrote:

Hi,

The tags now show as white text on yellow background, which is unreadable. I think you must copy "table.list td a.tag-deco” too, to set the text color.
Btw, this is probably the same as <https://bugzilla.yoctoproject.org/show_bug.cgi?id=13668>.

Regards,
Anders Montonen

On 10 Nov 2020, at 9:24, Michael Halstead <mhalstead@...> wrote:

I've copied the style into the new class name. Please let me know if this looks correct to you.

On Mon, Nov 9, 2020 at 12:29 PM Anders Montonen <Anders.Montonen@...> wrote:
Hi,

Since some time, the tags in the log view of yoctoproject.org’s cgit have not been highlighted correctly. The problem seems to be that in the HTML, tags are given the class “tag-annotated-deco”, which doesn’t exist in the CSS. The CSS does have a “tag-deco” style which is probably what’s intended.

Regards,
Anders Montonen




-- 
Michael Halstead
Linux Foundation / Yocto Project
Systems Operations Engineer







[PATCH yocto-autobuilder-helper] auh-config: add non-default distro features

Alexander Kanavin
 

This adds systemd and pam related recipes to upstream checks and devtool-driven updates.

Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
scripts/auh-config/local.conf.append | 1 +
1 file changed, 1 insertion(+)

diff --git a/scripts/auh-config/local.conf.append b/scripts/auh-config/local.conf.append
index 9628737..b18590f 100644
--- a/scripts/auh-config/local.conf.append
+++ b/scripts/auh-config/local.conf.append
@@ -1,3 +1,4 @@

INHERIT += "buildhistory"
LICENSE_FLAGS_WHITELIST = "commercial"
+DISTRO_FEATURES_append = ' systemd pam'
--
2.29.1


Re: Yoctoproject.org cgit tags CSS

Anders Montonen
 

Hi,

The tags now show as white text on yellow background, which is unreadable. I think you must copy "table.list td a.tag-deco” too, to set the text color.
Btw, this is probably the same as <https://bugzilla.yoctoproject.org/show_bug.cgi?id=13668>.

Regards,
Anders Montonen

On 10 Nov 2020, at 9:24, Michael Halstead <mhalstead@...> wrote:

I've copied the style into the new class name. Please let me know if this looks correct to you.

On Mon, Nov 9, 2020 at 12:29 PM Anders Montonen <Anders.Montonen@...> wrote:
Hi,

Since some time, the tags in the log view of yoctoproject.org’s cgit have not been highlighted correctly. The problem seems to be that in the HTML, tags are given the class “tag-annotated-deco”, which doesn’t exist in the CSS. The CSS does have a “tag-deco” style which is probably what’s intended.

Regards,
Anders Montonen




--
Michael Halstead
Linux Foundation / Yocto Project
Systems Operations Engineer





Re: Yoctoproject.org cgit tags CSS

Alexander Kanavin
 

I am not seeing a change - the tags are still not highlighted (e.g. commit on top):

This file still contains only the old name:

Alex


On Tue, 10 Nov 2020 at 08:24, Michael Halstead <mhalstead@...> wrote:
I've copied the style into the new class name. Please let me know if this looks correct to you.

On Mon, Nov 9, 2020 at 12:29 PM Anders Montonen <Anders.Montonen@...> wrote:
Hi,

Since some time, the tags in the log view of yoctoproject.org’s cgit have not been highlighted correctly. The problem seems to be that in the HTML, tags are given the class “tag-annotated-deco”, which doesn’t exist in the CSS. The CSS does have a “tag-deco” style which is probably what’s intended.

Regards,
Anders Montonen




--
Michael Halstead
Linux Foundation / Yocto Project
Systems Operations Engineer




Re: Yoctoproject.org cgit tags CSS

Michael Halstead
 

I've copied the style into the new class name. Please let me know if this looks correct to you.


On Mon, Nov 9, 2020 at 12:29 PM Anders Montonen <Anders.Montonen@...> wrote:
Hi,

Since some time, the tags in the log view of yoctoproject.org’s cgit have not been highlighted correctly. The problem seems to be that in the HTML, tags are given the class “tag-annotated-deco”, which doesn’t exist in the CSS. The CSS does have a “tag-deco” style which is probably what’s intended.

Regards,
Anders Montonen




--
Michael Halstead
Linux Foundation / Yocto Project
Systems Operations Engineer


[meta-selinux][PATCH] setools: fix build with Python 3.9

Yi Zhao
 

The Py_UNICODE_COPY, Py_UNICODE_FILL, PyUnicode_WSTR_LENGTH,
PyUnicode_FromUnicode(), PyUnicode_AsUnicode(), _PyUnicode_AsUnicode,
and PyUnicode_AsUnicodeAndSize() are marked as deprecated in Python 3.9.
(See: https://docs.python.org/3/whatsnew/3.9.html). But the current
python3-cython (0.29.21) hasn't adapt it yet.
Append '-Wno-deprecated-declarations' in CFLAGS as a workaround to fix
the build issue.

Fixes:
In file included from
/build/tmp-glibc/work/corei7-64-wrs-linux/setools/4.3.0-r0/recipe-sysroot/usr/include/python3.9/unicodeobject.h:1026,
from /build/tmp-glibc/work/corei7-64-wrs-linux/setools/4.3.0-r0/recipe-sysroot/usr/include/python3.9/Python.h:97,
from setools/policyrep.c:49:
/build/tmp-glibc/work/corei7-64-wrs-linux/setools/4.3.0-r0/recipe-sysroot/usr/include/python3.9/cpython/unicodeobject.h:446:26:
note: declared here
446 | static inline Py_ssize_t _PyUnicode_get_wstr_length(PyObject *op) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
setools/policyrep.c:97302:3: error: 'PyUnicode_AsUnicode' is deprecated [-Werror=deprecated-declarations]

Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
---
recipes-security/setools/setools_4.3.0.bb | 2 ++
1 file changed, 2 insertions(+)

diff --git a/recipes-security/setools/setools_4.3.0.bb b/recipes-security/setools/setools_4.3.0.bb
index 8fdeeb0..0f166c8 100644
--- a/recipes-security/setools/setools_4.3.0.bb
+++ b/recipes-security/setools/setools_4.3.0.bb
@@ -30,6 +30,8 @@ RDEPENDS_${PN} += "python3-networkx python3-decorator python3-setuptools \

RDEPENDS_${PN}_class-native = ""

+CFLAGS_append = " -Wno-deprecated-declarations"
+
RPROVIDES_${PN} += "${PN}-console"

inherit setuptools3
--
2.17.1


M+ & H bugs with Milestone Movements WW45

Stephen Jolley
 

All,

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

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

6437

Document how to set up the Yocto Project for production work

randy.macleod@...

mark.morton@...

3.2 M4

3.3 M2

 

12723

mysql requires unicode and char length filtering

david.reyna@...

david.reyna@...

3.2 M4

3.3 M2

 

13103

[Bug][QA 2.7 M1 rc1][Toaster] "Recipes" tableá and á"machines" table are not getting populated after clickingáon imported layer as well as after clicking Machines Tab on project page

david.reyna@...

david.reyna@...

3.2 M4

3.3 M1

 

13288

pseudo should not follow symlinks in /proc

randy.macleod@...

sakib.sajal@...

3.3

3.3 M2

 

13520

many valgrind tests fail for arm64

randy.macleod@...

stacy.gaikovaia@...

3.2 M4

3.3 M1

 

13589

Document sstate cache mirror best practices

randy.macleod@...

mark.morton@...

3.2 M4

3.3 M1

 

13669

Move Toaster testsuite-2 away from Testopia

david.reyna@...

david.reyna@...

3.2 M4

3.3 M2

 

13766

Using TCLIB=musl results in SDKs producing incompatible binaries

randy.macleod@...

sakib.sajal@...

3.3

3.3 M2

 

13767

Creating PDF docs doesn't include image files

randy.macleod@...

mark.morton@...

3.2 M4

3.3 M2

 

13904

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

randy.macleod@...

sakib.sajal@...

3.3

3.3 M1

 

13997

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

randy.macleod@...

sakib.sajal@...

3.3

3.3 M1

 

14026

documentation how to use systemd is inconsistent

randy.macleod@...

mark.morton@...

3.2 M4

3.3 M1

 

14051

[QA 3.2 M3 RC1] failure in ptest : valgrind.drd and valgrind.helgrind

randy.macleod@...

stacy.gaikovaia@...

3.2 M4

3.3 M1

 

14077

devtool doesn't handle server failing to startup gracefully

randy.macleod@...

stacy.gaikovaia@...

3.2 M4

3.3 M1

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Enhancements/Bugs closed WW45!

Stephen Jolley
 

All,

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

Who

Count

ross@...

2

akuster808@...

1

randy.macleod@...

1

david.reyna@...

1

Grand Total

5

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.3

Stephen Jolley
 

All,

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

Who

Count

richard.purdie@...

34

ross@...

22

david.reyna@...

21

bruce.ashfield@...

19

bluelightning@...

19

timothy.t.orling@...

12

JPEWhacker@...

12

sakib.sajal@...

11

mark.morton@...

11

akuster808@...

9

trevor.gamblin@...

9

kai.kang@...

8

Qi.Chen@...

6

stacy.gaikovaia@...

5

raj.khem@...

5

randy.macleod@...

4

rpjday@...

4

mingli.yu@...

4

mostthingsweb@...

4

idadelm@...

4

chee.yang.lee@...

4

yi.zhao@...

3

alejandro@...

3

hongxu.jia@...

3

ydirson@...

3

jeanmarie.lemetayer@...

2

mark.hatle@...

2

matthewzmd@...

2

kergoth@...

2

saul.wold@...

2

jpuhlman@...

2

jaewon@...

2

jon.mason@...

2

Martin.Jansa@...

1

kai.ruhnau@...

1

jason.wessel@...

1

nicolas.dechesne@...

1

liezhi.yang@...

1

ankur.tyagi85@...

1

jbb5044@...

1

dl9pf@...

1

aehs29@...

1

kamensky@...

1

anuj.mittal@...

1

liu.ming50@...

1

apoorvsangal@...

1

joe.slater@...

1

fede@...

1

maxime.roussinbelanger@...

1

mhalstead@...

1

kexin.hao@...

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  Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi

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 325 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.2”, “3.3, "3.99" and "Future", the more pressing/urgent issues being in "3.2" and then “3.3”.

 

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

 

2541 - 2560 of 53861