[yocto] HELP: Release Candidate Build for yocto-2.4.3.rc2 now available.

[Reyna, David]

Hi Richard,

I apologize for sending this patch for Toaster for Roco 2.4.3 very late. I have 
been focused on Sumo and I thought I had more time.

The Toaster for Rocko is broken on HEAD. There are two patches that made it 
into master and Sumo, but missed Rocko.

I have just now sent the missing patch set to "bitbake-dev". The first patch 
fixes an error that breaks the initialization of Toaster. The second patches 
fixes a change in behavior for Django that creates an extra thread that blocks 
Toaster from shutting down.

Please accept these patches for Rocko. They are confined to Toaster and do not 
affect the rest of the release.

Thanks,
David


-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Richard Purdie
Sent: Thursday, May 24, 2018 1:16 AM
To: yocto
Cc: ota...@ossystems.com.br; CHAN, AARON CHUN YEW
Subject: [yocto] Release Candidate Build for yocto-2.4.3.rc2 now available.

A release candidate build for yocto-2.4.3.rc2 is now available at:


https://autobuilder.yocto.io/pub/releases/yocto-2.4.3.rc2


Please begin QA on this build as soon as possible.


Build hash information: 
meta-intel : f66ce51d059d291a441d896854be8db70de5a554 
meta-qt4 : e290738759ef3f39c9e079eaa9b606a62107e5ba 
meta-mingw : 1cc620b38f6f30a0bdd181783297998fe073387f 
meta-qt3 : 8ef7261a331e0869a0461ab2fb44e39980cedc02 
meta-gplv2 : f875c60ecd6f30793b80a431a2423c4b98e51548 
poky : 7e7ee662f5dea4d090293045f7498093322802cc 

This is an automated message from The Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder
-- 
___
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] Target CPU architectures that Yocto Project Support

[Reyna, David]

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

[Reyna, David]

Hi Jefro,

I am very happy for you in your moving forward, thought I will very much miss 
your being part of our community.

Thank you for all your years of work and guidance and enthusiasm, and thank you 
for your generous support of the team as a whole and myself in particular!

I hope to get a chance to say hello next time I am in Portland (and if you end 
up in Canada, I am happy to meet up with you there as well :-).

- David

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Khem Raj
Sent: Wednesday, June 06, 2018 10:49 AM
To: OSIER-MIXON, JEFFREY
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Gratitude

Jefro

you have been very helpful all along has been great working with you. Your
contributions have been significant for project, thanks for all your
contributions.
Small world I am sure I will see you around :)

-Khem

On Tue, Jun 5, 2018 at 11:42 PM, Osier-mixon, Jeffrey
 wrote:
> I have been the Yocto Project community manager for over 7 years now, and 
> have had the pleasure of knowing or conversing individually with several 
> hundred of you. It is with mixed feelings that I must announce that I am 
> stepping down from my position as the YP community manager and the Advisory 
> Board chair after 7 years, as I am taking on a new role in my job.
>
> I am very proud of the progress that the project has made, growing from a 
> small set of build tools into an industry standard for building and working 
> with embedded Linux-based operating systems, supporting upstream projects 
> including the Linux kernel, hosting projects like opkg, and inspiring many 
> very successful downstream projects, including AGL and OpenBMC among many 
> others, and also supporting countless configurations of hardware among seven 
> different architectures. We have also seen the community of users grow from 
> fewer than 1000 in 2010 to a large city-sized community, estimated in the 
> tens of thousands of developers.
>
> Please continue to participate, collaborate, and come together as a 
> community! The Yocto Project is a success because every one of you 
> participates.
>
> Jeffrey "Jefro" Osier-Mixon, Intel Corporation
> Open Source Community Ecosystem Strategist
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Are Windows SDKs (mingw layer) supposed to work?

[Reyna, David]

Hi all,

I am trying to enable a customer for using YP SDKs on Windows. It apparently is 
supposed to work, but I am unable to get past fatal errors.

I have looked for documentation at the YP site and the meta-mingw repo, but to 
no avail.

1) My project is a simple default "qemux86-64" with YP-2.5 HEAD, with the 
latest "meta-mingw" layer added and .

The SDK builds fine and I get the "*.xz" generated file.

2) However, when I use 7ZIP to extract it on my Windows host (which is 
recommended for XY files), I get several fatal issues.

  (a) I get more than a hundred errors "Can not create symbolic link: Access is 
denied".

While I do not care about the ones for the bin tools in the sysroot, I do care 
that most of the cross toolchain EXE files are thusly broken, plus many of the 
libraries and header files in the sysroot.

Am I missing a step?

If I in fact extract this file on my Linux host, I can directly see that it is 
full of symlinks! Why are there symlinks in a Windows-specific tarball?

  (b) If I attempt to build a simple C file from the shell in the SDK 
environment, I either get a silent failure (for the 32-bit toolchain) or a 
blatant error as per:

  x86_64-poky-linux-gcc: error: CreateProcess: No such file or directory

I am assuming this error arises from the broken symlinks, specifically all 
those broken files in:

  SDKDIR\sysroots\i686-pokysdk-mingw32\usr\bin\x86_64-poky-linux-gnux32 (all 
zero length):
03/04/2018  08:29 PM 0 x86_64-poky-linux-gnux32-addr2line.exe
03/04/2018  08:29 PM 0 x86_64-poky-linux-gnux32-ar.exe
03/04/2018  08:29 PM 0 x86_64-poky-linux-gnux32-as.exe
03/04/2018  08:29 PM 0 x86_64-poky-linux-gnux32-c++.exe
03/04/2018  08:29 PM 0 x86_64-poky-linux-gnux32-c++filt.exe
03/04/2018  08:29 PM 0 x86_64-poky-linux-gnux32-cpp.exe
03/04/2018  08:29 PM 0 x86_64-poky-linux-gnux32-elfedit.exe
03/04/2018  08:29 PM 0 x86_64-poky-linux-gnux32-g++.exe
03/04/2018  08:29 PM 0 x86_64-poky-linux-gnux32-gcc-ar.exe
...

  
SDKDIR\sysroots\i686-pokysdk-mingw32\usr\libexec\x86_64-poky-linux\gcc\x86_64-poky-linux\7.3.0\*
03/04/2018  08:29 PM 0 ar.exe
03/04/2018  08:29 PM 0 as.exe
02/23/2018  03:48 PM21,962,568 cc1.exe
02/23/2018  03:48 PM23,256,499 cc1plus.exe
02/23/2018  03:48 PM   812,905 collect2.exe
03/04/2018  08:29 PM 0 cpp.exe
03/04/2018  08:29 PM 0 gcc.exe
03/04/2018  08:29 PM 0 ld.exe
02/23/2018  03:48 PM 1,101,508 lto-wrapper.exe
03/04/2018  08:29 PM 0 nm.exe
03/04/2018  08:29 PM 0 objcopy.exe
03/04/2018  08:29 PM 0 objdump.exe
03/04/2018  08:29 PM 0 ranlib.exe
03/04/2018  08:29 PM 0 real-ld.exe
03/04/2018  08:29 PM 0 strip.exe

3) I have done '-v' and ProcessMonitor tracing, and it all seems to come down 
to these broken links.

4) I see that Yang Wang had the same question (below), and I have not seen an 
answer.

Please help,
David Reyna


From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Wang, Yang Y
Sent: Thursday, August 17, 2017 11:41 PM
To: Yocto
Subject: [yocto] toolchain from meta-mingw gets error x86_64-poky-linux-gcc: 
error: CreateProcess: No such file or directory

I'm using Yocto krogoth and meta-mingw to build the meta-toolchain for windows 
system. The build is quite smooth.
I extract the built toolchain 
poky-glibc-x86_64-meta-toolchain-core2-64-toolchain-2.1.tar.xz on windows to 
c:/yocto2.1
However when I try to run a simple build from windows cmd console after I set 
up the environment-setup-core2-64-poky-linux.bat, I got the following error.
By further check, it seems the error is related to the symbolic link in folder 
sysroots/x86_64-pokysdk-mingw32/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/5.3.0/
 where the as, ar etc binutiles are the symbolic link to the file in -> 
../../../../../bin/x86_64-poky-linux/
However on windows, such "../../" symbolic link can't work. Simply execute the 
symbolic 'as.exe' will get error "Access is denied."

Anyone has the idea on how to solve this issue?

c:\Yocto2.1>%CC% c:/temp/temp/temp/test.c
x86_64-poky-linux-gcc: error: CreateProcess: No such file or directory

c:\Yocto2.1>%CC% c:/temp/temp/temp/test.c --verbose
Using built-in specs.
COLLECT_GCC=x86_64-poky-linux-gcc
COLLECT_LTO_WRAPPER=c:/yocto2.1/sysroots/x86_64-pokysdk-mingw32/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/5.3.0/lto-wrapper.exe
Target: x86_64-poky-linux

GNU C11 (GCC) version 5.3.0 (x86_64-poky-linux)
compiled by GNU C version 5.3.0, GMP version 6.1.0, MPFR version 3.1.3, 
MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable c

Re: [yocto] Are Windows SDKs (mingw layer) supposed to work?

[Reyna, David]

Hi Mark and Ross,

> Ross: Have you tried using 2.4 to identify when it broke?

I will try 2.4 and see if it is different.

> Mark: In the past 7ZIP (when not the admin) would create either copies or 
> 'shortcuts' instead of actual symbolic links.  

I will look to see if there is a new setting in 7ZIP.

> Mark: What version of windows are you using?  

I am using Windows 7.

Thanks,
David

-Original Message-
From: Mark Hatle [mailto:mark.ha...@windriver.com] 
Sent: Tuesday, March 06, 2018 5:40 AM
To: BURTON, ROSS; Reyna, David
Cc: Yocto; WANG, YANG
Subject: Re: Are Windows SDKs (mingw layer) supposed to work?

On 3/6/18 4:39 AM, Burton, Ross wrote:
> Have you tried using 2.4 to identify when it broke?  Clearly we need 
> to extend the selftest so the mingw SDK is actually tested...
> 
> Ross
> 
> On 6 March 2018 at 05:32, Reyna, David  <mailto:david.re...@windriver.com>> wrote:
> 
> Hi all,
> 
> __ __
> 
> I am trying to enable a customer for using YP SDKs on Windows. It 
> apparently
> is supposed to work, but I am unable to get past fatal errors.
> 
> __ __
> 
> I have looked for documentation at the YP site and the meta-mingw repo, 
> but
> to no avail.
> 
> __ __
> 
> 1) My project is a simple default “qemux86-64” with YP-2.5 HEAD, with the
> latest “meta-mingw” layer added and  "i686-mingw32">.
> 
> __ __
> 
> The SDK builds fine and I get the “*.xz” generated file.

The output format from the Yocto Project of a tarball has been that way since 
the beginning.  We (WR) had code that would produce a zip format, but that 
stopped working a few releases ago when the archive chaining was reworked..

We've not yet resurrected the code for the .zip generation but probably will in 
the next few months.

> __ __
> 
> 2) However, when I use 7ZIP to extract it on my Windows host (which is
> recommended for XY files), I get several fatal issues.
> 
> __ __
> 
>   (a) I get more than a hundred errors “Can not create symbolic link: 
> Access
> is denied”. 

This is odd.  In the past 7ZIP (when not the admin) would create either copies 
or 'shortcuts' instead of actual symbolic links.  It sounds like something has 
changed in 7zip.

> __ __
> 
> While I do not care about the ones for the bin tools in the sysroot, I do
> care that most of the cross toolchain EXE files are thusly broken, plus 
> many
> of the libraries and header files in the sysroot.
> 
> __ __
> 
> Am I missing a step?
> 
> __ __
> 
> If I in fact extract this file on my Linux host, I can directly see that 
> it
> is full of symlinks! Why are there symlinks in a Windows-specific 
> tarball?

Often I've extracted it on a linux machine, and then uses zip to recompress it.
(You still need to use 7zip to extract because of the long pathnames that blow 
up winzip.)

> __ __
> 
>   (b) If I attempt to build a simple C file from the shell in the SDK
> environment, I either get a silent failure (for the 32-bit toolchain) or a
> blatant error as per:

What version of windows are you using?  The last time I tested this (Rocko) it 
was working properly still, but I tested with Win 7.  So it's possible that 
something more recent has broken it.

I'm not sure if I'll have time today to retry this with Rocko, but I'll see if 
I can.

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

Re: [yocto] Are Windows SDKs (mingw layer) supposed to work?

[Reyna, David]

Ok, I have it working now.

The problem appears to be that 7ZIP treats "*.xz" files differently than 
"*.zip" files, specifically in the area of translating symlinks. I am using 
version 16.00, 64-bit, 2016-05-10.

With the ZIP file I did get an error about replacing 
"corei7-64-poky-linux\usr\include\linux\netfilter\xt_mark.h" with 
"...\xt_MARK.h" so the upper/lower case problem still arises just as it did 
with the XZ file, but I got ZERO errors about "symbolic links" and that makes 
all the difference.

This is the workflow that worked:

  1) Create the Windows SDK as per normal
  2) Extract the resulting "*.xz" file on your Linux host
  3) Re-package it with ZIP
  4) Extract that file on your Windows host with 7ZIP
  5) Open a Windows shell, start the environment, and build away

Linux:
  $ mkdir sdk_mingw; cd sdk_mingw
  $ unxz -d 
tmp/deploy/sdk/poky-glibc-i686-core-image-minimal-corei7-64-toolchain-2.4+snapshot.tar.xz
  $ cd ..
  $ zip -r 
poky-glibc-i686-core-image-minimal-corei7-64-toolchain-2.4+snapshot.zip 
sdk_mingw/

- David

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Reyna, David
Sent: Tuesday, March 06, 2018 8:00 AM
To: Hatle, Mark; BURTON, ROSS
Cc: Yocto
Subject: Re: [yocto] Are Windows SDKs (mingw layer) supposed to work?

Hi Mark and Ross,

> Ross: Have you tried using 2.4 to identify when it broke?

I will try 2.4 and see if it is different.

> Mark: In the past 7ZIP (when not the admin) would create either copies or 
> 'shortcuts' instead of actual symbolic links.  

