 Hi, everyone. I'm Steve. I've been doing WNCD stuff for far, far too long. We, as I always do, whenever I run this thing, this is not one place for me to talk and tell you everything. I'm going to start this off and then I really want everybody here who's got the pinion or wants to ask questions to please dive in. Otherwise, it'll be a very short session and I'll feel like we've wasted any place time. So, quick agenda. I want to have a quick go on to the current status. Plans for the existing sets of images we have. Talking about maybe some more image types. Any other random stuff we want to talk about. Somebody please take note to Bobby because, again, this is a session I want to get notes for. So I'll talk the notes afterwards and send out the sort of mails to the various lists. I tend to think that's very important so the people who aren't here are also up to date. And it's a good reminder so I don't forget by tomorrow exactly what we spoke about. So, current state. We have a massive number of CD, DVD, Blu-ray and dual-ray of Blu-ray images created using WNCD. These are published on cdimage.dev.org. That includes, and we try not to talk about it too much, some non-free images. We have some non-free vets. And we also have some non-free bundles of firmware. So there are tar balls and zip files. And literally, as of about an hour ago, also some CPIO images as well. CPIO? It's in the workout format. We also have some live images created using the live build tools. And again, we have non-free variants of those, including firmware. Again, for users who have hardware that needs it. We also have some open-stack images that are created using the open-stack provider tools. I don't see Thomas here, but he and I work through this. And Jesse was the first release where we ever had, I suppose, a cloud image included a part of our official release on our images server. I want to do more on that at the moment. All of these builds happen on Pettersen, which is a nice big server. It's actually been mined to play with for the last few years. It's awesome. Hosted by the nice folks at the University of Wales, Sweden, who are also applying the distribution site for all the Debian CD images. They have gigabits of bandwidth for monsters to use it. You like that? So, first announcement. Some people may be aware of this already. We will not be making CDs in the future. Apart from NetEast. Literally, I've been pushing changes for that for this week. Nobody uses CDs to a first approximation and people. We have the discussion multiple times in the past about when we're going to just stop doing them. And I've decided today that this week is the right time. If anybody wants to argue with that, feel free. Sure. So, by CDs you will be one such fit on a CD? Correct. We are going to continue making... Lifestyle it on a CD. That one is on a CD. Yes, that one is. Sure. We are not going to be making install up CDs anymore apart from the NetEast. The live images we are going to continue creating all of the current image variants that we have. I'm still going to carry on making DVDs and Blu-ray images for those that are potentially useful. The DVDs are still configured so the DVD number one will fit on a 4GB USB stick. I'm open to more requests for more different sizes of image. Obviously, as long as it makes sense, the more image types we add, the slower the bill goes and people obviously can be bothered by that. So, as an example, we did the Stretch DI Alpha 2 release last week for DI and Debian CD. That made 927 separate images called CDs. On AMV64, that meant we created... If you just downloaded the full CD set and wanted to wait all of them, you would need 88 blank CDs to do it. No one is ever going to do that. So, we've stopped doing it. We will continue to support the CD sets for existing, stable and old stable releases. We're not going to change those. Unless somebody really, really feels it's a total weight of space, I don't want to go back and basically and change what we've already done. So, the other change people may have seen. I asked about this on mailing lists a few days ago. The changes are in. I've picked. Again, I'm willing to be overruled. I think get.dev.org is a much better name for the CD image.dev.org. Again, fairly obviously, if we're not making CDs anymore, that's a really stupid name for server. We're going to keep the old name too. Again, people do get paranoid for good reason. For the sake of a DNSC name, we're not going to make the old things break. So, people who have existing URLs and all of the links and everything will continue to work forever, as far as I'm concerned. However, we're going to start publishing new URLs pointing here. One side effect of that is at the moment, if anybody is interested, go and have a look at get.dev.org right now. You will find that it first straight away takes you to a page telling you about devian CDs. Help with a new landing page would be awesome. We've been talking about and I've been struggling to find time, so please help. We've been meaning to change and get a much better front page that's more friendly to users basically forever. Help is always appreciated. We are still continuing to make non-free images. This is not non-free in terms of including non-free normal applications, but for those people who weren't in the firmware talk we had the other day, we explained it a bit there, they are images explicitly that contain non-free firmware. So for those people who have CD servers, whatever, no, laptops or servers, whatever, sorry, that need non-free firmware to be able to do basic things because of hardware support, we do provide images for those people. They have been unofficial because of course, we're deviant people. We don't like to advertise the fact that we have non-free stuff, but for software foundation we really don't like us doing it, but for those people who really need it, they are actually struggling to find them and that's not useful. From the firmware barf, we came up with a number of different points on how to just make really small changes that add up to improve user experience around these. I hope, again, that there will be mails coming round and we will be discussing exactly how we are going to do these things. Expect to see that the non-free images will be better late, there will be better advertised, along with text explaining how they're bad and why you don't want them, but we will make sure that people can find them who do need them. So, new image types, I absolutely want to help. If you have a type of image that we're not currently making, tell us. If it's one that you think would be better off working with a wider audience and you don't necessarily want to go through, you don't have a server with good net access or all these kinds of things, we are happy to produce more and more images on our central official server. It has the old server we're about to replace. The new one will be much faster. We actually have plenty of capacity to do more of these. As I said, we have an official signed cloud image to go in OpenStack. People have already spoken to me this week about stuff the Google Cloud and the Microsoft Cloud. Amazon people, I'm told, are also very interested. I have no idea how to use any of these. I'm not a user of any of these cloud services, but if we can help you produce images on official Debian infrastructure that are signed with official Debian key, we want to help so long as it makes sense. We have to first figure out how to do it outside of the infrastructure provided by those guys. Of course, that too. Please talk to me. If you can give me a script or give me a process that we can follow that we can run it on our own infrastructure so therefore it's totally trusted controlled by Debian, we're in. Yes. I work for Prophet Bricks and we are a cloud provider too and I created Debian and other images for our cloud, but maybe it would make sense to create the images directly on Debian. It would be even better if we would support cloud in it so that we can just use one cloud image that Debian creates and don't need one or two changes that we need for our platform. Awesome. Tell me how to do it OK. Not right now obviously. We can work this out. We have different variants of live images and Ian Learmouth, one of the Debian hand guys has been pestering me for the last few weeks on how to get a live image for Debian hand. Lots of these people Can you redirect him to us? He has stuff basically working. I've told him to talk to you as well. He's coming to my BBQ next weekend and we are going to be testing things and make sure it's all working. If there are any more talk to me, talk to Daniel and we can get loads more variants created. Again, so long as they make sense if you want to create a live image variant that's just for you we may tell you to go away and make it just for you. If it's sensible that a few millions of other users will find it useful too. Helen, we can do it for you. We are wanting to get some live images working for non-X86 as well. At the moment we've only had i386, amd 64. A lot of the architectures make no sense to have live images for because frankly trying to boot something live is hard or they don't have sufficient memory or removal media or whatever. There are things to be worked on here. Neil and I, mainly Neil will have been watching and encouraging. He's been tracking on a lot of the handy bootstrap support for making more variants of images including things with UFI support and everything in the last week. There's a whole slew of the activity going on here. Talk to us if you're interested. What else do people want to do? Does anybody have any burning requirements or suggestions that you'd like to see? We have built our own image for doing a net boot live system where we just create directly with the bootstrap and put some config in it, install some packages and so on and then do a net boot where we just have the kernel and the custom initRD to load the tarball extracted in a tempFS directory and boot into this tempFS directory. There's something that Devin provides that has similar functionality that we could use instead of our custom build script and... Don't know if anybody else is doing exactly that. This is creating a small kernel in a ramFS and then we have the tarball to extract into a tempFS. That's not too far off of what you're doing with live every day, is it? That's exactly what we're doing with live every day. You've got plenty of people doing it. You're doing it to... You can do it. Fine. Yes, I think. We have... Again, this came out in Wicu's talk about the different bootable image types we're reducing. We currently have 11 different image generator tools in Devin, and the whole slew of what was outside of Devin and the target Devin, and it's scary. Of course, the cool thing is that I think the reason why we have so many image generators is because it's not actually that hard a job to do to do the basics. So everybody starts off saying oh, I'll just do the basic bits and then they keep on adding more and more features the way they want to see them and that's how we end up with all of this work. It will be nice possibly to share at least ideas and possibly code more. We should totally talk about this on my own list and more discussion. I should say if you want to know anything more about this if you want to dive in the WNCD list is around. We have the WNCD IRC channel. It's fairly quiet most of the time because you may just find discussion between me and Keby or you'll see get commits turning up. Anything else people want to know? Anything else people want to help with? What help is always good? Yes. Is it possible to have a safety form several architectures that you either into a ham 64 machine 812 to connect with you and use also both? Yes, absolutely. We already have one existing multiarch CD where we have used the word multiarch and it doesn't mean the same thing as for packaging where the system will boot either on AMB 64 or Y386 and it has all of the packages for both if you were to do an installation with. Subset back. And we also we used to have the HP special as Walon described it so we had HPPA IO64 and alpha all on the same CD or DVD. So you could boot those. There is plenty of scope for booting lots of different architectures with one provider. If the way different architectures boot in different ways and sometimes they clash typically the way the older proprietary unit systems booted was you had to create a special set to zero on your CD or on your home disk which can take the pointers to work various other things the kernel, the init ram ffes lift so long as the different architectures you wanted to support didn't clash into what they wanted whichever offset in the boot sector it was all fine so that was why that combination worked. If however you wanted to make say an m68k on a spark boot the same CD they both wanted the same offsets for their own metadata. So you suggested what HOM64 and MIPS that shouldn't be quite easy to do HOM64 boots off CD using UEFI and El Torrito so that should work quite readily with the MIPS stuff actually MIPS or MIPSL Yeah I don't see that. That was your example. It all comes down to whether or not the two can coexist on the set with the same boot mechanisms on the same disk. There is information around describing how to do this if you can't find it yet. The question then comes down to how useful they are of course. We explicitly have the AMB64, I386 multiarch CD because that way we can have one disk, one net int you can give to anyone, almost anyone and little work on their laptop and work on their server. Job done. We're actually I don't see, you know, ODEX CDA has been working on fixing what we used to have auto-detect with Cislinux so it would pick up a 32 bit or 64 bit Intel chip at boot and then that broke. He's actually been hacking it back in recently the changes have gone in this week modular bug fixing it we should have that working again soon so the net int that is linked from the front page www.devin.org should then boot and do the right thing automatically on whatever PC you plug it into. So fingers crossed that will work again soon. So does that mean you're going to have O64 as that means in the future? At the point where AMB64 gets a sufficient proportion of users it will be easily persuaded. There's no point doing it until people are actually sufficient people with hardware. Yes. At the moment I'm creating some kind of cloud image platform which is called Vagrant doing this inside the Debian Cloud infrastructure but of course in the long term I would be very happy if I worked with you to do this. I've seen this has been done for OpenStack I don't know if it was but I'm sure it was. I'm telling it works. The images we're producing nobody's told me they're not working so it might not work. Something that would be really nice would be to have at least some simple tests that we can run on those images straight after build to check that they're at least vaguely useful. We can't test everything without a massive test infrastructure but at least it will be good. Yes, absolutely. If you have something to go for a different cloud image type again, talk to me and we can get it working. How does work, for instance, bug reporting for the OpenStack image or want to notify something about the image? At the moment I honestly couldn't say. Actually I think it comes to the Debian Cloud It should do, that's the best place for it. OK. Thank you for reminding me actually at the moment there is a pseudo package in OVTS for cdimage.dev.org We clearly need to add another one to get.dev.org and at that point we can then redirect all of those bug reports to the white people depending on which image it's about. I will be interested what test images are going through before they are published because it's kind of unified cloud image. We have to test it somehow. Exactly. At the moment the tests are whatever the image generation tool will do. Those are really minimal at the moment to a certain extent. They might even be so minimal that there are no tests. I don't honestly know what the test image does what the test build tool does. I do some simple sanity checking before release on the size of an image make sure it doesn't look too small and blow up too big and check to see if it looks like it's going to boot at least for some people. That's about as far as I've gone so far. On demo release day we try and run as many images as much of a matrix of different configuration images. Of course that works so well. That works well live and installed images for the cloud images we haven't got that far yet. We're going to unify something and there was a discussion on legal as well what we can call deviant. We have to specify the set of tests because everything will be passing. Please talk to us if you've got ideas of how to do it. We want to know. So for cloud images we usually have cloud images on them so you should be able to boot them give them network and association to them which would be a fairly good first test. But it's a good test for images working or not necessarily if it's comply with the deviant guidelines. Sure but then you have a running system which you can check against whatever you've got. So what came out of that in terms of guidelines for deviant images? If we're making them to a certain extent they're official what should we be doing? The problem is there was no explicit conclusion on it. Great. I think when deadline somebody says sometimes that the software which is used to produce image should be in main. It's obvious. The conclusion was that for example Amazon wants to have deviant images on Azure and they want, we have to approve it as a deviant. They want to run their own tests on it as well but the conclusion was they have to publish those tests and those tests have to be available for everybody to run them. So that's an additional point which you can see there. So for the installer images we have a test suite that was written by Tinchot Motton Barawi years ago when he did a GSOC project for deviant. I'll admit to my internal shame we've never fully integrated it into the CD building setup. It's been on my to-do list for so long. I want to get that in to check the installer images. Daniel, do you have any tests that are useful for live images in the same way? In the same situation for us there was a guy called Brandon who did an initial documentation of crazy VMC server stuff and had us some stuff. Who is speaking Go here? No, Go. Who hates it? That's not a solution because there is a kind of nice Go software called Packer which I mentioned earlier and you can automate various virtualizations so pre-immobil box, OpenStack, Amazon whatsoever and automate the graphical clicks through to some point. So you need to be able to rank Go and use it? No, somebody has to package it. Currently I downloaded a zip file from the page of the proposal also and just some untrusted machine and rabbit there which is not going to fly in there yet. Do we have a volunteer to help package my tailors? Where is Paul Tech? I'm interested but because I'm a sole user I have to create this image so he's not yet official yet. If we want to get to a point where we have a huge, much wider set of images to stretch obviously we want to make sure we get them tested we need to get some discussion going and actually get this done. I said definitely volunteers I'm not going to be able to do all of this for you. So back to the multi-arch topic. We have a customer install 64-bit we have a multi-arch enabled system that can run 32-bit after the end. Currently the only way to do that is full 32-bit 64-bit stuff on the installer and anybody else care about this thing. It's something people have asked about several times over the years but nobody's yet provided code. So when I first had it the support of Debian's a multi-arch image it was explicitly you would have as many arches as you want but they would all be complete up to the same level of completeness. The difficulty will be in terms of how do you define what is needed for each of the architectures if you can come up with a way of in an automated fashion working out what's needed. We have to do that anyway absolutely so we can just take in this is Debian CD itself it can take in just a package list you could shortcut the point that generates a package list or you can explicitly just have for any architectures you just want almost as a stuff say if you want AMB64 or if you want i386 available with some libraries you could just install the base system and add a few libraries to that and then just pass it straight through Shortcutting those bits of Debian CD probably needs code changes but it should be fairly obvious please follow the wishlist bug and I'll see what I can do to help I guess I'm always happy so please come and help this is in a depleted choir do every DevCon especially around to massively widen what we're going to be doing we are going to need help with making that work there's a usual choir as well especially when we come up to release time we're always looking for more people to help test what we're producing so we can make sure that we find it before end users do and they get confused because it's not just working so please keep an eye out for the call for help when it goes out for that especially if you've got the less common architectures thank you very much thank you I will say sorry I should have mentioned what I have me and my stuff you might have noticed we started a new Debian EFI team a few weeks ago I'll reiterate what I've said on the mailing list if you have a machine that builds EFI and does not just work with Debian and the installer please let us know sorry it's coming I'll come to that in a second if you've got the camera on it might not be a bad plan for EFI stuff we want to get problem reports if it doesn't just work flawlessly please let us know and tell us as much as you can about your hardware so that we can then actually track what's happening there is a cost distro effort and this is part of that work so all of the distros now are sharing information about particular brands and particular models of hardware so to be honest we can start telling the manufacturers instead of assuming it's our bug if everybody is seeing the same thing we can tell the manufacturers they're doing it wrong some of them might even listen we'll see and the second part of that is secure boot last year on how to do secure boot it got delayed I won't go into all the grotty details why it is still happening I'm hoping we'll be announcing initial secure boot support in Debian soon hopefully by the end of the year is it going to be available for KTVSE as well are you running K3 Bistie I tried a few times that's a very good question no joking the K3 Bistie folks have been asking for help to get a Jesse an unofficial Jesse release out would see the images and everything I'm happy to do that all of this stuff that UEFI would have so far is Linux only because that's what we've done I have no idea if UEFI even works tall in K3 Bistie it must do I hoped it would if anybody can tell us how to do it for K3 Bistie I'll happily plug the support into Debian CD we can plug it into all the other tools but it's just somebody needs to know I don't want K3 Bistie I don't particularly care that much with myself to go and do the work but I'm happy to accept patches now you can all go so see you on the secure boot front when you say support what does that mean exactly it's going to work properly or you can boot or it'll actually do the verification of the whole yes all of it firmware through kernel kernel modules, valuations that is the plan similar to what the Fedora guys have we are planning on having all of it so we will have a chip package that's signed we'll have signed grubs on kernels and in an appropriate mode it will be user selectable I think is the core of the plan but this is still subject to debate you will be able to say and this will only boot a signed kernel and a signed modules which key is going to be used to sign it sorry? whose key is going to be used to sign the elements of UFI we will have our own key this is part of the work that has been done we need DSA to set up infrastructure attached to FTP master that will be used for producing some signed packages that key will be dealt with entirely by trusted people only and will be offline all of that good stuff that I'm not going to bore you with we will have a chip package uploaded to the archive that will then be submitted to Microsoft for the usual for the signature process that is necessary on x86 hardware we are also very much interested in doing the same for secure boot on ARM64 and any other UFI platform that people ask for I know from the ARM world I've worked for ARM a lot of the server vendors are very interested in secure boot version once we cascade down I don't know exactly where the tail stops you probably know more about it than I do we definitely will have functional UFI secure boot in the installer, kernel and boot loaders and stuff that's the priority one can the relatives of Debian somehow focus on this whole process? probably it's something that is going to have to be talked about I don't have the exact details I'm not sure who wants to I'm hoping it will work of course it's a hard problem you know how far does the trust chain extend I know there are potential problems with the way the Ubuntu guys do it with their I have heard people complain about I don't know personally if it's a problem or not the Ubuntu, for example will happily load a non signed kernel what it calls if I exit boot services first I'm not sure whether or not that's going to be sustainable for them in the long term I've heard people say it's not but also I've not heard of anyone actually saying oh my god Microsoft would have opened our key I don't know Will the ARM images be signed by Microsoft? or have they been signed by Microsoft? that's a very good question no one has yet has come up with a central CA for ARM 64 secure boot it is very much under discussion and even if I didn't know what I probably couldn't tell you I work for all my overhear things although there are some things I should I know that I can't tell you or some things I don't know so I definitely can't tell you and now I think we are finished I hope any last question yay let's go