Re: [yocto] Yocto Project Status WW09'19

[akuster]

On 2/26/19 7:58 AM, sjolley.yp...@gmail.com wrote:
>
> Current Dev Position: YP 2.7 M3 (New feature Freeze has begun.)
>
> Next Deadline: YP 2.7 M3 Cutoff was Feb. 25, 2019
>
>  
>
> SWAT Team Rotation:
>
>   * SWAT lead is currently: Ross
>   * SWAT team rotation: Ross -> Chen on Mar. 1, 2019
>   * SWAT team rotation: Chen -> Armin on Mar. 8, 2019
>
I am going to be at LS on Monday March 10th and traveling on March 13. 
If this may be an issue, maybe rescheduling for a different week may be
in order.
I personal don't this there will be an issue.

>  *
>
>
>   * https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
>
>  
>
> Key Status/Updates:
>
>   * We have now passed the feature freeze point for 2.7
>   * YP 2.7 M2 rc2 is out of QA and being readied for release.  See:
> 
> https://wiki.yoctoproject.org/wiki/WW07_-_2019-02-14_-_Full_Test_Cycle_2.7_M2_RC2
> and
> 
> https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.7_Status#Milestone_2_-_Target_Feb._1.2C_2019
>   * We now have resulttool, buildhistory and build-performance all
> working with the autobuilder and will be using this as the primary
> QA mechanism going forward. More details can be found here:
>
> http://lists.openembedded.org/pipermail/openembedded-architecture/2019-February/001591.html
>
>   * There were some serious usability issues found with multiconfig,
> those have been fixed in master and thud.
>   * Various recipe upgrades made it in, thanks to all who contributed.
> Several recipes also converted to meson including glib-2.0 and
> gdk-pixbuf.
>   * We now need to build M3 as we’re past feature freeze point for
> 2.7. Right now we’re aware of the following things which ideally
> need to be resolved first:
>   o Bug 13178 “X server and matchbox desktop don't start up
> properly on beaglebone” needs to be fixed
>
a patch was sent and  is in master.
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=4860914b3b5b38926ed6a80bb83a011d341ff2d8