I will look to see if there is a new setting in 7ZIP.

> Mark: What version of windows are you using?  

I am using Windows 7.

Thanks,
David

-Original Message-
From: Mark Hatle [mailto:mark.ha...@windriver.com]
Sent: Tuesday, March 06, 2018 5:40 AM
To: BURTON, ROSS; Reyna, David
Cc: Yocto; WANG, YANG
Subject: Re: Are Windows SDKs (mingw layer) supposed to work?

On 3/6/18 4:39 AM, Burton, Ross wrote:
> Have you tried using 2.4 to identify when it broke?  Clearly we need 
> to extend the selftest so the mingw SDK is actually tested...
> 
> Ross
> 
> On 6 March 2018 at 05:32, Reyna, David  <mailto:david.re...@windriver.com>> wrote:
> 
> Hi all,
> 
> __ __
> 
> I am trying to enable a customer for using YP SDKs on Windows. It 
> apparently
> is supposed to work, but I am unable to get past fatal errors.
> 
> __ __
> 
> I have looked for documentation at the YP site and the meta-mingw repo, 
> but
> to no avail.
> 
> __ __
> 
> 1) My project is a simple default “qemux86-64” with YP-2.5 HEAD, with the
> latest “meta-mingw” layer added and  "i686-mingw32">.
> 
> __ __
> 
> The SDK builds fine and I get the “*.xz” generated file.

The output format from the Yocto Project of a tarball has been that way since 
the beginning.  We (WR) had code that would produce a zip format, but that 
stopped working a few releases ago when the archive chaining was reworked..

We've not yet resurrected the code for the .zip generation but probably will in 
the next few months.

> __ __
> 
> 2) However, when I use 7ZIP to extract it on my Windows host (which is
> recommended for XY files), I get several fatal issues.
> 
> __ __
> 
>   (a) I get more than a hundred errors “Can not create symbolic link: 
> Access
> is denied”. 

This is odd.  In the past 7ZIP (when not the admin) would create either copies 
or 'shortcuts' instead of actual symbolic links.  It sounds like something has 
changed in 7zip.

> __ __
> 
> While I do not care about the ones for the bin tools in the sysroot, I do
> care that most of the cross toolchain EXE files are thusly broken, plus 
> many
> of the libraries and header files in the sysroot.
> 
> __ __
> 
> Am I missing a step?
> 
> __ __
> 
> If I in fact extract this file on my Linux host, I can directly see that 
> it
> is full of symlinks! Why are there symlinks in a Windows-specific 
> tarball?

Often I've extracted it on a linux machine, and then uses zip to recompress it.
(You still need to use 7zip to extract because of the long pathnames that blow 
up winzip.)

> __ __
> 
>   (b) If I attempt to build a simple C file from the shell in the SDK
> environment, I either get a silent failure (for the 32-bit toolchain) or a
> blatant error as per:

What version of windows are you using?  The last time I tested this (Rocko) it 
was working properly still, but I tested with Win 7.  So it's possible that 
something more recent has broken it.

I'm not su

Re: [yocto] Are Windows SDKs (mingw layer) supposed to work?

[Reyna, David]

I am going to slightly amend my comments.

1) When you extract the XZ file you get a TAR. It is when you then extract the 
TAR that you get all the symlink errors.

2) If you run 7ZIP in Administrator mode then you do _not_ get the syslink 
access errors, but apparently neither can you build C applications 
("...gcc/i686-poky-linux/7.2.0/real-ld.exe: cannot find -lgcc").

I would explore further but I think that ZIP files are the only safe way to do 
this, especially since you can avoid Windows Admin mode.

- David

-Original Message-----
From: Reyna, David 
Sent: Tuesday, March 06, 2018 12:55 PM
To: Reyna, David; Hatle, Mark; BURTON, ROSS
Cc: Yocto
Subject: RE: Are Windows SDKs (mingw layer) supposed to work?

Ok, I have it working now.

The problem appears to be that 7ZIP treats "*.xz" files differently than 
"*.zip" files, specifically in the area of translating symlinks. I am using 
version 16.00, 64-bit, 2016-05-10.

With the ZIP file I did get an error about replacing 
"corei7-64-poky-linux\usr\include\linux\netfilter\xt_mark.h" with 
"...\xt_MARK.h" so the upper/lower case problem still arises just as it did 
with the XZ file, but I got ZERO errors about "symbolic links" and that makes 
all the difference.

This is the workflow that worked:

  1) Create the Windows SDK as per normal
  2) Extract the resulting "*.xz" file on your Linux host
  3) Re-package it with ZIP
  4) Extract that file on your Windows host with 7ZIP
  5) Open a Windows shell, start the environment, and build away

Linux:
  $ mkdir sdk_mingw; cd sdk_mingw
  $ unxz -d 
tmp/deploy/sdk/poky-glibc-i686-core-image-minimal-corei7-64-toolchain-2.4+snapshot.tar.xz
  $ cd ..
  $ zip -r 
poky-glibc-i686-core-image-minimal-corei7-64-toolchain-2.4+snapshot.zip 
sdk_mingw/

- David

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Reyna, David
Sent: Tuesday, March 06, 2018 8:00 AM
To: Hatle, Mark; BURTON, ROSS
Cc: Yocto
Subject: Re: [yocto] Are Windows SDKs (mingw layer) supposed to work?

Hi Mark and Ross,

> Ross: Have you tried using 2.4 to identify when it broke?

I will try 2.4 and see if it is different.

> Mark: In the past 7ZIP (when not the admin) would create either copies or 
> 'shortcuts' instead of actual symbolic links.  

I will look to see if there is a new setting in 7ZIP.

> Mark: What version of windows are you using?  

I am using Windows 7.

Thanks,
David

-Original Message-
From: Mark Hatle [mailto:mark.ha...@windriver.com]
Sent: Tuesday, March 06, 2018 5:40 AM
To: BURTON, ROSS; Reyna, David
Cc: Yocto; WANG, YANG
Subject: Re: Are Windows SDKs (mingw layer) supposed to work?

On 3/6/18 4:39 AM, Burton, Ross wrote:
> Have you tried using 2.4 to identify when it broke?  Clearly we need 
> to extend the selftest so the mingw SDK is actually tested...
> 
> Ross
> 
> On 6 March 2018 at 05:32, Reyna, David  <mailto:david.re...@windriver.com>> wrote:
> 
> Hi all,
> 
> __ __
> 
> I am trying to enable a customer for using YP SDKs on Windows. It 
> apparently
> is supposed to work, but I am unable to get past fatal errors.
> 
> __ __
> 
> I have looked for documentation at the YP site and the meta-mingw repo, 
> but
> to no avail.
> 
> __ __
> 
> 1) My project is a simple default “qemux86-64” with YP-2.5 HEAD, with the
> latest “meta-mingw” layer added and  "i686-mingw32">.
> 
> __ __
> 
> The SDK builds fine and I get the “*.xz” generated file.

The output format from the Yocto Project of a tarball has been that way since 
the beginning.  We (WR) had code that would produce a zip format, but that 
stopped working a few releases ago when the archive chaining was reworked..

