 Initially, we thought about running a panel like we had last year, but we thought maybe this was a bit more boring, and we tried to decide to change a little bit the format. I'd like to thank Paul Weiss, who's been working with me trying to make up this presentation, but I'll be presenting this. So I'm Hector Oron Martinez for the ones you don't know me. I work for Colabora, which is a consultant company that supplies consulting services. So what I would like to discuss today, I'd like to do a summary of what last year was discussed in the panel. So why Debian or why not Debian? Why do you need a derivative instead of using Debian instead? Or how can we make Debian, how can we improve Debian from derivative from point of view on the other way around? I'll try to go really quick through all this, and then I'd like to present the new derivatives that joined in 2015, 2016, and then we have some slot that I'll be presenting some derivatives I'm working on, and in the audience, there's other people running derivatives if they want to have a word, present their derivatives, you're welcome to. And then we want to present a proposal of an idea to create a reference derivative, so we can somehow standardize in the tools that we use to build derivatives. Because there are, well, many tools to do different things, and some people trying to run new derivatives, if they have some reference, then that would be good. So why do people, based on Debian for derivatives, is Debian is an excellent platform. Debian is stable, it has a lot of packages, there's a lot of QA through them, it just works. So Debian is an excellent pick to run a derivative. It has also multiple architecture support, so you might not care about Intel but other platforms, so Debian is a really nice choice. So why not Debian? Why do you need a derivative for? Well, there is some software which is special, it cannot be in Debian because the licensing, or maybe you run a web application which needs some dependencies, you cannot have those in Debian easily. Or maybe you want to drop some architectures and go faster on your development than Debian because Debian needs to keep up with too much architectures and packages and dependencies and Debian cannot go as fast as what the derivative might need. Also, the release cycle of Debian might not be adequate, so maybe you want to have a cadence of its release in three months or things like that, or you want to have a latest upstream so you can contribute or maybe just your default configuration in Debian is not suitable and you want to change the defaults of many packages. So what can we do in Debian to make derivatives life easy? So as a Debian developer, we can coordinate uploads. Like sometimes there's somebody uploads a package and Debian does a transition but the derivative doesn't notice, doesn't pick it up and breaks the whole thing in the derivative side. So maybe it would be also good to declare what versions we are thinking on for the release, having reproducible bills, dealing with trademark issues, testing the back ports bills. Then it would be nice to notify derivatives that Debian has removed a package as well because sometimes derivatives don't notice and then after two years there's, where is this package? There's no updates. So improving testing by not breaking it and improving the documentation, Wiki, and so on. So the talk I want to send them more into the infrastructure for working with derivatives. So, go ahead. Well, yeah, what can derivatives do, can do to help to improve Debian? So if you run a derivative, it would be really helpful if you join the census we have in a wiki page, wikidebian.org. And keep that information up to date. You may send patches to the VTS. And sometimes there are patches that are specific for the certain derivative. So those lines of code would be nice if that gets into some kind of conditional. Like, for example, GCC builds for Ubuntu, then they apply different patch sets. So that's in a conditional way. So it's, you have the package vendor or ways to, or LSB released, or, I think there's three or four ways that you can detect which distribution you are in. So depending which distribution you are running, you can apply different combination of patches or configurations. So in that way, you can send these patches to the VTS and then maintainers should be able to merge them. So if you have new packages which are not in Debian, then uploading those two mentors. So some developer might review, that would be helpful. Come to DevConf, that would be also, and be active on mailing lists. You run a derivative. So these are some of the derivatives that join the census in 2015, 2016, I think it's Linux joined by the end of 2014. But some people is here and we added there at the least, and they'll be doing a presentation later today. There is also Kali Linux, which they are doing some presentation. I think in this room after this talk. And I'll be presenting some of the derivatives I do. So I work at Colabora and I'm involved with these derivatives. So a purchase is an automotive derivative to have Debian running in the multimedia displays of the cars. Used to be the radio system in the car. Then nowadays it's quite complicated and it has a lot of multimedia resources. You have video, you have audio, Bluetooth, and we integrate all that and provide middleware and then we allow manufacturers give all the libraries. Manufacturers create their UI, so they are working on the same middleware, but they have different UIs on the car. So that's, we recently added a purchase, but we've been running this derivative for over four years now. And then SteamOS, it's a game. It's done by Valve, which is also sponsoring DevConf. And it's a game OS, it's made to run games. So they have a runtime to keep compatibility for games. They keep the same libraries, that's frozen, they don't touch that. But that runtime runs over a OS, which is SteamOS and it's based on Debian as well. And then Endless, Endless Mobile is a company based in San Francisco. And they're building devices to enable third world countries, like I think they put in a lot of effort in Guatemala. And they want to enable, they want to short the technology bridge between first and third world countries. So they are going into these classrooms of under developed countries and set up their devices and then the kids can have a machine. So they're doing quite nice modification. Their software stack is based on NUM, they forked the NUM shell and created what they call EOS shell, Endless shell. So it's very easy and intuitive for people to get started running on a computer, which they haven't had the chance to play with. And they also use some updating software based on OS3. I think like that because the network connectivity is not so reliable. So that gives more better stability on the upgrading their machines and things like that. So they're doing quite a nice job. So we have to keep in mind that from the end we have a stimulus. And then from a stimulus, there's a Stevenson rocket and from a Stevenson rocket, there's Bay por OS. So we have derivatives of derivatives. So the thing is growing and the family is going more farther away than we might think. So we all start in deviant, so contributing to deviant, you ensure that many, many derivative lines will pick up your fixes. So I know here in the audience there's some people running derivatives. So you may want to have a word on your derivative. I added some of the logos, some of the people that I know here, they're here. So if you want to have a word, you're welcome. It's not a microphone. So I'm starting the round just to help other people to speak because I won't say much. Because if you want to hear about callinics, you should stay in this room. I will give a presentation just afterwards. Basically it's a penetration derivative. And I explain all the infrastructure that we have set up. And I also speak of the challenge we have because we are based on deviant testing. So there are some downside and some positive sides and I speak about those as well. I hope you will stay. If you have questions for me, feel free to ask them. Yeah, I'm sorry, this was going to be a panel and have some of the derivative people here and maybe have some discussion with the audience. But the audience become the derivative people and maybe I'm trying to kind of have a deviant derivative hat and maybe try to centralize all the derivative carries and try to support derivatives better from a deviant point of view. So in that line, we come up with an idea of doing a reference derivative, trying to standardize a common set of tools. So maybe some new derivative want to get started. So we can at least tell them, well, we have a tool set here that you can use to build that derivative. So the current way deviant, well, this is very simplified version of what the deviant system is for building the whole thing. So we have developers there, which they work with software and prepare the packages and upload to some FTP place, which is the incoming queue. And then there is some it's called WannaBuild. It's a kind of a scheduler that picks up the source package and sends those to the build emons. And then it builds for many different architectures and do a lot of complex calculations. And once all the binary packages come from the source packages, those are installed in some package repository. And from that package repository, the users get updates or you can create the images or installer media or whatever. And then we have a happy penguin user family. So running a derivative is more or less if you want to build everything from source, you probably want to set up that kind of pipeline. But there are many different tools that we can use. So, well, in the picture before, there's some missing bits, which we do QA, which is quite important that verify and test the images or packages. So we have tests of different levels. So we were wanting to present this that having a preference derivative. So nowadays, there's no discussion sources are kept in git. I think maybe proposing it to keep sources. And then from git, from a derivative git, we can pull changes and from every end can see all the changes that are happening. If you use git, I think there is a depth, a proposal for a git layout called depth 14. So if you use that, that would help understand how the layout, the git layout is all structured. Then we couldn't come up with some tools that we might need for branding or customized or sources. But sometimes someone does some customizations or how do they apply their deltas? How do they deal with the changes? We, at Collabora, we have based, we have modified Ubuntu version of Mergeumatic. But we have renamed it because now have more lines of code coming from us than from Ubuntu for our system. And we renamed it, it's called Mergeumatic. So basically it gets upstream package and compares to the package we have and figure out depth and applies to the new version and sends to some build system. And then we build a new package, verify it works. Then we can add this to the new distribution so we don't lose the delta we have. So for building a derivative, there are many different options. It would be good if we discuss and come up with a good tool for the reference implementation. So for Collabora, we use OpenBuildService, which we are also working in the packages to get them in deviant. I like to thank Andrew Lee, which is doing a lot of work on that side. But other people might use SBuild or might have some custom scripts or maybe deviant users want to build. But the setup is quite complicated. I'm not sure if this is suitable for somebody starting a new derivative. So then when we have the binaries, those need to go into some repository. So we're proposing to use RipperPro, which is to manage the archive. Deviant uses DAC, but that is quite specialized for deviant and the Swiss they have. And it has some hard coding and might be a bit overkill for a new derivative. Yeah, please. Can you get the microphone, please? To develop Tanglue, deviant derivative doing almost that is done. And we are using DAC and we patched out all the hard coding, so using DAC is possible for a derivative. And it's our solution for this, because RipperPro wasn't able to handle more than 30,000 packages, which we have in Tanglue. And we also didn't manage to set up one build. I think that's impossible for anyone but deviant. Right now, we might reconsider that because we have a few issues with it, and building is actually the hardest part and could be optimized, but for now, the devout stuff is quite well working. Okay, yeah. Yeah, DAC is possible to use. I know there's a Lemux, it's a distribution from Munich, and they also run DAC and they have been contributing a lot of code to DAC. To make it more generic. As far as I know, when we tried RipperPro at the beginning, it wasn't able to process the stuff fast enough for... So that was the only option basically for a more kind of the size of Tanglue or Tanglue. Okay. We handled around 2,000 source packages. With RipperPro, we're fine, but you have more maybe that doesn't scale so well. I wonder what issue you have with RipperPro, because in Kali Linux, we use RipperPro as well, and we have all deviant packages, so it's about the same number. But we do not build all packages, we only build about 400 deviant packages. I don't know where the issue is. Is it in the processing of result of builds, or is that the part which is taking too long? Integrating a result of builds? Wait, give that microphone please. So yeah, the processing is a problem because we rebuild all packages, and also keeping track of those many packages in different streets was an issue with RipperPro. Because we do releases and have the stable suite and an incoming suite, and multiple old stable suites, and this amounts to a massive amount of different packages the system needs to keep track of. And because it was well working on Debian, we just went with Duck then and didn't pursue RipperPro further. So it might have been possible to work it out, but in the end, touching Duck was easier. And yeah, the FTP masters were of great help in helping us to set it up properly. Okay, it's true that RipperPro is probably not always very efficient. You have to take care, for example, by default it always exports all the files, including contents files for each operation. If you have multiple operations, you should really disable those and do a single export every hour or something like that. You have to know it a bit and to work around its limitation. We also have found a few issues that are annoying, but I disclosed those during my talk. You just choose your trade-offs with these kinds of tools. Yes, it was quite nice that by using Duck, we also had integration with Prithne and all the other tools, and we just needed to figure out how to use it, and with RipperPro, it would have been more work to make it work. Yeah, right. That's one of the missing features for me, it's Brithne integration, which we do hack in. So I think it would be good to keep discussing this, at least on the main list, considering all the people that is not possible to get here and try to come up with some sort of standard tools to propose from Debian Mindset. It doesn't mean that you have to change your derivative, but I mean you're free to use whatever you want or whatever switch you must, but from having a reference could be really, really good for Debian, I believe, and I wouldn't mind to work on that. Another bit, once you have the binary archives, then you create some images or some installer, so there are also many options available, and I refer to Rick Wolpeo did a presentation last year about if he showed in Debian archives there were like 15 or 16 different tools to build images. They all do the same, and when somebody wants to build a new image, they come up with a new script. There's no one tool that we can use. There's also a difference if you want to have an image that you can ded on this, on an SD card, or you may want to have some installer media, or you want to have a live image. So it depends what your derivative wants. You need a tool for the images. I know the Debian CD team is now working on live wrapper, and that might be a solution for building images, like for cloud images, and it's not ready yet, but it's something that we might want to have a look in the future because the official Debian is doing this, and it's currently working on that, and maybe derivatives can start using this and adapting for their needs. Also, live build is highly used by many derivatives, building live media, but it's all fun now. I think there's no maintainership, so live build has been working really well. I'd like to thank Daniel for that, but now we are kind of missing this. And then once we have the images, we need to validate those. That's very important, and run some Q8. So there are very interesting talks from Antonio Tercedo about their CI, continuous integration without a package test, and there is also a Lava framework for Linaro guides, which is packaged in Debian and you can install, but this is more to deploy on real hardware and run some tests. There are other frameworks. You can run some scripts from Jenkins to do some validation. I don't know if people here, derivatives, run any other tools. You'll be helpful to know. But coming with some tools for the reference derivative could be also good. And in this case, I would like to... CI uses auto package tests, and this is a standardized format of a test. And Lava uses YAML files for trying these tests. And then maybe other Jenkins have... You prepare a script for another test. So you have different frameworks and different formats. So maybe using all of them the same format could benefit us all. So from a derivative, you work on some tests, and maybe other derivatives can benefit from that test. I think the auto package test is probably a good solution, but we would have to teach these frameworks how to use it. Can you pass the microphone there to Neil, please? Yeah, just a note on the auto package test, because that is very based on an installed package. It'll test the installed package the way that the installed package has had its unit tests set up. It isn't designed to actually test lots and lots of different packages in one go for one particular image or one particular set of binaries. It'll test one package according to what's actually been asked for, and it only tests the operation of that package, not how that package interacts with other packages. So trying to harmonize all these kinds of things is... It sounds idealistic to me, because they actually have different objectives that try to do different things, and you need to find a set of tools that can help people to do the particular kind of testing they need, and that can be multiple tools. But trying to do one tool that does everything is where Lava in particular comes into problems in the early stages of the design, and that's why we go into this redesign, because if you try to do too many things, you end up with the tool itself getting in the way of those people who are trying to do it before a particular task. Right. So I understand we have different kind of tests. You can do a source code, unit testing, you can do package level testing, or you can do system level testing, but at least having some common format, some standardize that we can share. Yeah, it's an ideal. But after QA, I don't know if... Yeah, go ahead. I just wanted to pass on an idea. I was wondering also what's the problem of testing interaction between multiple packages, so you can't do that really in the auto package test, but we could maybe create a separate repository of maybe fake source packages which would specifically have the purpose of testing a common use case. I mean, for example, Linux, Abash, my SQL combination, as usual, running a PHP application and testing this. It's a way to test multiple packages, which is doable because the auto package tests have dependencies, or you can install whatever you want, and it could be a separate repository. And I believe that the code running caw.dev.net can easily handle only a subset of package or a dedicated repository, so we could have something on the side which would do some sort of integration test, if you want. Okay. I don't know. After QA, you validate the image and I don't know if somebody else does something else, but just profit and benefit from their derivative. Enjoy it. So I'd like to thank Collabora and Valve because they've been sponsoring Debian and also like to thank Debian and DevCon people. So if you have any questions or answers or some more discussion, I think we have a few minutes left. Yeah, around 10 minutes. So just feel free to talk. And yeah, I'd also like to invite you to the next talk of Kali Linux. And then afterwards, I think there's a HP Enterprise Linux distribution presentation. So we might see what they have to say. Thank you. So you mentioned one of the reasons and your list of reasons of why people would choose derivative or start one was concerns about licensing. Obviously, there's different forms of that. One is if you want to include proprietary software in the default distribution, that's been a common reason people make derivatives. My very concern now is derivatives that are now violating the GPL, which is different than just providing proprietary software. So I was wondering if you had any thoughts about how the Debian community should deal with downstream derivatives that are violating the GPL and what we should do about it socially. Okay. That point came up from last year's panel. And I think it was introduced by Bugsy Raphael. And that was because some, he runs a penetration test in distribution. So some of the software is built to do an attack or something bad to the system. So that might have some license. It might not be a good package that it's a good fit for Debian. So that mostly came up from that. So going to the binary blob discussion, we just need to, there's GPL violations. If we find someone violating the GPL, there's not much we can do. Just point it out and try to fix their way if they don't know. And if they don't fix it because they're able, then if you want to take them to court, then that's the process. And as you probably know, that's a lot of the work that I do. But I'm wondering if there's a social component to it as well. Should Debian have a different attitude towards derivatives that violate GPL or take some sort of position to try and put social pressure on them, rather than legal pressure to get them to stop? I'm just wondering if you think that would be appropriate or should we explore that? I think it's not our business. So if somebody uses a derivative and do whatever they want to do, I'm not sure from Debian point of view, what can we do? We can decide that we aren't so helpful towards a distribution that we feel is not complying with its obligations. We could add a note in the census. Or simply remove it from the census. We don't... Actually, we have... Well, it's the only place where we sort of advertise our derivative. It's in the census. It's not very visible. It's mostly an internal tool to track derivatives. But instead of trying to blame the bad derivatives, we could do the opposite, trying to promote the good ones. Having a sort of Debian-blessed derivative, because, well, you follow the rules. You clearly separate free from non-free. You give back and you're open and that kind of stuff. So, I would rather go in this direction rather than the opposite one. Yeah, I like that. Yeah, I actually completely agree with that idea. And it correlates with something I've been sitting here thinking about for the last few minutes. You talked about the idea of a reference distribution. And my brain's been sort of revolting against that from the idea that anything you try to create is a reference that isn't actually itself being regularly used, tends to not stay fresh and current and sort of in good condition for long. So, the notion of, you know, maybe identifying some subset of the available derivatives that seem to not only sort of be adhering philosophically or morally to the right behaviors, but which exhibit sort of good mechanisms or good practices for building a derivative could be an interesting alternative to creating some separate reference derivative. I don't know. Just thoughts. Right. So, I was more focused on the tools and the toolset of the toolkit we need to provide for derivatives and maybe then do the real derivative. Yeah, I understand. You're right. If you produce something you don't use it will get rotten very quickly. I've been very bothered by the controversy with the Ubuntu trademark recently. Like, we provide for Ubuntu something that the distribution that they can make money out of. And then whenever someone wants to make a Ubuntu derivative they have to either ask permission or remove Ubuntu everywhere. To me, that's not a correct behavior because they... How can I say? They are twisting the GPL license doing that by using trademark loopholes. So, I wonder if Debian could do something about that to enforce the fact that we want people to be able to do derivative of our derivatives. Is there a... I'm not a lawyer, but would there be a way to do that? I believe there's a bunch of people in the room. Yeah, I'm sure I got you guys angry about me saying that. I'm sorry for it. But I really feel uncomfortable with the current situation. My company had to remove Ubuntu from Debian Change Logs and Search and it's very painful. Yeah, so if I can echo that we make a Ubuntu derivative and I love all the Ubuntu derivatives for all the cool stuff they've made but when I contacted Canonical Legal we were also told to rebuild all binaries and it's not feasible so we were re-basing on Debian. Yeah, a steam case was similar. They were based on Ubuntu initially and then they moved to Debian as well. Okay, so what's like the moral thing that's going on here? So Debian's made up of free software, right? So people can take your free software and they can do things with it which you don't like and that's probably what you understand. Yeah, right? As long as they're complying with your licenses, right? They can take your software and they can do things and you might not like what they're doing but you can do that, right? What would you want Debian to do here? Do you want to restrict what people can do with your software if you don't like what they're doing? I'm not saying that... This is the license. Yeah, but they're already violating the license, aren't they? Like, well if you're saying there's a license violation then you should deal with that but I think people are saying that Debian should try and find some extra way to deal with... like uses of its software by derivatives that it doesn't like. I just don't understand the philosophical or moral arguments It's not a problem of licenses, it's a problem of trademarks, okay? Canonical is enforcing the Ubuntu trademarks here. And if it's entitled to use its trademarks in that way what's Debian's problem with that? I'm not saying there isn't a problem. The problem is that I feel uncomfortable that a company takes our packages, rebrand them and then say you can't reuse that and modify it and use the four freedoms of GPL. There is more than 300 derivatives based on Ubuntu and all of them have applied to use a different trademark instead of Ubuntu or Ubuntu and all of them have been... There is a community process to apply for it. You shouldn't need to apply, that's the point. You shouldn't need to apply. You should be able to do it without applying. In Debian you don't need to apply and that's why people come to Debian and I guess it's very good that Debian does that because different projects are different. Can someone get the mic up there? I think people have conflated a couple of different issues. The Ubuntu trademark policy was violating GPL for quite a long period of time. It is now in compliance as far as I know. So that's its own issue and we can argue about the annoyances that the downstream Ubuntu community has about the existing trademark policy but it's not a GPL violation anymore. So it's not an issue of the licenses of Debian being violated. It's more of a noise by the germ raising about work and so forth, which is a different issue. I'm much more concerned about the existing GPL violations that continue which Ubuntu is also in other ways violating GPL. Those are something we should think about. Just like when the trademark policy was violating GPL I think Debian should have... It would have been useful for Debian to take a stronger stand about that and now that there are other GPL violations it could be good for Debian to take a stand on those. Or in some way. I like this idea over here of trying to promote the good ones more and making a list of people who actually are compliant with the GPL. Positive reinforcement is better than negative reinforcement, certainly. But I think it's important not to complain all these issues because it's a question of license compliance versus non-license compliance and then it's also a question of whom and has to comply with whose policies. So I just see that being complaining a lot here. We have minutes left. If somebody wants to add something it's not... Not to the licensing issue but for the reference distribution again. I think that one of the biggest problems for a derivative is that there are sometimes in some areas no really good tools to do a certain task. For example, building packages in a distributed way was really not possible on the scale we wanted it to do until we found Debian. Yeah, because tools like what Fedora uses are obviously for Fedora packages then the open build service was almost impossible to set up for on Debian machines because it was developed by OpenSUSA for their needs mostly. I think it might be better now. And one build is so deeply integrated with Debian infrastructure that it was unusable. So we had really a big problem with building packages initially. Also with creating life systems there is no... I think it's not the thing that there needs to be a reference distribution but the tools would need to be much better and much easier to use and much better documented. That's actually the more important part than what we currently have. Creating good tools and documenting how to create a derivative that will be in my opinion far more useful than creating another derivative. Yeah, the idea was exactly that. That document the tools and provide tools and it was more on that line we've been talking about tools prior than derivative. Okay, then I misunderstood the case I think. I think we can prepare a summary of all this sent to the main list and maybe we can pick up from there and continue this conversation. So I'd like to thank you all for being here and we'll continue next talk with Kali Linux. So thanks.