[yocto] Preliminary QA cycle report for 2.5 M2 RC1

[Yeoh, Ee Peng]

Hello All,
This is the preliminary report for 2.5 M2 RC1 (while waiting for performance 
test data to be ready):  
https://wiki.yoctoproject.org/wiki/WW07_-_2018-02-14-_Full_Test_Cycle_-_2.5_M2_rc1

=== Summary 

The QA cycle for release 2.5 M2 RC1 was completed except performance test.  
Team had discovered a new bug [1] where sdk toolchain downloaded from Public 
Autobuilder failed when executing runqemu command.  

YP QA recently requested the performance host machines from linux foundation to 
replace old machines, where initial setup completed at WW06 and going through 
testing. Currently, running performance testing trial run to collect data. 
Expected data collection for regression and 2.5 M2 rc1 to be completed by 
WW08.1. 

=== QA-Hints

Waiting performance test data to be ready, the build is stable, need to fix the 
sdk toolchain bug in order to enable runqemu.

=== Bugs 

   New Bugs
    - 12545 [1] [2.5 M2 RC1] SDK runqemu failed with python import 
logging

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

Regards
Ee Peng 


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

[yocto] How did you separate release and development builds?

[Alan Martinovic]

Hi,
I'm assuming separating development and release builds
is a fairly common use case.
The release build would be something like:

- has all the funcions for production
- attack surface is limited (no ssh, only the required apps)
- config files set with real endpoints (logging or crash servers etc.)

But that's not an image you can really develop on given all the constrains.
So there is also a need for a development image:

- inherits the funcions available on production image
- developer convinence over security (debuggers, ssh access etc.)
- configs set not to depend on payed cloud services


Our curent approach is to solve this by having two different
image recipes.

Pros:
* Simple to implement (dev inherits production and just adds packages)
* You can build both at the same time with the same version

Cons:
* They have the same runtime name (cause they are the same distro)
* Separating config files is not yet clear
  (one way to have two versions of recipes, which was a lot of
duplication.
   Now we're chacking how to solve it by introducing external
templating (jinja))

How did you apprach it?
Would like to hear you ideas and from the field experiences.

Be Well,
Alan
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How did you separate release and development builds?

[Alex Kiernan]

On Wed, Feb 14, 2018 at 9:04 AM, Alan Martinovic
 wrote:
> Hi,
> I'm assuming separating development and release builds
> is a fairly common use case.
> The release build would be something like:
>
> - has all the funcions for production
> - attack surface is limited (no ssh, only the required apps)
> - config files set with real endpoints (logging or crash servers etc.)
>
> But that's not an image you can really develop on given all the constrains.
> So there is also a need for a development image:
>
> - inherits the funcions available on production image
> - developer convinence over security (debuggers, ssh access etc.)
> - configs set not to depend on payed cloud services
>
>
> Our curent approach is to solve this by having two different
> image recipes.
>
> Pros:
> * Simple to implement (dev inherits production and just adds packages)
> * You can build both at the same time with the same version
>
> Cons:
> * They have the same runtime name (cause they are the same distro)
> * Separating config files is not yet clear
>   (one way to have two versions of recipes, which was a lot of
> duplication.
>Now we're chacking how to solve it by introducing external templating
> (jinja))
>
> How did you apprach it?
> Would like to hear you ideas and from the field experiences.
>

The image-mode bbclass from Intel:

https://github.com/intel/intel-iot-refkit/blob/master/meta-refkit-core/classes/image-mode.bbclass

Then just add additional packages in your image recipe based on the
variant you're building.

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

Re: [yocto] useradd-example.bb

[Jeff Osier-Mixon]

Can anyone help Jean-Pierre? This seems at first like a simple issue during
do_populate.

On Tue, Feb 13, 2018 at 1:32 PM, Jean-Pierre Sainfeld 
wrote:

> Hi,
> I am working on yocto system at the jethro rev level.
> I am looking to use the meta-skeleton useradd-example.bb recipe
> So far I have been successful in adding the required users and group
> and creating files in the /usr/share directory
> The current issue I am facing is the ownership of the created file
> I see the right permissions at the do_install() time
> however when the image is loaded in the target
> those files are reverted to the root:root permissions
>
> The requirement of our platform is that we can create specific users and
> make some specific processes  and data files having the proper uid and
> ueid.
>
> I have been able to do all this successfully on the target
> but not through the yocto build system
>
> Any assistance in this regard would be fantastic and very cool :-)
>
>
>
> --
> Jean-Pierre Sainfeld
> 408-508-1741 <(408)%20508-1741>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>


-- 
Jeff Osier-Mixon - Open Source Community Manager, Intel Corporation
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] useradd-example.bb

[Mark Hatle]

On 2/14/18 2:57 PM, Jeff Osier-Mixon wrote:
> Can anyone help Jean-Pierre? This seems at first like a simple issue during
> do_populate.

Need more information.  Are you creating new users and putting files in those
user directories in /usr/share or elsewhere?

The /usr/share hierarchy is controlled by the system wide fs-perms.  Many of
it's standard subdirectories will globally set all subdirectories become
root:root 0755, while files become 0644 root:root.

See the fs-perms.txt file: meta/files/fs-perms.txt

Pay specific attention to the comment:

# Note: all standard config directories are automatically assigned "0755 root
root false - - -"

'standard config directories' refer to the following list:

(from classes/package.bbclass)
# By default all of the standard directories specified in
# bitbake.conf will get 0755 root:root.
target_path_vars = ['base_prefix',
'prefix',
'exec_prefix',
'base_bindir',
'base_sbindir',
'base_libdir',
'datadir',
'sysconfdir',
'servicedir',
'sharedstatedir',
'localstatedir',
'infodir',
'mandir',
'docdir',
'bindir',
'sbindir',
'libexecdir',
'libdir',
'includedir',
'oldincludedir' ]


> On Tue, Feb 13, 2018 at 1:32 PM, Jean-Pierre Sainfeld  > wrote:
> 
> Hi,
> I am working on yocto system at the jethro rev level. 
> I am looking to use the meta-skeleton useradd-example.bb
>  recipe
> So far I have been successful in adding the required users and group 
> and creating files in the /usr/share directory 
> The current issue I am facing is the ownership of the created file 
> I see the right permissions at the do_install() time 
> however when the image is loaded in the target 
> those files are reverted to the root:root permissions 
> 
> The requirement of our platform is that we can create specific users and 
> make some specific processes  and data files having the proper uid and 
> ueid.
> 
> I have been able to do all this successfully on the target 
> but not through the yocto build system 
> 
> Any assistance in this regard would be fantastic and very cool :-)
> 
> 
> 
> -- 
> Jean-Pierre Sainfeld
> 408-508-1741 
> 
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org 
> https://lists.yoctoproject.org/listinfo/yocto
> 
> 
> 
> 
> 
> -- 
> Jeff Osier-Mixon - Open Source Community Manager, Intel Corporation
> 
> 

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

Re: [yocto] useradd-example.bb

[Fred Ollinger]

How are you deploying the final image on your device?


From: yocto-boun...@yoctoproject.org  on behalf 
of Jean-Pierre Sainfeld 
Sent: Tuesday, February 13, 2018 1:32 PM
To: yocto@yoctoproject.org
Subject: [yocto] useradd-example.bb

Hi,
I am working on yocto system at the jethro rev level.
I am looking to use the meta-skeleton 
useradd-example.bb recipe
So far I have been successful in adding the required users and group
and creating files in the /usr/share directory
The current issue I am facing is the ownership of the created file
I see the right permissions at the do_install() time
however when the image is loaded in the target
those files are reverted to the root:root permissions

The requirement of our platform is that we can create specific users and
make some specific processes  and data files having the proper uid and ueid.

I have been able to do all this successfully on the target
but not through the yocto build system

Any assistance in this regard would be fantastic and very cool :-)



--
Jean-Pierre Sainfeld
408-508-1741
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Release Candidate Build for yocto-2.4.2.rc1 now available.

[pokybuild]

A release candidate build for yocto-2.4.2.rc1 is now available at:


https://autobuilder.yocto.io/pub/releases/yocto-2.4.2.rc1


Please begin QA on this build as soon as possible.


Build hash information: 
meta-intel : 5415ec29c7745fafb4b7311558d206f9c81fcae4 
meta-qt4 : f313dbee2ac3d5fcc9801407947d3cb6cfb90b5d 
meta-mingw : a2c5fb82e5595d5bb56b579b7c93147c4fb065a5 
meta-qt3 : f33b73a9563f2dfdfd0ee37b61d65d90197a456f 
meta-gplv2 : a0f8716d07324e945f0462b82f9309fa0934af17 
poky : 50189fdf620bc9ca42065998ce8c5a796ad8c331 


This is an automated message from
The Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder
Email: joshua.g.l...@intel.com 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto