 I'm going to talk a bit about JSC and Stretch for the Debian install part. So as a forward, I would like to apologize a bit for the people already in MIDI depth comp in Cambridge, because they might have heard some bits about the JSC part. But fortunately, they've got the Stretch one to still discover anyway. Looking back at Weezy, we had a first release candidate for the installer like a month before the full freeze, which was quite a short timing. So we tried to do better with JSC, and we managed to release the installer in March with a freeze in November, which was like a big step ahead. Looking at the number of releases, Weezy was a bit more productive because we had the first alpha, which was like a bit long to come. But then we had four betas in like four consecutive months, which was way better. And then three release candidates. And the last one was the installer used in the Weezy release. For JSC, we had first an alpha, then two beta, then three release candidates. So we didn't quite manage to keep the pace we tried to have for the Weezy release cycle. So we probably could do better for Stretch and above. As far as archicator changes go, we had quite some changes with the addition of some arm stuff, new fancy blah Steve knows about. And PPC with a new version going 64 bits as well. As for the removals, we had S390 who disappeared because it was already replaced with the X version. We had Spark go, all were so sad, and Italian as well. And K3BSE was like a pity because I know that Steven has done a lot of work, especially in the last months to try and keep up with all the changes and the blockers that were stepping up. But being mostly a single man alone is like hard, so we couldn't quite keep K3BSE in. But anyway, moving forward to the default desktop, we had an early switch to XFC. The idea was to try and see how stuff would go and maybe take a step back and decide that that wasn't a good direction. So we discovered quite a few bugs like in Dbian CD, we weren't using the proper set of packages and so on, so the switch was not totally transparent. We had some accessibility issues, mainly regression, meaning that, for example, blind people couldn't quite as easily as before install and use Dbian by default, which was a big step back because it's really hard when you have some disabilities to actually figure out what a problem can be and how to fix it and how to get some help. So that was really a big issue for us. So we had some desktop selection at some point, but that was happening at the C-slide time, which means the very first prompt where you just click enter because the highlighted entry is installed and that's what you want to do. But you could go to some advanced menu and then select something that was on the default, but that was not the right place to select the desktop you want to install half an hour later. So now the prompt has been moved into the regular installation process. At task time, we are asking whether you want to install a desktop and you have a choice of the desktop you want to install. It's even possible to install several of them and then to pick the right one at the session point. And looking back at the XFC switch, there was some desktop qualification that was launched, I believe, in Portland by Joey. The idea was to compare the pros and cons of the many desktops that we have and to figure out which one was going to be used for this release. So we decided to go back to GNOME because the pros were slightly better than other desktops, but only for EMD64 and the 32 bits version because the support as far as OpenGL and stuff is mostly working there and not elsewhere. So we still have XFC on the other platforms. So that was a joy as well. We had GrubbinSolar, which was kind of counterintuitive because if you booted from a CD-ROM installing, it was defaulting to DevSDA or whatever your disk is called and that was OK. If you booted from USB, like a USB stick, it would usually pick the USB stick to install in too, but also not prompt you just in case maybe that was an issue. And it was actually a very old bug, but back in squeeze and wheezy, there weren't so many people booting from USB sticks and that also depends on the order in BIOS or EFI or maybe on the Linux side, I'm not sure exactly how the numbering goes and so on. So that was really leading to major pain for users and there was no way to avoid that bug except for setting that on the command line before booting everything. So we decided to implement a prompt, like which device would you like to install the Grubbs file, the MBR and so on, so that's annoying when you have a single disk, but it's actually quite hard to cover all the use cases, so we decided to prompt in all cases. We might try to have something more smart at some point, but we really need to be careful not to introduce that kind of bug again. So that was Vincent, not Steve, Mike and I are anyway. We had some big regression coming up, we knew it was going to happen, so Udev used to report the missing firmware on its own rights and exposing that to user space, so it was easy to figure out that oh, maybe you would like to have this firmware because stuff is not working otherwise, but that was racy and buggy and not done right, so Udev people decided to remove that feature, but it was possible to patch Hardware Detect to look at kernel logs where Ben implemented some structured logging, so it was possible to using grep and tail and whatever we have in DI, which is like a very basic environment, to determine that oh, maybe we are missing this file and you could be... you can put it into some USB stick or redo your installation image and then you know that your wireless card is not working because it's missing this specific file. So that was mainly Ben for the kernel part and Peter for the implementation in Hardware Detect. We had some fun with APT and CD-DVD, like we are using some dark command in APT, which is APT CD-ROM to scan the label and figure out whether we are on the first CD or maybe we are using a second one and play with several of them, but this command is very only used within DI, so APT developers weren't quite aware of the non-interactive way we were using it, so that broke, but that was easily and quickly fixed, so that was quite okay. So APT people were very keen to upload that very quickly. We had some party fun as well, because there were some new upstream release. I was preparing for a Debian Insular release and one day everything was working fine and the next day, because at some point you have to sleep, I re-run the build like uploading the statistics for the language in order to get the final upload ready and partitioning was totally broken all of a sudden. So that was actually parted going into testing behind my back and this version had some behavioural changes like not supporting some operation or mandating that you do this and that for doing other stuff, so Colin was very responsive and he patched mostly all part-man dash something, Udevs on the installer side and then uploaded stuff and then I had to poke into incoming to see what was there and started building new local CDs and figure out that oh, but the swap is working as well and iterate, so that took a few days and when I complained to FTP masters that it takes some time because you've got to go through the install and do stuff and blah blah blah they were like oh, but we could open incoming to the public there's nothing private in there, so let's do that. So that was a nice side effect. So that was all saying to Colin and FTP team, ha, system D. Actually that was like not a no-brainer because we had an issue where the installation process was like everything going right and then when you rebooted you had like a 30 second hang for whatever reason and all of a sudden, twice, this one disappeared and that was actually the priority of the rights that were updated by FTP masters to promote system D like the default init system and when you actually booted with system D and no longer with CSV init the bug was gone. So that was a fortunate coincidence but I asked FTP people to maybe poke me before changes that could affect the installer. So that was the system D maintainers that did the world work and everything was transparent, we had nothing to change in DI just consume the change on the FTP master side. For wireless support, we had some fun again because DI is very limited in an environment and Udebs are kind of butchered or adapted version of the regular Debian packages and sometimes some bits are missing. So we put some patches into the WPA package to be able to get more debugging so you still have to go through syslog and whatever but it's actually possible to get error messages now, which is fine and with these patches it was possible to figure out that some crypto models were missing on the Linux Udebs so they were added and more wireless support in DI. So the WPA maintainer is Stefan. We had some fun with many things actually. With Punjabi which is I believe a language used in India, nobody else that must be okay. The rendering with the default font which is probably deja vu was not really satisfactory so it was proposed to extend the font slide group package to build a new Udeb, use it and we only had to add a mapping. Punjabi is using this extra font and that was okay. So Aman is the reporter and Vasudev had questioned the we see uploaders because they were like, oh, new patch, let it go. Oops, it's already there. My upload was rejected. That was a bit strange. So we had some breakage at some point with font config because some files were missing in the Udeb. Again, the duplication of work between Deb and Udeb sometimes bits are missing. So we had some kind of font in the graphical shell which was totally broken so it was easy to fix just for maintainers until font config Udeb is fixed and just landed that. We had a big change which was user parameters because it was decided on the upstream Linux side that dash dash was meaning something really important and having parameters before and after being consumed by systemd. So there was a change and we were actually using this dash dash separator to separate stuff for the installer for the kernel and so on. So we added a triple dash to work around the kernel change but that involves patching Debian installer, some utility package, Debian CD, the installation guide and so on. And that's all Jan's fault for having found out that issue way before others. Because it was breaking the installer in a very subtle way and it was not immediately trivial to understand what was going on and what was the difference compared to the image from the day or the week before. We dropped 32 bits a bit more. I mean, we went up, I mean, in terms of requirements. I was going to say that. And so, yeah, actually it was not reported that we had broken support for old Arch and so it was decided to actually advertise what we were supposed to actually support. So then most of the work patching everything and changing stuff in Linux and then fixing Udebs because there was some missing patch at some point. But now we should be a bit more honest about what we support. And I believe that's the last slide for Chessie. We had some fun with Macintosh because we have some mixed environments and EFI and so many combinations and it's totally crazy. And trying to add EFI support for 32 bits was breaking or is breaking all Macintosh computers because apparently the firmware is not smart enough to figure out that, oh, there's BIOS or EFI. Let's do one of them and figure out. So that led to enabling EFI in 32 bits anyway and adding a Mac flavor to support all computers. So it's a bit inesthetic as far as documentation and intuition go but that's probably the best we could do. So again, that was Steve. So looking at stretch. I'm going to talk about stuff that is already there, stuff we are considering and stuff you could possibly help with if you come to us and talk to us. I'm going to start by comparing release cycles. It's been only four months since the Chessie release. There's already two releases of the installer out. If you are looking, I'm not making any promise. At a freeze in November again, that would be a first release 16 months before the freeze which would be way better than any other release before. And you might have heard me complain about Linux transition. I mean, it takes some time and it might not be immediately easy to understand why this is so crucial to have Linux in testing. The fact is we have many changes that depend on the minimal kernel version. For example, on the ARM side, especially the new Flavor, we have many changes and the configuration in DI is committed to Git on a regular basis and we can't easily go back to a very old kernel and do everything and then say, okay, there's no new kernel in testing. We can do a release anyway because we would have to roll back too many changes. So in this regard, we must go forward and wait for the kernel to transition to testing. So there was a first big jump, so 3.16 to 4.0, three months after the just release. So that's the point where it migrated to testing. We managed to have a straight shell for one release just after that. And when I noticed that the new release under testing, I was like, maybe we should do a release right now just in case. So it should be easy to spot any regression that might be kernel related by just running with alpha 1 and alpha 2. And speaking of stretch alpha 1, that was really a close call because I knew there was some proposal on Debian Devil. We could change the way we are naming interfaces. So I was like, hmm, that might have some impact on the installer at some point. But I was like busy with other things. And actually what we ended up with just before the alpha 1 release was the installer system using ETH0, as usual. And the install system using whatever name is relevant for this specific hardware or virtualized interface, meaning that the networking that you had configured within the I didn't work in the install system. So that was... And thankfully, timing and all that, the system maintainers noticed that I was closing in for the release and were like, oops, you might want to take this and that patch. So we managed to avoid releasing or attempting to release a broken installer because we would have failed all tests after hours of CD images built. So that would have been quite some delays, quite some time wasted. I spoke a bit about funds before. Over the last release cycle, there was some policy change on the funds packaging team. And they went from TTF-something to funds-something for most of them. And we had some transitional packages that are still pointing to old packages and not to the new ones provided by the new source packages. So we are lagging behind from something like one or two years for some funds. So we are basically missing some character or glyph updates or maybe some unicode support. But that shouldn't be an issue to just rename the packages and go on with it. But there was a big change with Chinese, Japanese and Korean, which is what CGK is for. We used to have a very special package built by looking into all the templates we are using to ask questions during the installation. We were up to get sourcing some of them and looking into SVN and Git, depending on all the packages. And sometimes packages moved or were converted from SVN to Git. And there was no error handling, so we didn't notice and glyphs were missing. And it was totally crazy. And fortunately, we had some proposal to just use the new one, which is small enough to avoid being botched to only keep only the glyph we need. And the size bump is relatively not really small, but okay, given that we are getting full glyph support, we are not going to have to worry about possibly missing some new questions, some new characters, and therefore some glyphs. So far, so good. We had some updated default as well. I believe the graphical install was introduced in mid-2000, maybe 2005 or 2006 or 2007, or whatever. But it was really new and it was not made the default until we decided that maybe we should for Rizzy or Jessie, and we actually didn't, because too many things to do. So now that's done. And we have also a multi-art image making it possible to install an Intel platform in 64 or 32 bits. And now we default to the 64 version because, well, it's about time. Coming up next, making the menus in the multi-art image a bit smaller by not listing the 64 and i386 by using some conditional stuff in syslinux, it's possible to detect the CPU we are running on and only display the white block of option. So that's all, that's all Didier's fault. So you may thank him. I'm not sure how I'm doing this for time. Okay, thank you. We have GTK Plus. We are still using the version 2 because it's supported. So that's quite okay. And I was like, oh, I don't know what to do for DI. So let's look at CDEPCAMP GTK. So basically, DI is asking a lot of questions through DEPCAMP. We have the text installer and the graphical installer, but both are using exactly the same set of questions, just presented differently through CDEPCAMP. So I looked into porting CDEPCAMP the GTK front end from GTK 2 to GTK 3. It's actually quite trivial. There are some repenting functions that I wasn't really sure what they were for because not porting them was leading to OK-ish results. So there's quite some bit to polish for this patch series. Also, I didn't feel the urge to move to GTK 3 because its UDAB has been regularly not installable in a DI context. First, it was depending on Kerro object for which there was no UDAB and then 80 SPI. So I reported some bugs. UDABs were introduced. But basically, we have more packages, more impact on all these packages because they are caught up into the DI release process, so using version 2 just works for now. We now have LibEpoxy, which is a new package missing a UDAB at the moment. So in addition to cleaning up the patch series, we have to port or maybe rework the theme basically so that we don't use the default Adwaita, I believe, the GTK theme and have something a bit debilish. So it's probably getting worked on in a few months. On the X side, we are using InputFdev for both keyboard and mouse on Linux, a separate keyboard and a separate mouse packages for 3BSD and Aherd. There's a new component which is input LibInput using LibInput. But that one hasn't been tested outside DI yet, so we are not going to make it the default into DI. We're going to wait a bit that XMaintenors experiments in unstable MME testing and then only consider doing the same switch into DI. So again, a matter of months probably. We had some artwork to update, so we had Paul organize a kind of contest. People were submitting their theme and screenshots and whatever. And in the end, the lines theme by Juliet was selected. We had some nice side effects because Juliet joined us at MiniDebcom for Lyon earlier this year and gave a talk telling us about what happened as a new contributor in Debian. Not necessarily really very technical, technical with pencil and whatever you would be using to do art stuff. So there was some kind of a clash of culture because you have to get used to the tools. No! So there's a video of the talk in French but if you want to discover that a bit more she's actually there as well. So Paul was volunteered again. One of the biggest issues we have in Debian besides firmware which is not something I plan to talk about because we just have some buff and details will follow. But the biggest issue besides that is secure boot because at the moment it's possible to use EFI but not with secure boot enabled which means that by default many machines modern machines come with secure boot enabled and users have to fiddle with EFI settings to I don't want to use secure boot so we might require setting a root password first because the menu can be hidden which is not really user friendly. So I believe in Portland as well a plan was designed to get secure boot signing keys and then update whatever bit of info is needed to use them. Package, shim which is basically a building block we can put between UFI and grub or whatever so there's some chain loading involved and then merge support into DI and then test and get work on stuff but try to fix them. So that was mostly total spline I believe until he didn't feel quite like Kippicon with that and Matthew with the shims author and if you don't know him you really should be reading his blog post because it's really a nice word to discover. One of the big issue of the day or the week or the month is GCC5 becoming the default and the huge transition going with it so if you get caught up into this net it's like months of delay for a possible migration to testing but we don't use C++ in DI so we're basically okay basically because actually some packages are used like syslinux, the unstable version because it's a build dependency so pulled from unstable and when compiled with GCC5 it produces some images that are not bootable so part of the release is actually broken but that's one image among many others so that's basically it and I'm going to get back to exhibit stuff later one of the other big plan was proposed by Ansgar which is trim the list of packages we are installing by default because it's huge there are many stuff that have nothing to do there so we should be able to reduce default install size with DI, in-shoot, in LXE, Docker, whatever but we have to be very careful with the init system because at the moment it's pulled by priority so if it doesn't get pulled by default now we have to have some bits into DI to actually install something to boot the machine with and we have some pending feature requests because people like to meet me and tell me that they would like to have that into DI so they volunteer, that's nice we had some ISO loopback which was requested a long time ago but it was a bit difficult to merge at the time because too many packages were touched at the same time but there was nothing to actually enforce the lockstep so it was possible to update this and that package and breaking other use cases, I mean more common use cases so I decided not to take the dispatch then but we have a volunteer to help me sort out what is risky what is not and whether we want to have some depends or breaks or conflicts or whatever to ensure that nothing breaks could get out of sync we had some reports about multi-pass being broken so the multi-pass block devices not the ISO stuff the TCP stuff we have Matthew who work on Ubuntu with willing to port to resubmit an updated series of patches so that we have something that works again with the current version of multi-pass which was very different from the version we were using when the first series of patches were submitted so that's nice and I heard about DNSX support, Robert was asking maybe that could be an option for the installer and I went after him and was like it's easy there's multiple ways to do it but actually implementation is easy but the decision is not because there are so many use cases where DNSX would break stuff and users would complain and maybe switch distribution and whatever so it's apparently prudent to not do that right now, wait a bit for some other distribution to try it out so I run stuff and then only decide whether we are going to add an option I mean a non-hidden option to add DNSX support from DI and yesterday evening I was asked about HTTPS support because basically the work has been done by Colin in Ubuntu already but apparently in Debian we don't really need it so we didn't get those patches so we would have to discuss a bit, see what we would gain by merging HTTPS support and whether there would be any issues with it and finally we have new maintenance for some a bit unloved packages we have desktop launcher for DI in live images making it possible to boot a system with a live image and when one is happy with it we can just click a button and that would start DI so that didn't quite was maintained for a while but Ian stepped in so that's all nice, that was like yesterday and I believe yesterday as well Andreas stepped up to maintain DI a network assistant which is a tool to make it easy to download the right files for your platform put them into some PXE setup and then even add a menu so that you can have some PXE server with multiple images and multiple platforms supported on the same device and GNU PG and it was DKG coming up to us trying to figure out how to move GPG VUDEB from the GNU PG1 to the GNU PG2 package, I'm going to skip a bit because that's again mentioned later I talk I mailed DDA twice about freezing from time to time, basically what I meant when parted snake team while I was preparing the release could have been prevented by telling Brittany or release tool to just block everything producing UDEBs so I've done that a few times already I'm going to do that again if you want or need your package to migrate come to me and we can discuss the pros and cons and maybe it's going to wait anyway maybe it's going to get a jointed into testing because it's badly needed and we would have broken release otherwise so basically to sum it up, if your package ships a UDEB you can see that it's block UDEB so in the excuses pages in which case you talk to me please if you plan to implement changes affecting the so the installer or the install system it would be nice to contact Debian Boot to tell us a bit in advance if you notice a bug affecting the installer for example the syslinux producing images that can't boot please use exdebug cc so that Debian Boot gets a copy of the bug and is aware of the issue and maybe try to speed things up like objecting a fix into testing or maybe using testing proposal dates to fix syslinux quicker or whatever many thanks are there any questions? what is the current status of VLAN support in DI? can you know that? I believe we are still to the point where Philippe said we should rewrite these patches at some point I'm not sure we went further for now? No but apparently the patches were not totally crazy just crappy code and might just be written in a clean way because from what I can see IP root which is the support is already there so it just needs net cfk probably too I believe that's what the patches were doing you mentioned shortly the interface naming scheme and the problem of it do you plan to make it configurable? I mean if I want to change it after installation that may cause problems you mean moving from ifnames to mac again or renaming interfaces? or just excluding biosdev name my favorite but others may have other preferences I believe that it's possible to switch away from native names with a kernel command line it's possible to switch it off completely but I just like to change the priority of the various naming I believe that's something that should be discussed with systemd people because I'm not really sure that DI can do anything about it it's possible by configuring systemd or udev so maybe there's some stuff some advanced question that we could in the export mode to make that configurable directly from DI instead of installing a system and then going back after a reboot so that's probably possible so here's one of the systemd maintainers this was actually we discussed that that we would like to have DI is there a need option for that? better this way but what we don't want to reintroduce is the old network generator but simply switching off the new network interface naming scheme that's something which we thought would be useful to have in the installer so it uses the correct names in the installer and the installed systems it should be pretty easy to do so if you are open to take a patch for DI then we can do that any other question? thank you again