# 2023 Linux Plumbers Build Systems Micro Conference

* SLSA provides a mechanism for providing provenance of build artifacts
  * Common meta data formats across multiple build systems could be useful
  * Partially related to reproducible builds comparing output and provenance from multiple builders
  * Unlikely to have reproducible builds between artifacts from different build systems, but the provenance could be similar
* UAPI testing allows inspecting header code as well as using DWARF information from builds to be able to detect UAPI changes between different versions of kernels
  * Checking for UAPI changes between versions would be useful minimally as a way of seeing what's changed between kernels in build system releases
  * Often for embedded build systems, vendor kernels change a lot of things which might not be caught by public UAPI checking
  * Incorporating UAPI checking into build systems for the kernel may allow detecting UAPI changes during build and testing, rather than later which may be catastrophic
* Kernel support for build systems
  * How can build systems support more common systems and kernel patches for specific situations
  * Kernel patches don't make it upstream for a host of reasons, and how do we manage the required patches more effectively across vendor kernels
* Discussing the issue surrounding non-upstreamed patches (kernel and otherwise)
  * Some build systems tag patches in a way which allows one to know which have been submitted upstream, which can't be upstreamed, have been back-ported, etc
  * There are several different ways of tagging patches in this fashion and a common way of doing it across build systems would probably be a good idea
  * At the moment it appears that there isn't a lot of long-term patch tracking across individual build systems or between build systems.
  * Having patches not only explain their purpose, but also their current upstream status, as well as tracking their change over time, and between build systems yield some interesting trends
  * Patch tracking in this way can be used to gamify better upstreaming behaviour, both within a build system and between build systems
  * Leader boards of this data can be used to encourage people into better behaviours
* Devices often have code to be built for multiple cores: base OS, BMC, device firmware, etc
  * This can require multiple architectures, compilers and other tools
  * The way OpenEmbedded and Yocto Project do multiconfig was discussed to show how a single build can be used to build multiple different artifacts for different cores
  * Its important for things like SBOM and security to be able to track the artifacts built for the multiple cores, and what was used to build each of those artifacts
  * This is a common problem solved in various ways across different build systems. Sharing ideas on this topic might lead to more cooperation