yocto@lists.yoctoproject.org

[meta-virtualization] How to enable libvirt to work with XEN on a custom board. #yocto #meta-virtualization

daparrag@...

#50883

Dear all,

In the past days I was looking for some documentation that allows me to enable libvirt to work with xen. In my current implementation I managed to run XEN on DOM0 but unluckly I am having problems to make it works with libvirt.
I had followed all the recommendations listed on http://git.yoctoproject.org/cgit.cgi/meta-virtualization/tree/README but nothing works for me.

when I added libvirt in my packages I got the same error discribed on : https://www.yoctoproject.org/pipermail/meta-virtualization/2016-March/001835.html

any Idea of how can I enable libvirt to work with xen?
do you have some .bbappend that works out of the box?

Please let me know.

Configuration:
YOCTO version => rocko

Re: [yocto-builds] relocate_sdk.py is failing when installing yocto3.1.2 SDK

Ansurivijay Ramana <ansurivijay.r@...>

#50881

Classification: HCL Internal

Hi Randi,

I’m using poky distro.

DISTRO ?= "poky"

Using Ubuntu 16.04 LTS machine. Python version available in ubuntu machine is

/usr/bin/python3 --version

Python 3.5.2

Python version available in distro is 3.8.2

tmp/work/core2-32-poky-linux/python3/3.8.2-r0/

Thanks & Regards,

Vijay

Show quoted text

From: Randy MacLeod <randy.macleod@...>
Sent: Thursday, September 17, 2020 9:40 PM
To: Ansurivijay Ramana <ansurivijay.r@...>; Yocto discussion list <yocto@...>
Subject: Re: [yocto-builds] relocate_sdk.py is failing when installing yocto3.1.2 SDK

[CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.]

Hi Vijay,

I have redirected this thread to the main yocto list.

The yocto-builds list is for automated build outputs

rather than discussions.

What distro are you using?

What version of python3 is provided by that distro?

On Ubu-20.04, fyi:

$ grep python3 /.../oe-core.git/scripts/relocate_sdk.py
#!/usr/bin/env python3

$ python3 --version
Python 3.8.2

../Randy

On 2020-09-17 9:49 a.m., Ansurivijay Ramana wrote:

Classification: HCL Internal

Hi ,

I have added my layer and builded the SDK in yocto 3.1.2 but relocate_sdk.py is failing when installing.

Please help me in fixing this.

./poky-glibc-x86_64-core-image-sato-sdk-core2-32-qemux86-toolchain-3.1.2.sh

Poky (Yocto Project Reference Distro) SDK installer version 3.1.2

=================================================================

Enter target directory for SDK (default: /opt/poky/3.1.2): /home/vijay/build/test3

You are about to install the SDK to "/home/vijay/build/test3". Proceed [Y/n]? Y

Extracting SDK.........................................................................................................................................................................................................................................................................done

Setting it up...Traceback (most recent call last):

File "/home/vijay/build/test3/relocate_sdk.py", line 244, in <module>

change_dl_sysdirs(e)

File "/home/vijay/build/test3/relocate_sdk.py", line 118, in change_dl_sysdirs

sh_offset, sh_size = struct.unpack("<24xQQ24x", sh_hdr)

struct.error: unpack requires a string argument of length 64

SDK could not be set up. Relocate script failed. Abort!

Thanks & Regards,

Vijay

::DISCLAIMER::

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
 
 

--

# Randy MacLeod

# Wind River Linux

Re: #yocto #linux #systemd Having issues building command line utilities: ntpq, timedatectl, and ntpstat into kernel image #systemd #yocto #linux

Monsees, Steven C (US)

#50880

Currently not using system as our default init system (investigating why but this might not be an option).

Is there any other utility I might use under Yocto to get similar data as that produced by timedatectl ?

Thanks,
Steve

Re: #yocto #linux #systemd Having issues building command line utilities: ntpq, timedatectl, and ntpstat into kernel image #systemd #yocto #linux

Monsees, Steven C (US)

#50879

Is there documentation on how to set this up ?

Show quoted text

-----Original Message-----
From: yocto@lists.yoctoproject.org [mailto:yocto@lists.yoctoproject.org] On Behalf Of Quentin Schulz
Sent: Tuesday, September 29, 2020 11:53 AM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #linux #systemd Having issues building command line utilities: ntpq, timedatectl, and ntpstat into kernel image

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.

