 Hello. Okay, so hello everybody. I am Kuan from Vietnam. Today I talk about Customized Debian for Raspberry Pi and Bigo Bon Bon because I work in IoT. So he pre-introduction about me. So I work for a project in First Asia, the Susie Leeroves, and I have a startup about agriculture technology. So why I come to my Debian is because our project use some Raspberry Pi and Bigo Bon Bon. And we need to remove some components we don't need. For example, when I buy Bigo Bon Bon, they have some pre-increased software and we don't like it. I want to remove it to have a bigger one. And also the installation of our software to the board takes very long time. So we want to customize it to include our software. And we want to change some default config because it's the default config buggy like the bug with Abahi and the bug with Conman. And we also want it to be automatically built when we update our software code. So there is some hindrance about doing this. It's for family like Raspberry Pi and Bigo Bon. They have it's our way to customize the OS. So there is no common way. And the view strips are very different. I will show how. Now we see the Bigo Bon Bon. Here is the original view strip. This view strip is used for many variants of Bigo Bon like Bigo Bon Black, Green, Blue. And this strip can only run on a real hardware. We cannot run in our PC via KMU. And the last link is my customization. So this is my need to customize it. We want to add some depth view repository. This repository hosts our software package. Like we want to use Python 3.6. But the original repository only have Python 3.5. That's why we have to add the additional repository. And we want to remove some software that we don't need like Bonescript, Cloud9. We want to remove the default documentation. And there are some Python packages that we want to include. But we want to build but that package will need some other library. So we want to include those library to have building Python package faster. So how to do it here? These are the five that we need to customize the first. You see that this is our original, this is our strip. This one is copy from this one. We copy from this one and do some chain. The next one is in the chain root folder. So we have this is the original strip. We copy this and modify it and become this. And we write one more strip to compile those. The content of this new strip is to run, this is the main strip and then do some additional job like create the SD card image and generate some files to have the image faster like the B map. When you flash the image to the card normally you use the DD but the DD takes a long time. So the Python project they invent a new tune called B map tune. So that B map tune will read some B map file and will have flashing the image faster. And we also want to compress the image file so that we can let other people to download it. Here is for Raspberry Pi. The process of customization for Raspberry Pi is different. Here you can see the build strip of Raspberry Pi. What good about Raspberry Pi build strip is that it can run under KMU and Docker. It means that you can run in your PC but because KMU cannot emulate the ARM processor fully. So when I customize it, my build strip cannot run in KMU because it use some system code that KMU does not support. And the Raspberry build strip is better organized than the big one because it is free to multiple stages. So you build each stage after each stage you move to this stage and this stage this stage. So when you make some changes in one stage you just rebuild that stage you don't have to go over again. So it will save you a lot of time. And the stage two is to produce the control operating system without guide. And the stage three plus is to produce the desktop OS. But our application doesn't need desktop, doesn't need UI. So our needs are very similar to the build board that we want to include some repository. We want to include some rebuild with binary file for Python packages. And because this board is used in the first year, so the main purpose is to include the security software. Here is the building process. So you can see that it is free to many stage. So when you change in one stage it will rebuild. You don't have to go from the beginning in build again. And because our project doesn't need desktop OS so we want to modify somewhere between the stage two and stage three. Here so the Python allows us to create one middle stage. This is stage 1.5 and it will run before stage three. So before producing the desktop OS. And in this stage we just have a similar structure with other stage. Like we have this file. This one is to list the package that to be installed by UpGrid. And this one is the script that will be run inside chain root. Here our main instance script for Sushi root to be run. And here this is just to have some cleanup job. Like because inside this script we start some system D service. So in this script we stop the service to let the chain root exit cleanly. And this one is just this is just to inform Python that at this stage we need to produce the image file. And this one is just a copy of other stage. This task is to copy the file produced by previous stage. So when we do it and we find some problem and here is the experience to show that problem like inside chain root don't restart the system D or depth D. Because when you switch to a chain root environment you will have to buy to mount some folder like the depth folder and the sys folder. And the depth D will block you from unmount those folders. So you have to avoid starting depth D. And if your application needs Java you need to remove Java first and then install again. I don't really know how this can solve the problem. And in our project we also do some further customization. So this customization requires our to modify some files outside our stage. Like we want to compress the image with HS. The default build script, the original build script is to produce the GIF. But we found that GIF file does not help you to to flush the image to the SD card faster. Because with GIF file you have to unzip it to a file and then use that file to flush to the card. But for HS it helps you uncompress on the fly and right to the card. It saves more time. And we also have a different naming scheme with our file, our image. Here I want to show you how it works in the practice. This is the result of those build scripts that we use to build series. Here this is the result in the first file when we list the package to be installed by the update. Here the update is turning our package. It's very long. Okay. So my talk is finished. Do you have any questions? So you don't have questions. Thank you.