- armin
>
>  o
>   o Find the framebuffer problem with qemuarmv7 and switch to that
>   o Several ptest issues would be addressed (missing openssl
> tests, 3 timeouts)
>   o Arm build host issues identified and resolved
>   * It’s unlikely we’ll switch to virtgl by default for 2.7 due to
> lack of testing from the community although the base patches for
> this have merged.
>
>  
>
> Planned Releases for YP 2.7:
>
>   * YP 2.7 M2 rc2 is out of QA.
>   * YP 2.7 M2 Release Target was Feb. 1, 2019
>   * YP 2.7 M3 Cutoff is Feb. 25, 2019
>   * YP 2.7 M3 Release Target is Mar. 8, 2019
>   * YP 2.7 M4 Cutoff is Apr. 1, 2019
>   * YP 2.7 M4 Release Target is Apr. 26, 2019
>
>  
>
> Planned upcoming dot releases:
>
>   * YP 2.5.3 (Sumo) will be targeted after YP 2.7 M2 is done.
>   * YP 2.5.4 (Sumo) will be targeted after YP 2.7 M4 is done.
>   * YP 2.6.2 (Thud) will be targeted after YP 2.5.4 is done.
>
>  
>
> Tracking Metrics:
>
>   * WDD 2415 (last week
> 2392)(https://wiki.yoctoproject.org/charts/combo.html)
>   * Poky Patch Metrics  
>   o Total patches found: 1516 (last week 1527)
>   o Patches in the Pending State: 660 (44%) [last week 663 (43%)]
>
>  
>
> Key Status Links for YP:
>
> https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.7_Status
>
> https://wiki.yoctoproject.org/wiki/Yocto_2.7_Schedule
>
> https://wiki.yoctoproject.org/wiki/Yocto_2.7_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 Program Manager*
>
> (    *Cell*:    (208) 244-4460
>
> * *Email*:  _sjolley.yp...@gmail.com
> _
>
>  
>
>

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

Re: [yocto] Removing busybox

[Randy MacLeod]

On 2/27/19 9:19 PM, Adrian Bunk wrote:

On Wed, Feb 27, 2019 at 11:59:42PM +, Burton, Ross wrote:

On Wed, 27 Feb 2019 at 23:55, Tom Rini  wrote:

My current incomplete list is:
 bind-utils \
 bridge-utils \
 coreutils \
 dnsmasq \
 e2fsprogs \
 e2fsprogs-resize2fs \
 e2fsprogs-tune2fs \
 findutils \
 gawk \
 grep \
 inetutils-ping \
 inetutils-ping6 \
 inetutils-traceroute \
 iproute2 \
 less \
 net-tools \
 parted \
 pciutils \
 procps \
 sed \
 util-linux \
 vim \
 which \

And it's also incomplete as there's more stuff under inetutils I don't
need (but others may), and I set aside patch/diff/ed and some other
stuff I don't need.  And since some of that stuff comes from
meta-openembedded, it's indeed really not clear how/where a packagegroup
would reside as we need things out of meta-networking.


That's a good start.  For a oe-core packagegroup


Rather than just a single list per layer, we could do
something similar to:

https://github.com/WindRiver-Labs/wrlinux/blob/WRLINUX_10_17_BASE/wrlinux-distro/recipes-base/images/wrlinux-image-glibc-core.bb

where we defined an image called 'glibc-core' that tries to be a
close to a minimal set of discrete apps needed to boot to a
command line. Then we provide 10+ package groups that added a (mostly!)
logical set of packages that provide groups of functionality.
The groups and not perfect of course but the ones that we came up
with 5+ years ago are:

https://github.com/WindRiver-Labs/wrlinux/tree/WRLINUX_10_18_BASE/wrlinux-distro/recipes-base/packagegroups


For qemux86-64, our images (years old data) vary from:

Image NameSize (MB)Comment
======
glibc-tiny   6+Trimmed down glibc/busybox/minimal init
glibc-small 50 A standard busybox with sysvint, rsyslog
glibc-core  65 A minimal non-busybox image with
   sysvinit, rsyslog
glibc-std  350 A more complete non-busybox image with
   packages that are present for
   historical reasons.

We also have a WR specific template scheme that lets users add
blocks of functionality (single or multiple packages, kernel configs)
to the images above. I think MarkH has explained that to people before.

Anyway, I'm certainly not suggesting that Yocto would want to
adopt any of this directly but rather I'm just trying to give
an impression of what we use and find useful when contructing 
non-busybox based images. I could revisit the Wind River image

definitions and see if the lists we came up with years ago
could be tweaked, renamed and added to oe-core and meta-oe
to share this approach with other Yocto developers and users for
the an upcoming release, maybe even for 2.8 if people are interested.

I guess the question is if we want to spend time coming to an agreement 
on, testing and maintain these package groups and if they would

really be useful to users since, historically at least, people
who create images tend to be domain experts who can easily write
their own packagegroup file.

../Randy



I do not think a core-only packagegroup makes sense when the goal is to
completely replace busybox (and not just most apps while keeping a few
busybox apps installed).


I'd suggest dropping
dnsmasq bridgeutils bindutils to keep it lean.


The stated usecases are not "lean" but "replace all busybox commands
with the full versions".

For that you need bind-utils (in oe-core) for DNS lookup.


...
Also swap vim for something in core obviously.


It is not obvious how to do that.

What other vi implementation is in core?
Is there even any good non-busybox non-GUI editor in core?
Replacing busybox vi with ed would be a bad fit for the
stated usecases.

There has to be some vi implementation installed,
and the "desktop command" implementation is vim.


Ross


cu
Adrian




--
# Randy MacLeod
# Wind River Linux
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto