 Welcome to Lightning Talks. We have five people doing six things, and first up is Sean. Hello, I'm Sean, so Deagert is a multi-faceted project trying to solve a lot of problems at once – the source package certainly is. And so I wanted to briefly talk about one of the things that Deagert makes better the things that deagit makes better that is a reason why you should consider incorporating deagit push into your existing workflows. So one of the things that we offer our users in our stable releases is that we say, look, we are going to make sure that you can do apt-get source, apt-get build-dep package name, and then it will build. Right? That's one of the things we ensure and it's an RC bug if that doesn't work. But apt-get a'r arhu'r arwain pan hyfyreddo am y maíau rydyn ni'n rwynt o gweithio'n gwahag y cwmbrith, i fawr nhw fawr yn ni'r ychydig ac roedd yn ei wneud, roedd yn ni'n amser yn gwerth yn ni'n rhaid fawr na'n byw cwmbrith yn rhaid gyd wych. Felly oedd opnod yr aeth yn gwineud i ni diwethaf am yr ystod yn ni wneud i gyd-ciw. Now, Digit clone is kind of a shortcut there, so Digit clone will have to get source and commit it to git, roughly, there's more stuff going on, but that's one way to understand it. And that's the git history you get if you type Digit clone when the maintainer just uploaded the package with depot. So it's kind of useful, it's in git now so you can type git clean and that's pretty convenient, but I think we could do a lot better for our users. We could give them the whole packaging history and potentially even the upstream history, which makes it much more, which is a lot of power for debugging problems on their system. So that's what you get when you do Digit clone when it wasn't Digit pushed, what happens when it was, well that's what you get. If someone, like I did, typed Digit push, then when the user types Digit clone, they get this rich history with all this useful information for debugging. They can revert an upstream change, for example, and then try and build it or all that kind of stuff. And as you'll see, the Digit push command has GBP in it. This wasn't a fancy git debris-based workflow or anything like that. All I did was drop Digit GBP push into my existing team GBP workflow. So if you're on a team that has a GBP-based workflow, consider incorporating Digit push and give this extremely useful thing to our users. Thanks. Right, next up is Judith, telling us, Stebien Lani, worth every penny. OK, the main issue about having a talk about what Stebien Lani is, will you be able to fill five minutes with it? But I'm prepared and I'll have a backup. So who of you is still using Lani? Who of you plans to use Lani? That's great, so Lani is not completely abandoned. But back in 2009, when it was released, everyone was using it. And now you feel somewhat lonely about it. And of course, there are reasons for it. For example, it got security support discontinued in 2012. And of course, it's missing a lot of fancy stuff like HTML5. This might not be an issue if you don't like videos. And even if you would have support for HTML5, probably you wouldn't have support for most of the codex. And of course, you don't have this emoji thingies, which also could be an upside for you. The worst issue is that about, I think, 65% of the web is not usable for you. Because you do not have the support for the encryption. And you're missing recent CSS, which means the DevCon page looks like this. And it's supposed to look like this. Of course, it also has upsides. You spend a lot of time finding workarounds, using change routes, trying to compile your stuff yourself. One of the possible solutions would be to make Lenny testing zombie or something like this. But this is going to break. So the best solution is just making a change route. Of course, this is going to be a collapse because the bigger the gap gets, the more problems you get with running the recent Debian on the Lenny kernel. So if you want to run Jessie, you need to install a kernel from backwards. But there will come a point when this will no longer be possible. And of course, you can run KDE and Firefox and stuff like this on crappy hardware. And it's really stable. You don't get any updates. No one is writing software for it, so it's great. And of course, you don't get any of the new bugs. There are lots of security bugs I just reading. Okay, the first version of the kernel it has, it was 2012. So I don't care because I'm using Lenny. But it's a lot of fun and maybe some of you might want to try it. Gunnar, we have you for the first of two presentations. As I said, we have five people doing six things. Two of these are from Gunnar. Okay, this is not really for me. I'm presenting a work I didn't do. Or that I took a very small part of. Let's subtitle Debian videos. So in Debian 13, Madame Zoo created this team. It has had around a dozen contributors. It has an IRC channel, don't worry. It's not high traffic. I think I have a month worth of conversations on screen at any given moment. And it has a mailing list, which I now see we should migrate soon to something more modern. You can find the Salsa project, you can find it in Amara. Amara is a framework for subtitling videos or making translations. What is the motivation for this project? Well, it is accessibility. Many of you have suffered trying to understand somebody speaking in broken English or speaking in incredibly fast English. So what we aim to do is to subtitle all of the talks or some of them at least because it takes quite a bit of work. There are people with hearing problems and there are people who are not fluent enough to follow English who may prefer reading it. So how this is made? I differ a bit with Thomas Vincent who prepared this. He says it's three main steps I have done it in two. Transcription and synchronisation are two different activities I have used usually Aegisu, so I do them together. He prefers Amara, a web-based tool. So it's first transcribing all the text and then cutting it to match and to be of adequate length of the time part of the speech takes. And then of course reviewing it. And of course it's always better if you do some work, somebody else will review it. You get much more things. So we have this amount of subs made for each of the last several depth comps. Sometimes we do very little work. It's sad that we only managed to do say one for depth comp 14. For depth comp 16 there has been a lot of work done, but it has not been deemed publishable. I don't have information on 17 or so. But there is work and this is hard work and I think it's work worth doing. I should do more and so should each of you. So join us. I will try to get you up to speed. Maybe the best way is the IRC channel. It's basically watching the same very cool talks you come here to watch or which you download somewhere. And make, well watch them really slowly. Of course it's most important to keep this work in mind. So if you are speakers at depth comp, make sure you use the microphone correctly. Attendees, well we also want your questions. So wait for the microphone or go to the microphone before asking questions. And that's it. Just as a last point, it takes me usually around four hours per hour of video, which is not that much. I think it's really a nice service we should try to have. Thank you very much. Next is Ian Jackson with a quick demo, which will take a moment to just change laptops. Very quick and very keen. Just one moment. So Sean's explained why you should use DGIT push for Debian's users. I'm going to demonstrate why you should use DGIT push yourself. You'll see here, I've just run the test suite. This is my real upload workflow. All I've done is resize the windows. Test suite has passed. I look at my Kit K. OK, tested is at master. I'll just finalize the change log. I'll need a window for that. Just a moment, I'm going to put down the mic and type. OK, so my branch is prepared. I just need to faff with my PGP key. It's a bit slow here because the Wi-Fi is a bit slow, so it needs to fart about slightly. Normally this is a bit faster. By the way, the monitor here has gone. Oh no, it's flickering. It's just always doing that. So this is a native source package. You can use this with any of the other workflows, like the GBP workflow that Sean was talking about earlier. Do I actually have Wi-Fi here? If I'm trying to do a demo up and upload with no Wi-Fi. No, here we go. It's just double checking everything. Checking my signatures, doing the stuff. All sorts of like frantic paddlings going on under the scenes here. I don't need to worry about any of this. There we go now. There it's pushing the Git objects to the Git repo server so that the Git users get that history. There we go. Now it's uploading to FTP master. It's made all the signatures. I'm just going to take my key off. There we go. That's it. Uploaded. Back by popular demand. Gwna. Meanwhile, anybody know any good karaoke tracks? Okay. I'm going to show a project I didn't do. It's not mine. It seems I'm not doing anything. I'm just showing other people's work. That's right. This is not Debian related, but still I want to share with you. My Mexican friend in Japan who visited on my way here found this. You've all read about the Scratch programming environment, which is very nice for teaching cheerlearn or teaching newcomers how to program in a nice easy way without syntax only with blocks that are very, very hard to get right. The main problem with that is that it was made in flash. Hence it's basically death. It's obsolete. It runs in a non-free environment. So he made as found, which looks very similar and which adds several things. Of course I'm not that familiar with it all, but let's just open this as an example. The Space Invaders game. It even runs. Somehow it runs. I don't remember the key, but don't worry. It runs. Here you have the program. I'll now show something that's easier to grab on a single. Let's see the classics. Fibonacci example. One of the things that Scratch doesn't do is to handle the concept of standard input and standard output. It's implemented in JavaScript and can be run locally. I couldn't get it to run on the first try, but I know it can. This is the main program. This is the function to calculate a Fibonacci. You can check. It's quite simple to get right. If the value is 0, return 0. If it's 1, return 1. Else return the sum of eith minus 1 and eith minus 2. I'm showing this. Running it is very boring. We all know Fibonacci. But it's very nice that it can show what this compiles to in JavaScript. I think this can be used as a teaching, a very good teaching help. This is, well, amigojapan.github.io and he has the sources available here. I will be happy to relay any questions you have for him if his contact is not displayed here. That's it. Thank you very much. Thank you very much. We have our last speaker. It's Hector. He's requested a double slot. I guess we'll indulge him. Oh, that's exciting. Right. Come on up then. Hello. Thank you. Hello. Speaking to many people here. Are you able to see the slides? I was talking to some people here. I didn't have much time to prepare this. I didn't have any pictures either. But I thought it was important to let people know a bit of the history of the Debian embedded and the ARM ports. So at the very beginning, it was 1999, Jim Peake bootstrapped the Debian ARM port thanks to Russell King that was working enabling support for the RISC PC on the upstream Linux kernel. And there was a lot of unsigned char and unaligned access issues to go through at the time. And that's what all the fun started. There was support for a few boards at the time, NetWinders. It was a big platform RISC PC, LART, Dicus N2100, which could also run a different ABI, which was the embedded ABI, the RML port. Are you able to see it or not? Yeah. So the ABI port, there was a Leonard Bytenheck work on the port in 2007 as part of an applied data systems, and he did a build for ARM V40 using open embedded help doing this work. And then Riku Voipio announced the first RML signage uploads buildemon. And you can gather more information at the link, at the wiki page on the ARM EABI port page. And we had support for different hardware and the main platforms, which include many different boards, were based on Orion chips from Marvell, Keywood, Intel has their own ARM line, IXP4XX, and the IOP3XX, which is this look, was one of the popular platforms at the time. And then there was an emulator from ARM called Versatile. So the combinations in the kernel was like exploding at the time and the kernel maintainers were a bit upset of having to do different kernel build for every different hardware out there. So side tracking from ARM, we needed cross tools. There was a cross tool chain was provided by Ndebian. There were some pre-lending cross tool chains 295, based on the GCC 295 binary packages you could install. But then Ndebian worked on, well Nikita Juchenko created and updated some patches for cross GCC 3.X, 3.3. He was trying to keep up to date those patches. And they were like getting rotten quite easily. And then myself, I pick up support for those in 2005 and updated them for 3.3, 3.4. GCC 4.X also had a cross GDB, which now we have GDB multi-arc that you can install from the archive. You don't need a cross variant. And we enable multi-lips support in the cross compilers. So after a few years, 2014, I moved on to other things and the cross tool chain got picked up by Guki and Marcin, which were working on a Leonardo and enable multi-arc support and uploaded to Ndebian. So the embedded Ndebian kind of fade out and now it got merged into Ndebian. And now Matias Clos maintains the GCC cross package as he can do uploads of the cross compilers and keep them in sync with the native compilers. So at the time we also on the user land on Ndebian, it was released in 2009. It was released in Ndebian Grip, which the purpose for that it was filter the Ndebian binary packages, remove all the fact like documentation and things that were not meant to run, to be on an embedded system, repack the binary file and release them into some repository, a public repository. So people could install that. A lot of innovations came from that discussions at the time, like multi-strap, the package vendor, the package filters and others. And then other like anonical, for example, pick up on the deep package vendor idea and push it further. But all the initial ideas were created through these meetings. And with Ndebian Grip, you could get, it was created multi-strap, which was another way to run the bootstrap. And you could come up with 56 megs of installed size, not compressed root file system. When you multi-strap Ndebian, you could have 90 megs of a root file system. But if you run the basic the bootstrap, you get 269 megs. You get binaries that you can clean, and then instead it was like 2008 megs. And if you like migrate from Ndebian to Ndebian, you could get up down to 160 megs. So it was quite safe in the space. And then there were some ideas that were not really ever released, crash and bake. Well, crash I think there was some pre-release, but never crash idea was a cross build, a user land replacing core utils with busy box, so it would be less than what Grip was. And bake it was a cross build, a minimal user land, but without updating capabilities, so you could just bake on a target, a hardware like firmware, that is not meant to be updated. So this morning we had some buff session, Ndebian Cross, there are some people that might be picking up on some of the ideas. I don't know if you are interested, it could be interesting to see some work forward on this. And then the Ndebian army chef came on. I was involved with Constantinos Margaritis in the initial part of the hard float. It was sponsored by Toby Churchill and Genesis, Genesis for the Effica MX devices. They have a laptop or a laptop or a netbook. And then Linaro Canonical also helped a lot doing upstream support for the hard float. There's also a wiki link documenting these things in the Ndebian wiki. And the initial support was meant for the Effica devices, so it was running a free scale MX-5 chip. But later, thanks to Linaro, we got a unified kernel and we were able to move to the ARM multiplatform, ARM MP kernel, with device tree support. And we only have one binary to build and run on any other platform. So that kindly got happy the kernel maintainers. And finally, the Ndebian ARM 64. It was a migration from the 32-bit userland to 64-bit. And it was bootstrapped by ARM Linaro internally. There was no hardware available publicly. And they were using fast models and also later they enabled QMU. And later we got some chips made and made available. It was a Juno board for ARM and XGIN hardware and that helped bootstrapping the Ndebian port in Ndebian ports and later in the official Ndebian archive. There's also a wiki link there that you can access. And now we have a unified kernel for ARM 64, but we have some different ways to run the bootloader. So now you can run your boot, you can run XCPI boot or UEFI. And thanks for being here at the end in Lightning Talks and this talk. And if you want more info, you can search the ARM ports wiki, the ARM ports mailing list and the embedded mailing list, which the embedded mailing list was sidetracked by the bootstrapping, which is the goal is to build Ndebian from sources and the Ndebian cross mailing list, so we are worried about being able to cross build packages. So you have all these mailing lists available and wiki resources. So thank you very much. Thank you very much. We were meant to have one more speaker who on short notice is not available. I believe the gist of his talk was please join SPI. So on behalf of that speaker, please join SPI. Thank you all for coming too. Wait. This is very brief. Right. So SPI, I don't know if you know what SPI is. OK. So SPI is one of Ndebian's trusted organisations. It holds quite a lot of Ndebian's money, quite a lot of DEFCOM's money. It's quite important. It's a bit boring to be honest, but it has a release critical bug. The bylaws are a complete mess. They date from years and years and years ago. They were like some horrible hack for by people who didn't really understand. It's terrible. We need to fix the bylaws. We have written new bylaws, but we need the approval of two thirds of the SPI contributing members, which might be you, to get those bylaws through. Two thirds of people have to vote in favour of the whole membership, not two thirds of the people who are voting. So we're having a big drive where we ping all the contributing members. Every Ndebian developer is entitled to be a contributing member. People who contribute to Ndebian in other ways are often entitled to be contributing members of SPI. So we're working on removing the inactive people from the numerator, but we want to increase the denominator. We want the two thirds to get two thirds. We need lots of people who are interested enough, at least, that you'll go and vote in the new bylaws approval thing when that comes up later in the year. That's going to be like a month or two. The new bylaws are pretty good. They've been extensively reviewed in public. It's a complete rewrite, so asking for the diff is not really very helpful. If you want to know more about that, ask the SPI general mailing list or ask me or ask anybody with one of those SPI stickers on their laptop. Thank you very much. Thank you very much. See, I didn't have to do it myself after all. Yes, so thanks all for coming to Lightning Talks. See you at Lightning Talks again next year in Coddachyba. Bye.