[yocto] Yocto Project Status WW23’17

[Jolley, Stephen K]

Current Dev Position: Preparing for YP 2.4 M1

Next Deadline: YP 2.4 M1 Cut off is June 12, 2017


SWAT team rotation: Anibal -> Todor on June 2, 2017.

SWAT team rotation: Todor -> Alejandro on June 9, 2017.

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


Key Status/Updates:

·Morty YP 2.2.2 is due out of QA imminently. QA report so far is 
available at: https://wiki.yoctoproject.org/wiki/2.2_QA_Status#Summary_Report

·There are a couple of issues there which may mean we respin YP 2.2.2 
(Morty) and take it to an rc2.

·Krogoth YP(2.1.3) builds remain broken for no-x11 and musl.

·pyro 2.3.1 CVE backport work is still remaining.

·oe-selftest and rpm performance improvements aren’t quite ready yet 
and pending revised patches.

·A stable maintainer for the pyro series needs to be appointed. Armin 
has offered but has already taken on a number of releases. If anyone else is 
interested, please talk to Richard.


Planned upcoming dot releases:

YP 2.1.3 Cut off May 22, 2017 - Running late due to issues.

YP 2.1.3 Release by June 3, 2017

YP 2.3.1 Cut off May 30, 2017 - Running late due to issues.

YP 2.3.1 Release by June 9, 2017

YP 2.2.2 Cut off June 5, 2017 - Put into QA early.

YP 2.2.2 Release by June, 16 2017

YP 2.3.2 Cut off Aug 7, 2017

YP 2.3.2 Release by Aug. 18, 2017


Key YP 2.4 Dates are:

YP 2.4 M1 Cut off is June 12, 2017

YP 2.4 M1 Release by June 23, 2017

YP 2.4 M2 Cut off is July 17, 2017

YP 2.4 M2 Release by July 28, 2017

YP 2.4 M3 Cut off is Aug. 21, 2017

YP 2.4 M3 Release by Sept. 1, 2017

YP 2.4 M4 (Final) Cut off is Sept. 18, 2017

YP 2.4 M4 (Final) Release by Oct. 20, 2017


Tracking Metrics:

WDD 2793 (last week 2797)

(https://wiki.yoctoproject.org/charts/combo.html)


Key Status Links for YP:

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

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

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

[If anyone has suggestions for other information you’d like to see on this 
weekly status update, let us know!]

Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
•   Work Telephone:(503) 712-0534
•Cell:   (208) 244-4460
• Email:stephen.k.jol...@intel.com

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

Re: [yocto] Yocto for NFS/SDN networking product

[Kosta Zertsekel]

Khem,


Fully agree that Yocto has is good, 'cause it supports cross-build, has a wide

industry support and actually it has **the version** (meaning, all the packages

are taken with specific git commit id unlike debian/ubuntu binaries).


But then, I'm confused in the other respect...


I'm looking at the OpenSwitch build system (part of Open Compute project

under Linux Foundation) and I see that is uses yocto as a subsystem. It's really

confusing because yocto is supposed to have "meta-XYZ" for OpenSwitch

support.


So, when choosing a build system for OpenSwitch-based products - do one

still has to use yocto or just go with the build system provided by OpenSwitch?


Thanks,

--- KostaZ


From: Khem Raj 
Sent: Sunday, January 31, 2016 5:56 PM
To: Kosta Zertsekel
Cc: yocto@yoctoproject.org; Ran Wainstein
Subject: Re: [yocto] Yocto for NFS/SDN networking product

Kosta

Yocto project is developed by many volunteers and people sponsored by 
corporations,
all development happens in opensource. The community supports the project. There
are also lot of commercial OS vendors which use Yocto project to build their 
products,
so you can always go to them if you are looking for commercial support.

For advantages, it can build a small footprint since it builds bottom up. So 
you can really get only needed
packages for your custom image. It will create a source based distribution for 
you where you have control
over every part of the OSS stack. You can really tailor your solution to your 
needs.

It builds in cross-build environment, supports many CPU architectures and 
machines

The community is very welcoming and helpful. You can easily contribute to the 
project
and fulfill your needs by doing so. The learning curve might be a bit steeper. 
But then
you do have trainings available offerred by professionals.

Thanks
-Khem
On Sun, Jan 31, 2016 at 4:22 AM, Kosta Zertsekel 
mailto:kzertse...@mrv.com>> wrote:

Hi dear Yocto community,


I'm trying to evaluate Yocto as the candidate to create Linux distro

for NFS/SDN networking product. Through Google I get an impression

that there is a race between Yocto, CentOS (RedHat) and 6WIND

Linux distributions to get most of NFV/SDN Linux distro market.


Can you please help to find cons and pros of using Yocto for

NFV/SDN networking product?


I google over NFV/SDN part of www.etsi.org but couldn't 
make up

my mind what specific distro got the traction.


I see that Yocto has NFV/SDN layers 
(reference):