We've not yet resurrected the code for the .zip generation but probably will in 
the next few months.

> __ __
> 
> 2) However, when I use 7ZIP to extract it on my Windows host (which is
> recommended for XY files), I get several fatal issues.
> 
> __ __
> 
>   (a) I get more than a hundred errors “Can not create symbolic link: 
> Access
> is denied”. 

This is odd.  In the past 7ZIP (when not the admin) would create either copies 
or 'shortcuts' instead of actual symbolic links.  It sounds like something has 
changed in 7zip.

> __ __
> 
> While I do not care about the ones for the bin tools in the sysroot, I do
> care that most of the cross toolchain EXE files are thusly broken, plus 
> many
> of the libraries and header files in the sysroot.
> 
> __ __
> 
> Am I missing a step?
> 
> __ __
> 
> If I in fact extract this file on my Linux host, 

Re: [yocto] toaster

[Reyna, David]

Hi Matthias,

I am sorry I did not see your post sooner. The Toaster group generally follows 
the "toas...@yoctoproject.org" email list.

We fully intend to support mariadb as a production level database, especially 
given its open source credentials, but we have not tried it yet.

We understood that mariadb was supposed to be an exact drop-in replacement, but 
obvious your experience is different. Our experience was just with MySQL.

I will try to gather advice from our various users to see if we can help you in 
the meantime.

- David
 

 Forwarded Message 
Subject: [yocto] toaster
Date: Tue, 21 Feb 2017 17:33:08 +
From: Dr. Matthias Schöpfer 
To: yocto@yoctoproject.org 

Hello!

First of all, I have been working with yocto/oe for some time now and
enjoy and appreciate it very much!

I have a question regarding toaster in a "Production Instance" Setup. I
have tried to set toaster up on Ubuntu 16.04 following the
http://www.yoctoproject.org/docs/2.2/toaster-manual/toaster-manual.html
and ran into a bunch of problems. I have been able to resolve some, but
now I am at a point where I doubt that this setup can work at all, so
please correct me if I am wrong.

 From the top of my head, these where the troubles I had:

* there were Issues using mariadb instead of mysql.

* the |mod-wsgi |that comes with Ubuntu 16.04 has a bug that does not
allow to concatenate python-path with colon, so Update to Version >=4.5
was needed

* The line  ./bitbake/lib/toaster/manage.py checksettings will ask for
the path to the openembedded meta...

* I am not sure if TOASTER_CONF is used, at least, the toaterconf.json
and what I get on the webserver do not match.

* Finally, and this is the point where I doubt that this setup can work
at all as described: When trying to run a build, I get an Internal
Server Error, which boils down that $BUILDDIR is not set for environment
apache runs in. If I hardcode that, I get of course the error on the
signal, that permission is denied, because the runbuilds-service is run
as toaster user while apache runs as www-data user.

Therefore: Is anyone running toaster in this setup?! Should I abandon
this setup?

Thanks in advance!

Regards,

 Matthias



i.A. Dr.-Ing. Matthias Schöpfer  |  ithinx GmbH  |  Software Engineer
Phone: +49 (221) 99589-332  |  Fax: +49 (221) 99589-199
Address: ithinx GmbH  |  Butzweilerhof Allee 4  |  50829 Cologne  |  Germany
E-Mail: matthias.schoep...@i-thinx.com  |  Website: www.i-thinx.com
Registered Office: Cologne  |  District court: Marburg  |  HRB 6749
Managing Director: Christian Faust

This e-mail may contain confidential and/or privileged information. if you are 
not the intended recipient (or have received this e-mail in error) please
notifiy the sender immediately and destroy this e-mail. Any unautohrized 
copying, disclosure or distribution of the material in this e-mail is strictly 
forbidden.

We like trees. Please consider the environment before printing this e-mail. 
Thank you.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] MINUTES: Yocto Project 2.8 Planning Meeting 5/7/2019

[Reyna, David]

Yocto Project 2.8 Planning Meeting
MINUTES: 5/7/2019

Attendees: Richard, Armin, Joshua, Bruce, Michael, Randy, Josha Watt, 
Alejandro, Dustin Bain, Zach Booth, Tracey, Ross, Michael H, Tim, Vineela, 
David Reyna, Trevor

