 Look way through the whole thing Well, yeah, the main slides on this one and then mine then some notes on this Yes, it is working excellent You want to copy them on to this one this box Copy on the desktop Yeah, it's it's evens have been testing in most of the time That's what you've been testing yeah Is that okay? Yeah, it really doesn't want to stay put this thing Doesn't want to stay put And it's sort of in my beard so he's gonna rattle and I Yes, UK power Just don't day to change too many sort of other extension cables of it. No, I'm using a PDF so it's easy and Doing Right Do something like that with my little eye pack as a little presentation as it starts up Oh, yeah, the balloon is actually very very connectable it's a very good little thing Because it's got a lot more space than most embedded devices What's the what's the is that the keyboard to control it Yeah Yeah, I plan on having questions at the end because there's probably gonna be a couple things that are actually Yeah, because some of the things I'm doing it So they'll be my dear questions probably Yeah My back when it's moving more like someone's pharmaceutical and venturi After the caffeine to do it Yeah Whoops, it's more his last speed I Yeah I Looks like this should work Is this working wonderful Yeah, hello everyone Noon and welcome to the deputy in developers room for the zillionth time I've lost count We've got a number of very interesting talks Unfortunately, there's also one talk going to be missing plus we're serious couldn't make it because he fell ill But luckily France pop already agreed that he was going to do another talk This was one going to be about persistent device naming. So if you guys are interested in that, you should have a look at it It should be at what was it again? Half past four. Is that correct? Yeah, half past four. So Anyway, that's for this afternoon, but right now we have someone else doing a talk. This is Neil Williams, right? Yep, right Neil Williams, and he will be doing a talk for us about cross-building Debian and and tea depths translation This is about embedded stuffs and he will also be doing a companion talk in the abided death room tomorrow, I believe Yes, but for now, please everyone welcome Neil Williams. Thank you. Thank you Okay, so what I'm hoping to cover on this Main talk is how Debian can work better to support cross-building the changes that you can make in your own packages And then the talk tomorrow in the embedded track is about how we actually use those packages how we Prepare the file systems and the various images that developers would want to use to actually use your packages on a tiny device Something like that or the machine that I'm also targeting, which is one of those now Your basic debut strap is what 180 megabyte installed Devices like that. You've got 64 megabyte total. So something has to change something has to go because within that 64 you've got to get user data and you've got to get a full GUI as well All the packages exist. I've spent the last year or since I've Actually been a DD put in a lot of packages into Debian that are small compact and they're designed for these kinds of devices So the packages that they we've got the the tools that we need now What's needed is support from the rest of Debian to help me out to actually make the packages that you all prepare Easier for me to work with so there are general changes. They're not Specific for M. Debian. They're not anything that's Yeah, I was part. What's the password? I Was just going on the next slide this one lovely So that's a that's a start in premise that the default within Debian is if it works Then we enable it if there's a mode or a function or an aspect of a package that can work in Debian then the default is to enable it what we try to do with M Debian and really need for for embedded devices is almost the opposite if it's not absolutely essential then disable it if it Brings in a lot of extra dependencies that wouldn't be necessary with just the core of the package then probably we do a package split and just get More finer control over what you can actually install and these are package splits that are not for the Existing reason of just helping the archive. These are package splits on a functionality basis and that's an ongoing thing Which I'll be looking at through bulk reports in due course as we get through further into the All right now the There's a lot of problems with terminology nomenclature you've got to get you the the I the conventions across when you're actually dealing with which machine is which so we tend to use in Build for the desktop machine the one that's actually running the cross compiler and host for the handheld That's what I'm going to be sticking with through all the in Debian stuff through the talks and through the actual documentation for all the Packages and tools and scripts and bug reports and everything else. So that's what we're looking at build for desktop host for handheld now the biggest problem we come up against when you try and Reduce the size of that debut stop environment is the deep package app and everything else gets in the way because you've got tags in the control information that says This package is essential. It's actually a Build dependency issue, but the way it's implemented tends to mean that you end up if you have one Package tagged essential it'll drag in nearly all the others and we just can't work with that so currently what we're doing is actually patching your Debian control and In the cross build package will take out Essentials yes to just to give us that control over what packages we choose and to give the The developers for the boards themselves the the choice of exactly what they want. They can have any package set that actually works We also remove pearl because pearl is huge and Taking out pearl in one fell swoop. It reduces the the file space quite a bit now. There are obviously Implications with that which I'll come on to later, but there are ways that you have to either remove or re-implement some of the methods that you would use Would rely on pearl otherwise and as I said looking at Not at this stage, but certainly into the future looking at requesting extra package splits and if you could help us out with that way if you're looking at a package that's got maybe Back-end modules or it's got an easy split Supported upstream already for different functionality and you've actually lumped all into one Maybe there's a way that we can work together to split those out and actually have functionality splits that allow us to Particularly drop dependencies. That's the biggest issue. We want the core function of the program We don't want the other sort of extras like it'd be very nice to do things like gconf if If we could drop the L-dap support and that kind of thing So we are doing that with patches, but it'd be very nice to have that implemented in the archive so that we can actually Give full customization for the packages themselves the other things that we are dropping is all we're actually dropping all the man pages and the info documents and readmes and documentation packages things like that There's no room for those on an embedded device and a lot of embedded devices. You don't have the methods to actually support viewing them anyway So there's no to no point in having those around that's where we start again to the Where we are Following policy as far as we can within the constraints of the actual device But there are going to be plenty of times like this where the changes that we need are going to have to be implemented Against the current policy so there are some that we can do within policy some that while going to have to be done With an mdebian policy that's built on Debian, but not actually fully compliant. It's just one of those things we have to fit in within the embedded system This is the start of the first Bugfiring that I've already done and it comes straight from the auto tools recommendation for for Debian and it's basically allowing your Debian rules file To pick up when it's actually being cross-compiled. It's a very simple set of instructions that you can add to any Debian rules Okay Just detect in whether build and horse have been passed via the package itself and Setting up in this case for a configure script. You're setting up build and host and As we've discussed on Debian develop already build should be passed anyway But hosts should only be passed when you actually cross-compiling Otherwise you can get issues where it's actually trying to use across compiler for a Debian build So there are bugs already filed for this. They're filed as wishlist. They're filed with a patch We've got the tools in mdebian to prepare all of that all fairly automatically But the patches are tested and they are they will work with the with the packages so Please if we can sort of work with some of the bugs and help us out to actually apply the patches that have been put up Against the packages this it's there's not that many packages involved at this stage. We build in Just under 200 source packages For mdebian and you can probably predict which ones they're going to be because they there are the typical debut strap Packages the ones you'd find in any sort of P builder That sort of thing with the exception of pearl if you don't use configure, but he still use auto auto make then there's a command also for passing the Cross compiler in the cc variable otherwise what happens is that you you go through the process of trying to cross build and It actually builds a native binary and packages it in an arm.deb, which really messes things up For that reason we we do test the actual tools that we're using to to build the packages will test Nearly all the binaries And most of the libraries trying to make sure that every object file that actually goes into the Archive firm the mdebian is the right architecture inside as well as actually on the file name the other way of Keeping support within Debian itself without breaking anything is dead build options Now I'd like things like no docs to have a more sort of generalized Implementation so that where possible if you are generating documentation within the package and it's possible to just drop that generation Then no could be used to allow us to build the package without documentation entirely and not spend time Processing the documentation that we're just going to throw away So that's the next set of bugs that I'll be looking at once we've got the the current process them running and booting Is a series of bugs so looking at Better no doc support for the particularly for the packages that we're dealing with But if you've got any package that fits that bill then a conditional for no docs In your dead build options would be very handy because someone's probably going to want to cross-build it at some point Even if it's not mdebian for the kind of devices that we're looking at the other one obviously When you actually cross-building the package if you've got a make check or make test target It's going to try and run some kind of binary that's being cross-compiled and he's not going to work so At the moment there are plenty of bugs that I've implemented the patch for the d-package architecture support, but I haven't gone as far as actually putting in the no check wrapper as well That's just because we're working through these incrementally and there are bugs in other parts of Debian that still need to be fixed before We can really use The d-package build package dash a we still need the wrappers that we're using in mdebian at the moment So I'm working through the the various problems, but if you if you have a make check Then it would be very good if you could just wrap that in a no check And you wrap it For dead build options. You don't have to worry about Is this wrapped because of cross-compiling just specify it as a As a dead build option if you find it in the string that you can omit that Udebs There's they're very specialized for the di team and they're not really applicable to what mdebian wants to do We don't use that kind of installer. We don't need that kind of process Cross-building Udebs can be a bit tricky You've got you bring in lots of unnecessary Dependencies or build time dependencies you have lots of packages you have to work with that who wouldn't need to otherwise So at the moment the mdebian patches are actually removing Udebs from the package entirely before the cross-build now If the if it is possible to support a dead build option no Udeb then that would be Another set of our wish list bugs that I'd be looking at To try and get support to omit the Udebs and stop them being built in the first place Those I can't think one I'll stop my head actually about the extra dependencies that there was It was a while ago when I actually first built those I thought it was GTK There aren't many that actually bring in the extra dependencies the issue is Udebs are not designed for mdebian They're not designed for what we need them to do and commonly the actual We're not going to use them. We would like to be able to just omit them completely if it's all possible Yeah in most yeah in the majority cases that's fine It's more in case of Streamlining the actual Cross-build process that we can have an autumn auto builder and Simplifying the work of that auto builder as much as you can in case you get problems where the The build for the Udebs is actually just Or the it as it is probably is only GTK that's actually got that extra dependency. So it's not really a huge The extra dependency is only affecting GTK, but if there's the the the Udebb build itself Is does seem to be problematic? And if the package can build normally fine, you re-enable the Udebb and the cross-build can fail So there is still an issue there. I haven't really looked into it in a lot of detail on Specifically Udebs at this time, but that is something I'm looking at in so if that's more a case of Highlighting the issue and then looking for response like that and to say where we go from there Yeah, I mean I'll look at it again, but the the issue issue was some of the Udebs weren't actually cross-building in the first place But that there have been so many changes in The the tool chains and the various support for cross-building in the meantime. I may have to go back and look at that again Maintain a scripts Now it's all well and good cross-building the actual package But there are going to be times when you're maintain the scripts either our pearl themselves or They call pearl Scripts that are in Debian essential normally or you'll have various other reasons why you've got a maintain the script access in pearl in some way or other So that's another reason why we're actually Patching the the source on there. There's not a lot that Debian can do at that at that point But if there is a way of not using pearl for certain packages, maybe that's an idea to help us out But that's just an indication of the kind of changes we're making and then another one We don't need any of the backwards compatibility stuff that's in the maintainer scripts So if I'm taking out sections of maintainer scripts for pearl or because I handle info pages or other things We also take out back as compatibility checks just to try and make sure the package will install cleanly on a new environment So that's what we're trying to do and that's how we're actually trying to run the cross bills and the the scripts that we use still need to implement a couple of workarounds for remaining issues both in the packages themselves and In deep package itself now for deep package. I have got the bugs filed. I have got patches there I'm looking to try and hopefully get those patches applied as soon as possible, but The first one we're going to look at is the Library workaround. This was always been in deep package cross since Probably Woody of the fall thereabouts Where it used a a A Supplementary script it's really a hack, but it's a it's a supplementary script that rewrites the path of The actual build process itself. So when you are when you're running GCC and all its dash I commands and all the various Dash L commands that come through GT cross was actually rewriting all of those to make sure they all pointed to user arm Let's canoe live and user arm lens canoe include because there were issues where that wasn't happening now We've worked around we've got a better system for that, but there will be bugs where I'll be seeking your help to actually work out how the The library can locate itself. It's generally when you're off more than one Library or a library and a binary in the same package and then the Second build tries to link against the first it finds the one you've built, but then the Library but I'm binding gets confused again and actually looks at the host libraries instead of the Cross libraries and that's so the build then fails The way we're working around that at the moment Is with a new file Debbie and X control that we patch in And we set a field for that and that Reimplements the the old workaround, but that is just a workaround and so we can get the packages themselves fixed So there will be issues like that with immediate look at there are package specific And they're generally upstream issues. They're often down to the make file am not using the correct Macros and variables for the top source directory And getting confused and looking at things a bit too simply Debbie next control is Quite an important file that we will be looking at using much much more Simon Richter has written a Debbie next control package and that's actually one of the tools We're going to use to work with The next generation of sort of cross-building Support where we are able to Dynamically change the way that could be control file works Substitutions variants and things like that at the moment we're using it just to split apart The bill depends so that we can say what these bill depends Actually need to be installed as cross packages and these bill depends are just tools They're things like quilt CDBS Deb helper and we can have those on the host on the on the build system without any kind of need for crossing those Again, it's simplifying the bit the cross build process That bug tends to affect nearly all packages that Try and actually cross build so the the workaround is built into our scripts. There is a bug filed. There's a patch For deep package to try and fix the LD library path so you can actually find the right cross libraries and Anything using package config. There's another bug that's been filed against that For deep package support to actually Specify the right lib directory in the first place so that you can find the libraries during configure okay now the other part of the Endebian changes really centers on your translation files This is where I'm going to look now at t-debs How they fit in with the whole cross building support now there is There are outlines for translation devs already in Debian, but M. Debian needed them very quickly So we've gone ahead and actually implemented a working Version of translation devs that suit our needs and which should be transferable into Debian under the the existing plans are on the wiki so the idea is To not install user share locale translation files for locales that are not actually configured on that particular machine so you test whether the And the package is installed you test whether the locale is configured and then that Enables you to go and get the right locale package and install just that one So that you only get translations for French You don't get Hungarian and German and everything else that you don't actually understand yourself now I can see where Debian has got has got the idea to install all translation files Because you don't necessarily know who the user is for the machine But for an embedded device you've generally got that sort of link where the user is only going to want certain locales installed and at default That laptop here just running a basic gnome environment user share locale is something like 250 megabyte just on its own Just with translation files. So it's a huge issue The problem you come up with Is that you then end up with a huge? increase in the number of packages The way we do the actual Split is to have one locale for every source package Creating one t-deb so if you have eight translations in Your package you'll have a t-debs generated. We've also included a customized Source package that just contains the pot file enough files to make the the profile and the and the other sort of get tech support and the existing Translation if any and that can then be used by translators and the that's all experimental It's only an idea that's implemented at the moment But there are ways that you could then allow translators to upload t-debs separately That's one of the ideas from the from the Debian wiki the increase in package numbers is Staggering we would go from what we know 20,000 packages. We go close to a quarter of a million instantly So it's that's not sustainable. It's not sustainable for mDebian either in many ways So we're using a secondary repository and a separate tool that downloads the cache and then Bins it because you're only going to use it to actually update the locale package. It's not your main apt cache the application works with apt and this one I've written myself for for these embedded devices in order to put to sort of provide some kind of fallback support Then the repository itself is marked up via the locale route so that you will find in the PT Section of the of the repository you'll find PT PT br on all the other variants of the Portuguese translations for that particular package So what the Lang update? binary does is it parses the list of Supported locales generates a sources list temporary That it uses the locale route and then goes and offers whatever packages it can find for the ones that are actually installed Okay That's Now a lot of that is Some of it is contentious some of it has implementation issues, but yeah Man There's one issue I see if I understand correctly how you Plan to implement this As an arc all solution, so you would have only one TDAP for all architectures. Yes I Couldn't it be that that will be correct in most cases. Yeah, but isn't there a risk that there will be some packages that have different Translations or different strings for different architectures As far away in Debian at the moment, that's not and I'm not aware of any packages that are actually handling it that way I suppose you There might be some that are hidden, but I worked on the premise that there are a lot of Packages already that put their look translation files into Data packages or common packages, which are at all I Take the point there may well be some I'll cross that bridge when we come to it. Do you know of any that might do that? Sincerely doubt it Right Some things that are generated build time and that are architecture specific right so we talked about Translation strings translate the markup for translation, which would vary according to the architecture At build time that's yeah, I would need to look at that again to make sure that the actual Cross build itself in the first place is actually selecting the right arch By a get text so if you know of a package that does that I'll be How is that handle currently then because you have got data and common packages that are Shift all the number in the fine, so it's To our problems Because the the main drive for writing M install T-deb in the first place was to get rid of the Lee The translation files from the cross-built package and separate them out so because we really needed space the actual usage of these and the The runtime issues and the build time issues like that I'll need to look at from there So is that something that would affect every translation file It may well be because we actually The way the M install T-deb works It's actually a secondary build the build the cross build finishes M install T-deb starts up and it Just processes the the po files So it may well be something I can actually handle within the package So that the the mo file that gets put into the T-deb is the right is the right end in for the architecture That's been selected for the build. Yeah Two points one it just it sounds trivial to just invert the endiness of a mo file So it should be trivial to write a small program that can do that. No Because But in fact there is one space in this file, which is the ash table, which is not documented and Because can me and can I never find a man on i386 be read on spark? Yeah, but right then it can be mechanically converted. Yeah Performance issue and it's not an issue when you're talking about spark Well, it's an issue when you're talking about And the script that we were thinking of that would be run on the build machine. Yeah, all right In purely cross built yes, so what about packages that I can think of upstreams that can't be cross built at the moment that might be interesting to invent a platform such as Lua Right The actual Lua binary can be cross built But if you attempt to cross compile any lower scripts down to its binary form, right can't because for example arm has Slight double inverted doubles. Yeah, it has middle and the inverting point, which nobody else uses So you can't Part part built a Lua script and it's on anything and expected to work on On on any embedded track, I'm going to Just about expected to build on arm Would it work on army L because we've got rid of the millennium problems If army L doesn't have a millennium problem, they say it will work as long as it's the same in you But the binary format doesn't contain any in swapping information So if you attempt to load one that paired my fear at six on spark it will explode. Okay, so that big yeah And I'll be covering that whole issue in the embedded track talk tomorrow about how You can start to mix Debian with M. Debian and the issues that could result from doing that But it is possible certainly Yes, that was fixed that was fixed last November the self-conference. I had people there Yeah, because we would then just bring down the patches and apply the patches in Effectively a native build. We've got the same request a lot from people who want to Build for very small three at six boxes. They want to put M. Debian on it But they're actually doing a native build. So there was sort of work done In Austria to try and implement that so that's and no if it doesn't work then follow Bergen. Let me know It does so use a special way to align in memory strings translated yeah, and just in the recommendation you can see that it's made for risk objective so I think can be You just have to do something take into account that the fact that These files are And it's not just picking the hand me going down in fact, it's being a little in the memory Big walk That's interesting packages As you say would have that problem, but it's more of a problem to us So yeah, that's that's fine. I mean, it's With having them install t-deb as a second sort of build process at the end There are lots of various things we can do this mid to try and either see if get text can be persuaded To write out a different binary format And the effect to actually run get text is across I mean it may be possible to do something like that and work on it that way But yeah, the the The implementation is going to mean then you're not just going for a tenfold increase in package numbers You go for a hundredfold increase in type package numbers By the time you actually spread that out to the other architectures It makes it all the more important that we have a secondary Repository and a temporary cache and a program separate from apt-and-d package That can work with all that and just bring down the one package that the user needs for that particular Install package Yeah We replace debcom for the seed up There is one little issue with that which again bugs already already been filed where see debcom first of all it doesn't Set up its own debcom Database properly, but that's fixed in our sort of package version of it and also the default environment tends to Only look for debcom from not Have the C debcom environment variable set once this once the the correct environment variable is set Then it all works through so we can we can ensure that the actual Installed machine will have the environment variable sorted out the more be a problem at all So it's it's it's C debcom that will actually do the work Yeah Yeah, there won't be no debcom for actually be there Yeah As I said, there's already a transition trying to get to see them come Instead of it instead of debcom for anyway, but all the bugs that have filed so far. They're all I said They're all wish list. They're all there for And I said I've done as much the patch in as I can or one other part of the maintainer script is update alternatives Not sure where we're going to go with that at the moment You've got the issue that you can't actually run update alternatives itself Because it's a pearl script But you've also got the issue that because we haven't got the same Requirements for essential packages, then you have the option or at least of making sure that you don't need alternative support Because the the people creating the actual file system images and and installations They the support can be there to ensure that you don't get those conflicts in the first place because we actually Stripping down the system entirely whether how that will work out and in Real practice is yet. I'll work on that as we go if there's any ideas on alternatives and other social Foyables within deep package. All right. Are there any other questions? Yeah When the as as we've seen now there are still issues and it's still experimental But if others like the idea I think they could actually work in Debian itself Then fine. Yeah, all the code is there. I'll work on it in Debian as well What how does it sound with the idea of a temporary repository means that the mirrors are still gonna have to have a Lot more packages. They're very very small packages. Yes, you're talking about the smallest Debbie you've ever seen but Because the the dot deb only contains the dot mo file and nothing else This contains the its own its control information, but nothing else. It has no dependencies. It has no Issues like that at all. So how does that sound in terms of? Running that kind of system within Debian on the mirrors That's what I'm saying Normal packages Okay, well the way we way I've donated our name Debian Repository is that it's it's a completely separate repository completely separate URL Yeah, so it's just the actual it's the it's the space issue more than anything else. That's the Possibly not quite as trivial We're doing it to create a new set of indices. So we have packages sources translations. Yeah Yeah, but I've implemented at the moment as a normal R code because that's the way that's where the support is in Reaper pro and Yeah, and obviously you're reducing the size of the actual original binary in In the Debbie mirror anyway, because you've taken out all the look out On what I'm looking at is with the with the no docs support It is possible that you could have translated man pages and other translated documentation in the t-deb So the Debbie and t-deb would be much bigger and the m Debbie and t-deb would just have the dot I'm oh friends Did you have a question or? Okay, yeah Not the moment I mean theoretically there isn't anything to stop it once you've actually put the support into the M install t-deb script As long as the other translation system, whatever it is has a way of separating out presumably they all have ways of separating one language from another and having Independent files for each one and no sort of interdependencies Now see that's that would break with it with a t-deb situation because he wouldn't have any of the others Yeah, yeah Yeah No, exactly. Well as get text follows the the approach of the rest of Many sub-debian packages, which is that all everything so get text is implicitly duplicating Because the Dependency within the same locale route is not a problem because they're going to be in the same directory in the repository Because you'll have the EN source what we'll have is Deb HTTP and Debian slash locale then instead of main Non-trient contrary, but you'd have EN PT FRD you'd have about 30 of those components And then we need within each component. You then have the all the packages that are From that locale route. So NGB ENCA all those would be in in with the end Piles, so it'd be easy then to have to dependency from that Could technically do So Okay In the devian t-deb not in the end Because what I'd like is for whatever script much you do to create the t-deb whether same means they'll be there for And replace it it should be able to look for no docs in the dead build option So just drop everything So the devil solution without any translated content that you want There are the list talk on the devian wiki about translated images Images that contain text even the text translated put me the text in the t-deb So potentially something that in dead end can actually go quite long But yeah, there's the various support that can be done as easy as any other change What's the feeling generally on Having this sort of Supplementary build the end of the build you've done deep packet build package it comes to the end It says what there's your changes file We run lindia and then it goes in and does the the t-deb generation Initially did this as a script within the build and they proved problematic this solution is much simpler So are there particular problems Trying to actually Process the locale files within the normal build and then having to deal with DH move files DH install that's looking for these mofas all of a sudden because they've gone Because you've got them in another package and then you've got problems with the the files File in in debbing directory because you've you end up with the wrong file information for the for the package And it means that you can have a completely separate dot changes file Which is where this the the source upload comes in because you you will need a separate dot changes file to have two separate Uploads you upload the package to unstable you upload the t-deb to the locale repository And then split the move on once after after upload Right That was a solution I did For m debbing and if we apply it in debbing itself, then we can sort out all the other issues from there Yeah, that would that would probably Be our goal definitely. Yeah for debbing fine. Yeah That's what this Specifically so That's the other appeal of having this sort of customized source package Which just contains enough data for the translator to regenerate a new Transition file he doesn't have to bug you literally with a with a wishlist bug in a patch You can simply it would be some form of Allowance that we have for debbing maintainers without debbing translation uploaders Something like that. I mean, that's you know, that's that's that's probably a way off But it certainly there's no point in not enabling that because the the system can inherently cope with it And it would make life so much easier for Yes So I'll need to look at that with With respect to the get text and try and work out whether we can get that get text to do what we wanted to do Well, it's not As I say, I can imagine situations where you literally have different strings It's only but the extra strings only means a little bit of duplication Two different strings The thing is that for one architect, there will be only one string right for another architect There will be a completely different string So can you can have you can have both strings in your CPU file? No, yes, you can because One example Different different different every bill that's going to be impossible If it's going to be the same every build then but different on an architecture They can just collect all the strings from every architecture. It's going to be one view file and transmit that I need to do that anyway because otherwise the chance that it can't be solved That's right. It's it will be They will be all there in the source Yeah, but they're not they don't necessarily have to be all there in the binary Well Let me give you one example that the installation guide The installation guide has completely different texts. Yeah for each architecture because a lot of The instructions are just different Yes, in practice, it's not a problem because we generate different packages for each architect Just mentioning it as an example I'm I would be very surprised if there's not one packaging that has this Just for the reference usage format takes alignment Ending this and hash table control arguments. So as long as you pass it the right arguments when you build your tea there It'll be fine Why are they a binary for my mini It's quite a lot of extra comments and other sorts of blood in a profile And the L file has both the original and yes Based on the original when you execute the comment from just this gentleman here is that the MIPa can be meant And It's not actually It's explicitly written Yes, it could be four bit gray code Okay, I think I'll end it then thank you very much for your attention