 half the time, maybe a bit less, if you just ask for a cross compiler please, it will complain that it can't install because they get out of sync with, Debian changes theirs, it takes us a while to rebuild, and that breaks, which is very annoying. I get quite a lot of complaints and there's a lot on the mailing list saying, you told me to install this compiler but it says, well, apt can't because of long complicated list of complaints. There's this building them in Debian plan, I don't know if that will help, do you want to say something about the uninstallability problem? You just want to talk about how this works. Hello? Yeah, we have agreed a mechanism to have proper cross compilers under Debian instead of having them in Debian repositories. I guess nobody can read this, can you? No, sorry. I had to make it fit on the screen so I made it smaller. We could have it so that you could only see the top three lines, then you could read it. We'll try and explain. Yeah, okay. In fact, I'll keep that in case I need it later. The uninstallability problem is just some dependencies that the cross-touching has with the GCC-based package and yeah, I think that's it. Maybe some other libraries, there was a dependency with LibGump with this library for big machines with embedded, doesn't care, but this has been removed because it also caused problems with the native compiler and it has been removed. So we are planning to, and the problem is we have one source package and we upload this source package into the build-it-is and that builds the native compiler. There isn't a PDF. I did make. Well, you upload a source package to the auto-builder and it builds the native compiler and we don't want to depend on the cross-touching as well in the same source package. So we need to have other source packages to upload into the build-it-is and this, we have designed a way to do that by, maybe the other one, the, by. You don't need the diagram. Yeah, we have some source packages that depend on the binary packages containing the source, like the linker, the compiler, the kernel headers. You have the linker, you have the compiler, you have the C-library and the kernel headers. All this is involved to build a cross-touching. We have circular dependencies with C-library and the compiler library and we need to implement the first stage bootstrapping in the Debian compiler, because right now it only builds two states and in order to fulfill these dependencies correctly, from source, you need to do a three-stage bootstrapping of the tool chain. And the first stage needs to be implemented. And basically, this is like a dependency tree and that's how we are going to build this tool chain. I know you have some questions about it or you want me to explain a little bit more or this more technical. You can come up to me, I'm around and we can talk about it. So the point about this is it doesn't need any cross dependencies so we can do it with the existing builders, is that right? Yeah, and this will be done in Debian so when GCC uploads and then this will upload in the same day probably and it will have the same versions. It will be right in sync or in sync. The problem is that if you type de-package build package in the G-Lib C sources nothing happens. That's what I'm talking about. Oh. You mean our diagram didn't make sense to you. I can't see the diagram. I'm sick. Okay. Yes, right, good. Do you know when, how long will this take before we move to doing it this way? This can be done very well. We have to implement the first stage, bootstrapping and then when that's done then we can, yeah. Okay, yeah. So that should be good. That'll be cool, I hope. Maybe take half a year or... So, for those of you who've been following the multi-arch debate, this actually is quite fundamental to how people cross-build things at the moment. Like I say, to some degree this is a cross-compiling discussion and not an MDB in discussion but obviously quite a lot of us are cross-building things. I know how many people here cross-build things? Okay, a few. How many people have ever used MDB for anything? Slightly more. Wait for the mic. In my packages, Neil have sent me patches to support cross-compilation. Is there any way I could test that this is still working because during one of the changes we dropped one of the variables and it stopped cross-compiling. So is there anything I could do to test that cross-compilation is still working in my packages? Yeah, there's a couple of ways. So there's two parts to this. There's cross-building it at all. Are you exactly the same package or there's cross-building it in MDB and which implies applying our patches as well. Do you want to test the bare package just the cross-build part? No, what I mean is if there's any way like running few parts to cross-compile my packages so it's still working and I see if it's working or it's not working. You can get the cross-compiler from the MDB in the repository or zoom from MDB directly and try compiling your package with the package build package dash a some target architecture you have a cross-compiler for. So fundamentally it's that simple. Instead of typing dpackage build package dash rfake root you type dpackage build package dash a rml dash rfake root see if it works. But the problem with that is that you need all the cross-dependencies installed that allow it to build and that's the hard part. Now you know what your cross-dependencies are for so your own package is not too difficult to install all cross-dependencies which you do with dpackage cross or apt cross you should be able to say apt cross package your package and it goes and gets all the cross-dependencies and installs them. But in practice that doesn't always work it works if your package is very simple. Yes, but it would be very nice if this could be integrated in let's say pure parts because I always run pure parts with my packages. So you don't want to know anything you just want it to work. Okay, I mean yes you're right that will be really nice and no it's not in pu parts I don't know how easy that is. Yeah, that'll be a useful thing for somebody to do. I don't know how hard it is. Also I have set up an experimental repository of dpackage cross packages for army L. So you can just point apt edit and you get all the like lip something dash army L dash cross packages. Yeah, so the point is the cross packages you can either build them from the arm repository and actually generate a cross package now this minute or if somebody somebody could do it in all advance so that every package that needs crossing is already crossed and then apt can just get it. So you don't need to do the crossing you don't need the cross machinery to work but you still need to install the dependencies. Yeah, anyway I'm going to figure out how to do this and send the patch to the people. So yeah, I'd like to be able to use P builder effectively to do you know P builders good it would be nice if P builder cross worked but fundamentally it doesn't yet. So that's actually the bigger the in practice our cross building for the M. Debbie and the light writer do at work works except for the fact that the automatic dependent installation of cross dependencies isn't really ready yet. So you have to you have to tend your troops and make sure they've got the right things in advance and you depend on the cross compiler. So the first step is to get the cross compiler into proper deviant. So you can integrate in pew parts or whatever build the build systems and also this is very helpful for QMU people. We have a talk afterwards to build some bios a boss or this kind of things they they build for other architectures and and right now they they do it manually or do it or either have to hack it a little bit. And this is so the first step is getting the cross compilers into deviant and then everything will will come. Yeah, then there's something for all the charooting build tools to depend on and say well you need this part. So yeah, you're right that'd be really nice that when that's that's nearly where we're at where we have all these things starting to happen so that it's it's looking like this will be possible. And also there's this very few few people of us and not all not all of us are working a hundred percent on on the deviant. If this is like a few more people getting excited about going oh really I could do that that sounds useful and would have things go faster. Did you want to say something else on it? I am the light writer. There we are that light writer that's all cross built and in fact is running MW and Grip. So people really do use it. Where is it? It's sat at the back plugged into the sound system. So yes so I get to do this for work. She's good. Dependency stuff all changes. Yeah so this is about the transition to multi-arch really. I guess we've covered that. One thing that just popped on my mind. Okay for Debian not for variants would it make sense to... Yes sorry that's what I was gonna say. To have another triplet for variants and basically treat your variants as a separate architecture and still remain within the multi-arch system. No because so the problem here is multi-arch is great lets you install all the cross dependencies side by side and build things and it's all very simple. The whole process actually gets simpler because now you just want the package. You don't need a special package munged into the native architecture with a different name so that we can install them side by side. It all just works. However it only works because the host... Now for those of you not familiar the terminology here is thoroughly confusing. The build machine is called build. The machine you're building for is called host which most people kind of think of as the build machine and you don't call it target because that's something else only to do with cross-compilers. So when I say host I mean the thing we're building for. This stuff... a multi-arch only really works where the host versions of stuff that you're trying to build is exactly the same as the build versions of stuff that you're trying to build because as soon as you run binaries or check config files if they're different it'll all fall over because the only thing you've got the foreign version of is the libraries. You haven't got the foreign version of the config files or users share anything which defines what was supported by this build of the package. So it only works basically if you're trying to build something that's almost exactly the same as the system you're building it on which is a major limitation as soon as you're doing proper embedded you tend to want to build it without LDAP and without X. You actually want to make changes in the packages and now the config files have changed but you can't install the host version of the config file and the target version of the config file on top of each other so you have to do it in a charoute or at least a GCC sysroute maybe in order to have a whole file system containing all the stuff you need and the problem with that is that you also have to have all the tools in there you've got to install scrollkeeper and latex for building documents and sgml tools and all sorts of garbage you didn't want just so that you can build the package. So a lot of the stuff we've been talking about this week allows you to cross build Debian. Doesn't necessarily allow you to cross build something a bit like Debian which in practice is what most embedded people want to do. That's a more complicated problem and it's important to bear that in mind when thinking about different ways of doing things. Did that make sense? I lost everybody yet. Basically if you'll just link against the libraries you don't care about the config files. Yeah but you don't just link against libraries when you build something. It's a very simple package you just link against libraries but anything at all GUI runs all sorts of weird checks and things to determine. I mean even just the tools the autocomf can go and check stuff whether such and such is supported and if it finds a library for x it'll go and build it with x it's supported and that's not what you wanted so you have to do configure without blah. Yeah well but the autocomf checks usually know about cross compiling. The autocomf check should work and if it's not we can fix that but as soon as you run binaries like oh I don't know someone find me a good example. You need to look sorry. Okay font config I think is actually quite a good example. Font config knows where it should look for its config so it's very likely to get the build systems config not the target systems config and then generate stuff for the whole load of fonts you haven't got and didn't want on the machine you're trying to build but I think in practice there are lots of examples of this problem. We haven't come across it too much because we build relatively simple things that just needs libraries and tools but as soon as you get into GUI building have we got any of the mayor people here? You know about this don't you? You see you just avoided the whole thing by using scratchbox so it all goes away. But I mean the reason scratchbox was created well one of the reasons was that it is very hard to get all those tools and things to be right if you try building in the the whole system without a charude. So we can build all of GPE and that works but we mostly do it in a charude anyway just to be sure. So it's something to think about but yeah I quite like your idea of a separate architecture. Well no that solves it's interesting but I don't think it solves the version skew problem as perhaps I shall call it. So another big part of this is what happens if you want to build a different version of things. There's relatively simple stuff like taking the docks out which works very well in Grip. It will be nice if we could get no docks support in the build tools like debhelper and CDBS as a debbin build option like no strip no test which I think are the only two that are normally supported isn't that right? Is there a debug option? Debug is sort of implied by no strip. Yeah okay. Basically the policies as we always build with debug symbols and then strip them off. So one of the few things that's fairly obvious is you know basically every mdebian patch avoids running DH docks, DH install docks so they don't get installed. That works fine but it does mean you don't end up with a copyright file either which you might argue is not to kosher with the GPL. Mike? You cannot trust debhelper and CDBS to do all the things that gets installed in dock. No true. There's nothing to stop people just copying them in as well. Yeah exactly. So we'd have to patch that too but most things these days just list the files and get debhelper to do them. Do they not? Or CDBS. Or CDBS exactly. I mean I see fewer and fewer exception lines doing things manually in a lot of packages. It just does the right thing but you're right you can't rely on that it's not a complete solution. Or they use them and then they rename things afterwards. Yes. So that renaming will break if you try to override or suppress these parts of the debhelper. It's true. Basically that's a major limitation in debhelper. You cannot rename files while installing them. DH install only supports a target directory not a target file name. So if you want to have a file with a different name in the resulting package than it has had in the source package you need to rename it either before DH install time or afterwards. Yes true. So the debhelper no docs patch has been installed since May 2007 or something. So you have to persuade Joey it's a good idea. It is a bit crafty but it's a very easy win. Effectively that's what grip does. Pretty much. And it is quite effective. He's not here is he? Lazy bugger. There is an alternative to this which is to use d-package filters so you make the package the same as before but then you filter at install time which is more reliable because you'll definitely remove everything in user share doc. So the package size doesn't decrease. You still want to download it. But in a lot of context that doesn't matter much. So I guess that's something we should look at some more. Does grip use d-package filters to actually do the filtering? Nobody knows we need Neil. I think so. What else? A much harder problem. There was an interesting idea which Jonas had yesterday. So one thing we've discovered from doing this. If you make an MW and grip route it's about 90 megabytes for a base system which is quite a lot better than 400 meg or whatever 200 and something out of it. That's our base system with a fair amount of libraries in it. However as soon as you do app get update the first time and point it at W and it gets 50 or 60 megabytes bigger. So it gets more than half as big again just because of the package files, the list files, the cache files, all that stuff for managing our marvelous package system. And that's a big overhead. If it was 10 meg that would be good. 20 meg that wouldn't be too bad. 60 meg is far too much. And a lot of that is just the size of the package list. 22 megabytes compressed. So one thing we do in grip is chop off all the long description apart from the first four lines which makes an enormous difference to the size of the package file. So that's a good idea. Jonas suggested we could generate better package files on the fly. You could have a little proxy thing. So this would allow you to use real Debian but still to have a sensible size packages list. And also filter it further using DevTags. So it only includes, in the final list, includes the packages that is tagged in DevTags as being relevant for this embedded device. So we can tag everything embedded which would get you part of the list. And I don't know. You'd have to work out what suitable tags. But we can have any tags we like. Is that right? Or we have to ask Enrico for new tags? I believe we can throw in tags. We can even have a repository of DevTags ourselves. But that's more cool to work together with the DevTags people of course. So that's actually quite interesting idea because you now make an amazing array of distributions just by making new lists and pointing at the normal thing and then using de-package filter to filter stuff out. Interesting idea. So de-package vendor. How are we going to explain this? I don't know how this works. I tried to find out last night. I don't know if anybody else does either apart from, Neil is about any personal world who's actually used it. Simon's thought about it quite a lot. So this came out of the Debian Work session a bit over a year ago here where we were trying to work out a mechanism for dealing with the fact that hundreds of people make variants of Debian. Ubuntu is the most famous. Are we second most famous yet? I guess not. Limpus or somebody. Nopix. Yeah, okay. Do they actually build from Debian sources? I'm not sure what they do. That's lots of weird shit. I think they do now, yeah. Okay. So and they all want to build something with some changes in the rules files generally. We certainly found that we can do everything we want by only changing stuff in the Debian directory. We never have to change anything in the package itself or almost never. You can pretty much do what you need by changing the Debian directory stuff, which is nice. That limits the surface of the problem. But it would be nice to have a generic way. So the problem with all the patches is they're hard to maintain. We want to put it into the package, but we can't really have every package listing if Debian do what I normally do, if Mdebian do something they told me to do, if Ubuntu do something else they told me to do, and so on for a list of 100 distributions. That doesn't seem very maintainable. The deep package vendor stuff also has inheritance. So basically, we just tell it to if it's Debian or derived from Debian and not derived from Mdebian or Ubuntu then do this. Okay, so we can have hierarchical rules. Yes. Okay, which might work. Doesn't that mean you need to know what the other guys did in order to decide what to do? Basically, you base your distribution off an existing one and so you tell the package vendor that you are deriving there and all the packages will basically default to the distribution you're deriving from and then you just have to add the patches you need. Okay, so the attractive idea is that the 97% of packages which are the same as whatever you chose for your upstream, you don't do anything to and the few you want to change, you add some information. So in theory, this is quite a nice generic thing. But as you can see, this is the sort of thing people have to put in there. So the top half is the obvious way of doing this in a rules file. You know, you check the vendor thing. And if it's not Debian, then do something at a whole lot of different configure args, which isn't very beautiful. Actually, it's actually it's even worse than this because you have to check the inheritance tree. Like, you have to do yourself. It doesn't kind of magically happen. Yeah, basically, you have a list of things you check. For example, you start by checking, am I am I on Mdebian? And the answer is either yes or no. If the answer is no, then you can ask, am I on Ubuntu? If the answer is no, then am I on Debian? The answer is probably going to be yes, because every distribution is derived from Debian. Yes. Okay, did somebody else? This is not very like the nicer solution. This is the better solution we have come up with. And if you come up with a better solution, it'll be good. Because the package maintainers don't like to have like, let's say you have 10 or 15 this derived distributions, you don't want to pollute all your rules files with all these these an entrance for each variant. So the idea of the lower half of this screen is a recent suggestion for making this generic or more generic. So you run this Mvendor with a vendor and a package on the key. And basically we have sorry. Oh, there is. Yes. Hi. Please don't do the lower one because because if it's not equal to Debian, if it's a bun to say, then we get the embedded version of the package. And while we like it, we don't necessarily want to have a bun to be an embedded distribution. That's true. Yeah. But the point was, you'd set your vendor to whatever. So you would have set when you're doing a build. Overall, you say my distribution is a bun to. So now it would say Mvendor, vendor a bun to package of R he key whatever. Yeah, but that require that that would then require us to modify every single source package in Debian to say, to say a bun to is like Debian. Whereas the DPKG vendor stuff supports the inheritance which which we which we were involved in because because that's useful for us. So we just if we want to make so we can say we are derived from Debian and then we can have DPKG vendor derives from a bun to which we would use for our customization so that our derivatives then inherit. You're already using this mechanism. It's very new. So we haven't we haven't deployed much yet, but we were involved in the creation of it. So yeah, so we like it because because it allows us to and I think that's more of the reason why it's happened does asking for stuff doesn't necessarily cause much action. I guess a bun to asking for stuff is a little bit more that I don't think we asked for it. But I think we thought of it and people went we should tell you bun to people because they might like this might be useful. Yeah, it's good. And the inheritance stuff is good for us because we we want to we want to say that we inherit from Debian. So we get 99% of the packages correct, like you said, did but also support our derivatives. Okay, so I guess we should sit down afterwards and look at what I agree. I agree. There could be a better way of doing this. So the tools support it more. You said largely, you know, the package maintainer shouldn't really have to do anything. You want some magic so that you know, it's just set and stuff happens. But I think somewhere somewhere it has to say what happens for the different variants. And the question is, where should it say that really should go in the rules? The maintainer doesn't necessarily want to know about every single different variant of there being there is. But there's also an argument that when you open a Debian rules file, you should know what it's going to build. You shouldn't have to you shouldn't have to then go and check a separate repository, which says, here are the changes that are made for this distribution. And that's what the second flavor does that actually goes and looks off in slash ETC for, you know, ETC package name, key name, blah, you know, basically put the database of things. And the problem with that is, as you say, you've broken the fairly fundamental idea that the rules file does tell you what's going to happen. You could, you could, you could, we could actually use the second version, but just write it in a slightly different way so that you don't necessarily, so you don't get the embedded version if you're not Debian. So it should be, it should be a check for if we're derived from Mdebian, then we use the second version or something. But yeah, something in the tool so you can do package name dot install dot Ubuntu or package name dot install dot and Debian, which doesn't include the documentation or something like that. That might be, that might be an interesting thing to pursue later. Okay. Good. Thank you for the clarification. Who are you? Are you representing Ubuntu or are you talking about something else? Just curious. Ubuntu. Okay. Thanks. Okay. This is an enormous subject and we've only got a quarter of an hour left. Does anybody else want to say anything about this whole, what the hell do we do about variant stuff? Or again, just for clarification. This example you're showing here, that is intended for being put into each package or that is intended to be put into an DPK vendor configuration file master on the system that you're building. That goes in the rules file. Oh, it's not pretty, is it? Yeah, the biggest problem basically is if we want to use the inheritance stuff, then basically since there is no ordering on the names of the of the different distributions, it's very hard to decide. For example, if we have a, if we have a, if that helped gain support for that deep package render, and there was some install.dbn, install.mdbn and install.ubuntu, then it's pretty, that's a simple case basically because it's, it's pretty obvious which one is the most specific because it's, because these form a tree, but at some point it becomes, but for example, if you just have install files for two base systems, like embedded Debian and embedded Ubuntu or something like that, or embedded Debian and Ubuntu and you end up with an embedded Ubuntu system which install file should take precedence. Yes, it is tricky. I mean, I think something to think about, bear in mind when thinking about this, is that there's a set of changes which are actually changes by type and not really anything to do with the distribution as such. You know, no docs is actually just that, take out the docs. Now, that's something that a set of distributions would like, but there will also be a set of changes which really is quite specific to the distro. And this is a mechanism to let you choose both of those things, but I think we should try to have generic mechanisms like no strip and things which are, you know, entirely agnostic and just have a purpose, some purpose we can actually define that is useful and is worth doing because one thing that is, given the binary distribution focus of Debian, there is a limit to how customized things can be, you know, without rebuilding. We can only build a fairly small set of things, you know, a headless Debian. You kind of get that already, but you know, a small Debian for a headless box, a small Debian for a PDA. Like Hecton, we also discussed a little bit yesterday. I see the difference between some of the flags we are using today as the no strip and then some of the things that are needed here. The difference I see in this is that things like no strip, you don't want to ship such a package typically. You want to build it for testing purposes and then you want to throw it away again and have it go back to the proper package. Whereas things like no ex or no doc is typically things that you want to ship. So I'll throw in the idea, the way I see it is like what we're talking about here, yes, technically the mechanism should be like flagging similar to the ones we know today, but the difference would be like, I would call it flavoring. Like a very few packages, Debian packages today have multiple builds providing actually separate binaries, binary packages for variants of Francis libraries or variants of packages like no GNOME versions of the package or like I do with one package that people have shouted at me about was providing a no ex version of LibGD. That is really different flavors. And I think in the discussion of trying to find a common sense of what kind of flavors do we want separate from the discussion of what kind of flags do we want to signal for the compilation. You're right, there's a lot to be said for a package knowing how to build these several variants. Basically different configures, sets, and it spits all those out. And the problem at the moment is that you always have to build all of them, I guess, which is a bit slow, perhaps. One thing that's really important is if you change the dependencies by not having X, for example, it does need to be a different package name, at least if you want it to go anywhere near the rest of the Debian packages. If you want to mostly use Debian and change something like that, it has to be a different package name. You can't just go changing it. That is exactly why I'm talking about this not being a compile flag, but a handling of flavors. Because I'm working on, I have support for this, not officially, but I am working on pushing it into the official CDPS support for flavoring so that you simply say, oh, there is two different flavors. Then it actually, from the full build system, makes sure that it gets rerouted into multiple binary packages. There's different places in the chain that could use this flavoring mechanism. Not as a, we force all Debian developers, they should all support these and obey all these flavors. No, no, as optional. If you want to be nice to the Debian people, then have in mind if this package might want to provide a No-X version also. If you say, what the fuck? This is so tied to X that it only makes sense to build it together with X, then don't support this flavor. But just having a common consensus on what flavors are, what are we talking at, multiple optional variants. Yeah, I think that's very sensible. So we're a bit short of time, so I think we need to talk some more about that. I think that's a really good idea. Just to cover the other issues that we care about in case anyone gets excited. C-Library, it's not a big deal, but it does ship an enormous amount of time zone crap and, not time zone, all the locale information which we then, from which you generate the actual locale information. And it kind of annoys me that to get my two megabyte C-Library, which I've got to have pretty much, ignoring the whole UC-Libsy thing, I have to have four megabytes of files for locales I never wanted to use. So in familiar, they do this by pre-generating them all and you only install a tiny little bit. And that's much nicer. The Aurelian doesn't actually want to change it all for Debian, although it is gonna get compressed, which will make it a lot smaller than it is now. But if anyone wants to work on a better packaging of G-Libsy for our purposes, that would be nice. The biggest problem we've found in Crush or using Busybox instead of CoreUtils is the millions of maintainer scripts and init scripts that use command options that aren't in Busybox. grep.x-x is a good example. Quite a lot of things do grep-x in their scripts. If you replace the normal grep with Busybox grep, doesn't work. Script blows up, packages aren't installed. That's a big deal. I think this should be treated kind of the same way as shell versus bash. You need to declare whether you're using fancy GNU stuff or not. But we have to work out where. The problem is that CoreUtils is essential. So for Debian's purposes, you don't need to declare that you depended on it. It just kind of is. But somewhere it should say, and I'm not quite sure where somewhere is. But if anyone has a good idea, we could then start working through and filing bugs against things that use the extra options without saying so and we could fix them. Well, we could use an x-control field just to mark packages as requiring CoreUtils blah. Yeah, or as not requiring. And at the start, we could have like a field saying, okay, this package is clean. And at some point just decide that we are now going to start taking the other way around, okay? Or maybe use DevTax to have external to the package. The other thing we could do is basically have a wrapper package that just diverts all the CoreUtils and replaces them with just a small script that checks if any options that are not inside in the busy box variant of the tool. You mean an easy way for maintainers to actually check because often they don't know. Yeah, for maintainers and also users basically to have verifying that this system is still going to work when switching to busy box. For example, we could just lock, this script just called this tool with this flag which is not supported. And so we can find them easily. Just have a lock file of all. Yeah, sounds good. So I want to write that, that'd be really useful. The way I hear it sounds nice but it puts a burden on all of those doing the Mdebian to test it really. I'm thinking a way to do the opposite is to provide a package, like provide a build. I don't know how busy box is provided now if it's possible to install busy box without exploding your normal system. There's a version on Debian which doesn't explode your system, I believe. Okay, so install a busy box and then make a package that makes the semblance for grep and provides grep. Then in the normal Debian system, you have an alternative grep which then makes it easier for people to actually install the alternative similar to dash instead of bash. And then we can start the cultural thing of saying to people, hey, whoa, we really have to make sure that if you're using this funky grep, the GNU grep options, then it breaks for other variants of grep that is actually available for normal users. And then we can start pushing, please do this. And then so we can have it in the lintian and we can start finding bug reports with concrete examples of how they can verify this. Instead of it being a geeky thing to compile Mdebian so just to test this. Yep, that's actually kind of related to the other point which is making it possible to have a busy box say system but install the real versions. If you need real mount because you want to do something exotic or you need real find or something, making it so that, this certainly didn't work a while ago and I'm not sure if it does work now because busy box has moved on. We need to check, I know we run out of time. Install busy box and if you install find, find utils, you get the real version of find overwriting the busy box version without barfing that it's impossible and the files conflict and then ideally you take it away again, you get the busy box one back. That would be really neat. Somebody needs to test it. So, we've run out of time. There are lots of things to do. I hope some of that was interesting. We could do with some more people doing them because it's complicated and you get to kind of persuade the whole world. Very slow process. But it is nice to see, we started doing this seriously two or three years ago and quite a lot of stuff is now starting to change. So it does work and please come and talk to those of us with big mouths about any of this stuff if you have ideas or can help. Is there any way we could do something about this with the OpenMoco people? Yes, I'm sure they have exactly the same desires for many of these problems. I already have my free runner and I want to do something with that. Clearly, Mdebian on free runner is the thing I should be doing today. So let's have a go. I don't know if it works. Does it work? Right, okay. We have to stop. Thank you.