 Rydyn i fnw ymddangos nhw eu gwybod o leiaf o'r modd ac y cyfnod i'r gynnigol Cd. Rydyn i fath o'r modd arall sy'n golygu ddat�. Felly, Joi, y brwyfarf. Qibby yn fwy, roi'n ffordd o'n cael ei wneud ar gyfer IOC yn gynnig eich adeilig. I want to give you a quick update on the status of both sides of the install of the work. What our plans are, particularly for Jesse, of course there are things we need to help on and I'll point those out as we go and if there are any things that people here would like to talk about, if you've got any more ideas, if the things that you would love to do for us and you're just wanting guidance on how to do it then that would be awesome. Please, because I am sad to say getting old, my memory is deteriorating by the day it seems. Please, if somebody could take notes, or even all of you, because Godby is awesome and let you do that, take notes. So we've got a record of this discussion afterwards. Thank you. So, Debian installer status. Excellent. So, we have just about two weeks ago released Jesse Di Beta 1. It's the first of the betas that we're going to do before Jesse. I very, very much doubt it'll be the last. There are known bugs. There are some known issues and regressions that are already documented on the web. Please, if you're interested, go and download some of the images and help testing with them. Please report any issues you find in as much detail as you can because at the moment we can't test all the hardware. We can't test all of the architectures ourselves. The more information we can get about the possible issues, the better. Now, in particular, there are worries about some architectures which suggest that those architectures have not been tested very well at all in the last, say, a year or maybe even two years. I know, Cibi, in particular, some of you may have seen on the Debian boot list has been worrying about the K3BSD ports as a major thing. There are quite a number of major issues which we would have hoped if people were using this every day, we'd have seen reports of bugs already. So that is a major concern. Thank you. There's also, and again, Cibi holds his hand up for this, the scheduling of the releases of the installer has... Well, it's been an issue as long as we've been doing DI and even going back to bootfloppies before that. We've had lots of discussions over the years and suggesting we should go for a monthly release cadence or we should go for a two-month cycle or something. And everybody says, yes, that would be really awesome. We might get them eventually. What would be a really nice thing to do would be able to do that and have DI migrate mostly through the archive as normal into testing. It's never quite got there. One of the issues around that, again, is manpower. The more people we have actually working on things and helping to test them and also contributing the bug fixes, the better. So we have a number of plans. First things first, we're just making the changes right now that we were talking about two, three, four years ago. The graphical installer is going to be the default for Jesse on those architectures where it's supported. So specifically on x86, to be honest. Again, we've spoken about this for years. We just never got round to actually making it happen. We had a plan at Deppcon for Nicaragua to say, yes, let's do it. And we kind of ran out of steam. We got sidetracked into other things. It's not just a case of it's pretty. The reason for the graphical installer being preferred is there are a number of writing systems and there are a number of languages that we just cannot support in the text installer. And we want to be able to do a better job. The default desktop discussion has reared its head again in the last few weeks. And as is typical on this, there's a lot more heat than light. Joey wants to chip in. Do we have a mic? With Russ and said, well, what do you think the correct procedure would be to find the default desktop? Let's find the procedure first. And he pointed out that the architecture of re-qualification that's done by the release team is kind of similar to what we want. So what I've come up with is a wiki page which allows the various teams who have input to send in input and then we get some kind of criteria to. And of course, there are certain issues like accessibility that can just automatically default it to GNOME if it does turn out that GNOME is the only option. What I would like to do is schedule an talk buff later on this week and go over that wiki page and see if there's some more options we want to add and see what details we can get. And then hurry up with that decision by the end of DevCon for something in that area or maybe the week after. So that's the default desktop. And I'll be scheduling that sometime not tomorrow because she's in wanted tonight some other time. And regarding desktop choice, which I see you also have up there, the current status, of course, is that a while ago, Franz Popp had put in SysLinux menus to work around the fact that DI doesn't let you choose the desktop but in store time. But we also have some other not unrelated issues like the fact that some of the CDDs would like to be able to be in the task cell menu and then that blows the task cell menu with all kinds of weird stuff. So I know that Kibbie had suggested now but he had earlier, well, we could pick the desktop and then I could say which desktop you want. I personally don't like that option just because it's going to ask you which of these three options, which if you are a new user to Linux, do you want? It's another strange mess of terminology to throw at the user. What I would prefer to do is have at the bottom of the list of tasks, something that says more tasks or finer detail or something like that. So that opens up another window, another menu where you can then say, you know, KDE, XFC, and also it can have other stuff. But then you need criteria for what actually fit in that list. If someone has some good thoughts about how to avoid that list exploding to 200 items, which is not going to be usable and it's the default if we have such a list. I mean, maybe that would be a good one to do with that later buff as well, that people have a thing first. Maybe, I don't know if that's the same buff, but maybe, sure. Or maybe even another buff. But I think the issue for getting this to happen in time for the release is primarily going to be translations. So independently, if someone would like to think about what that menu item should say and get the wording and get it start to be translated, you can just put the string in task cell right now and let Christian Perrier work his magic. And if we get enough translations and we can have the feature, I think that's where we're at. Yeah, absolutely. So, I mean, the thing about the default desktop that a lot of people haven't understood thus far is, I mean, I've seen quite a few people say, why do we even have a default desktop? And we must have a default, even whether some people think about it or not. They think it's worth it or not. Exactly, as Joey says, for the people, frankly, who don't know what they want, they just want to download, Debian, install it. Without a default, it's impossible. So artwork. Again, this has come up quite recently. Paul Tagliamonte. I have no idea how to pronounce his name. So apologies if I've just pulled tag. Yes. Has is seems to be on top of this. There's going to be if there's still quite a bit of work to do once we actually have artwork that's chosen because it needs to be put into the right format. It's got to be set up. It's not a huge amount of work, but it's going to take some time. So don't expect it to happen tomorrow, but this is, you know, it's on the way. There's a whole lot of bug fixes. We're already aware of quite a few. For example, there's issues with the firmware support at the moment in the Jesse installer. That's one that's really important. There's others that are going to happen. New architectures. Some people may have spotted, some people may not have done that. Literally in the last fortnight we've had two new architectures introduced into Unstable, which is ARM64 and PPC64EL. Both of the teams who were getting those architectures bootstrapped very much want them to be in Jesse. So those are probably going to happen in the installer very soon as well. Basically it's down to port-a-work. As part of that, if you're a package maintainer, you may end up being told your package needs fixes to be able to build on one of these new architectures. If you have a package that is involved in the installer at all, obviously this is going to be critical. We're going to be sending out a mail later today to explain more of what's coming. Secure Boot is again something we've been talking about for at least two years. We haven't made a whole lot of progress on this because it seems all of the people who know what to do here and have the skills don't have the time. I spoke to a guy yesterday after Colin's grubbough who said he's very keen to help. Aaron, if he's around, I guess he's not. I told him to mail Debbie and boot. Again, if anybody else wants to help with this, that would be awesome. We're going to be discussing this again later in the week. I know Stephen, Colin and I, maybe others will be getting together to work out the infrastructure we need and make sure it happens. We might have Secure Boot for Jesse. I've question-marked it, of course, to be honest. It's not critical, but it will be a nice to have. Last thing is the graphical installer still uses GTK2. GTK2 is, as I understand it, deprecated upstream. Everybody has been told go to GTK3. It's much better. We do need to move over the bits of the graphical installer over to GTK3 Frankly, if it happens for Jesse, it will be a miracle, unless anybody wants to go and help do that. Talking of help, please help. We need help testing. As I said, we have a vast number of options. For all of the possible Debian installations out there, there are paths through the installer to get to that. We cannot test all of these. If you have an architecture that, basically, Cibi and I don't have at home, we need you to help us test it. If you come to us after the Jesse release and say, oh, God, but PowerPC doesn't work on my iMac G4 or something, we're going to be able to do nothing for you at that point. If you tell us now, we might be able to help you fix it. That's critical. Wookie, do you have a microphone? I went to the SUSE conference and they have the same problem of testing the installer. They have a whole load of magic software which runs through a large proportion of the possible options to check that they do appear and say what they should say. That's all free software and you can write tests. We should possibly look at using their tech for test coverage if we were enthused. Thank you for volunteering. I'll put it on my list. I just know that this exists and it's what we should probably look at. I forgot what it's called right now, but I could find out. Open SUSE are magic, something. Again, we need to help test. We don't necessarily need experts who can fix everything, but if between us we can't even check that the installer boots on some architectures, it's very, very difficult for us to go anything beyond that. Book handling. The flip side of this, of course, is we're going to get bug reports posted for DI. We already have more DI bug reports than we can possibly cope with. When I say we, I mean Cibbie. Taeluson was talking to me at literally 6am his time last night, so I have no idea if he's awake or slumped over a keyboard somewhere, but even with one person not sleeping and doing 24 hours a day dealing with this, we still need more help. Translations is always a place where we need more help. As Gerry mentioned, Christian is absolutely awesome. It's not just Christian, obviously. It's Christian and his team of translators behind him, but they always come and go. There are always more languages. There are always more translations we need. There are always bugs in what we have, whether it's elsewhere or translations or whatever. Again, please dive in. If you think that the particular translation that we have in Swahili for the installer is wrong, tell us, because we don't even know what Swahili looks like. And there's plenty more stuff. Seriously, if you're interested and want to help out, DI is a really cool project. It's nice and stable and it works for most people, but there are always more cool things we can do if we just have the time to do it. Dive in. Switching over to my other hat, WNCD. Obviously these two are kind of related, which is why I've done the boff together. Of course, we're always short of people for both teams. We cope, but I wouldn't say that we would always be happy to have more people help. For WNCD, we are building massive sets of images every day and every week. The weeklies are continuing, the dailies are continuing. There are tweaks happening all the time, whether people notice them. It would be nice if people noticed, but equally it's also nice when people don't notice because it means they haven't broken yet. One of the major bits of progress that I've made in the last few months is that we're now building the officially released Debian Live images that are shipped from CDImage, or I'm Building. Joey seems quite shocked. Daniel does some really good work on Debian Live, but his schedule and hours don't necessarily always match up that well when we come to do releases. One of the things that we'd like to do is to be able to make sure that we have timely releases and everything is done together and hopefully all tested together. It was to move over to actually get Peterson on our normal CDBuild machine to also build the live images. That's basically working for release images so far. The last couple of releases have been built and signed by me. So plans for the future. We need to work out exactly what image choices we have. So far, we tweaked things after Nicaragua a couple of years ago, so we don't necessarily build all of the same images, but at the moment we still build for every architecture, we build a Netinst, we build CD1s for every desktop that we currently claim as a first-class citizen, so that's currently GNOME, KDE, LXDE, XFCE. The Marta people mate, I don't know how it's meant to be pronounced. I'm sure we'd love to join in. I'm sure the other desktop people would love to join us. It's just a case of, frankly, tell us what you need and make sure it's all done in TaskCell. Actually, something I should have mentioned is the TaskCell desktop qualification thing. It's also a way for other desktop environments to get added and to get reviewed and there's a process to get them in. As soon as a desktop is ready in TaskCell and we think that it actually gives us a sensible Debian installation, tell us, let me know, and we can add it to the set of CDs. It's not trivial, nothing's trivial, let's be honest, but it's not hard. One of the things that I've been tweaking over the last few weeks is the choices of CDs. For a while, a stupid bug, and it was my fault, I will hold my hand up, the GNOME CD that was officially labelled a GNOME CD, installed XFCE. We had a few book reports, but I never actually got around to looking at it and then it was like, oh no, my fault, that's fixed. We still have a lot of CDs produced. The exact choice of what to do is still open. If we want to essentially give up on the full sets of CDs that we produce, I could be persuaded. DVDs are much more useful. At the moment we do Blu-rays, we do dual-layer Blu-rays. Not everybody uses them, but people still seem to ask for them. Yeah, Joey, pass the mic back. What's the status currently about forcing desktops into fitting into OneCD? It doesn't work. The issue with fitting them onto OneCD is that basically the bigger desktops don't. XFCE and LXDE have for a long time, so they're easy. It's one of the reasons why we suggested XFCE as a default desktop for a while. I think this is partly a messaging thing. You want people, if they are limited, if they're constrained by needing it on OneCD, they need a way to find that out and doesn't involve downloading GNOME, burning it to CD, and then taking it somewhere where they need the CD and they don't have network and finding out that it doesn't work. Exactly. We need better messaging around it. Basically, it's hard. The desktops get more and more features all the time. Even a minimal, no more KDE desktop really just has too much to fit on a single CD. Have you thought about just not building GNOME CDs at all? Do we need them? That's a very good question. I don't know. Again, sleet if you have any ideas. We're something quite possibly. At the moment, we used to have a multi-arch DVD-1 which had i386, AMD64, PowerPC and Source, and that would install all the desktops. That's already too big, so we dropped PowerPC. I'm not sure at the moment whether or not actually all the desktops fit even for AMD64 and i386 on a single DVD. It's a, wow, we have so much software. It's awesome. Guys, can we not squash it a bit more? I would suggest dropping the... If GNOME doesn't fit on one CD, we should just pick the size on which something reasonable fits. If that's a one gigabyte USB that you can burn on DVD or whatever. If it doesn't fit on CD-1, just let's not do it at all. That's something we can absolutely do. One thing we've discussed in the past and has happened already is DVD-1 is explicitly sized to fit a few bytes under four gigabytes deliberately to make sure that DVD-1, you can just dd to a USB stick that's four gig, or write it to a DVD and you're not wasting too much space. We can do one gig, two gig, four gig, eight gig versions of everything, but that's just a waste of mirror space, let's be honest. An exact spec or an exact choice, as given, by the guys who want it, by the known people, the KDE people, whatever, we can tweak this as much as we need. Anyway, I am really under-questing, so. I was just going to suggest, I wonder if we could get Popcon or similar uploading a notice of, did you install via CD, DVD, USB? Could we actually get real data here? We have considered that in the past, to be honest. Yes, we can. Please contribute code. Sure. The one detriment of that one is people who are highly disconnected are the people least likely to upload Popcon. Sure. Some data is better than none. Obviously, we'll have to take it with a pinch of salt. So, moving on, because, wow, I am taking a long time with this, and I want you guys to be talking, not just me. Debian CDV4 is, I've been hacking on for a while. Debian CD3 is what is currently in use. One thing that many people have complained about over the years was never affected me, so it's why it's never happened yet, is they want to be able to build Debian CD without having to have a full mirror. It is a major pain in the ass, I understand. All the machines I'm on have a full mirror. Why doesn't yours? I know it's easier said than done. I'm working on, I have a branch that's already public. It's far from complete, which adds HTTP support. So it will actually go and it will build basically enough of a local mirror on the fly just pulling everything that it needs. It's never going to be as efficient as it might be, but it's better than nothing. Fragment? Yeah, for approximately ten years now, I wrote a script that basically does exactly that as a wrapper around Debian CD, and it goes and fetches installer images called Simple CDD. I'm really excited to hear that might get that kind of support integrated into Debian CD. It's coming in something I've been hacking on for six months and I know I've not made much noise about it. It's hard. It really is. Not because it's really computer science hard, it's just there are so many places in Debian CD where we've made assumptions over the years of I need to know what files to put in. I can just do an LS locally. I've now got to go and grab remote directory listings over HTTP and hope it works. It's a mess. We'll get there. So, yeah. There's a load of bug fixes. Please report bugs if you're actually a user of Debian CD. I know there aren't many. The more bugs we get, the more chance we're going to fix them. I want to get regular live builds testing. So, again, so we can get some weekly builds out. This hasn't happened yet. It's coming, again, in my Copies free time. If people want to join in and help with this kind of thing, that would be awesome. It takes time. Another one that came up when I started looking at the live builds and I realised actually the only sane way of doing this is building in a VM for a whole slew of reasons. Basically, you need to have root to make a live image because you've got to make device nodes. The only sane way of doing that on a system that DSA are involved in is you do it in a VM or it doesn't happen. I understand it's hard. Once I've got a VM going and this is the system I've set up for the live builds, we can do cloud images. We can do images instead of necessarily installer images, say for embedded architectures. One thing I know Neil Williams has been playing with quite a lot in Lava for testing. He's going to be talking about that later in the week is actually having images that you can test on ARM and whatever other architectures you want. Running that and building those on the fly as you go with DI can be quite tough. There's nothing stopping us generating regular images which you can literally just download and stick a DD onto an SD card or whatever and run. It's something that nobody's ever actually got to and I'm quite surprised we don't have these yet but hell, I can do them. Just give me time. The last thing here, I've got a kernel patch to rewrite this week. I've spoken to Case who came up. There's a minor issue we have with CD builds. The way the Debian CD works is it creates a tree of hardlinks as it runs and then makes images from those. On systems where you're not running as the same user as the person who owns the mirror, like for example Pettison or Build Machine, this falls over in a heap because this is dodgy behaviour. I've got a kernel patch or I had one and then I lost it because I overwrote that VM by doing an installer test and realised afterwards. Again, I'm sure we've all done that kind of thing. I'm hoping to find time this week to redo that kernel patch. I spoke to him. He's happy to review it. So, discussion. I hope we still have a bit of time left. What else do people want to see? What else do people want to talk about? I've already monopolised half an hour here. Please tell me. One of the things that's been brought up on the Debian ARM list was what ARM platforms can we support? It's basically based on a bunch of kernels. Do we install U-boot or do we use the onboard U-boot and all that kind of stuff? I'd be really interested in working towards that or at least focusing on open or fairly open platforms and just moving in that direction. Thankfully, now we've got the OMP kernel and device tree and everything. Most kernel, we can at least actually possibly sensibly get to the point where we can run the installer directly. I have. Exactly. Now we have. We've never had, for example, in Debian CD, we've never had bootable ARM stuff because every platform was so different. It was ludicrous. That's the point where we might be able to actually have real bootable stuff that is available straight off the CD or straight off the USB stick or the SD card or whatever. Yes, definitely. Let's do that. I know Neil posted a lot of stuff and Ian and Fragrant. Is anybody else interested in helping with that? I guess I could just add. I don't know if we're quite at the point of doing it on the CD or definitely at the point where DI can make images that can boot on these boards easily with the device tree with that boot image or something like that. And, yeah. I mean, ARM64, of course, is going to be most of the UEFI is what various people like ARM are saying, but then a whole load of people have already shipped various versions of U-boot. It's like... Really? I wouldn't mind it. It's the apple board, but it does have UEFI. It does. Anyway, yes. I was wondering, with the proliferation of sizes for, oh, do we need a 500 meg image, a 1 gig, a 2 gig or 4 gig, we're pretty much all capable of running cat and the vast majority of bigger images are just more U-debs and more devs. Could we just create a set of concatenatable images where if you want a 2 gig image you concatenate the 500 meg, the 1 gig and the 2 gig image and throw them on a disk, and then you don't need to store the 500 meg data 10 times over for 10 different images? Um... That is possible. Yes, I mean, we need to write the code and it seems like a sensible idea is a baseline of cat these 3 images and write it to a disk. If that sounds like like an absolutely awesome idea when fortunately file systems don't work that way. If you fix that, you wouldn't need that part of your data. One of the things I've had a bug about for ages is to actually do something similar, which given a set of CDs or DVDs basically turn that into a mirror that works. So I've had people in the past who bought a set of DVDs for me as an architecture. I've got those and they say, well, I want to share this what do I do next. It's harder than it should be and it's quite related. Again, somebody asked I forget, a guy asked a couple of years ago could we do exactly that? Could we take a set of DVDs and make a 16-ig USB stick image? Cat is going to be too simple. Can't be a file system that might work? Oh, absolutely, yes. It should be entirely feasible to come up with a script that will make an image from a smaller set of images. Absolutely, that's essentially what Debian CD does. It converts the big image, which is the archive into a smaller set of images that just happen to work together. Putting smaller images back together and making it work is entirely feasible. It's something that I want to do I might get to in five years. If you have ideas and if you want to help, please dive in. I filed a wish list bug that was similar at one point, which was I want to make a multi-arch CD that is mostly AMD64, but has those other smaller versions of the other images. Yes, Debian CD's idea of multi-arch happened quite differently to the archive idea of multi-arch. I don't know if people are aware of this. We have a multi-arch CD and DVD set at the moment where basically we make sure that for any given package we install it for every architecture that is desired on a CD or DVD. The naming clash is unfortunate, but to be honest it is the obvious name to have to describe it. It would be nice absolutely to have more options in terms of choosing which subset you want for different architectures. It's a matter of coding. Please dive in. I would love to help and again, I was in the day at all. Just on the subject of cloud images and MMC images, so DI will actually be a lot of interesting and useful questions as you go about key maps and mirrors and all these sorts of things and the problem with images is that they don't you have to go and mess around, tweak in all that stuff which is a real pain. Just generally why I prefer DI. If it's going to happen somebody would need to go out and write some sort of first boot configuration utility that We can use preceding for it, but of course, the problem is that still the person using it for the first time doesn't get asked the questions. If we can actually we should be able hopefully to we purpose Yeah, we purpose bit, defer things and actually That's maybe all this all sort of exists. Yeah. I mean, that will be a cool thing to do. Paul. I just want to say that the cloud people already got something called cloud in it that does some of that stuff. Yeah, exactly. Thomas and I have had the discussion a few weeks ago where we asked well surely you know couldn't somebody else do this on official servers and push it and whatever. Absolutely. We can build them. We can host them on CD image alongside all of these. CD image is not a wonderful name for the central server that we have. We know this. We agreed this five years ago. It's just install a document or whatever would be better. It's just that, hey, names stick around for a while. So, definitely Just come up with a patch for Deleon and Mark. At some point I would love to have every possible type of image to install Deleon, whether it's just an image you did to a disc whether it's an installer which asks you a whole load of questions and partitions and everything. All of those are possible and we should be working to get them together. Again, it's a these are all cool ideas. Please help. So another cool idea. I'll just butt in for one second. Please somebody tell me that I'm holding these down in Gobe so we have notes. What's the status of signed images both within the image itself and signing the actual image? I don't remember. How do you mean? You've got a bunch of checksums but do you have GPG signed images with the archive keys? What did it take to make that happen? All of the images that we ship, all the official ones the weeklies are currently signed with a temporary key and so are the dailies. That's something we've only just had quite recently. I resisted it for quite a while because it's essentially meaningless. It's a key that it means nothing. It means that at least they've got some indication that it's not been man in the middle. Is there a trust part that you and I have cross-signed every key that we use with my own personal key on the official CD release keys I've had a few of the other people around who I can press again have signed it so we've had to say a couple of release managers and various people in the UK because hell they happen to be nearby have signed the normal CD signing key. We don't yet do a roll over on it basically because it's faff and I haven't got that far it'll happen at some point. In terms of so all of the things are signed we do get occasional people saying why isn't everything over HTTPS and we're about to get though I guess but the problem is the CDs are so big that we want people getting them from mirrors we don't necessarily want them all getting them from all from the same central site and signing gets signing an HTTPS and whatever gets harder then. Just mentioning that at least the DI is signed Win32loader checks that it downloads the signatures and all that and you can download the inside and output images that are also in the archive. The fun thing about actually having archive signatures on say the release files and whatever inside the CDs and again this is a discussion that's come up several times is it actually gives you nothing if anything is worse than nothing the problem by having the signatures on the CDs is that for a lot of people that means they will then implicitly trust them if you've been given a CD that has something that claims to have been signed what is your trust path you have no way of knowing that it came through yes I know if you've downloaded a signed image and then it has the archive inside anyway it's a hard problem that isn't a solution Can I just say with the HTTPS if you start using the HTTPS a lot with large files you get really big problems if people are trying to use squid proxies because it's a different file every single time and we have problems like that with daily build test images for the same reasons it can be a real pain if you've actually got everything ends up on HTTPS with no fallback I was just wondering if we had any idea what the status of DI on our new architectures was how PC and ARM64 has anyone actually tried it I've been building ARM64 DI images from Devingport for a while in stores but then there's a list of flashcards I did it in NVM and QMU but there's no boobloader so I had nothing to integrate with I've just last night switched it over using the official archive and there isn't enough bits in it yet Kibby's been pestering on a daily basis and giving me a point of view of the build so explicitly I pushed keyboard chooser yesterday with patches for ARM64 PPC64L so we have all the parts but possibly not kernels ok and we think it works on the hardware available you should do the nice thing with ARM64 is it should just work with device tree you've got a kernel I was just wondering to what degree it actually tried it so the installer on ARMHF and ARM64 as well as producing you the installer which is a directory full of all the device trees that that kernel came with if you can decode the names of those files into them we're very nearly done maybe time for one more question yeah a bit more of PPC64L that the batch is what we're done by the canonical folks so we are using on Ubuntu since 1404 and also we have an internal image I mean it's public now for Devin and it's able to install over a VM and over what we call bare mental so it's working pretty fine ok so fingers crossed we should have the new architecture just integrated as a matter of course for Jesse assuming that they're all built by then and of course if you've got stuff as I said earlier especially DI stuff that does not build for the new architectures fix it or you will be in a mood in the next two weeks so please help or we'll work around you and I think that's probably a good time to leave it apart from saying please help Devin installer, Devin CD we really need your help there's always more stuff to do and as you can see here just the discussion we've had there's more cool things that we've all been wanting to do for years but twice we'd like two of us we're not going to get there please join in, thank you