Date   

Yocto Technical Team Minutes, Engineering Sync, for September 29, 2020

Trevor Woerner
 

Yocto Technical Team Minutes, Engineering Sync, for September 29, 2020
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit

== disclaimer ==
Best efforts are made to ensure the below is accurate and valid. However,
errors sometimes happen. If any errors or omissions are found, please feel
free to reply to this email with any corrections.

== attendees ==
Trevor Woerner, Stephen Jolly, Saul Wold, Armin Kuster, Richard Purdie,
Bruce Ashfield, Jon Mason, Michael Halstead, David Reyna, Jeremy Puhlman,
Jan-Simon Möller, Ross Burton, Paul Barker, Scott Murray, Tim Orling,
Steve Sakoman, Randy MacLeod, <phone-in>, Alejandro H

== notes ==
- M3-rc2 through QA, release for later this week
- 3.1.3 in QA, release Thur or Fri this week
- more AB issues resolved, but many remain
- --x corruption in pseudo, probably undetected in many cases

== general ==
RP: 2 of 5 bugs fixed against M3-rc1, so we’re ready to move on

RP: the pseudo issue explains strange bugs we’ve seen over the years
Randy: any solutions?
RP: seems worrying, Peter thinks it should abort. with the aborts it only gets
through 2-3 tasks before aborting
PaulB: can we do something when non-pseudo tries to touch these paths?
RP: pseudo assumes it has 100% access to the entire system, but there are
things we change outside pseudo (which are fine), so we need a patch to
tell pseudo to restrict what it can see, but the ignore-list isn’t
complete. e.g. pseudo and qemu don’t get along so we stop pseudo to run
qemu, qemu then touches files that pseudo controls, but we can’t tell
which files were touched

RP: despite all the changes we’ve made, we’re still seeing timeout issues
on the AB

ScottM: could we scan a set of directories
RP: we could do an integrity check, the problem is deciding when to do it.
there are a number of tasks that run in parallel, so the trick is figuring
out when to do the integrity check.
ScottM: how amenable is that to someone helping without deep knowledge of
pseudo?
RP: once it’s down to analysing individual changes, we should be fine
ScottM: do we need a failed build to work on?
RP: no, with the aborts in place the issues crop up quickly
J-SM: could the abort patch be made available conditionally so people can dig
in?
RP: possibly. the build dies very quickly with the patch, so if we can get to
a certain point before failing then others can jump in
PaulB: other distros use fakeroot, is it worth looking elsewhere for ideas?
RP: we use pseudo because fakeroot had massive issues that didn’t map well
to what we’re doing (not sure if these have all been addressed) e.g. if
you open a shell and do the whole build sequentially in that one shell,
then fakeroot will work fine. but with us we use different tasks, in
parallel, etc which fakeroot doesn’t support
RP: these issues tend to only appear because of the heavy heavy load of the
build servers, these most likely won’t affect people doing “normal”
builds on mostly not-overloaded systems. i.e. the inodes are re-used very
quickly on our AB infrastructure

RP: i have some patches in master-next which i’ll push later this week. but
it raises the question about what to do regarding -stable
J-SM: i suggest doing the same, make the patch optionally available
RP: i’ll try to get it working somewhat so others can jump in more easily
Randy: things generally look good
RP: i think this bug’s been here a long time, but was exacerbated by
recipe-specific sysroots, these generate a *tonne* of database entries
RP: the only way people might have noticed this in the past is if someone did
a binary compare
Randy: right, but nobody’s complained about /bin/ls not having --x (for
example)
Jeremy: i’m guessing the issue has been around since 2.4 (Rocko). we have
been seeing issues where random executables would be missing --x
PaulB: we have to make sure to not attribute this issue to too many bugs

PaulB: Randy and i emailed the maintainers of meta-rust to bring rust support
in during the next development cycle. looks good so far
Randy: i have a patch
PaulB: and the patch adds the fetcher into bitbake

TW: OE happy hour tomorrow

TW: there was a discussion re default values, any resolution?
RP: nobody liked any of the suggestions well enough, so it faded

PaulB: inclusive language: add to contribution guidelines? the contributing
guideline only appears in the wiki, should we have something at the
top-level of the repository?
RP: go for it, anything to help new users


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

daparrag@...
 

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

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

 

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)
 


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)
 

Is there documentation on how to set this up ?

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

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)
 


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
 

Current Dev Position: YP 3.2 M4

Next Deadline: YP 3.2 M4 Feature Freeze - Now

 

Next Team Meetings:

 

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:

 

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:

 

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
 

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
 

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
 

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


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
 

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
 

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.


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
 

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


Re: File collision: same path from 2 recipes

Robert P. J. Day
 

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
 

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


File collision: same path from 2 recipes

Mauro Ziliani
 

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
 

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
 

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
 

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

 

1181 - 1200 of 52041