RP: Need to add milestones
RP: Need to set up 2.8 schedule page (as per 2.7)
RP: Most design items now have Bugzilla numbers (at least the ones for RP). 
Other should add create/their Bugzilla entries as well
RP: From triage meeting, observed that many things missing owners, specifically 
PatchTest (Django/Python) and PatchWorks 
(https://github.com/getpatchwork/patchwork) . This issue will be taken to the 
Advisory Board.
Randy: TImeline for Governing Board? RP: probably will fall to just 
prioritizing, especially PatchTest and Reproducible Builds (via automation 
tests)  needed for YP promotion
RP: Looking for ideas. Khem is handling GCC9, Armin is LTP, RP is PTest
GENERAL: list of proposals looks good
Randy: rank the proposals? RP: best done in Bugzilla
Randy: containerization status? Bruce: Bugzilla items created, must be careful 
because most popular tools bring in hundreds of non-build-related dependencies, 
will document and point people to meta-virtualization
Tim: “meta-virtualization” versus “meta-cloud”? Bruce, mostly moving to  
“meta-virtualization”, specifically some cloud recipes are being adopted there
Trevor: Refresh ARM status? Bruce: this is moving to a more modern reference 
board, newer than Beaglebone, closer to mainline kernel, hopefully ARM-64 at 
some point
Michael: newer machines coming on-line soon, but probably not have newer GPUs 
for QEMU acceleration, perhaps that can be addressed at refresh
Vineela (new Release Engineering): 2.8 starting? RP: yes, normal milestones, 
2.7.1 hopefully by end of May, 2.5 over unless huge problem/CVE
Vineela: place for test reports? RP: yes planning new git repo

AR: RP: Need to set up 2.8 schedule page with milestones (as per 2.7)
AR: RP to move these monthly meets back to normal tech calls
AR: RP et. al. to new git repo for merged test results (YP, Intel, Wind River, 
…)
AR: ALL to create Bugzilla entries for their 2.8 items
AR: David to post minutes (DONE)


-Original Appointment-
From: theyoctoproj...@gmail.com [mailto:theyoctoproj...@gmail.com]
Sent: Tuesday, May 29, 2018 10:59 AM
To: theyoctoproj...@gmail.com; JOLLEY, STEPHEN; yocto@yoctoproject.org
Subject: [yocto] Updated invitation: Yocto Project Technical Team Meeting @ 
Monthly from 8am to 8:30am on the first Tuesday (PDT) (yocto@yoctoproject.org)
When: Tuesday, May 07, 2019 8:00 AM-8:30 AM (UTC-08:00) Pacific Time (US & 
Canada).
Where: Zoom Meeting: https://zoom.us/j/990892712


This event has been changed.
more details 
»

Yocto Project Technical Team Meeting
When
Monthly from 8am to 8:30am on the first Tuesday Pacific Time

Where
Zoom Meeting: https://zoom.us/j/990892712 
(map)

Calendar
yocto@yoctoproject.org

Who
•
theyoctoproj...@gmail.com - organizer

•
stephen.k.jol...@intel.com

•
yocto@yoctoproject.org



Changed: We encourage people attending the meeting to logon and announce 
themselves on the Yocto Project IRC chancel during the meeting (optional):

Yocto IRC: 
http://webchat.freenode.net/?channels=#yocto

Wiki: 
https://www.yoctoproject.org/public-virtual-meetings/

Bridge is with Zoom at: 
https://zoom.us/j/990892712
Going?   All events in this series:   
Yes
 - 
Maybe
 - 
No
more option

[yocto] Minutes: Yocto Project Technical Team Meeting 6/4/2019

[Reyna, David]

Yocto Project Technical Team Meeting
MINUTES: 6/4/2019

Attendees: Richard, Armin, JoshuaW, Bruce, Michael, Randy, Scott, Alejandro, 
RobW, Ross, MichaelH, Tim, Vineela, David, Trevor, Sajal

RP:
  * YP-2.6 M1 for this coming Monday
  * ptest dependencies are improving, and we are getting better results
  * M1 at risk for patchtest, RP and Paul are working on it
  * Key change for M1 is GCC9, and we working on a few regressions
  * Need people to work on the NEWCOMER defects
  * Joshua is working on the autobuilder
  * Randy: Kevin will be pinged on the QEMU issue (PPC?)

Armin: Fedora Core 30 for M!? RP: we could add workers today to test that host. 
RP: FYI, we did get funding for updated build servers.

Armin: Question about “xe” support, issue with supporting two tarball 
compressions. Evidently some hosts, and especially some containers, do not have 
an tar that supports –J (specifically Thud) or do not have “xe”. RP mentions 
that the Thud documentation does require “xe”.

Randy: PTest improvements a priority for M2? RP: GCC9, bluez, and acl 
priorities for fixing.

Scott: Any specific help he can provide 2.8? There was mention of SPDX headers 
done but not licenses, more ptest, ARM autobuilder.

RP: Want to achieve for 2.8:
  * Ptest
  * License
  * reproducibility
  * hash equivalency important, needs updates to runqueue to implement,

Hash equivalency only as good as builds are reproducible. Mention that simple 
changes to perl rdepends can have a deep cascade effect. The feature needs to 
look at what changed, know that nothing really changed, and then substitute 
same hash and save un-needed rebuild. For example “perl-native’ rebuilds, look 
to see that it is binary equivalent (bit by bit). Another more flexible (but 
probably later) technique could be elf symbol comparison for equivalency. RP: 
goal is to make the checker pluggable so that enhancements are easy. Richard 
mentioned that it might be worth taking a month off of his daily merge tasks 
just to get this feature done.

Randy: Is there idle time we can use? Perhaps in some timezone like China? RP: 
usually fires off builds at end of his day, so not real idle timezone.

RP: can use help in getting pull requests together

RP: Automated tests, provable reproducible builds important to our upstream 
cred.

Scott: Meta-agl-v2? It has become hard to maintain, stale dependencies, no 
security patching, obsolete components.

RP: anything we are missing? Randy touched on Rust. RP: nice for 2.9, but 
reproducibility more important.

Tim: Meta-virtualization into core? Perhaps for 2.9. Meta-python? Split off V2 
support to separate repo.

- David


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

[yocto] Minutes: Yocto Project Engineering Sync, 7/09/2019

[Reyna, David]

Minutes: Yocto Project Engineering Sync
When: Tuesday, July 09, 2019 8:00 AM-9:00 AM 1.
Attending: Richard, Armin, Michael, David, Trevor, Tim, Vineela, Bruce

* Richard: General notes
  - Status report was sent last night: 
https://lists.yoctoproject.org/pipermail/yocto/2019-July/045968.html

  - Richard got work done on the runqueue changes (to run setscene and normal 
tasks in parallel)
  - Autobuilder still has NFS issues
  - 2.7.1 is now out of QA and waiting for TSC to approve for release, pending 
review of a ptest issue.
* Vineela: Ok to publish test report? Richard: yes.

  - Nathan posted a patch of test suites for the toolchain components 
(binutils/gcc/glibc). Good mailing list discussion.



* Richard: question to David about effect on Toaster for setscene events in 
parallel and thus somewhat out of order (e.g. effect on progress bar). David: 
probably no problem since Toaster just gathers the events (and progress is 
progress), will review the update.



* Michael: updated firewall, installed Debian Time (sp?).



* Tim: email transition? Michael: need to update list and resubmit, will get 
update on timeframe.



* Armin: posted security patch for Patchworks - who will receive it and apply 
it? Michael: ok with Django change. Michael went ahead and tested the patch 
during the call, and got support to post the update to the repo.



* Richard: mentioned that Sandy from WR is working on getting up to speed on 
PatchTest, but realized that she may not be also covering PatchWorks. We need 
to review how PatchWorks has diverged from the community.



* Tim: concerned about patches from Martin that dropping rdepends for Perl in 
core might affect native Perl, and concerned about potential broader scope of 
the issues/changes across Perl. Richard noted that (a) native Perl not split 
like target Perl is, (b) there is an open bug about the whole issue plus Ross 
is also concerned, and that (c) the big problem is that to fix it we probable 
need to change "PN-native" to "native-PN". Tim posted this link that may show 
unexpected target rdepends contamination on native Perl:



  
https://git.openembedded.org/meta-openembedded-contrib/commit/?h=jansa/warrior&id=d98e62e64219b365063fdb299d35f2af999d8f6e

* Richard: had sync meeting last week while North America was on vacation. 
Short meeting, no minutes.

* Tim: Khem travelling and patches are backing up. Richard: Khem should be back 
next week and will address queue. Discussion whether Tim as maintainer of Perl 
should go ahead and push patches himself to help relieve queue.

- David

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

[yocto] Minutes: Yocto Project Monthly Meeting 7/16/2019

[Reyna, David]

Yocto Project Monthly Meeting
MINUTES: 7/16/2019

Attendees: Richard, Armin, JoshuaW, Bruce, Michael,  Frederic, Tim, Vineela, 
David, Trevor

RP:
  * Status update will go out later today: 
https://lists.yoctoproject.org/pipermail/yocto/2019-July/046042.html
  * Richard will not be at ELC San Diego (limited conference budget)

Tim: Python 3.4 is on Debian 8, wants to move YP to Python 3.5 as minimum

Armin: Will we move to Kernel 5.2? Bruce: we will follow the published YP 
policy on kernel updates.  LTS release timing has been close and/or after YP 
release dates so will probably miss again this year. The version is usually 
picked after Linux Plumbers.

Armin: LSB versus LTS? Richard: there are two tests, (a) Poky LSB and (b) 
Kernel X.Y, and we propose to drop the Poky LSB test.

Bruce: Kernel 5.3 will not be ready for our release, so probably 5.2 will be 
the number.

Richard: considering to number YP release as 3.0 instead of 2.8, because of 
many changes (especially runqueue). Tim noted also the major transition to 
Python 3, and Michael noted we did a similar jump for YP-2.0. Question: will 
there be a functional change with this numbering transition? Richard: no.

Richard: question to Joshua about hash state equivalency? Runqueue could 
support it. Joshua: currently there are issues in the persistent state. 
Richard: would like this feature for 3.0, and are there any implications? 
Joshua: cannot complete this and reproducibility by himself. Richard: might 
help with this effort since these changes can “put us on the map”.

Trevor: will move to hash equivalency reduce runqueue time? Richard: potential 
gains. Even local set can receive a huge speed gain, for example a 
non-impacting change to “core-native” would no longer trigger unneeded global 
rebuilding.

Trevor: LSB removal. LTP like LSB? Richard: LTP supported, LSB dead.

Michael: Mailing list transition still in progress. Lists will become 
“list.project.org”.

Joshua: Zoom links for this meeting are wrong. Michael: there are several links 
for this time slot for the two overlapping meetings. Will try to consolidate on 
the more popular link (or may cancel both and create a new one). Will also need 
to update Google Calendar.

- David


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

[yocto] Minutes: Yocto Project Monthly Meeting 7/23/2019

[Reyna, David]

Yocto Project Monthly Meeting
MINUTES: 7/23/2019

Attendees: Richard, JoshuaW, Bruce, Tim, Vineela, David, Trevor, Jan-Simon (at 
end)

Note: consolidated bridge for Tuesday meetings: https://zoom.us/j/990892712

RP:
  * Weekly status update will go out later today
  * 2.7.1 out last week
  * 2.6.3. due out Wednesday
  * Autobuilder performance issues finally found and fixed
  * Some issues with default poky init system (sysv vs. system)

Richard: Runqueue optimizations appear to be working, though some performance 
issues (sometimes 3 minute break for calculations). Example of feature, if 
“m4-native” has change but do_populate_sstate same then sstate left the same 
and no cascade of rebuilds to rest of packages. Richard quite excited about 
this, especially having this early in the development cycle.

Joshua: What about non-local implementations? Richard: focusing on local hash 
state equivalency first. Good step towards reproducibility. Next would then be 
non-local support. Goal is less duplicated in sstate-caches, which will help 
with sstate-cache mirrors. Joshua: would appear that non-local users would 
still need the sstate and database together.

Richard: runqueue api clunky in that it supports multiple tasked formats. Would 
like to consolidate them but that would require a “flag day” for everyone to 
make the transition.

Richard: changes could run against earlier releases like Warrior/Thud with 
minor patches if we would want to do so.

Bruce: 5.3 kernel dropped, so he is busy with that.

- David


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

[yocto] Minutes: Yocto Project Weekly Meeting 7/30/2019

[Reyna, David]

Yocto Project Weekly Meeting
MINUTES: 7/30/2019

Attendees: Richard, Michael, JoshuaW, Ross, Tim, David, Trevor, Jan-Simon

Note: consolidated bridge for Tuesday meetings: https://zoom.us/j/990892712

Richard:
  * Weekly status update will go out later today
  * 2.8 (3.0) M2 sent to QA
  * 2.6.3. ready to build, then QA
  * The Technical Steering Committee (TSC) updated their Wiki mission page 
(https://wiki.yoctoproject.org/wiki/TSC), stressing that they are the committee 
of last resort.
  * Mentioned again the YP-2.8 will be renamed as YP-3.0. Michael noted that we 
need to change the hold release “2.99” to “3.99”.
  * With working with the optimization patches, may want to break/cleanup API, 
specifically around task naming (e.g. array, filename-XXX, filename:XXX)
  * Hash equivalency work is breaking the eSDK. Joshua offered to help, noted 
that they do not use the eSDK and therefore had not tested against it.
  * Linux Foundation has launched a New Community Bridge 
(https://www.linuxfoundation.org/press-release/2019/03/the-linux-foundation-launches-new-communitybridge-platform-to-help-sustain-open-source-communities/).
 Nico has forwarded this to the YP community to encourage mentors/mentees.
  * We are slightly behind schedule for M2, but wanted to get the runqueue 
patches in and part of the QA

Joshua: Reproducible builds, wants to know why simple class is different. Ross 
will ping Juro. Richard recalls the more complex class was to get sensible 
dates, and it has been working very well to date (with a few exceptions), and 
there may be a bug in the reproducibility build class. Richard is aiming for 
reproducibility build tests, and these builds are the builds to prove it [to us 
and to the general community].

Joshua: RSS (?) versus host tools. There are issues, for example perl-native 
man pages can get different dates in the text depending if it is pulled from 
host or cache. We should review host tools versus native tools. Richard: 
specifically host tools to build native and then native to build target, and 
there should never be docs built for native.

Richard: Goal for YP-3.0 reproducibility. Joshua: is there something on 
autobuilder yet?

Richard: Running more Autobuilder full builds as opposed to quick builds to 
help flush out issues with recent big changes (e.g. runqueue). Full builds 1-3 
times a weeks, cover pTest/LTP/build stats for x64 and arm64.

Tim: working with data analytics team in Intel, analyzing QA logs. Poses 
question to group: “what questions do we want to answer from the data?”. This 
will help guide the effort to extract meaningful results. Richard: noted that 
build performance is in a different database than what they are looking at 
right now.

Tim: Ported Autobuilder to Intel. Will update the wiki with learned lessons 
(e.g. local layers). Discovered that putting the sstats-cache on an NFS server 
brought the system to a crawl, was considering SSHFS. Local builds fast, but 
cache not shared. Richard noted the issue is that git does a lock on repos 
during check, and is slow/blocking especially for repos with long history. 
There was a fix/alternate process where the build is local and then the results 
copied to shared cache. Will provide patch to Tim, this is simpler that SSHFS. 
Noted that the Autobuilder was designed against YP’s build cluster. Tim noted 
that all the work on shared-caches over the years really helps.

Trevor: happy but curious why YP finally adopted “gsock”? Richard: still has 
concerns but will give it a go,  community and general experience has moved 
forward significantly over time, plus the fact it is LF project. We do need 
people to pick this up (not RP).

Tim: for community bridge topic, notes that care should be taken in choosing 
mentees: some become long term contributors, some never execute. Asked if there 
was any funding for mentees? Richard: there is some matching funds from LF 
especially for the underserved, also could get some support from YP sponsors. 
Trevor gave kudos to Xlinx.

- David


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

[yocto] Minutes: Yocto Project Technical Team Meeting, 8/6/2019

[Reyna, David]

Minutes: Yocto Project Technical Team Meeting
When: Tuesday, August 09, 2019 8:00 AM-9:00 AM 1.
Attending: Richard, Armin, Michael, David, TrevorW, Tim, Vineela, Stephen, 
Randy, Joshua, Alex Kanavin, Jan-Simon, TrevorG, Ross, Alejandro, Tracy

* Stephen: General notes
  - M2 in final review
  - M3 making good progress
  - 2.6.3 QA, release next day
  - The 2.8 will become 3.0



* Richard: General notes

  - Hash Equivalency/runqueue merged this morning. The UI progress output a 
little different, may be confusing. Joshua: is this on autobuilder? Richard: 
not yet.

  - Spent a lot of time on runqueue. Trying to keep up with pseudo changes.

  - There is still a locale issue, not fixed. Probably easy once we figure it 
out.



* David: will Hash Equivalency/runqueue affect the documentation? Richard: no, 
it should be all be in the background. However, the UI progress output was 
setscene with a normal progress progression and then the real tasks would 
start. Now, as hash equivalencies are discovered, "setscene done" messages 
appear, which can happen several times over the processing. The progress bars 
are thus not as linear as before, but Richard want to leave it verbose so that 
any issues can be debugged before tuning the messages down.


* Armin: back from vacation, back on stable releases. Richard handled the 
stable releases in the meantime.

* Richard: 3 defects from QA from M2. Marked as blocking for M3.

* Question: plan for Rust? Randy: there has been interest over time, he will 
make and share a plan (probably in August).

* Xilinx: how to manage "meta-jupyter"? Richard: best as separate repo/layer 
rather than trying to merge it into core. Notes that some people complain about 
too many layers, but this is more a tools issue, and separate layers in general 
allow more focused maintainer-ship and growth.

* Xilinx: What about npm, devtool support? Richard: no good solution yet, no 
tests in autobuilder. Current bitbake model is one recipe per package, but npm 
is organized to have 1000+ 'packages' which is impractical for each to have a 
recipe. There was some devtool support, but may not be current.

Randy: automation can help with npm package management, but does not want npm 
manager on target.

Richard: difficult to give up control to outside manager like npm. Alejandro: 
npm starts to download its own toolchain, and we lose reproducibility. Npm for 
YP did have changes to reduce that outside behavior, not sure current state,  
concerned that Rust will have similar problem (Tim: as does Go).

Tim: Node is in core, but not tests. Issus around npm dependencies.

Alejandro: Python update cadence per release, but node changes much faster. 
Richard: use the snapshot model, where we capture logical and stable package 
sets, especially for Python and here npm. Joshua: image containers for node.js? 
Richard: that just moves the goal post, the snapshot captures "our part".

FYI: See "node.js" presentation with devtool from DevDay 2017: 
https://wiki.yoctoproject.org/wiki/File:Ypdd-2017.02-ELC-Portland.pdf

* Question: Twitch stream? Richard: conflicts with this meeting. Presentations 
are captured to YouTube, where they are getting additional views. These 
presentations focus more on new developers.

* Vineela: will release number change (3.0) affect the Poky release number? 
Richard: no, and he is not sure what uses that number anymore.

* Richard: thanks to David for supporting the meeting minutes in Stephen's 
absence.

- David

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

[yocto] Minutes: Yocto Project Technical Team Meeting, 8/27/2019

[Reyna, David]

Minutes: Yocto Project Technical Team Meeting
When: Tuesday, August 27, 2019 8:00 AM-9:00 AM 1.
Attending: Richard, Armin, Michael, David, TrevorW, Tim, Vineela,  Randy, 
Joshua, Manju, Alex Kanavin, Scott, TrevorG, Bruce


* Richard: General notes

  - Just sent weekly update "[OE-core] Yocto Project Status WW35'19"

  - M3 is over, we are now in feature freeze for M4

  - Patch merge in progress, backlog for M3

  - Systemd (as default) versus SysVinit still in progress

  - Removal of LSB, test builder not set up yet

  - Many patches for hash equivalency

  - Joshua has many patches for reproducible builds (tested without sstate), 
problems with existing sstate. Richard: always build from scratch.



* Manju: status of patch set for devtool? Richard is reviewing them.



* AR: Triage Team: provide list of respective bugs to Xilinx for review



* Manju: Is WIC the only way to create images to SD Card? Richard: WIC is 
preferred - any errors in WIC should be filed as defects. Manju: ramfs 
preparation has race condition. Scott: meta-raspberrypi did use "mkimg" but now 
has WIC support.



* Manju: Status of Nathan's patches? Richard needs time to review them.



* Scott: The 2.8 list versus Python2 status? Notes that python2 goes 
unsupported this December. Richard: people currently treating this as a low 
priority (but will probably heighten when we get closer). Bruce has patch set 
for the perf/kernel, and this will be a big step forward to removing Python2. 
Richard: someone should do a scan on the remaining Python2 usage. Question: 
libftd? Richard: no, low priority. High priority are target tools over 
host/build tools.



* Bruce: will send 5.2 kernel and libc headers. Will check default BSPs.



* Richard: will need to merge each patch set in isolation given the number of 
merge failures he has been encountering.



* Manju: Is there a way to choose system versus SysVinit? Richard: yes there is 
an init manager variable that you can set. We are not dropping SysVinit but 
switch to system as default. Poky-init, poky-alternate. Richard: 4 different 
variants - tiny/busybox/..., system size constraints.



Notes from ELC BOF:



* Joshua: a lot of people want an LTS. Armin: specifically they like CVEs 
applied/backported to stable branches. Richard: people want no changes but all 
the features. Joshua: LTS to help convince silicon vendors to stabilize on 
releases (e.g. kernel has LTS releases). Richard: kernel has 4 releases a year 
where YP has two, so cadence is good. We could do a major/minor release 
designation but then which release gets which designation? Manju: mostly 
looking for CVE patches for last 2-3 years. Khem's general answer was to "send 
patches", not just let other people do the work.



* David: Questions about low activity on the security mailing list. Richard: 
most CVE patches are managed via normal patches. Armin: the person was looking 
for a security team. Tim: is he volunteering? Richard: we do fix the important 
stuff. David will follow up on team question.



* Manju: has a sstate-cache paper, covering their 600 gbyte sstate-cache. 
Richard: excellent paper for ELCE YP summit.



* Richard out next Tuesday. Stephen still out next week.


- David

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

[yocto] Minutes: Yocto Project Technical Team Meeting, 9/3/2019

[Reyna, David]

Minutes: Yocto Project Technical Team Meeting
When: Tuesday, September 3, 2019 8:00 AM-9:00 AM 1.
Attending: Richard, Armin, Michael, David, Trevor, Randy, Joshua, Alex Kanavin, 
Scott, Jean-Simon, Tim, Vineela, Denys, Zach Booth, Dustin Bain, Bruce


* Richard: General notes

  - Still building M3
  - 5.2 Kernel recipes
  - Still problem that 5.2 kernel is not default for QEMU
  - LSB removal done
  - Still performance issue with Hash Equivalency
  - Hash Equivalency server issues
  - Toolchain patch set soon
  - Autobuilder issues (QEMU MIPS, memory problem?)
  - Python2 removal great progress, not yet uboot nor host tools (which affects 
self-hosted targets)
  - Reproducible builds: fixed rebuild issue. Joshua: cannot always rely on 
clean sstate. Richard: people who use this will know this limitation and know 
to force clean builds.

* Armin: will there be 2 GCCs in Zeus (as there was in Warrior)? Richard would 
prefer to delete older GCC, was reluctantly talked out of that for Warrior.

* Randy: few weeks left for M3, one month for M4, release October.

* Randy: now that we are in M4 feature freeze, are package updates actually 
frozen? Richard: hard because he does not want the distractions, but hard to 
put off the submitted patches (not want to lose momentum nor make submitters 
anxious) even though they will not merge until YP-3.1.

* Joshua, Update on PatchTest/PatchChecker status? Richard: great progress and 
things generally working thanks to Sandy, but she may not realize that she is 
effectively the maintainer. Does not look forward for when we upgrade these 
systems and she comes to us all for help. Question about additional servers for 
these tools. Richard said that we need to be careful of Michael's time.

* Armin: Was the new mailing list serve actually deployed yesterday? Richard: 
still in progress, announcement soon.

* Randy: mentioned that he was making progress with "meta-rust", not yet 
building out of the box.

* Tim: 5.4 probably the next LTS kernel. Announcement waiting for 5.3 release 
(and probably Plumbers meeting).

* Scott: upgrade to system 2.4.3? Richard: too much of a change at this time. 
(https://github.com/systemd/systemd/blob/master/NEWS)

* Randy: Planning for 3.1? Richard: TSC put together details on technical paths 
and options, for example:
  - Layer setup
  - LTS
  - Binary distributions

* Trevor: asked about listening in on TSC meetings? Richard: those meetings are 
very focused and time bound. This Technical Team meeting is the better forum 
for such discussions.

* Randy: "meta-virtualization" layer is coming in

* David: pending AR on informing Xilinx on their bugs? Richard: Done.

- David

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

[yocto] Minutes: Yocto Project Technical Team Meeting, 9/10/2019

[Reyna, David]

Minutes: Yocto Project Technical Team Meeting
When: Tuesday, September 10, 2019 8:00 AM-9:00 AM 1.
Attending: Richard, Armin, Michael, David, Trevor,  Joshua, Henrik, Scott, 
Jan-Simon, Tim, Vineela, Stephen, Khem


* Richard: General notes

  - Not built M3 yet, progress being made, anticipated for next week

  - Hash Equivalency issues. API valid but need different way to create hashes. 
Richard has patch to reduce hash creation by one half.

  - Toolchain test quite merged

  - QEMU systemd still has issues

  - Alex looking at pTest timeouts

  - Richard out the rest of this week

* Joshua: Hash Equivalency being investigated to replace very slow REST 
interface with streaming model (5x faster), requires Python 3.5 or later, patch 
next Monday
* Richard: Task migration, merge pending

* Trevor: Will Hash Equivalency be on by default? Richard: no, too close to 
release, maybe for YP-3.1.

* Scott: Has systemd 2.5.3 running - is it too late? Richard: send patches to 
be tested, will see. Scott: should he look at the QEMU MIPS issue since it is 
systemd related? Richard: could fix that issue.

* Richard: Poky LSB is now Poky Alt config, used systemd, revealed QEMU MIPS 
defect.

* Richard: Systemtap patches sent upstream. Dropped 8 patches being carried.

* Richard: Reproducible builds, new baseline tests, good feature and PR for YP

* Richard: YP-3.1 planning. All please add ideas to Bugzilla.

* Michael: Mailing list moving next weekend, Mailman to Group I/O, new links 
being sent out. David:  what about people who use old links? Michael: those 
will be re-directed for a while. Armin:  Redo passwords? Michael: transfer 
should be automatic, otherwise simple ask for new passwords using the automated 
system

* Richard: Scott Rifenbark will be away for a while. We need help updating 
documentation. Updating the Testing/QA docs will probably be delayed.

- David

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

[yocto] Minutes: Yocto Project Technical Team Meeting, 9/17/2019

[Reyna, David]

Minutes: Yocto Project Technical Team Meeting
When: Tuesday, September 17, 2019 8:00 AM-9:00 AM 1.
Attending: Richard, Armin, Michael, David, Trevor,  TrevorG, Joshua, Scott, 
Jan-Simon, Tim, Vineela, Stephen, Khem, Ross, Tom Hochstein


* Stephen/Richard: General notes

  - Project status sent 
(http://lists.openembedded.org/pipermail/openembedded-core/2019-September/287038.html)

  - Not built M3 yet, three issues remain

  - Strace/ptest issues due to recent kernels (Alex has patch)

  - Systemd patch merged

  - QEMU MIPS appears to be regenerating hardware database everywhere (30-40 
seconds on QEMU MIPS), leading to timeouts. Scott will take a look. Looks to be 
faulty code.



* Joshua: Hash Equivalency server update. Richard: will schedule on Autobuilder



* Richard: who knows how docs get published to the website? Answer: Michael, 
Tracy, and Vineela



* David: who has experience with cve-checker? Answer: check with commit log 
(e.g. Pierre Le Magourou)



* Richard: Hash Equivalency users? Should be easy to enable. None on this call. 
"local.conf" settings send to IRC:

BB_SIGNATURE_HANDLER = "OEEquivHash"

BB_HASHSERVE = "auto"

* Armin: his toolchain group runs tests in different ways, would like to 
consolidate on new toolchain tests, can that be wrapped as a layer for easy 
consumption across releases? Richard: hard given all that it touches, but will 
look.

* Tim: IBM open sourced MIPS. Perhaps new org (Weave Computing?) would consider 
YP membership?

* Scott: Pulse Audio update. Richard: no new features at point.

* Joshua: can provide help getting Hash Equivalency up on Autobuilder

* Richard: touched on scope of ptest execution (1M mark?)

https://autobuilder.yocto.io/pub/non-release/20190916-9/testresults/testresult-report.txt

* Michael: mail list transition still under test

* Vineela: can help with doc publishing

- David

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

[yocto] Minutes: Yocto Project Technical Team Meeting, 9/24/2019

[Reyna, David]

Minutes: Yocto Project Technical Team Meeting
When: Tuesday, September 24, 2019 8:00 AM-9:00 AM 1.
Attending: Richard, Armin, David, TrevorG, Joshua, Tim, Vineela, Stephen, 
Denys, Bruce, Randy


* Stephen/Richard: General notes

  - Project status sent 
(http://lists.openembedded.org/pipermail/openembedded-core/2019-September/287297.html)

  - Built M3, QA this week, looks good, three issues have fixes or workarounds

  - Still Hash Equivalency server issues

  - Sstate growth issues

  - Would like to get back on schedule with M4 next week

  - Would like release around 25 October timeframe



* Vineela: LSB artifacts? Richard: concern about build re-names, does not want 
to break Warrior with renamed build scripts.



*Hash Equivalency server update. Richard: found many fixes. Fundamental issue 
around re-running sstate tasks if re-hashing. First answer was "yes", but now 
trying "no" because it behaves better.



Joshua: problem for example around relating to do_pack and do_fetch, skipped by 
set_scene, but then missing do_populate_license information.



Richard: Build cannot go backwards. Currently main queue already past (skipped) 
set_scene task. We could delay runqueue until all dependencies resolved, or 
re-execute skipped tasks. This would of course mess with the task count and 
build determinacy goes "out the window", as well as the risk of touching 
runqueue.



Richard: current plan is to "not rerun tasks", fix other issues, then come back 
to this problem.



* Richard: eSDK failures ow found regularly by build servers, but not on 
Richard's local host. Meta data is not matching expected values, so we are 
looking at the hashes. Devtool with unlocked task hash is misbehaving.



* Denys: M3 = strace and system timeout workarounds.

* Richard: Sumo issues hard to keep up to date with current staffing levels.

* Richard: call out for people to help with performance issues.

- David

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