Hi Steve,

On Tue, Sep 29, 2020 at 08:45:56AM -0700, Monsees, Steven C (US) via lists.yoctoproject.org wrote:
I currently have "ntpq" building and installing correctly...

Can someone tell me what it takes to get the "timedatectl" command utility built into Yocto kernel image ?

I see it referenced in both :

openembedded-core/meta/recipes-core/systemd/systemd_234.bb:                ${bindir}/timedatectl \
poky/meta/recipes-core/systemd/systemd_234.bb:                ${bindir}/timedatectl \
It comes with systemd. Use it as your init system and then you'll have the command.

Quentin

Re: #yocto #linux #systemd Having issues building command line utilities: ntpq, timedatectl, and ntpstat into kernel image #systemd #yocto #linux

Quentin Schulz

#50878

Hi Steve,

On Tue, Sep 29, 2020 at 08:45:56AM -0700, Monsees, Steven C (US) via lists.yoctoproject.org wrote:
I currently have "ntpq" building and installing correctly...

Can someone tell me what it takes to get the "timedatectl" command utility built into Yocto kernel image ?

I see it referenced in both :

openembedded-core/meta/recipes-core/systemd/systemd_234.bb:                ${bindir}/timedatectl \
poky/meta/recipes-core/systemd/systemd_234.bb:                ${bindir}/timedatectl \
It comes with systemd. Use it as your init system and then you'll have the command.

Quentin

Re: #yocto #linux #systemd Having issues building command line utilities: ntpq, timedatectl, and ntpstat into kernel image #systemd #yocto #linux

Monsees, Steven C (US)

#50877

I currently have "ntpq" building and installing correctly...

Can someone tell me what it takes to get the "timedatectl" command utility built into Yocto kernel image ?

I see it referenced in both :

openembedded-core/meta/recipes-core/systemd/systemd_234.bb: ${bindir}/timedatectl \
poky/meta/recipes-core/systemd/systemd_234.bb: ${bindir}/timedatectl \

but have yet to figure out how to get the command built and transferred to the kernel image.

Thanks,
Steve

Yocto Project Status WW39'20

Stephen Jolley

#50876

Current Dev Position: YP 3.2 M4

Next Deadline: YP 3.2 M4 Feature Freeze - Now

Next Team Meetings:

Bug Triage meeting Thursday Oct. 1st at 7:30am PDT (https://zoom.us/j/454367603)
Monthly Project Meeting Tuesday Oct. 6th at 8am PDT (https://zoom.us/j/990892712)
Weekly Engineering Sync Tuesday Sept. 29th at 8am PDT (https://zoom.us/j/990892712)
Twitch - See https://www.twitch.tv/theyoctojester

Key Status/Updates:

YP M3 rc2 has been through QA. We have resolved the beaglebone and bitbake UI issues, the ptest issues remain and need attention in M4. It is likely M3 rc2 will be released.
YP 3.1.3 is currently going through QA.
Unfortunately intermittent autobuilder issues, whilst reduced, do still remain.
Issues with file mode corruption in pseudo have been identified and we’re concerned this may be going undetected in the majority of cases. The issue uncovered would explain several odd bugs we’ve seen over the last few years where file mode bits have disappeared. There are some experimental pseudo patches available that reduce the impact and frequency of these issues but as yet we don’t have a full solution. We’re hampered by a lack of a pseudo maintainer with both the availability and experience to be able to help.
We continue to struggle with a number of autobuilder intermittent bugs. 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, unfortunately it is proving hard to find anyone interested in helping figure these out and they significantly hamper our testing.

Ways to contribute:

There are bugs identified as possible for newcomers to the project: https://wiki.yoctoproject.org/wiki/Newcomers
There are bugs that are currently unassigned for YP 3.2. See: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_3.2_Unassigned_Enhancements.2FBugs
We’d welcome new maintainers for recipes in OE-Core. Please see the list at: http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/distro/include/maintainers.inc and discuss with the existing maintainer, or ask on the OE-Core mailing list. We will likely move a chunk of these to “Unassigned” soon to help facilitate this.

YP 3.2 Milestone Dates:

YP 3.2 M3 is out of QA and should release soon.
YP 3.2 M4 build date 2020/10/5
YP 3.2 M4 Release date 2020/10/30

Planned upcoming dot releases:

YP 3.1.3 is built and in QA
YP 3.1.4 build date 2020/11/2
YP 3.1.4 release date 2020/11/13

Tracking Metrics:

WDD 2481 (last week 2469) (https://wiki.yoctoproject.org/charts/combo.html)
Poky Patch Metrics

Total patches found: 1270 (last week 1268)
Patches in the Pending State: 493 (39%) [last week 496 (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.pm@...

Re: [meta-security][master][dunfell][PATCH] gitignore added

akuster

#50875

On 9/22/20 11:25 PM, Adrian Freihofer wrote:
After running testimage there are some python left overs at
lib/oeqa/runtime/cases/__pycache__/

Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>merged
thanks
---
 .gitignore | 7 +++++++
 1 file changed, 7 insertions(+)
 create mode 100644 .gitignore

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..c01df45
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,7 @@
+*.pyc
+*.pyo
+/*.patch
+*.swp
+*.orig
+*.rej
+*~

[meta-security][PATCH] packagegroup-core-security: add opendnssec to pkg grp

akuster

#50874

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
 recipes-core/packagegroup/packagegroup-core-security.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/recipes-core/packagegroup/packagegroup-core-security.bb b/recipes-core/packagegroup/packagegroup-core-security.bb
index c69e3b3..789f4ea 100644
--- a/recipes-core/packagegroup/packagegroup-core-security.bb
+++ b/recipes-core/packagegroup/packagegroup-core-security.bb
@@ -38,6 +38,7 @@ RDEPENDS_packagegroup-security-utils = "\
     python3-scapy \
     softhsm \
     libest \
+    opendnssec \
     ${@bb.utils.contains_any("TUNE_FEATURES", "riscv32 ", "", " libseccomp",d)} \
     ${@bb.utils.contains("DISTRO_FEATURES", "pam", "sssd google-authenticator-libpam", "",d)} \
     ${@bb.utils.contains("DISTRO_FEATURES", "pax", "pax-utils packctl", "",d)} \
-- 
2.17.1

Re: File collision: same path from 2 recipes

Laurent Gauthier

#50873

Hehe, who needs a new command when you have already have "echo" :-)

Show quoted text

On Tue, Sep 29, 2020 at 2:59 PM Quentin Schulz <quentin.schulz@...> wrote:

On Tue, Sep 29, 2020 at 02:56:28PM +0200, Laurent Gauthier wrote:
> I would guess so.
>
> Here is a way to figure out all the packages in which your file is
> delivered (small trick that has proven quite useful for me to figure out
> which recipe/package provides a specific file):
>
> 1. cd <your-build-directory>
> 2. echo tmp/work/*/*/*/packages-split/*/etc/network/if-up,d/hostapd_restart
>
> This will show you which packages have the file
> "/etc/network/if-up,d/hostapd_restart".
>
> If you just want to check which recipe installs it (in case it is installed
> by the recipe, but not packaged):
>
> 1. cd <your-build-directory>
> 2. echo tmp/work/*/*/*/package/etc/network/if-up,d/hostapd_restart
>

If available in krogoth,
`oe-pkdata-util find-path /etc/network/if-up,d/hostapd_restart` does
this exact thing :)

Quentin

> I hope this helps.
>
> Kind Regards, Laurent.
>
> PS: in some configurations of your build you might have to adjust the name
> of the "tmp" directory.
>
>
> On Tue, Sep 29, 2020 at 2:37 PM Mauro Ziliani <mauro@...> wrote:
>
> > Thanks for your help.
> >
> > I'm working with an old Krogoth.
> >
> > This checks is true even with Krogoth?
> >
> >
> > MZ
> > Il 29/09/20 14:17, Laurent Gauthier ha scritto:
> >
> > Hi Mauro,
> >
> > From my experience there should be an error reported during the image
> > creation as long as the two *packages* that contain a file with the same
> > name are BOTH installed in the root filesystem.
> >
> > If you don't receive an error I would suspect that for some reason the
> > file is really only installed by one of the two packages.
> >
> > Another source of your issue is that there can be more than one package
> > created by one recipe, and maybe you are not installing the package which
> > contains the contentious file.
> >
> > Kind Regards, Laurent.
> >
> > On Tue, Sep 29, 2020 at 2:08 PM Mauro Ziliani <mauro@...>
> > wrote:
> >
> >> Hi all.
> >>
> >> There is a QA to test if 2 recipes try to install a file with the same
> >> path?
> >>
> >> In my BSP 2 recipes try install the file
> >> ${D}/etc/network/if-up,d/hostapd_restart
> >>
> >>
> >> I'd like receive an error from bitbale
> >>
> >>
> >> Best regards,
> >>
> >>
> >> MZ
> >>
> >>
> >>
> >>
> >>
> >
> > --
> > Laurent Gauthier
> > Embedded Linux Systems & Software
> > Phone: +33 630 483 429
> > http://soccasys.com
> >
> >
>
> --
> Laurent Gauthier
> Embedded Linux Systems & Software
> Phone: +33 630 483 429
> http://soccasys.com

>
>
>

--
StreamUnlimited Engineering GmbH
High Tech Campus Vienna, Gutheil-Schoder-Gasse 10, 1100 Vienna, Austria
Fax: +43 1 667 20 02 4401
quentin.schulz@..., www.streamunlimited.com

--

Laurent Gauthier
Embedded Linux Systems & Software
Phone: +33 630 483 429
http://soccasys.com

Re: File collision: same path from 2 recipes

Quentin Schulz

#50872

On Tue, Sep 29, 2020 at 02:56:28PM +0200, Laurent Gauthier wrote:
I would guess so.

Here is a way to figure out all the packages in which your file is
delivered (small trick that has proven quite useful for me to figure out
which recipe/package provides a specific file):

1. cd <your-build-directory>
2. echo tmp/work/*/*/*/packages-split/*/etc/network/if-up,d/hostapd_restart

This will show you which packages have the file
"/etc/network/if-up,d/hostapd_restart".

If you just want to check which recipe installs it (in case it is installed
by the recipe, but not packaged):

1. cd <your-build-directory>
2. echo tmp/work/*/*/*/package/etc/network/if-up,d/hostapd_restart
If available in krogoth,
`oe-pkdata-util find-path /etc/network/if-up,d/hostapd_restart` does
this exact thing :)

Quentin

I hope this helps.

Kind Regards, Laurent.

PS: in some configurations of your build you might have to adjust the name
of the "tmp" directory.


On Tue, Sep 29, 2020 at 2:37 PM Mauro Ziliani <mauro@faresoftware.it> wrote:

Thanks for your help.

I'm working with an old Krogoth.

This checks is true even with Krogoth?


MZ
Il 29/09/20 14:17, Laurent Gauthier ha scritto:

Hi Mauro,

From my experience there should be an error reported during the image
creation as long as the two *packages* that contain a file with the same
name are BOTH installed in the root filesystem.

If you don't receive an error I would suspect that for some reason the
file is really only installed by one of the two packages.

Another source of your issue is that there can be more than one package
created by one recipe, and maybe you are not installing the package which
contains the contentious file.

Kind Regards, Laurent.

On Tue, Sep 29, 2020 at 2:08 PM Mauro Ziliani <mauro@faresoftware.it>
wrote:

Hi all.

There is a QA to test if 2 recipes try to install a file with the same
path?

In my BSP 2 recipes try install the file
${D}/etc/network/if-up,d/hostapd_restart


I'd like receive an error from bitbale


Best regards,


    MZ




--
Laurent Gauthier
Embedded Linux Systems & Software
Phone: +33 630 483 429
http://soccasys.com

-- 
Laurent Gauthier
Embedded Linux Systems & Software
Phone: +33 630 483 429
http://soccasys.com


-- 
StreamUnlimited Engineering GmbH
High Tech Campus Vienna, Gutheil-Schoder-Gasse 10, 1100 Vienna, Austria
Fax: +43 1 667 20 02 4401
quentin.schulz@streamunlimited.com, www.streamunlimited.com

Re: File collision: same path from 2 recipes

Laurent Gauthier

#50871

I would guess so.

Here is a way to figure out all the packages in which your file is delivered (small trick that has proven quite useful for me to figure out which recipe/package provides a specific file):

1. cd <your-build-directory>

2. echo tmp/work/*/*/*/packages-split/*/etc/network/if-up,d/hostapd_restart

This will show you which packages have the file "/etc/network/if-up,d/hostapd_restart".

If you just want to check which recipe installs it (in case it is installed by the recipe, but not packaged):

1. cd <your-build-directory>

2. echo tmp/work/*/*/*/package/etc/network/if-up,d/hostapd_restart

I hope this helps.

Kind Regards, Laurent.

PS: in some configurations of your build you might have to adjust the name of the "tmp" directory.

Show quoted text

On Tue, Sep 29, 2020 at 2:37 PM Mauro Ziliani <mauro@...> wrote:

Thanks for your help.

I'm working with an old Krogoth.

This checks is true even with Krogoth?

MZ

Il 29/09/20 14:17, Laurent Gauthier ha scritto:

Hi Mauro,

From my experience there should be an error reported during the image creation as long as the two *packages* that contain a file with the same name are BOTH installed in the root filesystem.

If you don't receive an error I would suspect that for some reason the file is really only installed by one of the two packages.

Another source of your issue is that there can be more than one package created by one recipe, and maybe you are not installing the package which contains the contentious file.

Kind Regards, Laurent.

On Tue, Sep 29, 2020 at 2:08 PM Mauro Ziliani <mauro@...> wrote:

Hi all.

There is a QA to test if 2 recipes try to install a file with the same path?

In my BSP 2 recipes try install the file
${D}/etc/network/if-up,d/hostapd_restart

I'd like receive an error from bitbale

Best regards,

MZ

--

Laurent Gauthier
Embedded Linux Systems & Software
Phone: +33 630 483 429
http://soccasys.com

--

Laurent Gauthier
Embedded Linux Systems & Software
Phone: +33 630 483 429
http://soccasys.com

Re: File collision: same path from 2 recipes

Mauro Ziliani

#50870

Thanks for your help.

I'm working with an old Krogoth.

This checks is true even with Krogoth?

MZ

Il 29/09/20 14:17, Laurent Gauthier ha scritto:

Show quoted text

Hi Mauro,

From my experience there should be an error reported during the image creation as long as the two *packages* that contain a file with the same name are BOTH installed in the root filesystem.

If you don't receive an error I would suspect that for some reason the file is really only installed by one of the two packages.

Another source of your issue is that there can be more than one package created by one recipe, and maybe you are not installing the package which contains the contentious file.

Kind Regards, Laurent.

On Tue, Sep 29, 2020 at 2:08 PM Mauro Ziliani <mauro@...> wrote:

Hi all.

There is a QA to test if 2 recipes try to install a file with the same path?

In my BSP 2 recipes try install the file
${D}/etc/network/if-up,d/hostapd_restart

I'd like receive an error from bitbale

Best regards,

MZ

--

Laurent Gauthier
Embedded Linux Systems & Software
Phone: +33 630 483 429
http://soccasys.com

Re: File collision: same path from 2 recipes

Robert P. J. Day

#50869

Quoting Laurent Gauthier <laurent.gauthier@soccasys.com>:

Hi Mauro,

From my experience there should be an error reported during the image
creation as long as the two *packages* that contain a file with the same
name are BOTH installed in the root filesystem.

If you don't receive an error I would suspect that for some reason the file
is really only installed by one of the two packages.

Another source of your issue is that there can be more than one package
created by one recipe, and maybe you are not installing the package which
contains the contentious file.

Kind Regards, Laurent.

On Tue, Sep 29, 2020 at 2:08 PM Mauro Ziliani <mauro@faresoftware.it> wrote:

Hi all.

There is a QA to test if 2 recipes try to install a file with the same
path?

In my BSP 2 recipes try install the file
${D}/etc/network/if-up,d/hostapd_restart


I'd like receive an error from bitbale  I was just about to weigh in on this as I was just educated by
Richard Purdie as to the (im)proper use of SSTATE_DUPWHITELIST.
If two packages were truly trying to install the same file, I would
have assumed that you would have received an error to that effect,
so the fact that you aren't suggests one of:

 * they're not really trying to install the same file
 * you're installing only one of the packages
 * perhaps there is a do_install_append() that is manually
   removing the conflicting file from one of the recipes

  My opinion, FWIW.

rday

Re: File collision: same path from 2 recipes

Laurent Gauthier

#50868

Hi Mauro,

From my experience there should be an error reported during the image creation as long as the two *packages* that contain a file with the same name are BOTH installed in the root filesystem.

If you don't receive an error I would suspect that for some reason the file is really only installed by one of the two packages.

Another source of your issue is that there can be more than one package created by one recipe, and maybe you are not installing the package which contains the contentious file.

Kind Regards, Laurent.

Show quoted text

On Tue, Sep 29, 2020 at 2:08 PM Mauro Ziliani <mauro@...> wrote:

Hi all.

There is a QA to test if 2 recipes try to install a file with the same path?

In my BSP 2 recipes try install the file
${D}/etc/network/if-up,d/hostapd_restart

I'd like receive an error from bitbale

Best regards,

MZ

--

Laurent Gauthier
Embedded Linux Systems & Software
Phone: +33 630 483 429
http://soccasys.com

File collision: same path from 2 recipes

Mauro Ziliani

#50867

Hi all.

There is a QA to test if 2 recipes try to install a file with the same path?

In my BSP 2 recipes try install the file ${D}/etc/network/if-up,d/hostapd_restart

I'd like receive an error from bitbale

Best regards,

   MZ

M+ & H bugs with Milestone Movements WW39

Stephen Jolley

#50866

All,

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

Priority	Bug ID	Short Description	Changer	Owner	Was	Became
Medium+	11449	Allow overriding classes to override overridden classes	richard.purdie@...	richard.purdie@...	3.2 M3	3.2 M4
	11746	oe-selftest: capture self.logger messages in XML output	richard.purdie@...	richard.purdie@...	3.2 M3	3.2 M4
	12090	bitbake resident server reconnect needed ?	richard.purdie@...	richard.purdie@...	3.2 M3	3.2 M4
	12368	persistent bitbake server does not re-parse if previous build was ctrl+C'd	richard.purdie@...	richard.purdie@...	3.2 M3	3.2 M4
	12723	mysql requires unicode and char length filtering	david.reyna@...	david.reyna@...	3.2 M3	3.2 M4
	12970	uninative file should be versionned	richard.purdie@...	richard.purdie@...	3.2 M3	3.2 M4
	12986	Failed to expand SRCPV on updateding SRC_URI using pn overrides and BBCLASSEXTEND	richard.purdie@...	richard.purdie@...	3.2 M3	3.2 M4
	13008	toaster testing	david.reyna@...	david.reyna@...	3.2 M3	3.3 M1
	13109	Implement CPE to package to Release mapping	david.reyna@...	david.reyna@...	3.2 M3	3.3 M1
	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 M3	3.2 M4
	13123	package.PackageTests.test_gdb_hardlink_debug failed	randy.macleod@...	randy.macleod@...	3.2 M3	3.2 M4
	13183	bitbake-layers crashes with incorrect layer configuration data is given (expected proper error printing and exit with error)	richard.purdie@...	richard.purdie@...	3.2 M3	3.2 M4
	13278	If git protocol doesn't work, you get a tar.gz clone from PREMIRROR which has git protocol origin	richard.purdie@...	richard.purdie@...	3.2 M3	3.2 M4
	13325	Add link to the output directory from LHS console view	richard.purdie@...	richard.purdie@...	3.2 M3	3.2 M4
	13355	RDEPENDS does not work properly for native builds (only supports recipe names, not package names)	richard.purdie@...	richard.purdie@...	3.2 M3	3.2 M4
	13424	devupstream doesn't work with mutilib	richard.purdie@...	richard.purdie@...	3.2 M3	3.2 M4
	13448	bitbake master appears to expand variables it should not need to	richard.purdie@...	richard.purdie@...	3.2 M3	3.2 M4
	13599	Enhancement: Detect variables that shouldn't be defined in image scope, but in global (distro) scope	richard.purdie@...	richard.purdie@...	3.2 M3	3.2 M4
	13642	Split single "run-config" step into multiple steps	richard.purdie@...	richard.purdie@...	3.2 M3	3.2 M4
	13669	Move Toaster testsuite-2 away from Testopia	david.reyna@...	david.reyna@...	3.2 M3	3.2 M4
	13699	Prolonged recipe parsing times after removing tmp when the resident bitbake server is used	richard.purdie@...	richard.purdie@...	3.2 M3	3.2 M4
	13711	Parsing fails on externalsrc recipe containing both git and file in SRC_URI	richard.purdie@...	richard.purdie@...	3.2 M3	3.2 M4
	13729	Changing siteinfo files doesn't change task checksum	richard.purdie@...	richard.purdie@...	3.2 M3	3.2 M4
	13823	fetch2: PREMIRROR and SRC_URI with users on both url yields invalid username	richard.purdie@...	richard.purdie@...	3.2 M3	3.2 M4
	13886	bitbake resident server does not honour --runonly or --runall options	richard.purdie@...	richard.purdie@...	3.2 M3	3.2 M4
	13891	insane.bbclass: do_package_qa hangs when checking a FIFO (named pipe) file	richard.purdie@...	richard.purdie@...	3.2 M3	3.2 M4
	13973	rm_work sigdata written with same hash and empty diffsigs, though different contents	richard.purdie@...	richard.purdie@...	3.2 M3	3.2 M4
	14055	[QA 3.2 M3 RC1] failure in oe-core manual test: test_dependency_explorer_is_launched	randy.macleod@...	ross@...	3.2 M3	3.2 M4

Thanks,

Stephen K. Jolley

Yocto Project Program Manager

( Cell: (208) 244-4460

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

Enhancements/Bugs closed WW39!

Stephen Jolley

#50865

All,

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

Who	Count
richard.purdie@...	5
sangeeta.jain@...	1
randy.macleod@...	1
ross@...	1
khairul.rohaizzat.jamaluddin@...	1
michael@...	1
david.reyna@...	1
Grand Total	11

Thanks,

Stephen K. Jolley

Yocto Project Program Manager

( Cell: (208) 244-4460

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

Current Autobuilder Intermittent bugs by the WW created or closed.

Stephen Jolley

#50864

All,

Below are the lists of open and closed medium or higher Autobuilder Intermittent bugs by the WW created or closed.

WW Opened	WW Closed	Status	Count
2018WW48	2020WW26	Closed	1
2018WW49	2020WW28	Closed	1
2019WW26	2020WW31	Closed	1
2019WW43	2020WW30	Closed	1
2019WW47		Open	1
2019WW51	2020WW30	Closed	1
2020WW13	2020WW30	Closed	1
2020WW21	2020WW30	Closed	1
2020WW21	2020WW33	Closed	1
2020WW23	2020WW27	Closed	1
2020WW8		Open	2
2020WW8	2020WW29	Closed	1
2020WW24		Open	1
2020WW24	2020WW34	Closed	1
2020WW25		Open	1
2020WW25	2020WW27	Closed	1
2020WW25	2020WW33	Closed	1
2020WW26	2020WW26	Closed	2
2020WW26	2020WW28	Closed	1
2020WW27	2020WW28	Closed	1
2020WW28	2020WW29	Closed	1
2020WW29		Open	1
2020WW30		Open	1
2020WW31		Open	2
2020WW33		Open	5
2020WW33	2020WW34	Closed	2
2020WW33	2020WW35	Closed	1
2020WW34		Open	2
2020WW34	2020WW34	Closed	1
2020WW35		Open	2
2020WW35	2020WW39	Closed	1
2020WW36		Open	2
2020WW36	2020WW37	Closed	2
2020WW36	2020WW39	Closed	1
2020WW37		Open	1
2020WW38	2020WW39	Closed	1
2020WW39		Open	2
Grand Total			50

Thanks,

Stephen K. Jolley

Yocto Project Program Manager

( Cell: (208) 244-4460

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

Current high bug count owners for Yocto Project 3.2

Stephen Jolley

#50863

All,

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

Who	Count
richard.purdie@...	32
david.reyna@...	22
ross@...	19
bluelightning@...	19
akuster808@...	18
bruce.ashfield@...	18
mark.morton@...	11
sakib.sajal@...	11
kai.kang@...	10
JPEWhacker@...	10
trevor.gamblin@...	9
Qi.Chen@...	9
timothy.t.orling@...	9
hongxu.jia@...	5
raj.khem@...	5
rpjday@...	4
mostthingsweb@...	4
randy.macleod@...	4
mingli.yu@...	4
yi.zhao@...	3
jon.mason@...	3
jeanmarie.lemetayer@...	2
alejandro@...	2
michael@...	2
ydirson@...	2
jaewon@...	2
jpuhlman@...	2
steve@...	2
chee.yang.lee@...	2
mark.hatle@...	2
kergoth@...	2
aehs29@...	1
joe.slater@...	1
liu.ming50@...	1
Martin.Jansa@...	1
akuster@...	1
kai.ruhnau@...	1
liezhi.yang@...	1
kexin.hao@...	1
anuj.mittal@...	1
amber.n.elliot@...	1
maxime.roussinbelanger@...	1
changqing.li@...	1
matt.ranostay@...	1
ankur.tyagi85@...	1
jason.wessel@...	1
dl9pf@...	1
Grand Total	265

Thanks,

Stephen K. Jolley

Yocto Project Program Manager

( Cell: (208) 244-4460

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