```
git clone 
git://git.yoctoproject.org/meta-cloud-services
git clone 
git://git.openembedded.org/meta-openembedded
git clone --branch icehouse 
git://git.yoctoproject.org/meta-virtualization
git clone 
git://git.openembedded.org/openembedded-core
 oe-core
```


Are these layers officially supported by Intel?

Does Intel provide the NFV/SDN support?


Thanks,

--- KostaZ

[E-Banner]


MRV Communications is a global supplier of packet and optical solutions that 
power the world’s largest networks. Our products combine innovative hardware 
with intelligent software to make networks smarter, faster and more efficient.



The contents of this message, together with any attachments, are intended only 
for the use of the person(s) to whom they are addressed and may contain 
confidential and/or privileged information. If you are not the intended 
recipient, immediately advise the sender, delete this message and any 
attachments and note that any distribution, or copying of this message, or any 
attachment, is prohibited.

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


[http://50.57.127.206/images/Banner.jpg]


MRV Communications is a global supplier of packet and optical solutions that 
power the world’s largest networks. Our products combine innovative hardware 
with intelligent software to make networks smarter, faster and more efficient.



The contents of this message, together with any attachments, are intended only 
for the use of the person(s) to whom they are addressed and may contain 
confidential and/or privileged information. If you are not the intended 
recipient, immediately advise the sender, delete this message and any 
attachments and note that any distribution, or copying of this message, or any 
attachment, is prohibited.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Reminder: Yocto Project Technical Team Meeting - Tuesday, June 6, 2017 8:00 AM US Pacific Time

[Jolley, Stephen K]

Tuesday, June 6, 2017 8:00 AM US Pacific Time



Agenda:



* Opens collection - 5 min (Stephen)

* Yocto Project status - 5 min (Stephen/team)

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

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

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

* Opens - 10 min

* Team Sharing - 10 min



We encourage people attending the meeting to logon the Yocto Project IRC 
channel during the meeting (optional):



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

IRC Tutorial: http://www.irchelp.org/irchelp/irctutorial.html


Conference Details:
Company:   WIND RIVER SYS

- dial into: 1-800-262-0778/404-397-1527

- enter the bridge number: 88748961#


For International numbers see: 
https://www.yoctoproject.org/tools-resources/community/monthly-technical-call


Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
*   Work Telephone:(503) 712-0534
*Cell:  (208) 244-4460
* Email:
stephen.k.jol...@intel.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Why can't I install eudev-hwdb

[Alejandro del Castillo]

On 06/04/2017 12:30 AM, Gary Thomas wrote:
>> Which version of opkg are you using? do you have the libsolv backend
>> enabled? running opkg --version should tell you the opkg version and the
>> libsolv version, if the backend is enabled.
> 
> # opkg --version
> opkg version 0.3.4 (libsolv 0.6.27)
> 
> Built using poky:master (a3d160f9e5826140cc8d6b2ed1b38bf022443b08)
> 
>>
>> Also, could you send a verbose log of the installation? opkg install -V4
>> . While you are at it, it would be helpful to attach your
>> /var/lib/opkg/status file too.
>>
> Attached.  This looks like good information - opkd thinks that eudev-hwdb
> is in a strange (to me) state of 'deinstall hold not-installed'

Indeed. The BAD_RECOMMENDATONS for eudev-hwdb directly hacks into the
status file and sets the package status to 'deinstall hold
not-installed'. That works if the opkg internal solver is being used,
but fails with libsolv. This bug is already being tracked [1].

We need to get the root issue fixed, but for now, as a workaround you
could revert 1ff3de844c78e3766c7f92ca17c308ef3c9427e1 and use the
internal solver.

Ross: I added some thoughts to a possible solution into the bugzilla ticket


[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=11427

-- 
Cheers,

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

[yocto] QA Test Report for Yocto Project Point Release 2.2.2. rc1

[Cruz, Libertad]

Hello All,



Here is the report for the 2.2.2 rc1 full point release test cycle.



Full Report : 
https://wiki.yoctoproject.org/wiki/WW22_-_2017-06-05_-_Full_Point_Release_Test_Cycle_2.2.2_rc1





 Summary 



The QA cycle for release 2.2.2 rc1 is complete, there were 6 new issues.

Two of this are related  to testimage, one to compliance test, one to 
self-test, one to OE-Core and finally "11604 [Yocto 2.2.2] crosstap doesn't 
work" [1] this is a recurring issue that has been fixed on 10990[9]. Also the 
bugs 5948[10], 6016[11], 6118[12], 6122[13]  are just a few that have been 
marked duplicated of 10990[9].



Performance metrics showed a 16% improvement on Ubuntu machine, Fedora machine 
showed an improvement of 9%.





 Details 



QA Hints



QA test cycle seems to have been executed smoothly no apparent blockers or high 
priority bugs.  It would be worthwhile that before deciding if this build can 
be release, the following bugs have been reviewed and assigned priority 
11611[4], 11607[3], 11604[1], 11606[6]. We are concern about the recurring 
issue on Crosstap not working, not sure if there can be a strategy so that this 
issue is fixed on all environments. Even though it seems that 11604[1] is not a 
blocker it does require reporting, retesting and development analysis time 
whenever its present.





Bugs

  * New



   - Bug 11598 
- [morty]testimage quemux86-64 lsb genericx86-64 getty[1309]: tcgetattr: 
Input/output error^M[2]

   - Bug 11604 
- [Yocto 2.2.2] crosstap doesn't work[1]

   - Bug 11607 
- [morty] Testimage lsb image trow multiple smart errors[3]

   - Bug 11611 
- [morty] Compliance test lsb-setup-4.1.0-1.noarch.rpm download fail[4]

   - Bug 11565 
- morty self-test errors[5]

   - Bug 11606 
- [morty] OE-Core test_recipetool_create 
(oeqa.selftest.recipetool.RecipetoolTests)[6]





  * High / M+ Not New



   - Bug 10456 
- X can not launch on qemumips64[7]

   - Bug 11064 
- [Yocto 2.2.1] kernel version mismatched when using yocto-bsp to create custom 
qemu bsp[8]



Full Bug Report : 
https://wiki.yoctoproject.org/wiki/WW22_-_2017-06-05_-_Full_Point_Release_Test_Cycle_2.2.2_rc1#Bugs_Found_during_QA_Test





== Performance ==



All performance metrics showed improvements on Ubuntu machine, exceling 16% on 
rootfs creation, Fedora machine showed an improvement of 9% on extracting eSDK 
the other metrics where on the same level compared to 2.2.1 release.





Ubuntu  Test  2.2.1_rc1 2.2.2_rc1 %

sato  1:02:41   1:00:42   -3.16

rootfs2:43  2:16  -16.56

rmwork1:01:13   0:59:29   -2.83

kernel5:05  5:01  -1.31

eSDK  3:28  3:22  -2.88



Fedora  Test  2.2.1_rc1 2.2.2_rc1 %

sato  1:00:26   1:00:43   0.47

rootfs2:18  2:16  -1.45

rmwork0:59:17   0:59:29   0.34

kernel5:22  5:01  -6.52

eSDK  3:42  3:22  -9.01







Performance Charts :  
https://wiki.yoctoproject.org/charts/perf_milestone_GDC/performance_test.html





 Links =



1.https://bugzilla.yoctoproject.org/show_bug.cgi?id=11604

2.https://bugzilla.yoctoproject.org/show_bug.cgi?id=11598

3.https://bugzilla.yoctoproject.org/show_bug.cgi?id=11607

4.https://bugzilla.yoctoproject.org/show_bug.cgi?id=11611

5.https://bugzilla.yoctoproject.org/show_bug.cgi?id=11565

6.https://bugzilla.yoctoproject.org/show_bug.cgi?id=11606

7.https://bugzilla.yoctoproject.org/show_bug.cgi?id=10456

8.https://bugzilla.yoctoproject.org/show_bug.cgi?id=11064

9.https://bugzilla.yoctoproject.org/show_bug.cgi?id=10990

10.https://bugzilla.yoctoproject.org/show_bug.cgi?id=5948

11.https://bugzilla.yoctoproject.org/show_bug.cgi?id=6016

12.https://bugzilla.yoctoproject.org/show_bug.cgi?id=6118

13.https://bugzilla.yoctoproject.org/show_bug.cgi?id=6122



Regards
Libertad G.

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

[yocto] First attempt at x32 system: kernel panic

[Paul D. DeRocco]

I took a functioning 32-bit x86 system built with Morty and successfully
converted it to 64-bit. Builds and runs fine. Next, I tried applying the
x32 tune, as described in the Yocto manual. I created another BSP layer,
changed all the names accordingly, set CONFIG_64BIT=y and CONFIG_X86_X32=y
in one of my .cfg files, set DEFAULTTUNE to "core2-64-x32", and set
baselib to the expression documented in the Yocto manual (which boils down
to "libx32"). It builds without complaint, but when I run it, I get a
kernel panic almost immediately.

The problem is that the kernel is being compiled as regular 64-bit code
while everything else is using the x32 tune as it should. The init program
is symlinked to systemd, which objdump shows as having an architecture of
i386:x64-32, while various object modules used to build the kernel show
i386:x86-64. Everything in /lib seems to be x64-32 except for the .ko
files in /lib/modules.

I thought perhaps the problem was that one of my .scc files specifies
KARCH as x86_64, which I used because "yocto-bsp list karch" only lists
that and i386 for this CPU. I guessed that there might be an x64_32
choice, and tried that, but it went ahead and built an x86_64 kernel again
without complaint. I also tried removing CONFIG_64BIT=y, with the same
result.

So why am I getting a 64-bit kernel without the x32 tune?

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com

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