みなさんおはようございます。今日はこのプレゼンテーションをご紹介します。今日は私たちのアクティビティーを紹介します。デビアリン・ユヨクトのアクティビティーです。このセッションで3人がいます。マヌエルです。リナトロニックスです。ボージャンです。イルバースです。カズヒローです。シンバー・ココロシーズです。私たちのアクティビティーを紹介しています。デビアリン・ユヨクトのリナックスのアクティビティーです。今日はアクティビティーを紹介します。まずは、ここです。まず、このプレゼンテーションの後ろについて説明します。私たちはプロダクトデブロッパーです。世界中に多くのオプションがあります。このプロダクトデブロッパーはリナックスエンバーマンスを作っています。私たちこのプロダクトデブロッパー、私たちは一気において、私たちのプロダクトデブロッパーを紹介するために、私たちはこのプロダクトデブロッパーについて説明します。次は、私たちは私たちのプロダクトデブロッパーを紹介しました。私はこれを考えています、このプロジェクトについては、コモンの領域や、責任の必要があるのか、そして、これらのプロジェクトについていろいろなフィードパークが非常に重要なプロジェクトについてなぜか、このプレゼンテーションについてまずはプロジェクトの製品で一般的にリナックス based systemでも、普通にプレゼンテーションについてプロジェクトについていろいろな製品についていろいろなプロジェクトについていろいろなプロジェクトについてプロジェクトについてプロジェクトについてパサルパーティーソフトウェアディベンデンシーについてついて製品の製品で一般的にプロジェクトについてレディ2のイメージについて一般的にレディ2のイメージについて例えば、一つのバイナリファイルについてブドローダー、カーネラー、ブドファイルシステムなどについてもちろん過去の製品のプロジェクトはつまりレディについて製品用についてとても勉強されている情報、それまで明日そういった製品のプロジェクトを全ての製品について負けられないそして、私たちは、非常に柔らかい、充填のマーケージを使います。そして、長時間充填のメンテナンスの特徴が、非常に重要です。そして、最近、私たちは、スクールストックデビアンスの移動を支えることを支えることを忘れました。そして、多くのセキュリティアプレイのロボーランドのアプリで、私たちは、長時間充填のメンテナンスの特徴が、非常に重要です。2年以上、5年以上、全ての特徴のパッケージを支えることを忘れました。そして、多くのセキュリティアプレイのロボーランドの特徴を支えることを忘れました。そして、私たちは、スクールストックデビアンスの移動を支えることを忘れました。そして、私たちは、スクールストックデビアンスの特徴を支えることを忘れました。そして、私たちは、スクールストックデビアンスの移動を支えることを忘れました。そして、私たちは、スクールストックデビアンスの移動を支えることを忘れました。YOGTOプロジェクトは、世界中のエンベルドワールドにとって、非常に強いインティグレーションの特徴があります。そして、非常に複雑です。私たちは、全てを変更することで、レシピを変更することができます。そして、レイヤリングの仕事は、非常に面白いです。ここにも通常の存在ブロ殆どは、全体の和まようになっています。私はこちらのhow to get a show with altitude Microsoftプロジェクトを繰り返して或者財布について参加しました。忘れに down こだじれるベルトベルトレスが使用されることができます。デビアン、ネタ、エレベーを使用することができます私はこのものを使用することができますイザー、ポーションはイザー、メタ、デビアンを使用することができます3つのアプローチャーズが already existingデビアンとエンベーダーのアプローチャーズを使用することができます昨日、会話は聞いていたことがでましたデビアンとネタとエンベーダーのアプローチャーズ are also a huge lot of toolsVMDB2、Vmdboots、Vmdbe2デビアンとエンベーアンによっても多くのアプローチャーズもいますアンワイルメントを作って、デビアンとイメージを作っていることができます。しかし、その他のプロジェクトを担当しています。では、エルヴィスのベースシステムのネタエルヴィスを説明します。エルヴィスが前にエルヴィスが聞いたことがありますか?ああ、それは素敵です。エルヴィスのネタエルヴィスは、一緒にエルヴィスのファイルが詳細に取りにくいことができます。これをエルヴィスマイルのファイルに連絡していることができます。エルヴィスのネタエルヴィスのネタエルヴィスは、エルヴィスのディーメンとエルバディーメンの デビアンのステムのネタエルヴィスを使っています。LBDMENはデビアンライクディブーストアプライグとして使用されています。パイフェンアップはPBuilderのようなものです。XMLの資料をインタビューしています。それをイメージすることができます。SDKのイメージができます。リサンスの資料とソースファイルスの資料ができます。非常に利用していて、その自動写真、納得を売ることができると、XMLファイルを使う方法の筆に関してたくさん人が死後にビッベークの証拠を 見せることができます。そのため、ネタエルベのビッベークのインタフェイスも予想のあるプラモデルを使用しています。これを使う必要があるとはわかりません。基本的には、BitBakeが実際にコンフィックファイルをパーシングすることができます。コンフィックファイルをコンフィックファイルにコンフィックファイルをコンフィックファイルにコンフィックファイルをコンフィックファイルにサモソリロ寄りすぎ込みなぜそれをパーパーシングしたのなんて考えたのか意味がしていますかっきり違反している人 reallyandif you think about bootstrappingnew architectureheyDavianに対して、BitBakeは良いオプションを新しいGLIP-Z新しいGCC新しいアーケテクトラッシュ新しいバージョンを作ってみますまたBinary Packagesを使ってNATIVE-LYにQMU Emulated P-Builderを作ってみますこの建物はとてもクロスビルディングパッケージを作ってその理由はEDプロジェクトを聴いてみますこれが私のサイトでWarshamをお送りしますありがとうございますEtherはパッケージビルダーイメージゲットジェネータ同じステップインストールベースシステムプロジェクトのアプリケーションを作ってみますソースコードでインストールベースシステムを作ってみますそしてこれをインストールベースシステムを作ってイメージゲットジェネータを使ってみますEtherパッケージビルダーほとんどデビアンベース使ってデビアンバイナーシステムを使ってデビアンテールディーピケージビルダープロジェクトアプリケーションアプリケーションアプリケーションアプリケーションアプリケーション行ってみますヲストロ濃これは多くのでは久しぶりしかアクリルタインストールベースシステムであるいは、正確なオーダーです。重要なものは、ヨクタレイクのレイアリングに正確な仕上がり、ハードウェブ・エンドウェア・サプライアー、エンドウェア・アプリケーションデベローパンを使用しています。楽しみにしています。今日は、テクニックショーケースを紹介します。ここで、イザーの基本のストラクトを見ることができます。イザーは小さな穴でパッケージの作り方をオーケストratesをしています。パッケージのルートファイルシステムを使用しています。その上、BSPやソフトウェアやプロダクトのプロダクトのアプリケーションを使用しています。製作者にはSDKを使うことができます。簡単にアップストリームデビュアンパッケージを使用しています。最初からバリアンスを使用しています。これが一つのプロダクトたくさんバリアンスを使用しています。バリアンスを使用しています。80%のバリアンスを使用しています。バリアンスを使用しています。なぜこれが一つのプロダクトそれを使用しています。つまりバリアンスを使用しています。もちろん他們のフォーサーを使用しています。その上、バリアンスをアップストリームについて解決できるようになります3rd approach by Toshiba is called MetadibionMetadata Set is a method data set for YOKTA projectfor building Debian source codeThis means Debian source packages are integrated into the YOKTA layerand then built by YOKTA meansand also YOKTA, cross compiler and image generation tools are usedIn the difference to the previous approachesone is a distributionThis means that the packages are included with the meta itselfand it is source based like YOKTAit means that we want to cross build everything from scratchto achieve customizability and to be able touse this system for the latest CPUs with our desired tunings and so onThe motivation to work on the next generation build systemis to reduce build times by reusing binariesand also to reuse Debian packagingto avoid copying the Debian rules into YOKTA recipesHere you have the comparison with greenyou see some common features of each toolThis project works todayand our goal is to create the to reboot the whole thingand to create the next generation project with our shared goalsfor that we would like to define these goalswhat we would like to achieve hereso first we would like to name the thing somehowso one obvious thing is to combine the first lettersof our projects to aidand we pronounce it as aid in hope that it helps us and othersso what I personally like about the YOKTA projectis the ease of useso we have one command building with BitBakeand this is the only thing that the developerhas his first day working on this project has to knowthis is very important that all the details are hiddenin the first stage till you need thembut after you need to do some more complex stufflike adding new applications, adding dependenciesadding layers, etcyou will discover the recipe structure, dependency structureand so on, these use cases have to be covered in a scalable waythis is well done in recipes and dependencies between themit should be easy to customizethis also we know from the YOKTA projectbecause each recipe is responsible for its respective areaand by customizing the respective part you can get the customization you wantimportant thing is toolingwe would like to use existing toolsbecause Debian is about toolsand we want to use them as much as possiblewe would like to prefer existing toolsrather than developing our own tool sets for thatand use those tools also not as a forkbut by properly wrapping, connecting or enhancing them upstreamand if needed then contribute to upstream projectsduring that we would like to have clean minimal manageable architecture of the wholeregarding build targets, well this is a floating targetbut of course the obvious things are like build Debianizedor non-debianized sourcesgenerate ready to use images and generate SDKmaybe there are further topics like provide afterpositoriesthis is currently out of scopemaybe yeah regarding performanceperformance is one of the last topicsbut nonetheless quite importantso we would like to avoid rebuilding stuff every timeand reuse binary packages also from Debianand from our own buildingof course there is much QA that flows into Debian binary packagesand this is what we would like to usehowever we would also like to use cross buildingbecause in our experience it's faster than native building on native hardware or QEMOand avoid unnecessary stuff or parallelization blockersthat would slow down the whole thingand also of course this is a product oriented frameworkthis means we want to keep the reproducibility features of our projectsand have metadata layering for collaborationso here we have an example how this could look likefor those of you who are familiar with Yoctothis is quite obvious so at the bottom we have Meta8and then we have some layers for a company for projects and boardswith the difference that these recipes do not controlthey do not have the usual do build do install tasksthat do the actual thingthey inherit from one let's say Debian DPKG classthat builds the whole thing using Debian tools in Debian waythere are some nice to have thingswe personally find bootstraping Debian a very cool thingand it would also be useful for usif we had it for tuning for specific CPUsor for example one case where we needed to rebuild the whole projectback in all the times when Debian was built without stack protectionwe wanted to rebuild the whole thing with stack protectionand here where this would be useful if we could define project-wide extra C flagslast but not least is footprint is all kind of lower priority for usbut yeah if we could provide this it would be also niceso I'd like to pass over to Kazoo for current developmentfrom this slide I'd like to explain some technical partswe already defined some common visionsso it's time to define some use cases for our toolsthere are actually five main use cases hereand first one is to rebuild existing Debian sourcesby just typing the big big hello commandthis is an example for the hello packagewhich is included in Debian official packageand second one is to build Debianized sourceDebianized means the source tree which includes Debian metadatain this case we can also need to build the binary packagesjust typing the big big for example app1and third one is to build non-debianized sourcewhich is the normal case in your project maybebut in such case we also want to build applicationwhich is not Debianized or just building the boot loaders or kernels or somethingand then generate the root file system as decayit's also should be done by one commandlike a big big Debian imagewhich is all required binary packagesand generates a root file system or SDK imagesand to achieve that we need to implement at leastthe function is listed herefirst one is the source featuresin our case we usually use Debian source packages for the buildingso it's important to improve some feature functionfor the Debian source packages like the DSCand other important things is how to solve the dependenciesactually most dependencies can be solved with appswhich is throughout the same way as Debian worldbut actually we have non-debianized sourceand we need to implement a recipe for thatin such case the big big dependency mechanism help itand then we need to use the both dependency resolutionat the same time without any duplicationand of course the package builder is requiredand we need to use the same build package builderthe Debian official way which is sbuildand also need to implement some builder for the non-debianized sourcesin such case we need to put the source into the Debian change routeand use Debian toolchain and build itthe final is required thing is image generatorwhich is currently based on the debugstrapand we also have some possibilities to collaborateexisting toolsat least in Debian community there are many image generation tools availableso we are also looking for some chance to collaboratein such existing projectthis is a simple workflow of the current uploadfirst we needthere is a feature which just downloadthe Debian source package or the extra source codelike bootloader command applicationand this blue area is the Debianized worldand the green area is the non-debianized worldin the Debianized world all source code can be built with sbuildwhich is official build process in the Debian infrastructureand then we can get binary packageswhich is stored in the uptree repositorythen in non-debianized world there are two optionsone of them if the source code is very simpleand sometimes Debianized the existing sourceand after process is completely same as existing Debiansorry completely same as the processto build the existing Debian source packageanother way is to build with some low builderin the exchange route provided by sbuildand then use Debian to chainand generate just binariesthen packages to the uptree repositoryfinally generate the root file system with decay by image buildercurrently we have the featurescolor, red color things is available in our prototypeone of them is building the Debianized sourcesand also Debianizing and building with sbuildsome proper applicationwe can easily find some implementationby checking the GitHub repositorieshere is one example to rebuild the Debian source packagesit is very simple only three linesrequire to build the source packagesactually we need to define only the DSC URIwhich specify some URI to the DSC fileand after we inherit the Debian DSCall require source package files listed in DSCautomatically fetched by the systemand every build is done by sbuildby just inheriting the sbuild classthis is another example to build the non-debianized packageit is also not so complicatedthe first line means just to Debianize this source codeand put it to the build flowthat is same as the previous onethen the interesting part is the bottom three linesit depends some proper application of whocurrently depends on three packagesbuild dependency and runtime dependenciesif it depends on some other recipeswe can just define depends to for example partsthis is the same approach with the Yoct projectbut if the package just depends on some binary packageit already exist in Debian worldyou can define you can create dependenciesby just defining the Debian and other dependenciesregarding the build dependenciesthe both of the dependencies and the Debian herefinally go into the build dependency of the source packageyep, so the last part will be done by Manuelok, so let me summarize up what we've learned about the lasttwo years we are working together I thinkso we definitely learned that we can build SDK and root filesystems with our combination of BitBake and Debianwe thinking about evaluating more tools for doing the actualimage generation if you want to go to YoctoWay or DebianWay or maybe provide several options for doing this another thing we need to solve is the app repositorymanagement, currently we put all packages that are built intoone app repository but of course we need an easy way todefine which packages should be used from a binary repositoryand which packages should be re-builded from source each timeso this is another thing we need to think about and introducea solution, then it's about raw building of non-debianized sources, it's often preferred for your own application thatyou don't want to debianize it just to build it withina build system and therefore we did this prototype ofdebianizing automatically simple applicationsbut of course for complex applications that doesn't work at the moment and we need to think about do we want to supportsomething like BitBake does actually for building them orimprove the debianizer or what way we want to go therethen you'd like to customize, often you'd like to customizesome packages and also therefore we need to specify aworkflow especially for customizing currently existingpackages in debian for building them for example otherconfigure options or something like that.then we use currently QEMO emulator to build for doing theactual package build and therefore we'd like to dig intodebian multi-lib and as-build supporting crosstoolchains that we can use across toolchains insideas-build to have a native compiler in there.another thing we need to look at is reproducibility andall the management of the metadata and so on.So whatever is our conclusion of our work together,so it is possible to do it the way we think it should workwe learned that we want to rely on debian's infrastructuretools on debian cross-building features and that we don't wantto reinvent the wheel by our own.we haven't have even idea that it should be possible tobuild debian source packages without even having anybit-bake receipe in the file system so that we can see theinformation from the app cache directly into bit-bake.we have a pre-oof of concept code available on GitHub.I'll show you on the next slide.there we worked heavily on the dependency resolutionproblem over the last couple of months.of course we also learned that we often have tosupport the same thing in a different way because some peopledon't want to cross-build.they always want to do the native build because they have so complexapplications where they say I don't like to improve thebuild system that it supports cross-building.other say I need cross-building because of speed.so we learned that we need to implement sometimes two waysto do the same thing because the people have differentapplications on the process.another thing we realized there are many projects out therewith very similar goals and of course we are open so we wantto welcome you to join us so we just created a GitHuborganization called the AED project where we host ourprototype or the proof of concept code.we also want to use GitHub to track the issues and we implementedsome Travis based testing that you can also easily use to seewhat is working at the moment already.then we have created a mailing list where you are invitedto join us where we want to have the technical discussionsand where we do the review of patches.so for bucket reports please use the issue track on GitHubfor sending us patches please post them on the mailing list if you wantto join.we are here for today and tomorrow and we are happy to talkto anyone who is interesting.and now we have time for one last question I think.is there any?OK thank you.Somebody is using it right?Any question?So I have a working yoktor build.Of course I don't have the time to put it completely to something newbut if I happen to have a package that is no yoktor,no suitably yoktor layer available, could I easily usethe Debian package and your two classes you showed thereand would that integrate or is that something that would require more work?I think it's basically not possible because you're usingcompletely different versions of the glibc of the compilers and so on.You have different dependencies because bitbake names sometimespackages with other names than they have in Debian.That would be really, really a hard task.Thank you.Finished?OK.So thank you for your intention.As I told, we are open for questions here and there and on the technicalchokers portion you can ask questions about either.Thank you very much.