Re: [yocto] mono-native is trying to install files into a shared area...

[Khem Raj]

On Mon, Jun 11, 2018 at 8:36 PM Craig McQueen 
wrote:

> I wrote:
> >
> > I wrote:
> > >
> > > Lately, I'm trying to upgrade to a later version of mono, 5.4.1.6.
> > > When I try to do a build of my Yocto image, bitbake gets to the end of
> > > building mono- native, and then gets an error:
> > >
> > >
> > > ERROR: mono-native-5.4.1.6-r0 do_populate_sysroot: The recipe mono-
> > > native is trying to install files into a shared area when those files
> already
> > exist.
> > > Those files and their manifest location are:
> > >/home/craigm/yocto/poky/build/tmp/sysroots/x86_64-
> > > linux/usr/lib/mono/lldb/mono.py
> > >  Matched in b''
> > >  /home/craigm/yocto/poky/build/tmp/sysroots/x86_64-
> > > linux/usr/lib/mono/4.6.1-api/System.Web.Http.SelfHost.dll
> > >  Matched in b''
> > > ...
> > > /home/craigm/yocto/poky/build/tmp/sysroots/x86_64-
> > >
> > linux/usr/lib/mono/xbuild/14.0/bin/MSBuild/Microsoft.Build.CommonTypes.
> > > xsd
> > >  Matched in b''
> > >  /home/craigm/yocto/poky/build/tmp/sysroots/x86_64-
> > > linux/usr/lib/mono/xbuild/14.0/bin/MSBuild/Microsoft.Build.Core.xsd
> > >  Matched in b''
> > >  /home/craigm/yocto/poky/build/tmp/sysroots/x86_64-
> > >
> > linux/usr/lib/mono/xbuild/14.0/Microsoft.Common.targets/ImportAfter/Mi
> > > c
> > > rosoft.NuGet.ImportAfter.targets
> > >  Matched in b''
> > > Please verify which recipe should provide the above files.
> > > The build has stopped as continuing in this scenario WILL break
> > > things, if not now, possibly in the future (we've seen builds fail
> > > several months later). If the system knew how to recover from this
> > > automatically it would however there are several different scenarios
> > > which can result in this and we don't know which one this is. It may
> > > be you have switched providers of something like virtual/kernel (e.g.
> > > from linux-yocto to linux-yocto-dev), in that case you need to execute
> the
> > clean task for both recipes and it will resolve this error.
> > > It may be you changed DISTRO_FEATURES from systemd to udev or vice
> > > versa. Cleaning those recipes should again resolve this error however
> > > switching DISTRO_FEATURES on an existing build directory is not
> > > supported, you should really clean out tmp and rebuild (reusing sstate
> > > should be safe). It could be the overlapping files detected are
> > > harmless in which case adding them to SSTATE_DUPWHITELIST may be the
> > > correct solution. It could also be your buil  d is including two
> > > different conflicting versions of things (e.g. bluez
> > > 4 and bluez 5 and the correct solution for that would be to resolve
> > > the conflict. If in doubt, please ask on the mailing list, sharing the
> > > error and filelist above.
> > > ERROR: mono-native-5.4.1.6-r0 do_populate_sysroot: If the above
> > > message is too much, the simpler version is you're advised to wipe out
> > > tmp and rebuild (reusing sstate is fine). That will likely fix things
> > > in most (but not all) cases.
> > > ERROR: mono-native-5.4.1.6-r0 do_populate_sysroot: Function failed:
> > > sstate_task_postfunc
> > > ERROR: Logfile of failure stored in:
> > > /home/craigm/yocto/poky/build/tmp/work/x86_64-linux/mono-
> > > native/5.4.1.6-r0/temp/log.do_populate_sysroot.108358
> > > ERROR: Task (/home/craigm/yocto/poky/build/../../meta-mono/recipes-
> > > mono/mono/mono-native_5.4.1.6.bb:do_populate_sysroot) failed with
> > exit
> > > code '1'
> > > NOTE: Tasks Summary: Attempted 670 tasks of which 662 didn't need to
> > > be rerun and 1 failed.
> > >
> > > Summary: 1 task failed:
> > >   /home/craigm/yocto/poky/build/../../meta-mono/recipes-
> > > mono/mono/mono-native_5.4.1.6.bb:do_populate_sysroot
> > > Summary: There were 3 ERROR messages shown, returning a non-zero exit
> > > code.
> > >
> > >
> > > I'm building with Yocto poky morty branch (currently commit
> > > 0e730770a9), meta-mono master (commit dced6635ca). I'm building on
> > Ubuntu 16.04.4.
> > >
> > > I have tried deleting the tmp directory, deleting all mono and
> > > mono-native from sstate, cleaning mono and meta-mono, etc, to no avail.
> > >
> > > It's puzzling why I'm getting these errors, because it says "Matched
> > > in b''", so the files are not clashing with another recipe. It seems
> > > to be somehow trying to install its own files twice, or something like
> > > that. If I look under tmp/work/x86_64-linux/mono-native/5.4.1.6-r0/,
> > > then I see the files present in both:
> > >
> > > sysroot-destdir/home/craigm/yocto/poky/build/tmp/sysroots/x86_64-
> > linux
> > > / and image/home/craigm/yocto/poky/build/tmp/sysroots/x86_64-linux/
> > >
> > > Is that part of the problem?
> >
> >
> > I haven't had any success figuring out what is going on. I tried doing a
> new
> > clean build, and got the same error.
> >
> > Does anyone else have this problem? Is it an incompatibility with Yocto
> > morty, which I'm using? Any pointers on how to narrow down the cause?
>
> I tried updating from morty to rocko, and 

Re: [yocto] mono-native is trying to install files into a shared area...

[Craig McQueen]

I wrote:
> 
> I wrote:
> >
> > Lately, I'm trying to upgrade to a later version of mono, 5.4.1.6.
> > When I try to do a build of my Yocto image, bitbake gets to the end of
> > building mono- native, and then gets an error:
> >
> >
> > ERROR: mono-native-5.4.1.6-r0 do_populate_sysroot: The recipe mono-
> > native is trying to install files into a shared area when those files 
> > already
> exist.
> > Those files and their manifest location are:
> >/home/craigm/yocto/poky/build/tmp/sysroots/x86_64-
> > linux/usr/lib/mono/lldb/mono.py
> >  Matched in b''
> >  /home/craigm/yocto/poky/build/tmp/sysroots/x86_64-
> > linux/usr/lib/mono/4.6.1-api/System.Web.Http.SelfHost.dll
> >  Matched in b''
> > ...
> > /home/craigm/yocto/poky/build/tmp/sysroots/x86_64-
> >
> linux/usr/lib/mono/xbuild/14.0/bin/MSBuild/Microsoft.Build.CommonTypes.
> > xsd
> >  Matched in b''
> >  /home/craigm/yocto/poky/build/tmp/sysroots/x86_64-
> > linux/usr/lib/mono/xbuild/14.0/bin/MSBuild/Microsoft.Build.Core.xsd
> >  Matched in b''
> >  /home/craigm/yocto/poky/build/tmp/sysroots/x86_64-
> >
> linux/usr/lib/mono/xbuild/14.0/Microsoft.Common.targets/ImportAfter/Mi
> > c
> > rosoft.NuGet.ImportAfter.targets
> >  Matched in b''
> > Please verify which recipe should provide the above files.
> > The build has stopped as continuing in this scenario WILL break
> > things, if not now, possibly in the future (we've seen builds fail
> > several months later). If the system knew how to recover from this
> > automatically it would however there are several different scenarios
> > which can result in this and we don't know which one this is. It may
> > be you have switched providers of something like virtual/kernel (e.g.
> > from linux-yocto to linux-yocto-dev), in that case you need to execute the
> clean task for both recipes and it will resolve this error.
> > It may be you changed DISTRO_FEATURES from systemd to udev or vice
> > versa. Cleaning those recipes should again resolve this error however
> > switching DISTRO_FEATURES on an existing build directory is not
> > supported, you should really clean out tmp and rebuild (reusing sstate
> > should be safe). It could be the overlapping files detected are
> > harmless in which case adding them to SSTATE_DUPWHITELIST may be the
> > correct solution. It could also be your buil  d is including two
> > different conflicting versions of things (e.g. bluez
> > 4 and bluez 5 and the correct solution for that would be to resolve
> > the conflict. If in doubt, please ask on the mailing list, sharing the
> > error and filelist above.
> > ERROR: mono-native-5.4.1.6-r0 do_populate_sysroot: If the above
> > message is too much, the simpler version is you're advised to wipe out
> > tmp and rebuild (reusing sstate is fine). That will likely fix things
> > in most (but not all) cases.
> > ERROR: mono-native-5.4.1.6-r0 do_populate_sysroot: Function failed:
> > sstate_task_postfunc
> > ERROR: Logfile of failure stored in:
> > /home/craigm/yocto/poky/build/tmp/work/x86_64-linux/mono-
> > native/5.4.1.6-r0/temp/log.do_populate_sysroot.108358
> > ERROR: Task (/home/craigm/yocto/poky/build/../../meta-mono/recipes-
> > mono/mono/mono-native_5.4.1.6.bb:do_populate_sysroot) failed with
> exit
> > code '1'
> > NOTE: Tasks Summary: Attempted 670 tasks of which 662 didn't need to
> > be rerun and 1 failed.
> >
> > Summary: 1 task failed:
> >   /home/craigm/yocto/poky/build/../../meta-mono/recipes-
> > mono/mono/mono-native_5.4.1.6.bb:do_populate_sysroot
> > Summary: There were 3 ERROR messages shown, returning a non-zero exit
> > code.
> >
> >
> > I'm building with Yocto poky morty branch (currently commit
> > 0e730770a9), meta-mono master (commit dced6635ca). I'm building on
> Ubuntu 16.04.4.
> >
> > I have tried deleting the tmp directory, deleting all mono and
> > mono-native from sstate, cleaning mono and meta-mono, etc, to no avail.
> >
> > It's puzzling why I'm getting these errors, because it says "Matched
> > in b''", so the files are not clashing with another recipe. It seems
> > to be somehow trying to install its own files twice, or something like
> > that. If I look under tmp/work/x86_64-linux/mono-native/5.4.1.6-r0/,
> > then I see the files present in both:
> >
> > sysroot-destdir/home/craigm/yocto/poky/build/tmp/sysroots/x86_64-
> linux
> > / and image/home/craigm/yocto/poky/build/tmp/sysroots/x86_64-linux/
> >
> > Is that part of the problem?
> 
> 
> I haven't had any success figuring out what is going on. I tried doing a new
> clean build, and got the same error.
> 
> Does anyone else have this problem? Is it an incompatibility with Yocto
> morty, which I'm using? Any pointers on how to narrow down the cause?

I tried updating from morty to rocko, and no longer got this error. So it seems 
it's somehow an issue with meta-mono in conjunction with morty.

-- 
Craig McQueen

-- 
___
yocto mailing list
yocto@yoctoproject.org

Re: [yocto] Target CPU architectures that Yocto Project Support

[Ricardo Ramirez]

Thanks for the reply, Khem!

What steps should I follow to be able to verify the build I put together
for SPARCv9 works (or doesn't)?

I realize it is a pretty non-conventional (newbie like) question but I'd
like to follow a methodological procedure to validate the build.

I appreciate your answer.

-R

On Mon, Jun 11, 2018 at 5:41 PM, Khem Raj  wrote:

> Hi Ricardo
>
> On 6/10/18 7:06 PM, Ricardo Ramirez wrote:
>
>> Hi David,
>>
>> Thanks for the prompt reply!
>>
>> My question was a follow up of Khem's inquire (posted on 2014-05-02)
>>
>> https://lists.yoctoproject.org/pipermail/yocto/2014-May/019387.html
>>
>>
> this reply still holds as of today.
>
> Using the links you sent me, I found that the old OE-Classic branch
>> supports sparc32 but didn't see any sparc64
>>
>> http://layers.openembedded.org/layerindex/oe-classic/recipes/
>>
>> As such, I'd like to know what steps I need to follow in order to enable
>> a SPARCv9 machine in Yocto.
>>
>>
> We support arm/aarch64/mips/mips64/ppc/ppc64/riscv64/x86/x86_64 for major
> arches in OE-Core, we also carry patches to support SH4 but do not test
> actively for it. sparc support is in there atleast I see basic constructs
> are there. Its should be possible to build upon that easily. But it will
> not work out of box to set your expectations right.
>
> I appreciate your answer.
>>
>> -R
>>
>>
>> On Sun, Jun 10, 2018 at 7:17 PM, Reyna, David > > wrote:
>>
>> Hi Ricardo,
>>
>> __ __
>>
>> If you are asking about the list of MACHINE types that Yocto Project
>> supports, then the best place to look is in the Layer Index:
>>
>> __ __
>>
>> https://layers.openembedded.org/layerindex/branch/master/layers/
>> > >
>>
>> __ __
>>
>> Click on the “Machines” tab, click on the “Search” tab with or
>> without a search value, and see the glorious list.
>>
>> __ __
>>
>> The same goes for supported layers, recipes, classes, and distro
>> values.
>>
>> __ __
>>
>> You can change the “Branch” value to see the MACHINE’s per
>> release.
>>
>> __ __
>>
>> - David Reyna
>>
>> __ __
>>
>> *From:*yocto-boun...@yoctoproject.org
>> 
>> [mailto:yocto-boun...@yoctoproject.org
>> ] *On Behalf Of *Ricardo
>> Ramirez
>> *Sent:* Sunday, June 10, 2018 5:07 PM
>> *To:* yocto@yoctoproject.org 
>> *Subject:* Re: [yocto] Target CPU architectures that Yocto Project
>> Support
>>
>> __ __
>>
>> Hi,
>>
>> __ __
>>
>> Naive question from a newbie. How can this be achieved? I'd
>> appreciate if you could please shed some light on what steps need to
>> be followed?
>>
>> __ __
>>
>> Thanks in advance,
>>
>> __ __
>>
>> -R
>>
>>
>>
>>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] sysroot not being populated

[Andre McCurdy]

On Fri, Jun 8, 2018 at 2:42 AM, Patrick Vacek  wrote:
> On 08.06.2018 10:26, Khem Raj wrote:
>> On 6/8/18 12:27 AM, Patrick Vacek wrote:
>>> On 07.06.2018 19:06, Khem Raj wrote:
 Hi Patrick

 On Mon, Jun 4, 2018 at 2:01 AM, Patrick Vacek
  wrote:
> Hello all,
>
> I have a recipe (aktualizr-hsm-prov) that depends on another
> (aktualizr)
> to provide an executable and a config file. The former recipe includes
> `DEPENDS = "aktualizr-native"`, and my do_install() for
> aktualizr-hsm-prov has a line something like this:
>
> aktualizr -i ${STAGING_DIR_NATIVE}${libdir}/sota.conf
>
> The binary executable (aktualizr) runs, which tells me that the recipe
> can find that. (Although to be honest, I'm not sure which version
> it is
> running.) However, it doesn't find the config file, and sure enough,
> ${STAGING_DIR_NATIVE}${libdir} does not have the config file I
> expect. I
> can see that aktualizr-native is populating its sysroot-destdir,
> but it
> isn't getting copied to the sysroot for aktualizr-hsm-prov.
>
> I see this problem in sumo and master, although previously this logic
> has worked just fine in morty/pyro/rocko.
>
> Switching to depending on aktualizr (instead of aktualizr-native) and
> using STAGING_DIR_HOST or STAGING_DIR_TARGET does not help, and in
> fact
> makes it worse, as it can't even find the aktualizr executable in
> that case.
>
> What am I doing wrong? What changed between rocko and sumo?
 is aktualizr recipe installing this .conf file when building native
 version. If not may be
 add it to do_install

 install -D -m 0644  ${D}${libdir}/sota.conf
>>>
>>> Hello Khem,
>>>
>>> I believe so. The aktualizr recipe includes the following (edited for
>>> simplicity):
>>>
>>> BBCLASSEXTEND =+ "native"
>>>
>>> do_install_append () {
>>>  install -m 0644 ${S}/config/sota.conf ${D}/${libdir}/sota.conf
>>> }
>>>
>>> PACKAGES =+ " ${PN}-host-tools "
>>>
>>> FILES_${PN}-host-tools = " ${libdir}/sota.conf "
>>>
>>
>> Can you check location of sota.conf in the build tree for
>> aktualizr-native in directory called package/
> Oddly, I do not see a package subdirectory inside the aktualizr-native
> directory in the build tree. I do see it inside the aktualizr directory,
> though, and it contains everything that I would expect. Is there some
> sort of configuration of the packaging system for a native recipe that I
> haven't done correctly?

No, what you see is expected - there's no packaging for -native recipes.

Back to the original problem, I think you should consider the
aktualizr executable and the sota.conf file as two separate things.
The host executable should always be provided by aktualizr-native.
It's less clear what should provide sota.conf - it depends whether
it's just required for building other recipes (ie like a header file)
or whether it needs to be present in the final rootfs? If it's only
required for building other packages, then it should be in the -dev
package for aktualizr. If it needs to be present in the final rootfs
then it should be in the default package for aktualizr. Either way,
recipes which need to find sota.conf in sysroot would then depend on
"aktualizr". Therefore recipes which need both the host executable and
sota.conf in sysroot should depend on both aktualizr and
aktualizr-native.

> For the record, here is the actual recipe:
> https://github.com/advancedtelematic/meta-updater/blob/master/recipes-sota/aktualizr/aktualizr_git.bb
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Target CPU architectures that Yocto Project Support

[Khem Raj]

Hi Ricardo

On 6/10/18 7:06 PM, Ricardo Ramirez wrote:

Hi David,

Thanks for the prompt reply!

My question was a follow up of Khem's inquire (posted on 2014-05-02)

https://lists.yoctoproject.org/pipermail/yocto/2014-May/019387.html



this reply still holds as of today.

Using the links you sent me, I found that the old OE-Classic branch 
supports sparc32 but didn't see any sparc64


http://layers.openembedded.org/layerindex/oe-classic/recipes/

As such, I'd like to know what steps I need to follow in order to enable 
a SPARCv9 machine in Yocto.




We support arm/aarch64/mips/mips64/ppc/ppc64/riscv64/x86/x86_64 for 
major arches in OE-Core, we also carry patches to support SH4 but do not 
test actively for it. sparc support is in there atleast I see basic 
constructs are there. Its should be possible to build upon that easily. 
But it will not work out of box to set your expectations right.



I appreciate your answer.

-R


On Sun, Jun 10, 2018 at 7:17 PM, Reyna, David > wrote:


Hi Ricardo,

__ __

If you are asking about the list of MACHINE types that Yocto Project
supports, then the best place to look is in the Layer Index:

__ __

https://layers.openembedded.org/layerindex/branch/master/layers/


__ __

Click on the “Machines” tab, click on the “Search” tab with or
without a search value, and see the glorious list.

__ __

The same goes for supported layers, recipes, classes, and distro
values.

__ __

You can change the “Branch” value to see the MACHINE’s per release.

__ __

- David Reyna

__ __

*From:*yocto-boun...@yoctoproject.org

[mailto:yocto-boun...@yoctoproject.org
] *On Behalf Of *Ricardo Ramirez
*Sent:* Sunday, June 10, 2018 5:07 PM
*To:* yocto@yoctoproject.org 
*Subject:* Re: [yocto] Target CPU architectures that Yocto Project
Support

__ __

Hi,

__ __

Naive question from a newbie. How can this be achieved? I'd
appreciate if you could please shed some light on what steps need to
be followed?

__ __

Thanks in advance,

__ __

-R




--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] excluding the Proprietary source code from the archive

[Khem Raj]

On 6/8/18 2:57 AM, jan vermaete wrote:

Hi,

I have a question about the licenses stuff of Yocto.  I hope this is the 
correct place to ask.


I followed the instructions of the mega manual (chapter 7.32.3.1 
Providing the Source Code).


Added in my local.conf:
   INHERIT += "archiver"
   ARCHIVER_MODE[src] = "original"
   COPYLEFT_LICENSE_EXCLUDE="CLOSED Proprietary"

I have a recipe called x.bb , with 'LICENSE = "Proprietary"'

After a build of the image, there is the file 
'build/deploy/licenses/x/recipeinfo' which holds the correct license 
'LICENSE: Proprietary'


However, I still see the archive of the source code in 'build/deploy/source'


PS: I have DEPLOY_DIR = "${TOPDIR}/deploy" in my local.conf file.  But 
without, the result is the same.




if you enable verbose output from bitbake it should print the reason for 
excluding/including a recipe into archive. Maybe that will give better 
hint on why it thinks it should include the package in source archive



br


--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-security][PATCH 0/2] Fix build issue for apparmor

[akuster]

series merged.

Thanks,

Armin


On 06/06/2018 07:06 AM, Jinliang Li wrote:
> This patch series fix 2 build issues for apparmor.
>
> Jinliang Li (2):
>   Fix build issue for apparmor kernel configuration
>   Fix build issue for apparmor when systemd is used
>
>  recipes-kernel/linux/linux-yocto_4.%.bbappend | 2 +-
>  recipes-security/AppArmor/apparmor_2.11.0.bb  | 5 +
>  2 files changed, 6 insertions(+), 1 deletion(-)
>

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Generating license/manifest for a specific layer?

[Beth Flanagan]

On Mon, Jun 11, 2018 at 2:46 PM, Michael Habibi  wrote:
> Our use case is to capture the license files, manifest (package/version),
> and download information only for packages we modify/add. We use our own
> layer to modify/add packages, everything coming from standard Yocto layers
> are untouched.
>
> Is there a way to generate this information on a layer-by-layer basis,
> instead of a full manifest that includes all standard, unmodified packages?

The easy (cheating) way, would be to modify the tmp/deploy/licenses
artifact post build (I do it to remove -native- and -cross- from
things I distribute as I'm not actually distributing them) or put in a
post do_rootfs function that does it.

I guess my question would be (and this is less a technical question
and more of a legal one) is why would you want to only include a
manifest for only part of what you're distributing (or am I
misunderstanding what you're trying to do here?)

-b
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [autobuilder][PATCH 1/2] yocto-autobuilder2: add missing __init__.py to top level

[akuster808]

On 06/10/2018 03:44 PM, Richard Purdie wrote:
> On Sun, 2018-06-03 at 17:22 -0700, Armin Kuster wrote:
>> This fixes the import of modules when starting buildbot
>> as master.cfg has:
>> from yoctoabb import builders, config, schedulers, workers, services,
>> www
>>
>> Signed-off-by: Armin Kuster 
>> ---
>>  __init__.py | 0
>>  1 file changed, 0 insertions(+), 0 deletions(-)
>>  create mode 100644 __init__.py
>>
>> diff --git a/__init__.py b/__init__.py
>> new file mode 100644
>> index 000..e69de29
> I've merged the other patch (2/2). I've now realised this issue is due
> to the use of python2 when we've been testing with python3. Rather than
> trying to support both, I'd prefer to simply suggest people use python3
> at this point.
>
> Fancy sending a patch to document this? :)
Sure no problem.

- armin
>
> It'd be useful to me to be cc'd on patches for the autobuilder stuff
> too if that isn't too much trouble as I sometimes don't get though all
> the mailing lists as often as I'd like.
>
> Cheers,
>
> Richard
>
>
>
>

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Project Status WW24’18

[Jolley, Stephen K]

Current Dev Position: YP 2.6 M1 is accepting patches.

Next Deadline: YP 2.6 M1 release is June 11, 2018 (See update)


SWAT Team Rotation:

· SWAT lead is currently: Stephano

· SWAT team rotation: Stephano -> Armin on June 15, 2018

· SWAT team rotation: Armin -> Maxin on June 22, 2018

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


Key Status/Updates:

· 2.4.3 is in QA

· 2.3.4 and 2.2.4 are also both queued ready for QA after 2.4.3.

· The gcc 8.1 update is nearly ready for merge once the final 
edgerouter build issues are addressed. Once that merges, we’ll be ready for 2.6 
M1 testing.

· Due to the milestone, patch merging is slowing to stabilize.

· There has been some good progress on the autobuilder2 work. Thanks to 
some help from upstream we figured out how to create the build controls we need 
to run our testing which was a major blocker on updating our infrastructure. 
Once we have the wiki reporting fixed from the autobuilder we should be able to 
complete the update. Some of the improvements we need were merged upstream too.


Planned Releases for YP 2.6:

· YP 2.6 M1 Build Target is June 11, 2018 (See update)

· YP 2.6 M1 Release Target is June 22, 2018

· YP 2.6 M2 Build Target is July 16, 2018

· YP 2.6 M2 Release Target is July 27, 2018

· YP 2.6 M3 Build Target is Aug. 27, 2018

· YP 2.6 M3 Release Target is Sept. 7, 2018

· YP 2.6 M4 Build Target is Oct. 1, 2018

· YP 2.6 M4 Release Target is Oct. 26, 2018


Planned upcoming dot releases:

· YP 2.4.3 (Rocko) rc2 is built and in QA see 
https://wiki.yoctoproject.org/wiki/2.4_QA_Status it is 94% complete.

· YP 2.3.4 (Pyro) rc1 is built and in QA see 
https://wiki.yoctoproject.org/wiki/2.3_QA_Status it is at 86% complete.

· YP 2.2.4 (Morty) rc1 is built and in QA see 
https://wiki.yoctoproject.org/wiki/2.2_QA_Status it is at 19% complete.

· YP 2.5.1 (Sumo) will be targeted after YP 2.6 M2 is done.

· YP 2.4.4 (Rocko) will be targeted after YP 2.6 M4 is done.


Tracking Metrics:

· WDD 2551 (last week 2523) 
(https://wiki.yoctoproject.org/charts/combo.html)

· Poky Patch Metrics

oTotal patches found: 1597 (last week 1592)

oPercentage of patches in the Pending State: 741 (47%) [last week 742 (47%)]


Key Status Links for YP:

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

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

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


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 Project Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
•Cell:(208) 244-4460
• Email: stephen.k.jol...@intel.com

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Generating license/manifest for a specific layer?

[Michael Habibi]

Our use case is to capture the license files, manifest (package/version),
and download information only for packages we modify/add. We use our own
layer to modify/add packages, everything coming from standard Yocto layers
are untouched.

Is there a way to generate this information on a layer-by-layer basis,
instead of a full manifest that includes all standard, unmodified packages?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] semodule-utils: clear -dev's RDEPENDS

[George McCollister]

Set RDEPENDS_${PN}-dev = "" so ${PN}-dev doesn't RDEPEND on ${PN} (which
isn't created because it contains no files).
This recipe places every file under one of it's sub-packages.

This fixes an error encountered when building an SDK:
 nothing provides semodule-utils = 2.7-r0 needed by
 semodule-utils-dev-2.7-r0.core2-32

Signed-off-by: George McCollister 
---
 recipes-security/selinux/semodule-utils.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/recipes-security/selinux/semodule-utils.inc 
b/recipes-security/selinux/semodule-utils.inc
index 1e92745..2c75c48 100644
--- a/recipes-security/selinux/semodule-utils.inc
+++ b/recipes-security/selinux/semodule-utils.inc
@@ -8,6 +8,8 @@ LICENSE = "GPLv2+"
 
 DEPENDS += "libsepol"
 
+RDEPENDS_${PN}-dev = ""
+
 EXTRA_OEMAKE += "LIBSEPOLA=${STAGING_LIBDIR}/libsepol.a"
 
 PACKAGES =+ "\
-- 
2.11.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] [PATCH 4.14&4.15] MIPS: Use '+=" instead of '=' to avoid the CFLAGS override

[Bruce Ashfield]

On 2018-06-11 6:17 AM, Kevin Hao wrote:

We used the CFLAGS_xxx to workaround the gcc 8 build warnings
for some specific file. But CFLAGS_xxx is also used with '=' in
other places of this Makefile. This override the gcc 8 workaround,
so replace all the '=' with '+=" to fix this issue.


merged. SRCREV updates will be out shortly.

Bruce



Signed-off-by: Kevin Hao 
---
  arch/mips/kernel/Makefile | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/mips/kernel/Makefile b/arch/mips/kernel/Makefile
index f10e1e15e1c6..7a00a8e840ad 100644
--- a/arch/mips/kernel/Makefile
+++ b/arch/mips/kernel/Makefile
@@ -124,11 +124,11 @@ obj-$(CONFIG_MIPS_CPS_PM) += pm-cps.o
  ifeq ($(CONFIG_CPU_MIPSR2), y)
  CFLAGS_DSP= -DHAVE_AS_DSP
  
-CFLAGS_signal.o			= $(CFLAGS_DSP)

-CFLAGS_signal32.o  = $(CFLAGS_DSP)
-CFLAGS_process.o   = $(CFLAGS_DSP)
-CFLAGS_branch.o= $(CFLAGS_DSP)
-CFLAGS_ptrace.o= $(CFLAGS_DSP)
+CFLAGS_signal.o+= $(CFLAGS_DSP)
+CFLAGS_signal32.o  += $(CFLAGS_DSP)
+CFLAGS_process.o   += $(CFLAGS_DSP)
+CFLAGS_branch.o+= $(CFLAGS_DSP)
+CFLAGS_ptrace.o+= $(CFLAGS_DSP)
  endif
  
  CPPFLAGS_vmlinux.lds		:= $(KBUILD_CFLAGS)




--
___
linux-yocto mailing list
linux-yo...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 4.14&4.15] MIPS: Use '+=" instead of '=' to avoid the CFLAGS override

[Kevin Hao]

We used the CFLAGS_xxx to workaround the gcc 8 build warnings
for some specific file. But CFLAGS_xxx is also used with '=' in
other places of this Makefile. This override the gcc 8 workaround,
so replace all the '=' with '+=" to fix this issue.

Signed-off-by: Kevin Hao 
---
 arch/mips/kernel/Makefile | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/mips/kernel/Makefile b/arch/mips/kernel/Makefile
index f10e1e15e1c6..7a00a8e840ad 100644
--- a/arch/mips/kernel/Makefile
+++ b/arch/mips/kernel/Makefile
@@ -124,11 +124,11 @@ obj-$(CONFIG_MIPS_CPS_PM) += pm-cps.o
 ifeq ($(CONFIG_CPU_MIPSR2), y)
 CFLAGS_DSP = -DHAVE_AS_DSP
 
-CFLAGS_signal.o= $(CFLAGS_DSP)
-CFLAGS_signal32.o  = $(CFLAGS_DSP)
-CFLAGS_process.o   = $(CFLAGS_DSP)
-CFLAGS_branch.o= $(CFLAGS_DSP)
-CFLAGS_ptrace.o= $(CFLAGS_DSP)
+CFLAGS_signal.o+= $(CFLAGS_DSP)
+CFLAGS_signal32.o  += $(CFLAGS_DSP)
+CFLAGS_process.o   += $(CFLAGS_DSP)
+CFLAGS_branch.o+= $(CFLAGS_DSP)
+CFLAGS_ptrace.o+= $(CFLAGS_DSP)
 endif
 
 CPPFLAGS_vmlinux.lds   := $(KBUILD_CFLAGS)
-- 
2.14.3

-- 
___
linux-yocto mailing list
linux-yo...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[yocto] [PATCH] [yocto-autobuilder2] Add extended support on MailNotifier services

[Aaron]

From: Aaron Chan 

---
 config.py   | 34 ++
 services.py | 32 
 2 files changed, 62 insertions(+), 4 deletions(-)

diff --git a/config.py b/config.py
index 2568768..9d0807f 100644
--- a/config.py
+++ b/config.py
@@ -80,3 +80,37 @@ builder_to_workers = {
 "nightly-deb-non-deb": [],
 "default": workers
 }
+
+# MailNotifier default settings (refer to schedulers.py)
+#smtpConf = {
+#"fromaddr" : "yocto-bui...@yoctoproject.org",
+#"sendToInterestedUsers": False,
+#"extraRecipients"  : ["yocto-bui...@yoctoproject.org"],
+#"subject"  : "",
+#"mode" : ["failing", "exception", "cancelled"],
+#"builders" : None,
+#"tags" : None,
+#"schedulers"   : None,
+#"branches" : None,
+#"addLogs"  : False, 
+#"addPatch" : True,
+#"buildSetSummary"  : True,
+#"smtpServer"   : "",
+#"useTls"   : False, 
+#"useSmtps" : False,
+#"smtpUser" : None, 
+#"smtpPassword" : None,
+#"lookup"   : None,
+#"extraHeaders" : None,
+#"watchedWorkers"   : None,
+#"missingWorkers"   : None,
+#"template_dir" : "https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] [yocto-autobuilder2] Add extended support on MailNotifier services

[Aaron]

From: Aaron Chan 

---
 config.py   | 34 ++
 services.py | 32 
 2 files changed, 62 insertions(+), 4 deletions(-)

diff --git a/config.py b/config.py
index 2568768..9d0807f 100644
--- a/config.py
+++ b/config.py
@@ -80,3 +80,37 @@ builder_to_workers = {
 "nightly-deb-non-deb": [],
 "default": workers
 }
+
+# MailNotifier default settings (refer to schedulers.py)
+#smtpConf = {
+#"fromaddr" : "yocto-bui...@yoctoproject.org",
+#"sendToInterestedUsers": False,
+#"extraRecipients"  : ["yocto-bui...@yoctoproject.org"],
+#"subject"  : "",
+#"mode" : ["failing", "exception", "cancelled"],
+#"builders" : None,
+#"tags" : None,
+#"schedulers"   : None,
+#"branches" : None,
+#"addLogs"  : False, 
+#"addPatch" : True,
+#"buildSetSummary"  : True,
+#"smtpServer"   : "",
+#"useTls"   : False, 
+#"useSmtps" : False,
+#"smtpUser" : None, 
+#"smtpPassword" : None,
+#"lookup"   : None,
+#"extraHeaders" : None,
+#"watchedWorkers"   : None,
+#"missingWorkers"   : None,
+#"template_dir" : "https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] [yocto-autobuilder2] Add extended support on MailNotifier services

[Aaron]

From: Aaron Chan 

---
 config.py   | 34 ++
 services.py | 32 
 2 files changed, 62 insertions(+), 4 deletions(-)

diff --git a/config.py b/config.py
index 2568768..9d0807f 100644
--- a/config.py
+++ b/config.py
@@ -80,3 +80,37 @@ builder_to_workers = {
 "nightly-deb-non-deb": [],
 "default": workers
 }
+
+# MailNotifier default settings (refer to schedulers.py)
+#smtpConf = {
+#"fromaddr" : "yocto-bui...@yoctoproject.org",
+#"sendToInterestedUsers": False,
+#"extraRecipients"  : ["yocto-bui...@yoctoproject.org"],
+#"subject"  : "",
+#"mode" : ["failing", "exception", "cancelled"],
+#"builders" : None,
+#"tags" : None,
+#"schedulers"   : None,
+#"branches" : None,
+#"addLogs"  : False, 
+#"addPatch" : True,
+#"buildSetSummary"  : True,
+#"smtpServer"   : "",
+#"useTls"   : False, 
+#"useSmtps" : False,
+#"smtpUser" : None, 
+#"smtpPassword" : None,
+#"lookup"   : None,
+#"extraHeaders" : None,
+#"watchedWorkers"   : None,
+#"missingWorkers"   : None,
+#"template_dir" : "https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] sysroot not being populated

[Patrick Vacek]

On 08.06.2018 10:26, Khem Raj wrote:
>
>
> On 6/8/18 12:27 AM, Patrick Vacek wrote:
>> On 07.06.2018 19:06, Khem Raj wrote:
>>> Hi Patrick
>>>
>>> On Mon, Jun 4, 2018 at 2:01 AM, Patrick Vacek
>>>  wrote:
 Hello all,

 I have a recipe (aktualizr-hsm-prov) that depends on another
 (aktualizr)
 to provide an executable and a config file. The former recipe includes
 `DEPENDS = "aktualizr-native"`, and my do_install() for
 aktualizr-hsm-prov has a line something like this:

 aktualizr -i ${STAGING_DIR_NATIVE}${libdir}/sota.conf

 The binary executable (aktualizr) runs, which tells me that the recipe
 can find that. (Although to be honest, I'm not sure which version
 it is
 running.) However, it doesn't find the config file, and sure enough,
 ${STAGING_DIR_NATIVE}${libdir} does not have the config file I
 expect. I
 can see that aktualizr-native is populating its sysroot-destdir,
 but it
 isn't getting copied to the sysroot for aktualizr-hsm-prov.

 I see this problem in sumo and master, although previously this logic
 has worked just fine in morty/pyro/rocko.

 Switching to depending on aktualizr (instead of aktualizr-native) and
 using STAGING_DIR_HOST or STAGING_DIR_TARGET does not help, and in
 fact
 makes it worse, as it can't even find the aktualizr executable in
 that case.

 What am I doing wrong? What changed between rocko and sumo?
