OEDEM 2016

NOTE: for the OpenEmbedded General Assembly 2016, held the same day at the same location, see the page Berlin, 2016

Location and Time

Friday, October 14 2016
(after ELC-E [Oct 11-13])

Maritim Hotel - Berlin, Germany Stauffenbergstraße 26, 10785 Berlin

Salon 16

Start at 0900

Attendees

• Florin Sarbu "fsarbu"
• Andrei Gherzan "agherzan"
• Khem Raj "khem"
• Armin Kuster "Armpit"
• Marco Cavallini "mckoan"
• Pierre-Jean Texier "pjtexier"
• Koen Kooi "koen"
• Anders Darander
• Sean Hudson "darknighte"
• Changhyeok Bae "chbae"
• Peter Kjellerstedt "Saur"
• Josef Holzmayr "LetoThe2nd"
• Vicentiu Neagoe
• Nicolas Dechesne "ndec"
• Denys Dmytriyenko "denix"
• Philip Balister "Crofton"
• Jan Lübbe "shoragan"
• Enrico Jörns
• Jeff Osier-Mixon "Jefro"
• Andrea Galbusera "gizero"
• Richard Purdie "RP"
• Changhyeok bae "chbae"
• Scott Murray "smurray"
• Behan Webster "behanw"
• Jan-Simon Moeller "dl9pf" 11:30 - 12:45 only
• Bruce Ashfield "zediii"
• Marcin Juszkiewicz "hrw"
• Mark Hatle "fray"
• Rich Persaud
• Kristian Amlie "kamender"
• Marek Vasut
• Eystein Stenberg

NOTE: if you add your name to this list, please let me know at jefro@jefro.net, otherwise watch this space for a link to attend by phone

Agenda Items

OpenEmbedded eV General Assembly Berlin,_2016

1. LTS (group discussion)
2. Make perl and python distro features? [Saur] (small group)
3. Support for meson build system? [Saur] (small group)
4. Can devtool be made standalone, or how to use latest devtool with older version of OE? [Saur]
   1. Are we going to make large changes in next release? (group discussion)
5. Show off Wind River 'setup' tool (response to discussions from last year and this spring) [Fray] (group discussion)
6. Suggestion for improvement of how to handle site and user configuration. See explanation below. [Saur]
7. BSPs and layer name recommendations (try to start around 3pm to accommodate remote folks from the US) (group discussion)
8. Layer index (group discussion)
9. Yocto Project v2 compatibility (group discussion)
   1. https://github.com/dl9pf/BSP-LAYER_GUIDE
10. Make Mender, the OTA update framework, part of Yocto?
    1. Clarification: General discussion on OTA (group discussion)
11. The use of ${COREBASE}/LICENSE in LIC_FILES_CHKSUM. [Saur] (small group)
    1. Many references to ${COREBASE}/LICENSE causes requirement for inclusion
12. Discuss merging duplicate classes and recipes, (metadata) (small group )
13. Discussion on mesa and splitting libgbm (small group)

Site/user configuration

We would like to improve the possibilities for a developer to easily configure his/her environment to minimize the required changes that are needed after having sourced oe-init-build-env for a new build directory. Typically there are some options that must always be applied for all developers, e.g., proxy settings, and some that should be applied, e.g., locations of global download mirrors and sstate-caches. These typically belong in a site.conf file common to all developers. Then there are options that I as a developer always want as my defaults, e.g., how many bitbake threads and make processes to use in parallel, and to enable debug-tweaks and debug-tools by default. There is currently no suitable configuration file for these options.

To make it easier to configure these kind of static default options we suggest:

• That we add support for a new configuration file conf/user.conf that is included by bitbake.conf, e.g., after site.conf.
• Add a user specific directory to BBPATH by default, e.g., "${HOME}/.openembedded".
  • It is also suggested that the name of this directory is available as a variable set in bitbake.conf, e.g., "OE_USER_DIR", so that it can be used as a default location for, e.g., DL_DIR in one's user.conf file by setting DL_DIR = "${OE_USER_DIR}/downloads".
• Make it possible to inject directories into BBPATH via the environment, e.g., via a BBPATH_EXTRA variable. This can then be used to specify the common directory (e.g., NFS mount) where conf/site.conf can be found for all developers.

We have a similar solution in place today in our layers. But the drawback is that it is only supported when at least one of our own layers are included in the build, which means that if I, e.g., want to build with only Poky, it will not work out-of-the-box since it will no longer find the site.conf that I must use, and my user.conf that I expect for all my own tweaks are of course not used either.