 Well, hello everybody. This afternoon we will have an MDN update by Neil Williams. I will please ask you that if you want to speak to us for the microphone, Neil will have it so you have to ask Neil and if possible say your name and look at the camera and well I hope you enjoyed it. Thanks. Sorry about the the side of the presentation there but I've got a few problems with the laptop. It's just going to cut off the last couple of words but we should be okay. So we're looking first of all at what MDN can actually provide as the embedded MDN project we're trying to bring MDN to much smaller devices, much smaller systems. Not necessarily low resource units, we're not necessarily looking to wind back the clock and do things that we can't run multiple codes, we're just turning the code itself a lot smaller. We are ready to make a more or less simultaneous release with LEMI using many packages across both of ourselves and reducing the size. So that's on target. We are actually in sync currently with Debian and Stable and we've migrated those down to MDN testing and then to MDN Stable so it will be very much like the kind of systems you normally expect to find. So the actual tools that you use both to prepare with our systems and to customise particular packages or to build whole new package sets for your own architectures and requirements and customise everything from there. If you're all in LEMI there will be updates because they're very new so they're not necessarily about free in LEMI but they are working. And the distribution itself will not be a typical Debian distro. For starters we'll be doing the things on the time we'll hand out like that if anything at all. There will be no kernels necessarily provided within LEM Debian although we'll provide the most support if we count the kernels if you need, typically because the Debian Stable kernels will simply be too big. You want to reduce part sizes as much as possible in all the areas so the kernel will just want. The kernel modules is another, you really want to customise the modules that you're actually going to install even if you build them you don't necessarily want them all in. And the big emphasis within Debian is that whereas Debian allows you to customise the package selection this one really is allowing you full control of the package selection and allowing you to customise the packages themselves to get down to the really small sizes. We have got more work going on to make things even smaller and to spread the network wider. As I said the RML is a natural successor. We're building ARM packages at the moment because when we started in Debian and this particular method the RML port wasn't ready so we started with ARM and it can fairly smoothly, I hope, migrate to RML and then sort of native build support. Trying to make sure you've got a clean difference between the cross-build and the native small MDebian build for i3 and 6. The main stay for what we're trying to do is cut out some of the dependencies. A lot of what we're doing is switching something that in Debian says enable some function in a library we'll change that to disable unless we've actually got a reason to use it. That's something that's going to be ongoing. It's fairly small scale at the moment but as we've got a working system, we've got working people having out testing, then we're going to increase the number of functions and things that are disabled again to drop dependencies and therefore drop final installation size. We don't use Perl. We don't have any list of essential packages. Those are the two big differences with Debian. Apart from the cross-build. All dependencies are explicit and they have to be done that way to make sure that you're actually following it right through. Again, what work we could be going on to provide tools to help and assist with that. Now that we've got a working system, we can actually work out what bits we could take out rather than relying on the Debian dependencies which can be a bit more than you actually need and we remove huge amounts of documentation. I'm not going to cover T-debs in this talk as a separate item but yes, we are removing the cows as well as a huge step. So for example, OpenMoco was yours 480 megabyte in stores or something like that. Debian on the OpenMoco? The basic store is I think 400. Yeah, okay. The basic store is 400. Yeah, that's with some of our program. Minimum installation was like 200. But then Debian, we've got a full GNOME based or GNOME part of the environment. GUI with an X server and a calendar and contacts and other things. And we're down to a 75 megabyte install and basic system down to about 24 megabyte install. We're hoping to get the full GPE environment under the magic 64. What are you using instead of Pro Shell? We are re-implementing various of the essential Pro scripts in Shell, yes. One or two might have to go to C. But I'm not that happy with what came with that. At the moment, Pro has made a big win on both sides. Just a little word on conventions. When I'm talking about build, I'm talking about the big thing on the big desktop thing you've got sitting in the corner. When I'm talking about hosts, I'm talking about the thing you carry in your hand, the handheld. We've got two trains for i386, AMD64, real builds. We've built for RMEO and various other hosts as well. We've got a full range of compilers and as soon as any releases, we're going to have a hard time, we're going to have to add 4.4 to that. We don't really support the cross compiling on PowerPC anymore. That was my old laptop that I hadn't read in rep and it really struggled to build a two-chain for itself. Unless there's anybody who really, really wants 4.3 of the upcoming 4.4 on PowerPC, then we're just going to leave it at 4.2. We are sticking to G-Lib C. UC-Lib C is not in Devian at the moment. It's going to be hopefully back in Devian sometime after any. There's various copyright licensing problems. You've got to sort that first, but there is work going on for that and there is outline support for UC-Lib C already in the tools. Can you outline the other alternatives? I've seen things like Diet-Lib C, but I don't know how to evaluate them. I can't really say much on that more. We haven't tested with anything except GC-Lib C and we've got outline support for UC-Lib C. With more people on the team, we might be able to look at some of the others as well. The tool-trains recently, we've actually managed to get an order builder for those as well. You've got a Build-D that builds cross-compilers. That's a big investment and it actually takes a huge amount of time and it's a difficult thing to get right because sometimes you build one tool-train and then one of the other tool-trains becomes uninstallable because of the packages you've just built. The tools we actually use, D-Package Cross, is what gives you your cross-dependencies. It puts them in the right place so that the cross-compiler can find arm binaries on an AMD64 box. Apped Cross is what gets the arm package and actually gives it a D-Package Cross and then Debian Tools and the packages within it do all the rest. And those are in-led. Very recently as well, we've actually had another Build-D come online which is a cross-building Build-D. So it's actually building our target packages. Both of those order builders are our own work. They're not actually based on S-Build at the moment but we're going to work on that from there. They're both developed as a natural progression from the tools we already had because both kinds of builds can take a long time and you want to leave them running unattended so it became a natural evolution of the tools to support unattended building and therefore order building. So the actual tools themselves that will be in Lenny, we have the support there not only to provide the tool chains but make sure they're installable and help you in the odd situation where both things can go wrong and you need to perhaps build a small tool chain for yourself. Again, actually getting hold of the cross-dependency libraries and putting them in the right place so the compiler can find them. So with all these kinds of things sometimes on a... if you're actually managing your own tool chain it won't be hassle and the tools are taking us away. We do need a fair number of Debian packages at the moment. Work is going on to put all those packages into Debian packages. There's a lot of work to get Debian help on our side and then once that's done a lot of packages will disappear and we can actually work on the few problems we've got left where packages that we need don't actually cross-build direct in Debian get those incrementally improved in Debian and just long-term mass bug filing to facilitate that and get the packages available to the relevant maintainers. Now, as I said, we actually try to support as much customization as possible. We not only do that by giving you full control of what packages you select and taking essential out of the equation on that but actually providing extra patches on top of the cross-builds to customize how you want your particular package to be built so you could disable something that we haven't taken out yet. It's going to be tricky at this stage because we've still got so many patches of our own but that's going to become more and more useful as we get more and more patches including Debian upstream. And then the tools themselves take the final stage. You have a repository either on your local machine or on somewhere or somewhere or you can use our own in Debian repository for ARM packages and you specify your customizations if you want them. You add in a couple of extra dependencies if you need those and you build a root file system it sits alongside your kernel and your kernel modules and you install it on your device in your way. That system uses the build system to do as much of the work as possible so only the final stage of the actual installation needs to be done on the device. It's one stage on from the normal Debian struct foreign type procedure. So the package we've got, we base ourselves on Busybox to give it a core utils and to give it a pull. We use a fairly large config for Busybox we try and use as much of it as we can. We've got then the binary packages working up to the full X server GTK plus two and the G part of the environment and touchscreen support. I was hoping, hence the title on the original talk, to demonstrate the touchscreen support with the Blu3 but yesterday it developed a hardware error and we had a few problems with the driver and now the y-axis works for the x-axis as always the same. This can be very handy. We've been working on that when we get back. So the actual order builder, all the cross building logs now are available online and they go back for a reasonable period of history but they'll be kept update as the order builder works so you can always tell what the difference is between the cross build and the native build and you compare and find, oh, Ion, you're doing something different though. So you can look at your own packages and find out what we're doing with them. That's the root file system part from the tools. We're using the pre-built packages put them together with Deep-N-Strap to give you the pre-configured as much as we can. Now, this is being covered in another talk with Zack's talk about EDoS Dev Check. We're using EDoS Dev Check a lot. It is a prerequisite for upload to the archive. Nothing gets into the archive unless EDoS Dev Check has first cleared it and if there's any error, it has been manually reset. So we're using that to make sure that the packages that are going into even an Mdebin unstable are always installable and we have ongoing checks every time the upload goes up and even between uploads as well to make sure that the package sets that we offer are installable. It does not mean that the whole archive is installable. To use that terminology, we are non-trimmed substantially non-trimmed, about 50% non-trimmed. Mainly because you're not going to want debug packages on that kind of device. You're not going to want dev packages on that kind of device. You're not going to need auto make or all the other stuff that you would have typically on a dev unit installed. So we don't necessarily care whether those packages are installable or not. They're there because you've built the source package, or a lot of them a bit, and the dev just gets built automatically. It's easy to let them don't be built but to take it out afterwards. This is something we might want to work on. And that's where the machine variant customization comes in again. Each stage we offer as much customization as we can and if you need anything else changed or any other custom changes anywhere through the process, from the initial package selection through the cross build, through the repository and up through the actual root file system, just ask and we'll work on the two to make it possible to support the other alternatives. And develop a time is what limits us to GPE. I'm a maintainer for most of the GPE packages in Debian. It was a natural thing for me to work on. That's the kind of thing I'm interested in myself because I want a PDA type environment. But there are lots of other packages out there. We are working with the open local people to try and get their packages into MDebian so that you could actually have a much smaller installation once all that work cross builds and it's going to take some time but no one's there, we can use it. And the customization allows you to pick and choose whatever you want in the archive. So how you actually get onto the machine Debian is a great bit of software. It has a lot of the dependency reconciliation that we need. It handles the actual preparation and packing of the archives. It helps us a lot in that way but you could use another backend if you wanted to. We don't use the full people start forum because that would require a cross compiler to actually prepare the root file system. We've separated out the packages so you can build a root file system without needing a toolchain. You've got all the pre-built packages. If you want them as we've done them, you can have a root file system unchanged and just change whichever selection you want. So we've devised an unpack method which is not quite the same as deep package unpack runs the maintainer scripts. And you'll be running these on your build system and you'll try to run post binaries and you'll die crash. So we have to work around that. We unpack to the point where the maintainer scripts are available to the system after we've installed it. There are no dot devs left on the system when you actually install it or everything has actually been put in the right place and then when you actually copy it over, you unpack the table and the one thing you run then is deep package configurate on the actual machine. It's the only process that then runs on the device itself prior to the reboot. The machine variant customization is organised by defaults. So you can have just a user string for whatever you want as your main machine description and a variant for all subtypes of that. So I would use bulletin3 for the machine name and then have busybox gpe or just gdk for the variants and just change in the various package select. And you can literally select anything that will actually install. We don't put any barriers in the way and central's gone, don't have to worry about anything that is normally on a devian system. Priorities are not enforced though still in the control file but that's just because of the positive you need. You can literally have whatever you can get that works and that's a rough indication there. The system that's actually running on this balloon here it's a full gpe GUI there's a set of contacts and Victory Gallery, what else has it got on it? To do the to-do list, time tracker, configuration upload, salon clock, calendar, image viewer, text editor and that gets in it under 75 megabyte. I'll hand this around so you can actually have a chance to see some of the information of the actual development board we're using but by no means is that the only board you can use we can put us for any board you can find. It brings me onto the kernels. What we're actually going to release as I said is just the pre-built binaries. We're not going to go into any of the particular kernels. You will need to work that out for yourselves. And we're currently not actually doing the full DI setup. It is going to be possible, I hope. Hopefully there will be some work doing ExtremaDura in September to actually see if we can get a proper DI setup. It would be nice to have DI just to do the final stage. We won't be doing the first block where the DI is actually doing the installation. We just need it to run the package configuring and set the root password or set up a user and reboot. It would be nice to do that in a relatively standard interface rather than having to do every device in a customized, specialized way. So because you're building a variant of Debian instead of some other random operating system presumably there are Debian versions of all of the binaries that the maintainer scripts are potentially going to call on, right? Why can't you just run those instead of a trute and pretend that you're on the device? We have tried that. It didn't get the results we wanted. You would have to run that on an ARM CH root to get the real results. So you then start to think, because if you run the maintainer scripts in an AMD64 CH root you're going to get the wrong results. In some cases, not necessarily all of them. Have you tried a key move? We cross-billed everything. We're not actually using emulators at this stage. We would like to stick with cross-building the whole lot to stick with the Debian idea that we can build the whole lot from source and not necessarily relying on emulators to do that. But for the maintainer scripts, I mean... It's not actually a problem. You do so much of the work beforehand before you actually create the table. The package configuring really doesn't take that much time. I'll actually go and demonstrate on the device. I might do that later on for the best time. So that's what we're looking at there. It just needs to be unpacked as a table. That's the process for the balloon 3. That's actually what we would normally do. So there's bootloader support for a different kernel on the device. You boot into that. You mount the USB stick. You copy over the kernel image and tile it. CH root. What we need to work on around the time of the release and after the release are these two-chain build-time issues and the installation problems that can happen from those. That's what we're hoping to get done part of that in Extramedura. It should make things a lot easier if we can actually manage those better. It probably means a second machine to do simultaneous builds. Well, I386 named it both the main ones in there. To get under that magic 64 megabytes we need to work with the GWC maintainers to strip out the G-con libraries and work out how to handle those sanely so that you don't have too many displays that have just blank squares all over the place. And to work out some way of handling your timezone data in a sane way so that you don't have to worry about timezones in 1894 or whatever. As I said, the RMEL support is one of the big issues. I'll take some time. This has come together fairly quickly and a fairly piecemeal way because it's very difficult to plan your way from GWC to GTK. And it really is starting off on a whole new port and a whole new cross-build. It's actually very difficult to work out which library do I do next. And you end up building a lot of libraries and then come to a data end and think actually I don't need that bit over there. So there are quite a lot of packages in the archive. We've got 243 source packages, 700 binaries and 1700 t-dates. And there's, there will need to be a full-scale code audit to work out which bits we still need, which bits are actually going to be cut down and all the rest of that. And that will be fed in then to the long-term mass bug filing to get all the packages put into Devian as soon as we can. We want to work with OpenWoke and we want to work with the kind of devices they've got because it would be easier for everybody if there are more devices around. One of those things is Python support. It does cross-build in OpenEmbedded. So it should cross-build eventually in Devian. It's just a matter of working out what patches it needs to the Devian stuff to allow the upstream stuff to do it. It couldn't do anyway. It's surprisingly common that the Devian rules and the Devian files are actually getting the way of cross-building when the upstream package cross-builds fine. That Devian installed integration. That's one of the things we're hoping to work on in the next time we do it. To make sure that we do as little as possible on the actual device. As for later on, perhaps if we want to support really small devices like routers and things like that, you're going to have to do everything you can on the build machine, as little as you can on that one. But then we've got a smaller package set to sort of keep package configuring. It will take less time even though it's a smaller device. Now, the long-term mass bug fine has been going on for a while. There are bugs that have been open for that for over six months. And once Lenny's out of the way, I'm going to do some enemy use. So that's fair enough, I think. I've waited long enough. So I'm going to have to be able to upload some of those and actually implement in the cross-build support. It's all been tested to have no effect on the Debian package itself and have no effect on the Debian build. It's all conditional on there being a request to cross-compile it. That's the only time that the patch comes into effect. The other issue we need to sort out is i386 support. Building in a 32-bit CS route on that AMD64 essentially a native build. At the moment, some of the patches, some of the methods we're using, they are bit too hard or bit too far optimized for cross-building. And we need to back off a little bit in some areas and allow a native build to carry on. That ties in nicely then with the mass bug filing and the enemy use to make sure we're getting this balance right between not interfering with the native build and allowing the cross-builder work as we need it to. And then yeah, this is the file system we use on Bloom waiting for mainline support in the kernel but that depends on Wookiee every more time. We actually need to make sure that that file system can actually do what it needs to do which is checkpointing so that when you reboot it doesn't have to spend time checking the file system. So that's an issue at the moment when you boot the board it takes longer than it should do. Oh it only takes an extra 15-25 seconds for the but that's enough in terms of a device like that to actually be a problem. So yes, that's why I put it there because we need to fix it. That's a basic outline of how you actually use the tools. How we would use the tools in Lenny or in Unstable. So your M setup is just telling you what you need to change to have a toolchain there in the first place then it goes ahead and installs it for you. M source is a wrapper for up-get source it gets the package and packs it, applies our patches and puts you in there ready to start the cross-build. M recent goes through the cross-builds that you've done passes them through looks for the dot-changes files for the ones that you've built successfully, passes them to EDoS dev check, checks that are actually installable, runs them against Lintian. Now we've got Lintian support in Mdebian and we treat all Lintian errors as fatal. Even Lintian warnings are fatal. So we only check the tests we need trying to get more support in Lintian to do only that but there are things like this is an ARM package and it contains x864 binaries that's simply going to break everything so we have to make sure that kind of Lintian check is fatal, breaks the build and then stops. For actually preparing the bug reports we've got them supporting the tools again to Mbug prepare then packs two side-by-side directories, one with the Debian one with our patches on top as well and you can use nice little tools like meld to show the difference between the two and to make sure you get the right diffs into the Debian package test it, make sure it builds natively and carry on from there and then submit the report from that. So what have we got in this GPE environment? We're basing on Matchbox which has had a fairly large rewrite since I last saw it on familiar so it doesn't look the same anymore but it does work quite nicely and you've got the tools I've been describing already so we're going to add games and console terminal emulators and calculator, image viewer all that kind of stuff. The touchscreen support is what I've been working on at DepthConf 8 and up until about 48 hours ago it was working fine and certainly we have packages already for Bluetooth and audio support, that's all there if you've got the hardware on the machine it will work. Now I've got an example board at the front here, there's a box going around with the various other details of what the device can support if you've got any questions on what the device can do and I'm connected into it on there it's a fairly simple arrangement, you've got USB networking and then going through so you can actually query the internet through the laptop this particular device doesn't have a battery so I can't actually put it around your wall so if you want to see it you've got to come up here but you can see there it's got all the basic features you would want and when the power comes back on you can actually see the screen as well so if we kill X I'm only having to do it this way because the touchscreen support has failed otherwise I'd be able to tap the screen and get it up for you so you should see there it's actually doing the touchscreen support and trying to load it up from there just comes up with X on there so that's there for people to have a look at when, are there any questions there where have we got to? What are the pros and cons of the different flash file systems available? I mean everybody used to use JFFS2 and are you using apps? You're using JFFS2 for open mocha, aren't you? To be honest a lot of that sort of question those kind of questions I would wish would have gone to Wookie but he hasn't been able to get to you for a dead comp aid my work is what was the excuse for you on the software side and the cross-building in the tool sets so hardware questions I start to look at someone else Do you know what part is it? I only have a big question to you Jaffas is ground designed up for non file systems only if I remember correctly and is designed to boot much faster so before JFFS2 would have had the checks the logging support Jaffas didn't need to check everything when you started up so for a large file system gave you a big performance increase hope for that I believe JFFS2 is caught up there and that their arguments are minimised a bit but the plan is still to get Jaffas into the mainline kernel some work has been going on but I might have to be involved in it Thanks The reason we're working with Jaffas I think is because that's the company that actually worked with the the balloon board they're currently working on balloon 2 this is the balloon 3 board production model and that's the kind of devices they're actually supporting with that they've been too loud they've been doing the Jaffas work at Toby Churchill working with those from there I'm currently using the Jaffas on there I don't see any particular reason why I wouldn't be able to use any of the other flash based file systems and as I said the main problem we've got at the moment is that something in our setup is preventing the Jaffas from doing its main selling point which is that checkpoint to stop the delays on reboot How would you compare this to open embedded? He says looking straight at the open embedded guys The biggest difference is that we are still Debian it's still a derivative of Debian all the Debian tools are there they're using d-package and app get now that's a big enough incentive that the open mocha people have done the same and they've got Debian as a bigger installation on the open mocha device for those kinds of reasons we're starting off with d-package and app get the other difference is that we have got this intermediate stage with the repository and you don't have to go in and have to build any packages necessarily you can actually just build a root file system get your kernel and your kernel modules, go ahead and install and give it a try and you can change the package set and you can work with that once you actually need to start adapting the package to themselves that's when you need to cross build the tool chain Just a couple of points in addition to the advantages having worked with open embedded as well one is that while we were doing glibc you're still able to copy across a binary from a Debian box of the same architecture you can make use of the ARM or the ARMEL port if that's the box running on a copy straight across the other thing is that mDebian is allowed to leverage the release structure of Debian and the security updates of Debian something which in my experience open embedded haven't been quite so good about doing so you can basically rebuild automatically from the updates that are done on Debian and get those into mDebian automatically Thanks that was something I did want to mention actually I should have done a slide on that you can mix mDebian and Debian on the same system you have to be a little careful if we start playing around with too many dependencies and that would become a little more difficult but generally there isn't anything inherently blocking you from just adding a Debian mirror to your app sources list on that device and getting some ARM binaries on top of that device because that would be bigger than what we would provide there's a space on the device and you can satisfy the rest of the dependencies you can go ahead and there is support even in Debian that's been support for years and years to use things like equips to build a sort of false package if there is a dependency it's not like add user which in Debian is pearl but in mDebian it's busybox so you could, the function ID is there, you don't have to change the package to work with that you just need to trick the package to allow you to install things you can't so you just provide a false package and away you go that is a big advantage we can actually just fold into Debian well I had to work with Gamstix motherboards at the beginning of the year and I was using open embed because it was Gamstix it recommends and I saw they had two branches you can build an open embed in two ways with microsoft clipsy and with clipsy and the last time I checked, about two months ago they were telling people not to use micro clipsy because they had a lot of problems with it do you think you will counter real problems because you were suggesting to port to do things with micro clipsy do you think you will counter problems using that or it's just I don't think so because the Debian maintain as a uclipsy you're actually working almost as part of the upstream for uclipsy now so we've got a better relationship with uclipsy and we can get the update straight into Debian and therefore straight into mDebian it's okay to but it is a big issue because it's not just the copyright problems with uclipsy it's the whole issue of how you can manage it and you have to link everything against uclipsy and you can't necessarily then mix you lose the advantage of bringing in Debian packages because they're going to want glipsy and you're going to be potentially causing crashes so all those kinds of things can potentially chip you up once you actually start with uclipsy so it's a big step we'll have to see how we get on with the actual support but we've got the infrastructure within Debian to cope with that kind of thing generally quite well anybody fancy in the world I'm going to look at the balloon you mentioned a couple of times that the real time is rather long it's 15 to 20 seconds do you reboot it very often or just for testing it's been testing that particular device all the time so I'm constantly so putting new root files on to it and testing the installer and all that kind of stuff once this problem with checkpointing on the apps is fixed then the actual boot time will be far more respectable I have been able to work with it in his proper checkpointing mode and the boot there is half cut by half so it's a lot better but these particular devices the way they're going to be used with this particular company the boot time isn't that much of an issue different devices, different boards you may well get much faster boot times it may well be optimised in different ways this is actually called quite a large fast system on it as well so when the checkpointing doesn't happen it takes longer than it might otherwise because this is this has got enough space this particular balloon 3 it's got enough space to run a normal devian install I'm using it for mdevian so we can work on much smaller devices that haven't got that kind of luxury hello could you elaborate a little bit more on what would be a roadmap to include microlipc support because it's not only about creating the tool chains that support microlipc but as well you need to customize several build options because microlipc lacks crucial functionalities for many packages like icons and stuff like that so you would need to change several rules files for packages that's going to be another part of that I'm hoping again the maintainer who's going to be looking after ucylipc and devian is also the guy who had the idea for these d-packet variants d-packet classes that kind of functionality in d-package so that once you've got more patches from mdevian into devian upstream after leni then you can have this whole variety of configurations passed on to d-package so you can have these options with disabled something based on the variant you're using and then it's a distribution wide variation across the board you can just set a string of configuration options and it will pass those across to all packages across the board so that's something we need to work on to try and get that thing and it is going to be part of what we need to work with ucylipc so it's going to take us a while any volunteers? what about architectures that aren't currently supported by devian like codefire do you think it would be possible to support them? difficult it is embedded devian we are reliant on devian and the architecture support within devian we've got the dds to get those kind of changes into devian if there is the demand to do so but we need that kind of precursor it does need to be in typically devian d-package before we can really use it we actually did get some codefire boards a few years ago from free scale to make the m60k support codefire unfortunately we haven't really reached any point with that yet but we have a codefire v4e because the regular the other codefires don't have an MMU and you cannot run a full devian on that one but at this point probably that's not going to change very soon partially also because we are going to be kicked out of devian as you probably know now but we have a meeting for the mc8 developers at the end of this month and we'll probably discuss that but for now codefire is not going to change very soon why is it so crucial to have devian support for that architecture enable to be able to build within devian and toolchain for that architecture and cross build for that architecture there are several packages that will be need patches to be sensible to accept them out for the normal package as long as there are non-introsive packages patches there's two stages to that I showed you that d-package cross which is a package that can extend d-package for extra cross building functionality we do have support within that to allow a little bit of tweaking so that you can get a head start but at the end of the day when you're actually trying to install the system you want the proper devian d-package to understand what kind of archive it's handling and after and everything else from there so if they come along at some point and say I know an architecture you're going to be in trouble so we need at least d-package to support that particular string described in the architecture but we don't necessarily we can work around the rest but it can take a surprising length of time to actually get some new architectures listed in d-package so hopefully we'll get uclibc but that's a different issue again it's a whole new set of architecture strings with d-package but d-package has got a lot of work on other things so it can be queuing things up a bit we should be okay it just takes time I think I already know the answer but has anyone popped it up and said hey what about cutopia I feel like I'm going to pass this over to Jan in a minute the cutopia stuff there's no cutopia is one block isn't it so there isn't a cutopia in devian for us to bring down and use the cuti stuff well maybe someone will find the time to work with small versions of cuti4 and actually prepare a package set for that to begin build because the gpe stuff that I show you yet is gnome based but it isn't gnome you won't fit gnome on a device like that or the device we're targeting these are bespoke applications designed for small screens and for handhelds they have extra little functionality to make sure you can use certain buttons and touchscreens and understanding and that kind of stuff you won't need different packages you won't be able to just take a chunk of KDE and cross build that and stick it on the device I'm not sure how much work is going on on that as soon as it's in devian we can have a go it's going to what we really need and more people to do that kind of work so that we can come along so that I don't have to deal with 700 packages yeah I'm working on KDE as well with a group of people yeah so as you're actually getting these packages into devian if you're looking at anything if you're looking at adding any package to devian that actually has an embedded application an embedded usage come to the devian embedded mailing list ask us what you need to have in devian rules file and what kind of cross building support you want before you stick it up into new preferably so that then you've got the cross building support from day one and then get a tool chain, install it and test it and see what it builds another question is is one able to do partying work without one of these balloon 3 oh yeah you can work with the packages that's only that's really there for testing of the installation methods and to make sure that we've got the checks right and the various set up to make sure you've got the right files in the right places and the right support across the file system yeah there probably will be changes when you go from one device to another we can improve the tools but yes that is, I did a lot of this in devian work before I even had a balloon to work with in fact probably half of it was actually done without a machine to even test it off that's part of the reason for the code audit because some of the packages were done such a long time ago that I actually need to go back and have another look Hello again I would like also to ask you how is the tool chain generation works right now do you prepackage them for all variants you support or is there a tool that would generate like a sequence of packages stage 1 GCC compile there are headers and stage 2 it's a big block it's a big block you actually run one script that controls a series of other scripts it's maintained by another member of the mdebian team and he does that as a big big block build so he tries to build he'll say well I'm going to the mde64 tool chains today and he'll build each of the 12 cross compilers or 10 cross piles or however many he needs to build at that one go because he's watching the GCC version in devian and when it's updated he has to do a whole new build across the board that can take at the moment up to 24 hours are there plans to release some simpler version of that script any user plan specified like I would like to build a cross compiler on my system with my host and with that no triplet as output yes mdebian tools already supports that it does have a little tool called mchain mchain is what also allows you to customize an existing toolchain to work with uclibc it's primarily designed for times when you can't install the there isn't a relevant mdebian toolchain available for you and it's fairly crude in places it is just trying to do the little bits to get the right source package to build it and see what happens it does require you to have a little bit of debugging if you like as the build goes on and it doesn't necessarily it isn't necessarily a first time user tool we're trying to hide it away so that you mostly with msetup tries to get pre-built toolchains and if you need mchain then you need to come onto the main list and see if we can help you through it thank you I think that's about it alright, the device is here if you want to have a look at it I'll get the screen back on so you can actually see what's on there because it's one of these things with power sensors it powers off ok thanks for watching see you next time