 Teemu Savula. Thank you. He already covered my name. I'm here representing Movial and the Scratchbox project. Within the Scratchbox project we've been developing ways to cross-compile Debian. And lately we've also been trying to cross-compile Debian from Scratch, which is even more interesting, at least in my opinion. First I'll describe the background of embedded development and Scratchbox, and then I'll describe how we actually managed to compile Debian from Scratch. Many of you probably already know this stuff, at least after you listened to Wookie's presentation. I was also hoping to see yesterday's presentation about cross-compleation, but now I have to cover this subject myself a bit more. So basically, embedded development is about low end devices, and usually weird architectures that you can't find binary compatible fast build machines for those architectures, except PowerPC, of course. But then there are some other even more embedded architectures. So you probably want to do cross-compleation. I'd like to say it's required, but it's almost required. At least if you're trying to build something as large as Debian, it's classified as required. And it's technically quite easy to do. Basically, cross-compiling source code file is quite well understood. It's just a compiler. But if you want to build software, it gets more tricky, because you have to deal with these weird building systems. Packaging isn't so hard, but it might also get a bit tricky. The key thing is configuring, and the key word is configure. And it's quite painful to work with. And in addition, you also have some requirements that are imposed by the architecture. For example, you don't have FPU, but you can work around that by not writing any floating point code yourself. But if you are trying to reuse existing software, you probably don't have that option. And you want to probably get rid of the runtime emulation of floating point code by using a soft flow tool chain. So if you missed Wookie's presentation, check it out. It's interesting also. Well, at least it is interesting. I don't know about this one. I'll describe the Scratchbox tool kit briefly, because I'll be talking about that quite much later on. I already presented a longer version of Scratchbox. I forced them, so I won't repeat it. You can, if you were good, but you can check it out. Basically, Scratchbox is a CH route environment. But it also provides all the build tools that you need in order to build a typical open source packages. And it provides a cross-compiler tool chain, or actually several to choose from. But it's executed so that it appears like a native GCC. This is the key thing about Scratchbox, because the build systems don't have to have any sort of cross-completion support. They just find the correct things, and everything just works most of the time. But Scratchbox isn't a full-scale emulator either. It includes QM and that sort of stuff, but it's only used part of the time. The interesting thing concerning this presentation is, of course, the Debian support. And we have modified versions of several build tools in order to make all this work. And DPKG is one of the important ones that we have modified a little. Here's a bit of history of our work. When we first added Debian support in Scratchbox 0.9.7, we also had to figure out a way to do Debian development in it and how to build Debian for ARM in it. And we call this project crocodile. Don't ask me where the name comes. Well, it used to mean something, but it doesn't mean anymore. So basically, we ended up working so that because of Debian's crazy dependencies, at least in some parts of the system, we ended up extracting packages and configuring them later. And that way we created root images. And we used those images or root straps in Scratchbox. We extract them there, and then we just start compiling custom packages. So pretty much the same method as Debian itself. So we start with ready installation and then add more or rebuild old packages. Well, obviously it works because Debian works, but it's a bit inflexible, at least from our perspective when we want to do custom systems. So for example, you can't easily rebuild Debian using software toolchain. You can start doing something like the C++ ABI migration right now and do it gradually, well, you know it's not fun. And also because of the early version of Scratchbox, even though it provided several build tools, DPKT didn't recognize them when you build a Debian package. So we had to fill up the target with build dependencies that never really go to the target file system at the end anyway. But nowadays things are a bit better. After improving the Debian support in Scratchbox 1.0, we started to do this thing again and we had a more ambitious goal. So we also wanted to cross-compile Debian from Scratch. And that's the thing that I'll be talking during the rest of the presentation. So this nice matrix thing graphic displays actually the two separate problems that we are solving. On the vertical axis you have the cross-complication and on the horizontal the traditional versus from Scratch solution thing. And it gets interesting when you combine these two. These cells two and three illustrate or represent the work that we are now doing, especially number two is our immediate goal. But it might be appealing for many other Debian developers to know that this makes it possible or easier to push up new architect support. So since every Debian system requires the essential packages, it's logical to start building those first. And obviously also need their runtime dependencies. And it's not so bad, only 47 packages, binary packages that you need to build in order to run bash, which is among the essential packages, which is nice. So we have a user interface. But when you start to look at the source packages that you need to build, everything blows up. And well, you have dependencies to X and well, a lot of things. Thankfully Scratchbox provides a lot of build tools. So you don't have to go and build every build dependency. And actually I'm getting ahead of myself a bit. When you look at this job, and you start to think, how can you compile Debian from Scratch? Well, strictly speaking, you can't compile anything from Scratch. You have to start with some resources. So now we have to consider what sort of trade-offs are we willing to make, what sort of compromises. And I'll show them next. So there are two key things about Scratchbox that helps us. Many of the, like I said, many of the build dependencies are only build dependencies. You don't need them at runtime. For example, Autoconoff. You don't need to install Autoconoff at the target in order to run a program that was built with all the tools. So we have modified the DPKG to recognize our build tools. And that helps a lot. But we still have these source packages that want to build several binary packages. And we only need one or two of those binary packages at the end. It slows the build down a bit, but that's not a real problem. So as we are cross-compiling anyway. It becomes a real problem if the unused binary packages have crazy build dependencies. And in order to fill those build dependencies, which might be library dependencies that you need at runtime, and those might have even more problems with their dependencies. So we end up with things like x, building x. Fortunately, the only two major problems in the essential system are glibc and gcc. And we have those in our cross-toolchain. Since we build our cross-toolchain ourselves, well, actually my rule of thumb is that if you don't install any binary on the target that you haven't built yourself, then you are compiling from scratch. And we are using our own cross-toolchain. So it includes target binaries that we need. And let's use those. This is the part where we stray from the Debian build system. But I think it's justified because these are fundamental libraries. Many embedded people probably want to use custom versions of those anyway, so it's convenient. And we built them with Debian packages. And we used the original upstream Debian control files to generate our packages, so they are compatible. So these two key things bring us down to only 100 packages. So from 200 approximately, that's an approximation because it's hard to calculate the real amount to do all these recursive dependencies. Well, maybe this, but I was tired when I generated these numbers. So we don't have any circular dependencies left anymore. And actually on Friday we finally managed to build this essential Debian system for ARM architecture from scratch. And there's a temporary page where you can get those. But it's still very much work in progress. And you also need a pre-release scratchbox to build that. And even that needs some sort of tweaking. But I hope that I can release a new stable scratchbox in the near future. This is the fine print. So we couldn't build the vanilla Debian system. There were some issues. Well, I don't know which one of these is the major issue, but at least several packages failed their unit tests. And I'd like to think that it's because they assume that the essential system is there. And in some cases that is actually the case. After we have built this system from scratch and installed it, then we can complete the tests successfully. But some packages failed the tests because the scratchbox environment is a bit peculiar. It's, well, just doesn't work perfectly. But that can be counted as a bug in scratchbox or those things that make this test fail. And, well, Perl is our long-term favorite. It always has something. But this time there were only two one-line changes. Other was that Perl wants to see if a user in Perl exists before it builds itself. And it obviously doesn't exist since we are building an empty file system. But that check doesn't make the build fail because scratchbox provides Perl in a non-standard location. And finally, well, this is my favorite nowadays. LibDB wants to build its Java bindings. And, well, I have tried building that by adding, hacking all this Java support into scratchbox, but I didn't want to commit it yet. Maybe we'll get around to supporting Java in scratchbox eventually, but just a depressing problem to fix anyway. So I'll just ignore that Java binding building for now. Okay. This is my message. This is the new Debian policy. Well, the Debian policy has so far ignored the embedded world mostly or completely. But there are some things that can benefit everyone. For example, making Debian buildable from scratch, well, it could theoretically help in the C++ API transition and also porting the new architectures and maybe also in testing build dependencies. So you can start with a minimum system and try to install all dependencies of package and see if they're correct and that sort of thing. And then there are small inconveniences for the maintainers. For example, if every package supported this node check option, it would be maybe two lines of additional, two additional lines to the rules file, but it would make my life easier and maybe a lot of the embedded guys would like that. I mean, maybe this node is not such a good idea because there's this, well, Riku argued that node is useless because there's this build in-depth and binary in-depth, but well, he's probably right. And these two last bullets are a bit more speculative. It would be nice if the source packages of packages that build essential packages wouldn't build Java bindings. I'd really like that. And you would think that it's not too much to ask. Maybe it isn't, I don't know. And this last one is, I first thought it was a good idea when I was brainstorming, but if all essential packages would depend on other essential packages explicitly, then you could calculate the correct build order from that. Currently, I just use like test in which order they build correctly and so far it has worked. But that would also mean that the dependencies of essential packages that are not essential themselves would also have to explicitly declare the dependencies to essential packages which gets out of hand. So that's not feasible. So some notes about the future. We are continuing the development of Crocodile and Scratchbox. It doesn't really make sense to stop with a system that can only run bash. It's not really useful. And we also have been thinking about an experimental port to Chris architecture. Chris is a really low-end architecture and we would only port the base system as a proof of concept. And I won't comment about the last one. And finally, we have some pre, well, designs for a new Scratchbox. I liked that the first one because it's so optimistic. Well, from Debian's perspective and Debian's developer's perspective, the many improvements would be that it's not one big tarball. You can install new packages easily, upgrade them. You could reuse your existing cross-compilers. We could reuse the cross-compiler tools provided by Mdebian. And also if the multi-arc goes forward, that could be an option to Sandbox. We could see two architectures of a multi-arc Debian system as host tools and the target file system of Scratchbox. And that would be convenient for Mdebian. So they would need this duplicate Sandbox environment. I hope that we can publish some longer design document about Scratchbox at some point in future. So you can ask questions now. Or if you are shy, you can join us on our IRC channel. There's no dedicated Scratchbox list or anything, but these are such low-traffic lists. Well, the channel is now more lively. Yes? One point about your goal to be able to exclude documentation. The problem is that when you're generating a normal deb, you're actually supposed to include documentation. So basically, we've discussed this issue a bit with Carlos from Nokia's OSSO department. And what seems to be the most probable solution is a better framework to automatically generate microdebs, which basically would give you what you need for the embedded side of Debian. Since microdebs by definition don't include templates or don't include documentation, basically just the binary and the absolute minimum you need to operate and install a given package. So basically a framework to generate that would be your solution, I think, so that you don't end up infringing the policy as well. So you're talking about UDebs. Yes? Well, that is probably much easier way of compiling from Scratch, but we are attempting to build a real Debian. And the rationale about disabling generation of documents is that if you are building an embedded system, you probably don't need them at any point. But if you are compiling from Scratch, you can go back and build them when you have the dependencies. Well, I think the difference here between why UDebs don't help is that UDebs are created using the same Debian rules and they say all the Debian rules creates documents anyway and we want to avoid creating documents because the documentation generation tools are the ones that usually pull the most evil build dependencies, which are not interesting for cross-compiling. Yeah, that is a good point because we are not so much interested what gets into the package. We are interested what goes on before we make the package. No one? I guess one possible solution in this case to return to this question is that if there would be a way to either have an extra Debian DEB helper or some other mechanism to strip documentation without having to have a separate binary target to generate or maybe some environmental variable to pass to a DPKG build package so that you end up without having to change the rule files still end up without documentation and basically building what you need without breaking the policy if you submit anything back to Debian but that would have to basically be passed as an environmental variable. You cannot put that in DEB rules, for instance. That is exactly what this DEB build options NoDoc does as far as I can understand your question. But does it successfully pass as a command line environment? If it does, then it basically already does what you need it to do. Well, we passed that as, well, not NoDoc but we passed NoCheck as in the environment variable for build package and works. Right. Okay, well, that answers my question then. Some packages check whether it's cross compiling or not and then do not run the checks automatically when there'd be a better option than some environment for you. Was a question that could you skip configuring and pass the results? You have that DEB build option NoCheck for you. Oh, that refers to unit tests. Yes. Some packages just look at other environment options like the host and target architecture and see if they're cross compiling or not. Yeah, actually, in Squarespace folks, host and target are the same because Scratchbox mimics or emulates or simulates the target environment. So you can detect that you're cross compiling. If you can detect that you're cross compiling, then this is bugging Scratchbox. Maybe that's it then. Oh, calm down. Did anybody try to build Debian for a big engine arm machine? Not yet, no, but since... Well, there might be some problems because Debian doesn't support big engine arm, so you might need to patch the sources more. But it's trivial to try that. You just compile a toolchain for Scratchbox using an arm toolchain that enables big engine. I have tried this for meeps, but there was an additional difficulty, so it didn't work yet. I have to investigate that. But anyway, in theory, that works for anything that Debian supports. And if you take an architecture that Debian doesn't support, well, you have to modify DPKG and patch some not so portable packages. No questions left. Okay. Well, I guess I should thank you then. Thank you.