>>> is aktualizr recipe installing this .conf file when building native
>>> version. If not may be
>>> add it to do_install
>>>
>>> install -D -m 0644  ${D}${libdir}/sota.conf
>>
>> Hello Khem,
>>
>> I believe so. The aktualizr recipe includes the following (edited for
>> simplicity):
>>
>> BBCLASSEXTEND =+ "native"
>>
>> do_install_append () {
>>  install -m 0644 ${S}/config/sota.conf ${D}/${libdir}/sota.conf
>> }
>>
>> PACKAGES =+ " ${PN}-host-tools "
>>
>> FILES_${PN}-host-tools = " ${libdir}/sota.conf "
>>
>
> Can you check location of sota.conf in the build tree for
> aktualizr-native in directory called package/ 
Oddly, I do not see a package subdirectory inside the aktualizr-native
directory in the build tree. I do see it inside the aktualizr directory,
though, and it contains everything that I would expect. Is there some
sort of configuration of the packaging system for a native recipe that I
haven't done correctly?

For the record, here is the actual recipe:
https://github.com/advancedtelematic/meta-updater/blob/master/recipes-sota/aktualizr/aktualizr_git.bb

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] excluding the Proprietary source code from the archive

[jan vermaete]

Hi,

I have a question about the licenses stuff of Yocto.  I hope this is the
correct place to ask.

I followed the instructions of the mega manual (chapter 7.32.3.1 Providing
the Source Code).

Added in my local.conf:
  INHERIT += "archiver"
  ARCHIVER_MODE[src] = "original"
  COPYLEFT_LICENSE_EXCLUDE="CLOSED Proprietary"

I have a recipe called x.bb, with 'LICENSE = "Proprietary"'

After a build of the image, there is the file
'build/deploy/licenses/x/recipeinfo' which holds the correct license
'LICENSE: Proprietary'

However, I still see the archive of the source code in 'build/deploy/source'


PS: I have DEPLOY_DIR = "${TOPDIR}/deploy"  in my local.conf file.  But
without, the result is the same.

br
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] sysroot not being populated

[Patrick Vacek]

On 07.06.2018 19:06, Khem Raj wrote:
> Hi Patrick
>
> On Mon, Jun 4, 2018 at 2:01 AM, Patrick Vacek  wrote:
>> Hello all,
>>
>> I have a recipe (aktualizr-hsm-prov) that depends on another (aktualizr)
>> to provide an executable and a config file. The former recipe includes
>> `DEPENDS = "aktualizr-native"`, and my do_install() for
>> aktualizr-hsm-prov has a line something like this:
>>
>> aktualizr -i ${STAGING_DIR_NATIVE}${libdir}/sota.conf
>>
>> The binary executable (aktualizr) runs, which tells me that the recipe
>> can find that. (Although to be honest, I'm not sure which version it is
>> running.) However, it doesn't find the config file, and sure enough,
>> ${STAGING_DIR_NATIVE}${libdir} does not have the config file I expect. I
>> can see that aktualizr-native is populating its sysroot-destdir, but it
>> isn't getting copied to the sysroot for aktualizr-hsm-prov.
>>
>> I see this problem in sumo and master, although previously this logic
>> has worked just fine in morty/pyro/rocko.
>>
>> Switching to depending on aktualizr (instead of aktualizr-native) and
>> using STAGING_DIR_HOST or STAGING_DIR_TARGET does not help, and in fact
>> makes it worse, as it can't even find the aktualizr executable in that case.
>>
>> What am I doing wrong? What changed between rocko and sumo?
> is aktualizr recipe installing this .conf file when building native
> version. If not may be
> add it to do_install
>
> install -D -m 0644  ${D}${libdir}/sota.conf

Hello Khem,

I believe so. The aktualizr recipe includes the following (edited for
simplicity):

BBCLASSEXTEND =+ "native"

do_install_append () {
    install -m 0644 ${S}/config/sota.conf ${D}/${libdir}/sota.conf
}

PACKAGES =+ " ${PN}-host-tools "

FILES_${PN}-host-tools = " ${libdir}/sota.conf "

Thanks,
Patrick
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] [yocto-autobuilder2] Fixes on schedulers default build-appliance

[aaron . chun . yew . chan]

From: Aaron Chan 

---
 schedulers.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/schedulers.py b/schedulers.py
index 8f3dbc5..02e4340 100644
--- a/schedulers.py
+++ b/schedulers.py
@@ -63,7 +63,7 @@ def props_for_builder(builder):
 props.append(util.BooleanParameter(
 name="deploy_artifacts",
 label="Do we want to deploy artifacts? ",
-default=Boolean
+default=False
 ))
 
 props = props + repos_for_builder(builder)
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto