OEDEM 2015: Difference between revisions
(→Agenda: add layerindex feature requests) |
No edit summary |
||
(86 intermediate revisions by 18 users not shown) | |||
Line 1: | Line 1: | ||
The 2015 OpenEmbedded Developer's European Meeting will take place Friday, Oct 9, 2015 in Dublin, Ireland | The 2015 OpenEmbedded Developer's European Meeting will take place Friday, Oct 9, 2015 in Dublin, Ireland. Part of this meeting will also constitute the annual OE General Assembly, and some corporation/eV matters will be discussed. | ||
== Location and Time == | == Location and Time == | ||
Line 9: | Line 9: | ||
9am - 5pm (note: times may change) | 9am - 5pm (note: times may change) | ||
Gibson Hotel is at the end of the red LUAS line, adjacent to the stadium. Come up to the 3rd floor and follow the signs for the Cordoba room. (the sign says "Mtg", that's us) There is coffee here. See you all soon | |||
== OpenEmbedded eV General Assembly == | == OpenEmbedded eV General Assembly == | ||
Line 16: | Line 18: | ||
* Proposal to dissolve the current e.V. and re-constituting it in the U.S. to reduce the administrative burden for the project. | * Proposal to dissolve the current e.V. and re-constituting it in the U.S. to reduce the administrative burden for the project. | ||
* Define a method for identifying lapsed memberships. | * Define a method for identifying lapsed memberships. | ||
* Proxy form [[File:Proxy_instructions-oe.pdf]] | |||
* <b>[http://www.openembedded.org/wiki/Dublin,_2015 Meeting Minutes]</b> | |||
== Agenda == | == Agenda == | ||
* Standards for BSP behavior. (Crofton) | * <s>Metadata</s> | ||
* | ** <s>OVERRIDE syntax: is it time to reconsider _?</s> | ||
* LayerIndex feature requests (tlwoerner) | ** <s>meta-yocto -> meta-poky. People are still spending too much time explaining reality. (Crofton)</s> | ||
** <s>variable expand = True by default</s> | |||
* <s>BSPs (tlwoerner)</s> | |||
** <s>Standards for BSP behavior. (Crofton)</s> | |||
** <s>feedback on layerindex to indicate BSP: | |||
*** last successful compile (feedback from outside builders?) | |||
*** last successful boot | |||
*** master branch parsability (perhaps ties into bugzilla 7792?)</s> | |||
** <s>several BSP layers to choose from for some boards, none for others (linux.com SBC survey)</s> | |||
** <s>guidelines/requirements for setting up a new BSP on layerindex | |||
*** bugzilla | |||
*** mailing list (use general mailing list(s) for patches?) | |||
*** git.yoctoproject.org/<yourbsplayer></s> | |||
** <s>making sure BSP layers only touch the variables/settings they should touch | |||
*** should a BSP layer ever use = ?</s> | |||
** <s>does/should a BSP produce artifacts that are easy to install to SD cards? (Crofton)</s> | |||
*<s>Processes</s> | |||
** <s>LayerIndex feature requests (tlwoerner) | |||
** build feedback (autobuilders and off-site) | ** build feedback (autobuilders and off-site) | ||
** | ** Build and test failures on the public Autobuilder (Bluelightening)</s> | ||
*<s>Systemd | |||
** Systemd packaging. As new things appear, they are lumped into one package. Update split? (Crofton relaying info) | |||
** Can we get systemd's first-boot support to work? It is currently disabled in the systemd recipe by touching /etc/machine-id. (Saur)</s> | |||
** <s>How to make it easy to setup a system "the systemd way"? New DISTRO_FEATURE or IMAGE_FEATURE? (Saur)</s> | |||
*** <s>Link /bin -> /usr/bin, /lib -> /usr/lib, etc.</s> | |||
*** <s>Change ${systemd_unitdir} to /usr/lib.</s> | |||
*** <s>Make the systemctl wrapper install in ${systemd_unitdir} rather than ${systemconf}/systemd. | |||
**** This should also happen when installing a package in runtime.</s> | |||
*<s>Advocacy | |||
** There are still a lot of projects (too many?) not using OE (tlwoerner) | |||
** why aren't more projects using OE? | |||
** how can we get more people using OE? | |||
** who should we be targeting? (build people (obviously), kernel devs? user-space devs?)</s> | |||
== Attendees == | == Attendees == | ||
Line 37: | Line 75: | ||
# Alexandre Belloni (abelloni) | # Alexandre Belloni (abelloni) | ||
# Armin Kuster (armpit) | # Armin Kuster (armpit) | ||
# Belén Barros Pena (belen | # Belén Barros Pena (belen) | ||
# Peter Kjellerstedt (Saur) | # Peter Kjellerstedt (Saur) | ||
# Alejandro del Castillo (adelcast) | # Alejandro del Castillo (adelcast) | ||
# Denys Dmytriyenko (denix) | |||
# Sean Hudson (darknighte) | |||
# Nathan Rossi (nrossi) | |||
# Mark Hatle (fray) | |||
# Nicolas Dechesne (ndec) | |||
# Paul Eggleton (bluelightning) | |||
# Andrei Gherzan (agherzan) | |||
# Felipe F. Tonello (ftonello) | |||
# Changhyeok Bae (chbae) | |||
# Saul Wold (sgw) | |||
# Ashish Shrivastava | |||
# Pascal Bach (bachp) | |||
# Richard Purdie (RP) | |||
# Michael Halstead (halstead) | |||
== Proceedings == | |||
RAW notes shown in boxes like this | |||
=> this is an action item | |||
-> this is a desired thing | |||
Introduce TSC | |||
* Martin Jansa (jama) | |||
* Mark Hatle (fray) | |||
* Paul Eggleton (bluelightning) | |||
* Richard Purdie (RP) | |||
* Khem Raj (khem) | |||
go over agenda | |||
BSP topic first to accommodate member travel | |||
=== BSPs & Layer Index === | |||
Paul described layer index process & how it works | |||
BBP layers also come into toaster, expose to people, dependency list very important - snapshot when setting up toaster | |||
module branches - will look in repo for branches | |||
some layers don't have a master branch, don't show content - need way to present in UI | |||
REST API | |||
DD automatically parse layer to check for required content? PE do want, necessitates background queuing process | |||
parse w/dependencies | |||
also affects YP Compatible, RP's proposed layer validation tool | |||
error reporting system - tie together with info in layer index, intention there | |||
JH ability to register layer & specify quality | |||
------------------------------------------ | |||
not getting resources to work on core BSPs | |||
people working on own BSPs - not really a complaint, but an observation | |||
SH would love to see REST APIs | |||
PE would love some help with the layer index | |||
RP love ideas, but people need to resource, step up & drive | |||
------------------------------------------ | |||
=> oe driving toward machine readable files, can also drive from layer test (yp compat) side - KK | |||
------------------------------------------ | |||
oe-core or oe-devel? oe-core | |||
------------------------------------------ | |||
=> publicize defs of each list? discuss on members list - where to overall architecture discussions belong | |||
discussion: decided on oe-core | |||
oe needs its own goals, interact with the yocto project | |||
------------------------------------------ | |||
status email to oe-core list, useful? to most people. cross-postd to yocto list | |||
KK should be about oe-core, not about poky | |||
=> TSC to add new mailing list specifically about project architecture, no patches, and determine list name | |||
------------------------------------------ | |||
KK realize that OE has no project vision | |||
RP is there any vision that needs to be represented to YP, and are there resources | |||
KK as a project take an active role to work with YP | |||
marketing/visibility standpoint, wear OE hat | |||
if list of oe bugs that should be raised, bring to philip | |||
-> KK bring discussion to new mailing list | |||
------------------------------------------ | |||
TW can new layers use bugzilla | |||
PE struggle with volume of bugs currently in triage process | |||
RP triage process - yp has taken on oe-core eg. don't want many bugs from idle layers, YP judged on metrics from that system | |||
SW some layers already in that state | |||
DD attended call regularly | |||
RP maintainers must be willing to come to triage process | |||
some issues don't have a clear maintainer | |||
------------------------------------------ | |||
BSP standards - standards exist,coming soon are methods for comparing a given layer with the standard | |||
"oe has no rules, only half-documented best practices" - Koen | |||
=> need wiki documentation for TSC to ratify | |||
-> document distro vs. machine policies, other best practices | |||
------------------------------------------ | |||
BSP layer availability | |||
-> encourage board vendors to provide a BSP, make it easier to do so | |||
people problem, not technical problem | |||
add questionnaire about why people don't | |||
ask LF to include a list of BSPs that are supported | |||
=> ask yp ab to talk to linux.com [PB] - community issue | |||
build for qemu, with limited resources | |||
-> look at digi manual (i.e. "just add bsp changes in local.conf") | |||
best practices : should be easy to use, instructions/tools to put it on a card, etc | |||
wic incomplete but promising | |||
------------------------------------------ | |||
touching variables - discuss on new arch list | |||
------------------------------------------ | |||
=== Metadata === | |||
meta-yocto to meta-poky: | |||
=> RP to take action on the YP side, possibly not for 2.0 | |||
override syntax | |||
underscore character to designate overrides, underscore is overloaded | |||
need better method | |||
KK maybe _OVERRIDE_ | |||
dot character? | |||
require all lowercase overrides? benefits for bitbake speed | |||
=> formalize lowercase as mandatory requirement for overrides, look for other options in the future | |||
=== Processes === | |||
Layer Index feature requests discussed with layer index | |||
build feedback>> | |||
Build/test failures on public autobuilder | |||
problems: | |||
RP | |||
different failures "random" - actually is a pattern, but initially looks random | |||
build poky and poky-lsb, lsb turns on different distro features | |||
boots a machine in qemu & runs scripts, most qemu machines, just says "kill" - unknown | |||
release blocker causing qa failures | |||
also, systemd having timeout issues | |||
should OE care about these things? (yes) | |||
PE | |||
set up environment to detect regressions | |||
did upgrading qemu and systemd create these? get to a correct point | |||
not poky changes or bsp changes | |||
eg poky enables ptest, doesn't affect systemd timeout | |||
RP | |||
have massively increased scope of tests | |||
ptests, sdk.. | |||
resources always an issue | |||
-> ask for cycles from employers to work on these issues | |||
-> make people aware, help with triage, provide resources | |||
KK -> plan B, C, etc. have had this problem for years | |||
more issues recently | |||
=== Security === | |||
security a long term issue, beginning to be noticed - now reluctant to address it, as it is being noticed/resourced | |||
if patch had standard cv, could write automated tools to parse | |||
-> need a method for tracking CVs | |||
MH have to have someone whose job it is to pull CV list, look for differences, assess applicability | |||
Michael Halstead : LF can run security audits of individual tools | |||
could do layer index, toaster, ... busybox | |||
MH independent academic audit found OE very good | |||
=== Systemd === | |||
currently scaling up | |||
complaints: more package config, comments; look at packaging to have minimal systemd even with options available | |||
-> need someone with time available to work on it | |||
-> need to get systemd feedback, people using systemd talk to package maintainer | |||
MH automotive is a heavy user, could ask genivi for help | |||
peter, koen using systemd but not using official oe recipe - based on | |||
Can we get systemd first boot support to work? | |||
MH wind struggling on read-only filesystems | |||
Easy setup "should work now" | |||
yes can get it to work - talk to upstream | |||
changing prefixes problematic | |||
MH unitdir to /usr/lib - can't boot without base lib | |||
should be able to boot minimal system w/shell and some commands | |||
should work if reasonable default can be changed | |||
patches are problematic - RP wants clear coherent vision | |||
systemctl wrapper needs documentation for working with systemd | |||
current docs targeted at app developers - not distro devs | |||
want to use the install section | |||
=> file systemctl wrapper bug | |||
=== Advocacy === | |||
b | |||
why aren't more projects using OE? | |||
Belen: | |||
difficult to understand & get started with | |||
- toaster | |||
don't understand the benefits | |||
- not a distro | |||
slower systems complain about performance (also don't understand sstate) | |||
- could enable sstate mirrors by default | |||
- now measuring size of builds | |||
- massively examine macros in autotools | |||
how can we get more people using OE? | |||
outreach | |||
documentation | |||
intro on oe, what it is & benefits | |||
no official body within OE to handle this - community mgmt, advocacy | |||
-> board to discuss advocacy/community, invite jefro to meetings | |||
need someone to run oe booth at fosdem, as paul is leaving [beth, belen] | |||
value in tools: | |||
devtool | |||
adt | |||
who should we be targeting? build people, kernel devs, userspace devs | |||
* college kids, interns | |||
* grad school programs | |||
* makers | |||
* white papers - active promotion (how is this different from debian etc) - at executive level; case studies, potato counter, comcast | |||
* maintain community metrics | |||
* koen: conference presentation comparing various build systems (oe, buildroot, etc) | |||
* devs doing board bringup | |||
* is oe for everyone? | |||
== Potential OE Day at ELCE next year == | |||
PB: day of oe presentations | |||
more like bofs | |||
=> board: do a proper cfp | |||
tlwoerner: lightning talks | |||
[[Category:OEDEM]] |
Latest revision as of 17:38, 12 August 2020
The 2015 OpenEmbedded Developer's European Meeting will take place Friday, Oct 9, 2015 in Dublin, Ireland. Part of this meeting will also constitute the annual OE General Assembly, and some corporation/eV matters will be discussed.
Location and Time
The Gibson Hotel
Point Village
Dublin 1, Ireland
+353 1 681 5000
9am - 5pm (note: times may change)
Gibson Hotel is at the end of the red LUAS line, adjacent to the stadium. Come up to the 3rd floor and follow the signs for the Cordoba room. (the sign says "Mtg", that's us) There is coffee here. See you all soon
OpenEmbedded eV General Assembly
We have a short administrative meeting before starting the Developer meeting. All are welcome for this.
- Proposal to dissolve the current e.V. and re-constituting it in the U.S. to reduce the administrative burden for the project.
- Define a method for identifying lapsed memberships.
- Proxy form File:Proxy instructions-oe.pdf
- Meeting Minutes
Agenda
MetadataOVERRIDE syntax: is it time to reconsider _?meta-yocto -> meta-poky. People are still spending too much time explaining reality. (Crofton)variable expand = True by default
BSPs (tlwoerner)Standards for BSP behavior. (Crofton)feedback on layerindex to indicate BSP:- last successful compile (feedback from outside builders?)
- last successful boot
master branch parsability (perhaps ties into bugzilla 7792?)
several BSP layers to choose from for some boards, none for others (linux.com SBC survey)guidelines/requirements for setting up a new BSP on layerindex- bugzilla
- mailing list (use general mailing list(s) for patches?)
git.yoctoproject.org/<yourbsplayer>
making sure BSP layers only touch the variables/settings they should touchshould a BSP layer ever use = ?
does/should a BSP produce artifacts that are easy to install to SD cards? (Crofton)
ProcessesLayerIndex feature requests (tlwoerner)- build feedback (autobuilders and off-site)
Build and test failures on the public Autobuilder (Bluelightening)
Systemd- Systemd packaging. As new things appear, they are lumped into one package. Update split? (Crofton relaying info)
Can we get systemd's first-boot support to work? It is currently disabled in the systemd recipe by touching /etc/machine-id. (Saur)How to make it easy to setup a system "the systemd way"? New DISTRO_FEATURE or IMAGE_FEATURE? (Saur)Link /bin -> /usr/bin, /lib -> /usr/lib, etc.Change ${systemd_unitdir} to /usr/lib.Make the systemctl wrapper install in ${systemd_unitdir} rather than ${systemconf}/systemd.This should also happen when installing a package in runtime.
Advocacy- There are still a lot of projects (too many?) not using OE (tlwoerner)
- why aren't more projects using OE?
- how can we get more people using OE?
who should we be targeting? (build people (obviously), kernel devs? user-space devs?)
Attendees
If you plan to attend, please list your name below.
- Jeff Osier-Mixon (jefro)
- Philip Balister (Crofton)
- Trevor Woerner (tlwoerner)
- Anders Darander (andersd)
- Marco Cavallini (mckoan)
- Koen Kooi (koen)
- Alexandre Belloni (abelloni)
- Armin Kuster (armpit)
- Belén Barros Pena (belen)
- Peter Kjellerstedt (Saur)
- Alejandro del Castillo (adelcast)
- Denys Dmytriyenko (denix)
- Sean Hudson (darknighte)
- Nathan Rossi (nrossi)
- Mark Hatle (fray)
- Nicolas Dechesne (ndec)
- Paul Eggleton (bluelightning)
- Andrei Gherzan (agherzan)
- Felipe F. Tonello (ftonello)
- Changhyeok Bae (chbae)
- Saul Wold (sgw)
- Ashish Shrivastava
- Pascal Bach (bachp)
- Richard Purdie (RP)
- Michael Halstead (halstead)
Proceedings
RAW notes shown in boxes like this => this is an action item -> this is a desired thing
Introduce TSC
- Martin Jansa (jama)
- Mark Hatle (fray)
- Paul Eggleton (bluelightning)
- Richard Purdie (RP)
- Khem Raj (khem)
go over agenda BSP topic first to accommodate member travel
BSPs & Layer Index
Paul described layer index process & how it works BBP layers also come into toaster, expose to people, dependency list very important - snapshot when setting up toaster module branches - will look in repo for branches some layers don't have a master branch, don't show content - need way to present in UI REST API DD automatically parse layer to check for required content? PE do want, necessitates background queuing process parse w/dependencies also affects YP Compatible, RP's proposed layer validation tool error reporting system - tie together with info in layer index, intention there JH ability to register layer & specify quality ------------------------------------------ not getting resources to work on core BSPs people working on own BSPs - not really a complaint, but an observation SH would love to see REST APIs PE would love some help with the layer index RP love ideas, but people need to resource, step up & drive ------------------------------------------ => oe driving toward machine readable files, can also drive from layer test (yp compat) side - KK ------------------------------------------ oe-core or oe-devel? oe-core ------------------------------------------ => publicize defs of each list? discuss on members list - where to overall architecture discussions belong discussion: decided on oe-core oe needs its own goals, interact with the yocto project ------------------------------------------ status email to oe-core list, useful? to most people. cross-postd to yocto list KK should be about oe-core, not about poky => TSC to add new mailing list specifically about project architecture, no patches, and determine list name ------------------------------------------ KK realize that OE has no project vision RP is there any vision that needs to be represented to YP, and are there resources KK as a project take an active role to work with YP marketing/visibility standpoint, wear OE hat if list of oe bugs that should be raised, bring to philip -> KK bring discussion to new mailing list ------------------------------------------ TW can new layers use bugzilla PE struggle with volume of bugs currently in triage process RP triage process - yp has taken on oe-core eg. don't want many bugs from idle layers, YP judged on metrics from that system SW some layers already in that state DD attended call regularly RP maintainers must be willing to come to triage process some issues don't have a clear maintainer ------------------------------------------ BSP standards - standards exist,coming soon are methods for comparing a given layer with the standard "oe has no rules, only half-documented best practices" - Koen => need wiki documentation for TSC to ratify -> document distro vs. machine policies, other best practices ------------------------------------------ BSP layer availability -> encourage board vendors to provide a BSP, make it easier to do so people problem, not technical problem add questionnaire about why people don't ask LF to include a list of BSPs that are supported => ask yp ab to talk to linux.com [PB] - community issue build for qemu, with limited resources -> look at digi manual (i.e. "just add bsp changes in local.conf") best practices : should be easy to use, instructions/tools to put it on a card, etc wic incomplete but promising ------------------------------------------ touching variables - discuss on new arch list ------------------------------------------
Metadata
meta-yocto to meta-poky:
=> RP to take action on the YP side, possibly not for 2.0
override syntax
underscore character to designate overrides, underscore is overloaded need better method KK maybe _OVERRIDE_ dot character? require all lowercase overrides? benefits for bitbake speed => formalize lowercase as mandatory requirement for overrides, look for other options in the future
Processes
Layer Index feature requests discussed with layer index build feedback>>
Build/test failures on public autobuilder
problems: RP different failures "random" - actually is a pattern, but initially looks random build poky and poky-lsb, lsb turns on different distro features boots a machine in qemu & runs scripts, most qemu machines, just says "kill" - unknown release blocker causing qa failures also, systemd having timeout issues should OE care about these things? (yes) PE set up environment to detect regressions did upgrading qemu and systemd create these? get to a correct point not poky changes or bsp changes eg poky enables ptest, doesn't affect systemd timeout RP have massively increased scope of tests ptests, sdk.. resources always an issue -> ask for cycles from employers to work on these issues -> make people aware, help with triage, provide resources KK -> plan B, C, etc. have had this problem for years more issues recently
Security
security a long term issue, beginning to be noticed - now reluctant to address it, as it is being noticed/resourced if patch had standard cv, could write automated tools to parse -> need a method for tracking CVs MH have to have someone whose job it is to pull CV list, look for differences, assess applicability Michael Halstead : LF can run security audits of individual tools could do layer index, toaster, ... busybox MH independent academic audit found OE very good
Systemd
currently scaling up complaints: more package config, comments; look at packaging to have minimal systemd even with options available -> need someone with time available to work on it -> need to get systemd feedback, people using systemd talk to package maintainer MH automotive is a heavy user, could ask genivi for help peter, koen using systemd but not using official oe recipe - based on
Can we get systemd first boot support to work? MH wind struggling on read-only filesystems
Easy setup "should work now" yes can get it to work - talk to upstream changing prefixes problematic MH unitdir to /usr/lib - can't boot without base lib should be able to boot minimal system w/shell and some commands should work if reasonable default can be changed patches are problematic - RP wants clear coherent vision
systemctl wrapper needs documentation for working with systemd current docs targeted at app developers - not distro devs want to use the install section => file systemctl wrapper bug
Advocacy
b why aren't more projects using OE?
Belen: difficult to understand & get started with - toaster don't understand the benefits - not a distro slower systems complain about performance (also don't understand sstate) - could enable sstate mirrors by default - now measuring size of builds - massively examine macros in autotools
how can we get more people using OE?
outreach documentation intro on oe, what it is & benefits
no official body within OE to handle this - community mgmt, advocacy -> board to discuss advocacy/community, invite jefro to meetings
need someone to run oe booth at fosdem, as paul is leaving [beth, belen]
value in tools: devtool adt
who should we be targeting? build people, kernel devs, userspace devs
- college kids, interns
- grad school programs
- makers
- white papers - active promotion (how is this different from debian etc) - at executive level; case studies, potato counter, comcast
- maintain community metrics
- koen: conference presentation comparing various build systems (oe, buildroot, etc)
- devs doing board bringup
- is oe for everyone?
Potential OE Day at ELCE next year
PB: day of oe presentations more like bofs => board: do a proper cfp tlwoerner: lightning talks