 So, we're starting now with the Debian derivatives, both, the both more later both speaker proposer is Paul Weiss. Okay, so the way I thought we would structure this is start off with some introductions from people who are involved in derivatives and Debian and then some open discussion about issues and stuff and finally we'll talk about some things that Debian is working on within this context including the front desk, the decks which is a little bit inactive at the moment, the census and our derivatives guidelines which kind of a how to for running a derivative. Okay, so, can you pass the mic around? I'm Paul Weiss, I'm working on the derivative census and a little bit of the other things that Debian is doing. I came to Debian because of Gnopics, so yeah derivatives are the reason why I'm here in Debian. I get the reason why I'm here in Debian, a part of using Debian is probably because of fields which is another Debian derivative. I'm Stefano Rivera, I'm a Debian developer and a Ubuntu developer. I don't do too much in the derivatives community but I sit in both communities so that's why I'm here. I'm Jonathan also from Ubuntu and also Eddie Bunti. I'm Jonathan too and I'm being here by interesting. Daniel, I work on Debian and the derivative and I'm generally interested in the topic. I'm Ansgar and I'm just the art of interest as well. I just use Debian mostly and well sometimes I actually use Ubuntu so. Anyone else want to say something? Hi, I'm Fernando, I'm here because I'm interested in the implementation between Ubuntu and Debian called Odnovo, now part of the text. Okay, so does anyone have anything they want to issues they want to bring up or things that have worked well or perhaps in Trigera you can talk about some tales things? Well, perhaps it's a bit early to discuss that because things I have in mind are for OISI plus one probably but given that we when we'll meet again we'll have been working on OISI plus one for a while already so perhaps it makes sense. Right now. Okay, I've been working on a firmware integration to Debian. Aperma is a mandatory access control framework, a kind of security thing, you know? And it happens that Ubuntu has been using this a bit for a while and using it more and more and it's been out of tree at the kernel level. It used to be but it's not anymore and we'll get a Aperma-enabled kernel in OISI and some very minimal Aperma support in user space. I really would like this support to be improved a lot in Debian during the OISI plus one release cycle but it's given how it worked since a few months. It's pretty clear that it can't happen just by efforts done by a lone Debian developer. So, I think I will go reach the Ubuntu people and say, hey, you want to reduce your delta presumably and we want that in Debian. Let's make this a release goal and come help us and let's maintain this profile together. I'm not sure how this integrates with the existing DEX and other pieces of infrastructure. The technical details probably can be left for later. It seems like a good project for people doing the DEX, the Ubuntu DEX stuff to work on. Paul, I have a question here from Kevin Mark. He asks whether there are any derivatives having any plans for UEFI? UEFI? I guess Ubuntu has their plans for UEFI. Maybe you can say something about that. So, this isn't anything that I know too much about but I know our CD's already supported and it works, it's been supported by Debian installer as far as I know. So, presumably the patches are in the BTS. Thank you, Ubuntu, you can read all about some. We have one later arrival, maybe you'd like to introduce yourself. My name is Luis. My name is Luis. I'm from Venezuela. Mia and one partner are here from Canaima Distribution. We're looking forward to share experiences, things we should do, things we shouldn't do, how we can collaborate with each other in our work. So, that's it. For those people who don't know the Canaima Distribution, could you say something about it? Of course. Well, Canaima started around 2008. It was version 1.0 was based on Edge, I think. Version 2.0 was on Lenny. And then current version, stable version 3.0 is on Squeezy. And as you see, we're synchronized with stable Debian distribution. So, version 4 will be on Wheezy. Basically, Canaima is promoted by Venezuelan government for several projects. One of its derivatives that is kind of famous in the country is the Canaima Educativo, Educational Canaima for the children. So, the government puts Canaima in those laptops for, yeah, education and the children basically. There are almost two million of those computers in the country. So, that's what basically Canaima does. Luis, we have a question from the IRC, again from Kevin Mark. He asks whether collaboration means to share the language translation or to use a common server, or if you have similar uses like those in telecentros. I mean, what's the collaboration? And I would add, what's the main uniqueness, the main difference you have with Debian? Well, basically we need, well, Canaima goes to primarily the National Public Administration of Venezuela, although there are other versions of Canaima that goes to general public. But basically we need newer software in Canaima, and as we base on stable, Debian stable, we need back ports. So, also we need specialized software that otherwise we would have to wait two years, or the main Debian cycle for it to be in Debian stable. So, we added locally. I didn't understand the collaboration part. Well, the exact wording, he says collaboration equals share language translators, or use a common server, or you have similar uses. Well, the usage part is covered, but yeah, he's asking. Right. So, yeah, we haven't, how do I say this? I mean, we're starting now to retribute our work to Debian. Actually, that's why we're here. No, we haven't done much of collaboration to our father distribution. So, but we're starting to do it now. We're starting to get packages in shape so that they start being in Debian and retributing that work. Slightly bouncing again to the, well, the topic on Ubuntu that was already mentioned. Kusanagi asks, is it too crazy to have some kind of PPA integration with Debian? Actually, wouldn't it be nice to have some kind of PPA in place for Debian to allow work as a pre-integration in the project? He was questioned whether it's a pertinent question for this talk. He answers, I feel there's a lot of packaging potential out there that Debian is not taking advantage of. Maybe Ubuntu PPA are not what Debian needs, but maybe Ubuntu Packagers can have an easy transition packaging upstream. So, I don't know if you want to comment on this. Again, I'm not a canonical person. So, Ubuntu, canonical's often been asked if we could have support Debian or other derivatives on Ubuntu PPA, well, Lodgepad PPAs. And the answer has been no, because it's a fairly expensive service to run and they don't want it to cost any more than it's already costing. There have been fairly frequent talks about PPAs and Debian, which is probably a far more appropriate answer to this problem. But the last I heard that was going to be for Debian developers only. So, by the time you get to that point, you probably already integrated a lot of things back into Debian. Okay, just while Paul finishes writing this, I know that as far as I follow the discussions, having PPAs in Debian would be, as you say, restricted to Debian developers, mainly because of the legal revision, that we cannot just allow service to be open to the general public without reviewing the content and redistributing. I mean, canonical has decided to run with the risks of that. Well, so far Debian has decided not to. There are also other issues with providing PPAs for all architectures to the general public, because the well, S-Build itself is not very secure. So, actually, you can break out in various ways. So, you need to run builds for PPAs in a virtualized environment. And I think not all architectures are capable of this. But I think there have been discussions about if it is legally possible to provide PPAs to the public in Debian. But, well, nothing really happens so far. And yes, it is not the priority, I think. So, are there any other topics someone would like to bring up? Or should we move on to the derivatives initiatives that Debian has been working on? Would the people in Ubuntu like to say anything about the collaboration between Debian and Ubuntu? Or any other distribution? Yeah. So, me as a Ubuntu developer, when I am working with newer Ubuntu developers or actually any Ubuntu developers, the first question when reviewing an upload is, has everything that Ubuntu is deviating from Debian here been pushed to Debian? If not, why not? Is there a way to get there in the future? I think that is a fairly common view amongst Ubuntu developers these days. At least the community ones. In a derivative, it is a hell of a lot easier to keep maintaining your distribution if you push as much upstream as possible. When you are maintaining a patch set on top of something else, it is your work. If you push it upstream, it becomes upstream's problem. And it will be far more widely tested and probably work a lot better. In Ubuntu, we also have lots of people who want to fix bugs and upload new packages into Ubuntu. And then we want to say, well, you know, it will actually be easier to get it in Debian directly. Otherwise, products, definitions, we have other patch to maintain. We have a package that only exists in Ubuntu and not in Debian. And it is helping people if you get it into Debian, while other distributions and Debian users benefit from this as well. But it is sometimes difficult to know where to send them within Debian. We try to send them to Debian mentors, but it is not always the best place because it is sometimes a bit scary for some people. They are not sure how to interact with the Debian community necessarily. I am not sure if it might be useful to have some kind of system for that because we would like to make it easier to send people who want to actually contribute to Ubuntu to Debian so that they can get their work in the proper way. Okay. Is there any other topics? Daniel, would you like to say something? No? So in the audience, apart from the people in the circle, is anyone else involved in derivatives? Show of hands? No? Canaima. Yeah. In Canaima, we have another thing, like, I think in Venezuela we have almost three and four million lactose because we have a public industry for made computer and all computer are released with Canaima, okay? So it's a lot of computer and we have another project in this moment and I am the person promoting this project, okay? We have industry for mobile device and we have in Venezuela almost three industry for mobile device and we need, and we are working, trying to get or trying to collaborate with another project like GECO or like Open Web Device and we are trying to work Debian and Canaima in the mobile device industry in this moment, okay? It's a great project and we are working very hard in this, in this moment. Okay, regarding the mobile devices thing, later in DevConf there is a bof about Debian mobile stuff. The ODEX isn't here, but yeah, I will be at that bof as well. And there have been quite a few, well not quite a few, there have been a couple of mobile distributions. I'm pretty sure everyone's heard of Mamo in the year 900. That was a Debian derivative, yeah. So have any of the people involved with derivatives had any issues trying to contribute back to Debian and collaborate with Debian? This is on, yeah. Well, prime example, if you want LSIB support in deep package, deep package maintainers tell you that they don't want it because they already have LSIB MA in it and we are transitioning to XZ so they want to get rid of LSIB MA. Unfortunately, well, the patch for having LSIB support in it is like less than 10 lines or so so it doesn't really hurt, but for political reasons you can't have it because deep package maintainers say they don't want it even though other people want to use it. And these sort of things is understandable but it's hurting progress on other stuff so it would be nice to have some sort of way to get this stuff into Debian even though the maintainer doesn't like it but it's just something that doesn't harm him. Does that mean linking new libraries in deep package? He asked if it needs a new library, no it doesn't, it just calls LSIB as it's done with XZ. We do have the technical committee to resolve those sort of issues but that's probably a bit of a heavyweight thing for that particular patch. So, Stefano, you mentioned before... Just for the record, I'm not blaming deep package maintainers at all. It's totally understandable why they don't want it. Just from a point of view outside of Debian it's very hard to deal with that because that means you basically are always working deep package forever and putting your patch forward for every upload. Marc-Fran? One thing I have found slightly hard sometimes is to have really critical bugs fixed in stable. It happened a few times that once the bug is fixed in stable the maintainer does not care anymore that their packages does not work on squeeze. It's not that often but I think we probably need more publicity and awareness about the various efforts to track and fix RC bugs in stable. So, one of the new things in Debian that we have is the Debian maintainer dashboard. It's kind of like a to-do list that tracks which release things are fixed in and if there's an RC bug in stable then it will put a to-do item. Also Rhonda has been working on stable release critical bugs. Maybe you'd like to say something? Yes, I think there's still sort of, there's a lot of misunderstanding with respect to version tracking and how it's properly working. I'm working on an event that will announce mail to explain it better because actually it's fairly easy but it's also fairly easy to get some things wrong if you don't know what's going on with text and things like that. And I think we still need to get people to better understand that stable actually is a release that we are meant to support properly and that it's not that hard anymore to get fixes into stable. I think it's not like that since several years now but it's still stuck in the heads of some people that it's almost impossible to get any fixes into stable which just isn't true anymore. Yeah, just word of experience from fixing bugs in stable. So I do that sometimes for my own packages which works really well and for some other packages that other people are maintaining it helps preparing the patch of course and sometimes people agree to prepare the upload if you handle talking to the release team because they don't have time or are busy with other things. So is there anything else on the RC bug topic? Maybe we can go back to the issue mentioned by the Ubuntu guys before. Debbie and Mentos being scary. Did you attend the BOF earlier in the week? So in general we want that to not be the case. So could you elaborate on what kind of things people are saying about the process? Well, I don't think... I've heard people say that it's scary. I've followed the process too and I didn't think it was necessarily scary but it is definitely very slow which is purely a manpower thing and I think that's not an easy problem to solve but one thing that was encouraging in the sponsoring session was that a few DDs actually said, I want to be a sponsor, how do I get involved? So it seemed like not everyone is as aware of that there's a need for DDs to sponsor things like they should be and maybe if there's some campaign maybe even just an email every six months or a year to Debian Development saying that, hey, we kind of would like people to help with sponsoring and would you like to get involved? Please contact this address or whatever. So a reason I could think that Debian Mentos would be considered pretty scary is if you're a new contributor you're normally contributing a new package these get reviewed very thoroughly by the sponsor trying to help you upload them and they'll often get reams and reams of feedback and that is daunting and it's because the person is reviewing the package is trying to help you and make you the best maintainer that they can but it's also a long painful process. I don't know if there is an easy solution to that we don't want to accept horrible packages into the archive and we want to teach our new maintainers that we can. So there's going to be some difficulty and it's best to be clear to the people that are starting this process that you're going to have to do a bit of work but once you get through it we'll help you do the best you can. From what I've seen, I think one of the frequent complaints about sponsoring being a pain is that didis don't check very often didis don't check at all this list of pending packages. So for example I don't do. I don't do it because yeah I'm very bad managing my own time and if I have some free time I prefer to make my packages a bit better which really needs some logging from me. But part of this problem is because I see all of the packages from all of the fields that are waiting for somebody to upload. I know this is not the buff for this but since you're taking notes maybe it could be a nice addition that prospective packages to be included via mentors were to be categorized by something like the DevTag system. So there can be a matching if somebody uploads a package to be mentored the developers who are maintaining similar packages can be noticed expressly. There is some work going on with mentors there are a bunch of Googled summer of code students and lots of other people who are working on DebExpo and doing that sort of matching and stuff. I'm a genius. I'm a late genius. I think there will be an announcement about when the features are fully implemented. So it's 12, 30 minutes. And here Laney mentions we should get less mentors and more packaging teams. That's also... Many of the teams have worked on have become great doors to welcome new developers to get them involved and to avoid them having to wait for mentorship. Okay. So it's 12, 30 now maybe we should move on to the stuff that Damien's doing for derivatives. Unless anyone's got other issues or positive things to bring up. We've got one over here. I just want to ask about the... now that there's this extra effort to involve derivatives and the communication back to upstream for many of the packages and what upstream needs to be aware of now that these extra efforts are going on whether this is relevant in any way for release dates. Like obviously different derivatives are releasing on different schedules that can impact when should upstream be releasing and there are probably other issues as well in how things are communicated. You could have different derivatives pulling upstream in different directions in a worst case scenario. So I guess there isn't really sort of coordination with communicating between Devian derivatives and upstream. It's more like individual maintainers are involved in the upstream project and their community and they inform people about their release dates and whatnot. So yeah there's no coordination of that sort of thing at the moment. Maybe that's something we could work on within the context of the Devian derivatives stuff Do you want to add something to the goby about that? So elaborate more about your ideas and we'll move on to the next stuff. Okay so for those who don't know this we, Devian has a number of initiatives reaching out to our derivatives and trying to bring them back closer to Devian and giving them a space to collaborate with each other. The first one is the Devian derivatives front desk mailing list IC channel for discussions about issues and coordination and other things. It's not particularly active at the moment but yeah that's a good place to get help if you need help coordinating with Devian or discussing issues and figuring out how to get involved with Devian that sort of thing. So there's, if you're involved in Devian you can help us help derivatives so join the list and IC channel. So the next project that Devian is working on is DEX. This is had pretty limited work so far. The first, the main thing that happened was a review of a bunch of old patches and all of those were successfully merged or rejected and reviewed and all that sort of thing. That worked pretty well but more recently, there hasn't been much work on DEX and I think maybe we need some infrastructure stuff set up to make that easier and working. The next thing is the derivative census. This is my pet project. It hasn't really been any contributions from other people apart from the excellent people who have registered in the census and maintain their census pages. So the way it works is each derivative has a representative and they come to the Devian wiki and create a wiki page, click that button up there and then they fill out a wiki page with some data. Let's click on the Ubuntu one. So here we have a whole bunch of data about Ubuntu that can be useful to Devian developers and other derivatives as well, of course. So if a Devian maintainer sees that there's a patch for some package in Ubuntu and they want to go and ask someone about it, they can look at this information and find out different things about Ubuntu and all the stuff. And part of that is the sources.list of the derivative. And so from that sources.list we go to... We download all those source packages and we create patches so that the derivatives themselves don't have to do it. Ubuntu has done that for their packages already but it makes sense to do it derivative-wide rather than every derivative having to re-implement that system. What? Not do typhos. So derivatives patches. And yeah, this is generated on the snapshot.devian.org which has the whole history of the Devian project, every source package, every binary package. It needs a lot of... This stuff is not really ready for consumption by Devian developers yet. There are some limitations. Yeah. And I'm slowly working on that to improve them. So the next project that we have is the derivatives guidelines. I should go back to the other one. So the other thing about the census is the integration of the information that's gathered through these working pages into the Devian infrastructure. The first thing that it did was planet-devian derivatives which just aggregates all the blogs of all the derivatives into one planet. And I'm reading that and I'm finding it really useful. So I encourage people to subscribe to it and then you can contact people who are doing interesting things. That was the first thing. And then the second thing was the patches stuff. We've also integrated the Devian... We've also integrated bug linkages into the wiki so that if you link to a bug, you can tell whether it's closed or not just by looking at the wiki. There are some other ideas for integrating stuff into the Devian infrastructure like UDD, packages.devian.org, but I haven't worked on any of that stuff yet. So the next... I'll go on to the next project. This is the derivatives guidelines. It's basically a how-to for running a derivative and ways in which Devian would like derivatives to operate. So it includes things like changing branding, repositories, key rings. Of course, the Devian trademark, branding, and popcorn and all sorts of stuff. So it's a good resource and if you have questions about it or suggestions, please bring that up on the mailing list. And here we have some links about derivative stuff. So if anyone has any more questions, the end and we've got five minutes, four minutes. So one of the topics in your cabinet was branding and artwork. So this cycle, I did some work on the desktop package which includes all the usual artwork like the Plymouth theme and GNOME and KDE themes. And it seems to contain pretty much all of the Devian branding. So if you want to not have Devian branding, it seems like all that you need to do is replace this with something else. So I'm not really sure what the exact issue on that is if you could rate... The desktop base is one of the packages. There are other packages that include their own Devian logo or something. So this is one of the initiatives we should do for WeezyPlusOne is look at what exactly we need to do to get rid of all that stuff and separate it out into a separate package. Anything else? I have a question for Canaima developers. Currently Devian is not fully translated to Spanish and maybe for Canaima they did some work in translation to the requirements of the stuff in government schools and more. Is it possible to contribute that translation and that material to Devian? Is there a plan for that? It's very possible. We have a strong... because in this moment the Venezuela government have support for free software movement. And we are working to get a lot of projects for trying to get funds for work for free software activity. But we need work in infrastructure to make more easy collaboration. For example, in Canaima we have a lot of translation for software. For example, report book NG is a weak tool but the interface is in English. This is a little project to get this tool in Spanish for Canaima firstly and return this work for Devian. So we need to get a way for sharing between the Devian-Ting Spanish translation and Canaima. This is a weak project working in it. I have a question. We're starting to do the collaboration. So the way the translations are given to Devian is not the same as packages. There's a team. So we just have to integrate to that team. So for Spanish this is the language for translation stuff. You can join the list and introduce yourselves and get involved. Of course. Christian Perrier is here. He's the Devian installer coordinator for translation stuff. You should probably talk to him while you're here. So I think time's up. If you want to talk to me about derivative stuff during DevConf, just come and say hi. And thanks for everyone for coming.