 I guess I'll get started. Hi, everyone. Thanks for coming from the stock. My name is Prajo Mohun. And I've been working with Intel for several years. Before I started working on Tizen, I was also working on the Mego project. And before that, I was working on the Moblin project, if you guys are familiar with that. And I've been working on the build and release team for all Moblin, Mego, and now Tizen. So I wanted to talk a little bit about building packages for Tizen. And I wanted to give an overview about some of the infrastructure that we have for Tizen, like the source control management, the build system, the repo and image creation, how it all fits together, and kind of give you an overview of the Tizen tools that we use for building Tizen packages. During Mego days, we used the open build system, the OBS, for both building and source control. And we found that OBS, although it was a great build tool, it was lacking in some of the capabilities that we needed for reviewers and maintainers. So a natural progression was we switched to Git and Garrett for source control. I'm sure everybody is familiar with Git. I don't want to go into details of what Git is and how it works or what are the advantages of using Git. A Garrett is kind of the wrapper around Git, if you guys are not familiar with that. Android Google uses that. And it's a web-based review system, and it's a great tool for review. So when users submit their patches for review, then the maintainers can look at that. QA can give input, and a lot of other people can give input and comment before it's merged into the main line. As I said in my first slide, for users to be able to get to the Garrett for Tizen, you need to go register at tizen.org. So once you have an account, you can go to the Garrett web page, and I'll have a link for you at the end. Once you have the web interface for Garrett, for you to be able to clone all the code from Garrett, you would have to register the SSH keys. And you can do that by going to accounts and adding your SSH keys. You can have multiple SSH keys associated with an account if you have multiple systems which you want to keep all the SSH keys different. So once you have the clone, you could clone any project you want, and submit changes to one or multiple branches in that project. However, the maintainer and reviewers of the project would be able to merge the change that you submit into the branch, or create additional branches and other privileges that only maintainers would have that. So this is a general overview of what the Garrett would be. I wanted to talk a little more about OBS, which is our build server. OBS stands for open build server, and it was developed by OpenSUSA. And we have been using it for quite a while now. And it is a great build tool, and it takes care of all the dependencies and what not. So some of the fundamental features of OBS is the main thing would be a package. A package contains a source star ball, a spec file, and any other things that you need to build a given package. Other things might include things like a change log, or it might include an additional patch file, or any other thing that might be required for a given spec file to work. So once you have the package, you have projects with your collection of packages. So an example of the package would be a VI or GCC. And a project contains one or more packages. So for example, if you have a project called, let's say, Tizen, and it has over 1,000 packages, and it includes anywhere from GCC to bin utils to enlightenment packages and applications and what not. So once you have a package and a project which has all the packages that you need, you need to build them against something. And that something would be the build target. You could build OBS. OBS can be used to build against any targets that you want. You could build it against Fedora. You can build it against Ubuntu. You can pretty much build it against any distribution you want. But for Tizen, obviously, we are interested in building against Tizen. So in the Tizen OBS, we have packages for every single packages that are included in Tizen. A project which contains all the packages. And this project builds against itself, which is Tizen. And that is what we have in OBS. For registered users, you also have the ability to have a home project. Where in which you can create packages and build in your home area any package you want against Tizen, the mainline Tizen. The advantage of doing this is if you have any dependencies, OBS takes care of all the dependencies for you. Or it'll let you know that you're missing dependencies. And OBS is pretty diligent enough that if you make any changes, it will trigger a rebuild in all the packages which depends on the package you just changed. For example, if you have a package like GCC and if you make a change in GCC, almost every other package which depends on GCC, which most packages do, OBS, once GCC is done building, it'll trigger a rebuild, a cascading rebuild on all the packages which depend on GCC. Or if you have a project, let's say your home project, and you have an application in there, and somebody goes ahead and changes a middleware in Tizen Main. If you are building against the mainline Tizen, then OBS knows that your package in your home project needs to be rebuilt because some middleware in the mainline changed and your package depends on that package. So OBS takes care of all the dependencies. And also, for example, if your package depends on something which is not in Tizen, then it'll let you know that, hey, this is not resolvable because you're wanting to build with a package which is not in Tizen. So OBS is a great tool and it takes care of all the dependencies for you. And that's one of the reasons why we're using OBS for Tizen. So once OBS is done building a project, it creates what's known as a live repository. A live repository basically has all the RPMs it generated. RPMs might include the binary RPM, source RPM, debug source, debug, and develop RPMs. It creates a live repo. And it also creates a pattern with all the metadata. For example, if you need a group of packages, say, Tizen applications, which include multiple applications. And if you include the pattern, it'll create a live repo with all the metadata included in that. But the live repo is updated every time a package is built, successfully built, of course. So let's say, for example, somebody changes GCC. GCC builds and all the packages which depend on that rebuild. And once all the packages in a given project are done building, OBS publishes this live repo with all the changes that happen. For the release engineering team to make a particular release, we cannot work just off of the live repo because it's constantly changing. And it's bleeding edge. So what we do is we take a snapshot of the live repo. We take all the RPMs which were published in the live repo and create a snapshot. And once we have a snapshot, we also generate an image for various target, maybe a IVI device or just a loop mounted devices that you can use to cheroot and test your changes. So the snapshots will include the images. Release engineering works with Tizen QA to assess the quality of these images and the repos. And we publish the snapshots as a daily release or weekly release based on the quality criteria associated with the given snapshot, whether all the features that were required for the week or they are included in the image, whether they're in the aggressions, whether in the bugs. We include all that and publish the daily and weekly snapshots. The structure of a Git repo for Tizen is pretty much fairly fluid. We leave it up to the developers to create any structure they want. The only mandatory branch that is required is the master branch. The master branch has the complete source code. It also has the packaging directory which has the spec file, optional.changes file, and any other file that are required for packaging purposes but not necessarily included in the source. And we encourage people, the maintainers of the package, to have a upstream branch which contains the upstream code for packages which does not belong, which are not upstream Tizen packages, let's say, for example, GCC. This way, you can use the upstream branch to rebase master branch whenever it's deemed necessary. And usually, the upstream branch would not have any packaging information because most of the packaging information would be distribution specific. And the packaging directory would have Tizen-specific packaging metadata in the master branch. Once all the changes have been checked into the master branch, we can use the tools, which I'll be talking about a little later, to submit a request to OBS to be included in the build. The reason why we bifurcated the source from build is we did not want to hinder the developers having to check in all the changes to the main line when they're not ready, but yet have the flexibility of having been able to collaborate with other developers on the master branch and check into OBS only when they are ready to check it into the build system. So the overall flow would look something like this. The developer would check out the code from Garrett into their local system. And they would do all their modification, test their change, and use a Garrett push to submit to Garrett for review. The maintainer of the package or other developers would review the code. QA would probably verify the code before they give their input. And once the review is completed, the maintainer would either reject the change or accept the change. If it gets rejected, an email would be sent back to the developer to submit a change. If a reason is included, it would be included in the email as well. And similarly, if it's accepted, another email would be sent with an accept message as well. And once it's accepted, it would get merged on to get. And after several iterations of push review accepts reject, when the developer or the package maintainer feels ready to submit these changes to OBS, he would use the GBS tool, which I'll be talking about a little later, to submit a service request to OBS by placing a tag, which basically has a submit slash the branch you're submitting to. In many cases, it would be a master branch. And a date and time tag. And once that request is made, that's when release engineers comes into picture. And they review the code changes from a packaging perspective. So until now, all the developers, all the maintainers, are reviewing from a developer's perspective as to whether this change makes sense. Does it do what it's supposed to do? Are there any bugs in the code? And things like that. But the release engineer reviews it from a packaging perspective. As in, is the spec file OK? Does this package actually build against the Tizen? Are the dependencies listed in the spec file OK? Do other packages break because of this change? For example, if you take a change which depends on something else, and you're waiting for that change, accepting this change at this point probably might not be OK, until all the changes which depend on each other land in Tizen. So release engineer looks at these SRs from a packaging perspective and timing perspective before it's accepted into the main line. And once the release engineer accepts this change, that'll be built in OBS. And the live repo will be published, as I said before, and a snapshot is created, and the images are created, which are then used by QA as an input to the QA. An input to the QA. So to talk a little more about the roles and responsibilities, developers would write the code, then submit the code, and they would do unit testing and also local bills in their local machines, and then verify the changes and submit a merge request to Garrett. The maintainers would be responsible for reviewing those requests, and they have the ability to merge the change into the main branches, whatever that branch might be, usually it's the master branch. Other than that, they also have the ability to create new branches and have option to rebase if they have an upstream branch or fundamentally rebase from anywhere else that they choose to. And release engineers would be responsible for approving the submissions to OBS and smoke-testing the changes before accepting them into the build and reviewing from a packaging perspective and a timing perspective. So before I talk a little more about the Tizen tools, all the tools are available on download.tizen.org slash tools, and we have these tools available for various distributions like OpenSOSA, Ubuntu, Fedora, and CentOSA. So whatever the distribution of your choosing, you probably have binaries available so that you can just add it to your app repo or yum or zipper repose and install the Tizen tools. We also have sources for all of the tools. So if your distribution is not one of these, you should still be able to get the sources and compile them yourself. So one of the main tools that we have for developers for Tizen is the Git build system or GBS. GBS is a nice wrapper around most of the tools which are actually already available, and it makes it easy for developers to build these packages on Tizen. Some of the features are it can do local build, it can do a remote build, you can shoot into the build route and submit changes and create change locks or edit that. You can also clone, pull Git repository, import and export, et cetera. Well, you can do Git clone and Git pull without GBS, but what GBS does is it already creates a proper branch and checks out and tracks the proper branch for you. It also creates a local environment for you where you can build the packages locally. What local build does is if you have a package checked out, you can build it in your local system once you point it to a depository of your choice. In this example, it would be Tizen, so if you point your GBS configuration to Tizen, it would get all the RPMs that are required to build your package and builds it in a true route. Remote build does the building on OBS, so if you have checked out a package from OBS, it packages it in a way that OBS understands that would be a tar-ball spec file and other changes and submits it to OBS in your home project so that it will be built on the home project. True route into the build is a very nice feature if you have build errors. Let's say you check out a project, you did a local build and you have an error. For you to be able to go look at what the build error is or to run any debug to make sure that it builds okay, this feature can help you to true route into the build route and see what is going on, like what is the error, am I missing any packages, am I missing any dependencies, so on and so forth. And finally, when you're done with all the local building and submission local building, then you would want to submit your changes. One of the things we recommend developers to do is include a change log with your submission so that it can kind of give you an idea as to what changes that you're trying to submit and the submit itself will create an annotated tag with the format I just mentioned before and submits the changes to OBS for review by release engineers. So what GBS is fundamentally doing is kind of providing a nice wrapper around some of the tools which are already available and provide a local build feature so that developers can use GBS to do everything from checking out cloning git trees, checking it out, or doing a local build, remote build, route into the build, or submit the changes. Well, one other interesting feature of GBS which sometimes developers would need would be the import and export feature. Usually when you have any upstream packages, all you will have is a git tree or a tar ball which does not necessarily might not be formatted in a way that OBS would understand. That is, it does not have a tar ball with a spec file and other changes as a file. It would just have a git tree with all the sources and the GBS, what it does when you do an import is you can import a already pre-built source RPM or a tar ball or any OBS into a git tree to create a nice git tree for you with the packaging directory, with the spec file and other things in the packaging directory itself. And export does the opposite of that. If you have a git tree and you do export, it will export in the format which is understandable by OBS which is a tar ball in a spec file and what not. The format of the tar ball would depend on the spec file. It looks at the spec file, parses the metadata and looks at the version number that is mentioned in the spec file and creates an appropriate tar ball which can be used by OBS. So as I mentioned earlier, GBS can, you can download GBS from download.tizen.org slash tools and we have various repos available for various distros. You can add the metadata to your YUM or app or zipper repo and do a zipper install or YUM install to get GBS. GBS has three configuration, three layers of configuration. The main configuration file would be at cgbs.com and there's a local configuration file in your home directory.gbs.com and you can also have a project specific GBS configuration which would be in a given directory and .gbs.com and like any other configuration file, the project specific configuration file would override the local configuration file and the local configuration file would override the global configuration file. And you can also, other things that you can configure in GBS would be the build root location where you want the build root to be and the repo URLs. The repo URL would be important is because you need to tell GBS what to build against. So if you have checked out a package, let's say an application, you need to tell it what to build against. Am I building against Tizen? Am I building against a given snapshot? Am I building against the weekly release? So this repo URL tells GBS what the packages should be built against. You can have multiple profiles which says that for this project, if you have a project specific configuration, you could say for this project, build against the snapshot which might be more latest snapshot available, latest snapshot available, or you could say build against a weekly which is a little more stable. So you could configure multiple profiles either in the project or local configuration or the global GBS configuration. You can also configure the API URLs for OBS if you want to do remote builds if you have a home project in OBS. So the GBS, if you do a local build, it would look something like this. So you would have a source code in a, checked out in your local home directory. You would have a binary repo in the GBS configuration, the URL I mentioned, like what to build against. And then you invoke a GBS build. When you do a GBS build and it succeeds, it will create a local repository with the RPMs built. It might be one project or it might be multiple projects. And a good thing about that, it actually creates the metadata for the repo just builds as well. So you can use the local repo to build next time. Say for example, if you build middleware and it builds successfully and you have another application which depends on the middleware. And if you want to build that middleware, you can include, if you want to build the latest application, you can use the RPMs in your local home, local prod on your local system to build the application so that you're building all the packages that you have consistently with each other and not just against the main line Tizen before you submit all your changes. So GBS provides a great way to do that. You can include multiple repos, multiple remote or local repos in the GBS configuration and it will follow the rules of Zipper or YUM, whatever package manager you choose to select which version is the one which gets built, usually be the one with the higher version number or if you have a epoch that will get used. So an example of how you can build GBS would be GBS build dash A would mention the architecture. You can also have many other ways you could do a GBS build. If you want to specify a one-time URL along with the build, you can do it with the dash R option. We have extensive documentation on how to use GBS on social.tizen.org and GBS dash help will also give you all the other options that you might want to use but fundamentally you're building, you're specifying what packages to build that would be the local directory and what architecture you're building it for and the GBS configuration would have the repo where GBS would know where to fetch all the RPMs that are necessary for your package to build. And once all the build is done, the next step would be to create images because now that you built your RPM, you could test it in multiple ways. You could install the RPM that you built on the device you have and make sure it works but if you have multiple RPMs that you just built, it's not very easy to have all the RPMs transfer it to your target device and then do an install. Instead, you would want to create a new image for yourself with all the changes that included and that's where Image Creator comes into picture. Image Creator uses a Kickstarter file to create images and it can create images in multiple ways. You can have just a file system image, you can have a live CD or live USB or just a loop device or just a plain raw tar ball. It also has other features where you can chute into the image once you create it and it has an option to convert one format to the other format. Let's say for example, if you had a pre-built image from somewhere and it was live CD and you just want to have a loop image out of that so that you can just loop mounted on your local system to debug anything that you might want, you can convert from one format to the other format and chute happens to be a very useful feature too if you want to just chute into the image and you have the file system and you can manipulate the file system from your local system and then flash it onto the target device for any kind of debugging that you might want to do. So as I mentioned before, Image Creator uses Kickstarter file to create images and Kickstarter files have really really simple format and fundamentally it has three components that you need to specify. Where to find the RPM repository? What needs to be installed? And if you need to do any post installation scripts, whatever that might be. So where to find the repo would be you need to point in the Kickstarter file the repo where all the RPMs are and the RPM metadata is. So in this case it might be download.tizen.org and the entire repo URL. You can include multiple repositories in the Kickstarter file and as with GBS, if you have the same package in multiple repositories, it would pick the one with the highest version number and follow the kind of yum and zipper rules for picking which version to use. The RPM repository does not necessarily have to be a remote URL. It can also be a path on your local file system. What to install? So once you specify that here's the repository which has all the RPMs that I need to create the images with you need to tell Image Creator what packages needs to be installed. It can be done in one or two ways. First way is to explicitly mention every single package that needs to go in the image. Obviously it's gonna be really really cumbersome and the second way is to use groups or patterns. So in the Kickstarter file you say install the standard applications. There's a pattern standard application. You can just say install all the standard applications. Or you could use a combination of both. You can use a combination of explicitly installing a particular package or a pattern or both. And lastly the post install script steps. So after you're done creating the images, after you're done installing all the RPMs then you might in certain cases might want to do some post install operations. Like you might want to edit a configuration file because there's a bug. And you want to edit a configuration file to set certain parameters correctly. So you can do that in post install steps. An example of a mic command would be to create a here. It's creating CRS for create and it's creating a loop device. The sub command uses the kind of image that you're trying to create. Either it can be live CD or live USB or a loop image or a raw image. And the kickstart file that needs to be used to create this image. And mic has other options as well which is documented on source.tizen.org. So this is fundamentally the flow that we have for developers is you'd go register on tizen.org and create an account. You would go to the gared site and then upload your SSH key so that you'd be able to clone the projects in Garrett and to be able to submit and review the changes on Garrett. You would use GBS local build to do local changes and then build those packages and test it, verifying your local system which might include creating images on using mic and create images with all the changes that you have and test it on an actual device. Then use GBS submit those changes to be merged into the master branch and place submit tag and that would get submitted to OBS where release engineer reviews those changes and either accept the changes or reject the changes. And that gets built into a live repository and a snapshot where the stock images are generated and those are also available on download.tizen.org. So I basically went through the overview of the entire tizen build process and I wanted to give more time for people to ask any questions and open for discussions. I'm not sure about the timeline of when that will be released but basically from my understanding is that the standard SDK image came with the repo URL in the image which was deprecated because we kind of changed the structure in download.tizen.org so the new images needs to reflect those changes in the URL but I'm not sure when that's gonna be released. Sure. We decided that we're gonna have RPM packages for tizen. I don't think we're gonna have support any other packaging format for tizen. However, OBS has the capability to build the DBN packages as well but we do not use that for tizen. Sure, that's a good question. What you do is if you have a local git repository you could just populate that with whatever content you want and you could use all the tools which I just mentioned, GBS and MIG to build it locally against mainline tizen and then use image creator to build an image locally. So basically you would take a kickstart file from download.tizen and then modify the kickstart file to include all the packages that you just created and create your own image and you'll be able to flash it on any device for your testing. If you want that to be submitted to tizen you have to request a maintainers like, hey, could you please create a package in Garrett and if the maintainer accepts that then you have a package on Garrett and then you could populate the Garrett project and then submit it to OBS to be included in the mainline itself. Correct. Correct. I have submitted the slides to the collaboration summit people and should have them available. All the documentation, detailed documentation that are available on socials.tizen.org, please go check it out and if you have any questions do email me and I'll be more than happy to answer your questions. Sure, go ahead. I don't think it can as far as I know. We have a Samsung lunchboxes that were available which can run tizen but I'm not aware of any other platforms. There would be a great project to take tizen and see if it can run on a Nexus. Thank you.