 Good afternoon, everyone. Thank you for attending this presentation. Today, I'd like to introduce reproducible and maintainable embedded Linux named DB. I've already made several presentation in the Linux conference in Japan. So in this presentation, I'd like to explain some abstract of the DB and also new features about it. This project is called Shared Embedded Linux Distribution, which is one of the activities of the C working group project. The goal of the project is to create an industry supported distribution and provide the long-term maintenance. Please visit this webpage for more details about the project. Then today's Linux is running on a lot of many embedded systems including the civil infrastructure. Then when we choose the distribution for such system, we need to consider the number of supported packages and their versions, supported hardware and the stability and so on. In our case, we want to make custom embedded Linux environments, and we need wider hardware support and stability and long-term support and customizable build systems. Especially long-term support is the most important things because the most products in the civil infrastructure required over 10 years support. Our solution is to combine the Yacht Project Pocky build system and Debian source code with MetaDebian. MetaDebian generates a reference distribution named Debian. This is the definition of the terms, and MetaDebian is a layer for a Pocky build system. This is separated from the core components of the Yacht Project named Open Embedded Core and other layers. Also, it allows the cross-building Linux images using the Debian source code, and the source code is available on the GitHub. Debian is a reference distribution that is built with Pocky and MetaDebian. The name of Debian comes from Debian and Pocky, and it also comes from the Debian line. Debian is built from the Debian source, but in the binary package level, Debian is different. So we should call it the Debian-like. This is the default structures of the Pocky build system. The Pocky fetches upstream source code and build the Linux images for the target hardware. Then when we use MetaDebian, enable the MetaDebian with Pocky. Pocky fetches the Debian source code instead. Then build the Linux image called Debian for the target hardware by the same way. This is the target version of Debian. The target version of the Debian source code is version 8.0, this is currently supported. Your project version is 2.0 stable and 2.2 development version. The purpose of Debian is to satisfy our needs, especially to provide the stability and the long-term support with Debian stable release and long-term support. Also, we should contribute to the upstream projects including the Debian LTS. When we create recipes for Debian, basically we follow the Debian's packaging rules. In other words, use the same commands and options in configure and compile process, and the same install process, and binary package name and dependencies as Debian. But as you know, Debian rules the core component of the Debian packages assumes the native build. But Debian is cross-compiled from Debian source code. So we cannot execute the Debian rules directly. Instead, we need to implement configure and compile commands ourselves and also sometimes we need to add some patches for supporting cross-compile. Then also, Debian is intended to not only embedded system but also the desktop PC and the servers. So sometimes we customize some settings for embedded system if necessary. For example, remove unneeded features, unneeded dependencies, and packages. For example, some packages generate UDEP packages that is only for the Debian installers. In such case, we don't need to generate. We need to take care about such packages. About the details of this policy is written in my old slides. So if you want, please refer to this information. From this slide, I'd like to explain how to build Debian and run it on the QM environment, and also explain how to generate SDK and cross-compile your applications and run it on QM. First, simply download Pocky and also download the meta-Debian into the Pocky directory. Please note that the red circle mean the meta-Debian specific space. Second, we need to modify a bit. Change the default configuration by setting the template conf variable to the net meta-Debian slash conf. This mean the core configuration files located on this directory. Then run the startup script that is provided by the Pocky. After these settings, we can run BIPAKE. In this case, generate the root file system and kernel. The built binaries images located on this directory in the case of the QM x86. The final is run kernel and root file system on the QM environment with runQM command. That is also provided to Pocky. Currently, in total, the five QM architectures are supported. The next, build SDK by this command, Bitbake meta-tool chain. Output is generated in this directory. This file, this script is just a self-extracting string. So you can easily install the SDK into your host system just by running this script. Then this is the simplest application and make file. For such simple application, we just need to export SDK environment variables by this command and then make. Then you can get cross-compiled hardware. But the required settings to compile the application is dependent on the implementation of the application. So please refer to the React project manual for more details to how to cross-compile the application. The final is copies the built binary to the root file system image and then run on the QM environment. Very simple steps. Here are the new features of the DB. About the Yoc project, supported version is upgraded to the 2.2 development version. But kernel, the supported version is also upgraded to the 4.4 LTS and 4.1 LTSI. The latest version of the LTS and LTSI. Also, the several new recipes and some target machines are newly supported. Some new useful features are supported. The first one is package management with DPKG and ABT. The second one is a tag-based source code fetch and build. This function is a function to rebuild the Linux image that are built at the specific time, the old release. And the last one is the summary generation. This is a function to generate some information of the packages that are included in the generated root file system and SDK. So from this slide, I'd like to talk about these features in the latest slide. First, I'd like to talk about the package management. This feature is, by default, available in the open embedded core from the beginning. And we also made it available in the meta-debian layer. But, by default, this feature is disabled, so we need to add this definition into our local.conf to use the package management. When we enable the features, first, we can simply add the binary packages into runtime environment. For example, sometimes, temporarily, we want to install and uninstall some packages for system evaluation. And sometimes, we want to install the debug packages for some debugging purposes. And second, we can upgrade packages without stopping the system. And also, we can install upgrades that packages without installing the root file system again. Building and upgrading the root file system in the embedded system sometimes takes time. So this kind of feature is useful for updating each package and quickly. This is the build flow of the bokeh. Each recipe fits the source code and build and generates some binary packages, such as the dev package. And root file system recipes generate the root file system with by installing the dev packages with up to get installed. But by default, there is no data for controlling such binary packages in the root file system. If we enable the package management feature, root file system keeps the data for controlling the binary packages. And we can dynamically install, upgrade the binary packages from the package pool on the build environment. In this case, the app repositories, the package pool, need to be published by the web server. With this flow, even if we update some recipes or source code in MetaLevion, we can install or upgrade the binary packages without installing the root file system again. Next, I explain about tag-based source code fetch and build function. By default, MetaLevion doesn't have the reproducibility. In other words, it cannot reproduce root file system and SDK that was built at a specific time. Because the recipes in MetaLevion always fetches the latest source code, that intended to automatically import the security updates. And reproducible build is one of the essential features in long-term maintenance. We might find some issues three or four years later after we released our products. In such case, it's useful for finding the source of the issues in the old release. And how do we provide these features? First, register a release tag in Git repository every release and add a new global variables Git rebuild tag into the Pocky build system and reproduce an old image by specifying a town name using this variable. I explain with this simple figure. Each line is the timeline of the source code and the MetaLevion. And the circle means the version numbers of each software. If we released a Linux image at this red line, we just register a common release tag. In this case, the name of the tag is R1 to the released software version. And the second release and the third release also register a release tag by the same way. Then, how to reproduce an old release image? As a first step, check out the MetaLevion revision R1. And the recipes in MetaLevion fetch the latest source code by default. So to avoid this, we set the Git release tag to R1. As a result, the MetaLevion fetches R1 tagged source code only. And from this slide, I'd like to explain how to register tag and rebuild in the real environment. First, create a Git repository mirror with Docker. Unfortunately, the default Git repository on our GitHub don't permit to push the tag. So we need to create the mirrors first. We also provide a simple tool to generate mirrors in Docker image. The name of the tool is MetaLevion Docker. So you can easily set up the repositories in the mirror with these two. Then set up the Pocky and MetaLevion. By default, the MetaLevion fetches all source codes from the GitHub by default. So before we pick, we need to change, override some variables about the Git repository servers and the protocols in local.conf. After these settings, we can bit base something using the Git repositories on the Docker image. After built, the list of used Git repositories is generated in the build directory with generated image. Then we can register a tag to the repository with the script GitTaggle.sh. This script read the generated list and automatically register a tag to the repository in the list. Now, ready to rebuild? Or we can easily rebuild the old image by setting the Git rebuild tag variable to the old release tag name in local.conf. And next, I'd like to explain about generation of the summary information. In most product developments, summary information of the open source software is required. For example, the list of installed software and versions addressed where the source code fetched and licenses. Generating such information, summary information should be automated by build system. But Pocky and MetaLivian generate only a list in source software by default. So we added some functions to automatically generate such summary information into root file system and SDK recipes. In Pocky's build flow, recipes build the source code and generate binary packages such as def file. The root file system and SDK are generated by installing the such generated binary packages. And we added a hook to hook in the default packaging function. This hook embeds the additional metadata into the binary packages. For example, license or source code name and so on. We also added another hook into the recipes that generate the root file system and SDK. This hook just generates a summary file from metadata in binary packages installed in the target image. And this is the samples of the summary information. The installed packages are listed in the last column in the package name. And each row has information about packages. These features can save some times to generate such a summary information in the product development. So I'd like to summarize this presentation. I explained about shared embedded abstract of the shared embedded distribution and for its devies. Devies intended to provide, especially the long-term maintenance. And this slide focused on the new features. For example, the package management with the DPKG and apt and the tag-based source code which end built. This is a function to reproduce an old image, release image using the git rebuild tag. And the last one is a summary generation. It automatically generates summary information about the root file system in the SDK. This is the current development state of the Debbie. The base YoctoProject version is upgraded to 2.2 development version. And the current version is also upgraded to the latest LTS and the LTSI. And some new VSP and recipes are also added. And about future works, we need to keep the following updates of Pocky and Debian. I am my understanding the YoctoProject 2.2 will be released as a stable version soon, at the end of October. So we need to follow with a newer version. And also, we need to support more embedded boards. And we'd like to improve the build time for upgrading target images, because we always need to bit bake and build all required packages to update some software every time. It takes too much time. So we'd like to improve the time. And there are related interesting work already presented in this embedded Linux conference. The first one is a generate Linux image from the Debian binary packages with bit bake. And it uses bit bake, but don't build from the source. All applications and customized packages built in the Debian's change route. And bit bake is used as some tools to generate the binary. No, generate target root file system. And the second one is LB. LB also generates the Linux image based on the Debian binary packages. And all specification about the root file system is described in XML file. So it's very interesting and easy to trace. And the last one is smart package managers. This provides a tool to install and install pre-built packages built by the bit bake without rebuilding a lot of packages. There are several similar approaches that use the Debian distribution currently. And I think we should collaborate with them and find out better ways about the package management. And then we are trying to, in the research level, we are trying to generate the recipes automatically from Debian loops to save times to create recipes. Because creating recipes also takes times and costs for the maintenance. So we'd like to find some efficient way to create recipes. And the last one, we also need to integrate the Debian with LTSI testing environment named Fuego. We'd like to contribute to this project by providing some test cases for the Debian and Debian and or providing some other useful frameworks. So we are waiting for your feedback. The features explained in this slide are just examples. If you have additional issues about the long-term maintenance, please let us know. And we'd like to consider adding more features to solve such issues. So let's choose first. This is the end of my presentation. And do you have any questions? Toolchain is also based on the Debian source code. And meta-toolchain in the POKI generates cross-toolchain from the upstream source code. But if you enable the meta-debian, the BitBake generates toolchain only using the Debian source code. But meta-data to generate SDK comes from the POKI. Only the source code is based on the Debian. Yes? Can you use Debian repositories once everything is set up? Debian repositories? To get packages. Do you mean can we install the binary packages from the Debian repositories? Currently, some packages can be installed. But not tested. And for example, the package VC is very simple packages, very simple commands. It depends on only libc. Such simple packages can be installed into the Debian directory if these architectures are the same. But some other complicated packages, maybe you cannot install because the meta-data in the Debian's binary packages might conflict with our binary packages currently. But I think there is some possibilities to reuse some simple packages by installing from the Debian repositories to development purpose. The recipe generation. Yeah. We're very new for that because we did that manually. Manually? Yes. I just want to know how this can be done. Yes. It is still in research levels. But I already mentioned we basically use the same command and options as the Debian rules files in our recipes. So some commands or some basic dependency information can be found in the Debian rules file or Debian control files automatically by creating some script to pass. But yeah, I also think it's too difficult to automate all of the process to generate the recipes. But I think we can automate the generating based of the recipes and then modify something by our hand. For example, about the settings for the cross-compiling. Yeah. Currently, we are creating the recipe from nothing. So it takes too much. Thank you very much. Considered you modules in order to avoid the Debian repositories? Sorry. Fat tools. Git, Git. What? Superdue. Git, Git, Superdue. Git modules. Yes, you can. Sorry. Which tools? Git, Git modules. Yeah, we just. We just simply use only Git command. Yeah, this is the Git command. No dependencies on other modules. Yeah. Do you hope your different functionality, I mean, do you just change the source URI of the upstream target with the Debian one and just build from that? Or you are using also the metadata from Debian? Yeah. We combat the old Debian source code from the app and from the turbo to the Git repo to get it fast. Then you use it. Do you use some of the infrastructure that Debian is putting in its package, I mean, the metadata of the Debian package, or just picking the target that Debian has and the patches that Debian uses for maintenance and just pick that, put together, and build the source from there? How many packages do you cover? For example, you are covering all the recipes that are in the Bokeh repository, or something like Qtify for these kind of packages that are in other diodes? The list is just dependent on our request. Yeah. Currently, the number of recipes is more than 300 or 400. So probably Bokeh and MetaPenembedev recipes, but not something like MetaQtify for all the layers with graphical things. Currently, we don't touch any BB files in the MetaOpenembedev course. So what do you mean is, for example, do you have recipes to pick Qtify libraries from Debian, or do you just cover, I don't know, maybe command line applications, or? Sorry, could fetch? The question is, do we have libraries for the graphical recipes, recipes for, for example, Qtify or Qt4? Yeah. I see. About Qt, we are currently still implementing the recipes for the Qt. And about X environment, we already switch some very tiny recipes. We are integrating new recipes as soon as you need them. But so there is no, I mean, a roadmap. So in this version, we are going to support up to here. And in this other version, we are going to support up to here. Yeah. Because of these destinations, because of just our requirements, we're trying to make the name and doing the terms and we're not so big community. So our main purpose for using this kind of stuff is mainly for the controller. Yeah, that controller doesn't reach a variant for the brush cut stats. That is why we try to do that, but not strongly for some of the brush cut stats. Yeah, thank you very much for the question. Do you have any other questions? OK, oh, yes. Up to repository is our package management. This one. You fetch your upstream sources, the devian sources, then you build the devian packages and you put these devian packages to an app repository. And then from this app repository, the root effect is generated. Is it correct? Yeah, all of this one is in the build environment. And all of them are generated by BigPake. Yeah. So this is done in every build environment? Yes. In the build directories of the Pocky, Pocky and Metal Evian. Repository automatically, in the fetch rules, whether the binary package is already available, then you would solve your rebuild problem, right? This is the way we want to do the CPSR. So we want to put the packages not into the local app repository, but on the server repository. Yeah. And then check in the fetch rule of every source package whether it was already compiled and is available in the central app repository. And in this way, we would avoid the recompilation of the stuff that was compiled or in previous builds. Yeah. This is what we want to do, we have to adjust. Yes. Now, currently, the package management functions of the package management from the Pocky are available, currently. But we like to provide and implement more features about management of such binary packages in the root file system, the target environment, and the build environment. So I think there are a lot of hints in another project such as either or every. Thank you for questions. Yeah. This works for you today for the one you have. The question was whether you can share this. Yes, you can share it. It's somewhere in the local project. Any other questions? If you have more questions, please come here and talk with me. So thank you for attending this presentation.