 So good morning everybody. I'd like to welcome you all to the first DebKonf lightning talk session We have 45 minutes to do this and we have nine different talks. They're gonna try to fit in this time We have seven different speakers So I'd like to ask you to hold questions to the end of the session if we have a little bit of extra time we'll have we'll try to answer questions then or you can just pull somebody aside in person and and In case anybody doesn't really understand what a lightning talk is. It's just a very short talk about five minutes long So I hope we all don't talk too fast. I hope you enjoy it and I'll start off with your own who has the first talk Thank you. I'm your room for wolf la and I'm talking now this five minutes about actively discovering books and issues with packages One of the there's a lot of books in Debian packages that will always be books And of those books that are not actually Discovered by maintainer or by a user needs to be Can be discovered by maybe some automatic fashion a few of those famous examples are actually the lintian checks of the whole archive or the pure parts run by last we say yes or Various people who are trying to build all the packages Regularly in the archive to see whether they are still buildable There are just a few problems with those this approach The one of the things is of all those different efforts. It's a bit uncoordinated Various people are doing things Without there being one single source of information Which means a certain amount of duplicated effort Also, it's quite hard to add new tests to this The two main reasons one is it requires quite some resources Hardware to add a new test with specifically also the infrastructure Every time you want to run a test over the old archive You need to make sure you have a way to run it on the old archive that you present results by some way Etc. Etc. This can be quite prohibitive to add new tests even if you have a nice idea to do so And also, yeah because of the not being very coordinated You'll have a hard time as maintainer for example to find out what is the results of all those tests that is going on with my package What's there the result? What's the status of it? Well, I think this would be very worthwhile to look for a better way on that And here comes the mall system in mall is a QA project The intention of it is the design is that you can add very easily tests By adding those tests is because the infrastructure is already existing you can add simply a file describing what kind of test it is and The workers that are going to actually perform the test simply need to know how it works Be including in the infrastructure will be a website where you for example maintain a base can see What's as the result of all those tests? Etc. That have been run over my package For example, does my package currently built does my package currently built under P builder? Does the package self tests once that is is there is an infrastructure for it? Does that work? Next to the web interface is also of course a raw interface file system base so that the data can be automatically parsed and automatically used in maybe different tests or different things The result submission of one you have Someone has a test running on the archive and it doesn't need to be by some QA person basically anyone can introduce A test of whatever nature The submission will be by email and therefore Enter the the infrastructure and the system so logs will also be available over there Basically quite parallel to how the building infrastructure works And optionally this infrastructure can also provide work distribution by simply indicating Which packages need to be tested maybe retested if it's a type of test that depends on the contents of the archive Etc. But it's not really required to use it if you you run your own Distribution of work. That's also possible And this would hopefully allow for a lot of extra tests to be added If you're interested in helping out, please email Debian QA at lists.debion.org and Well, one of the random things that is for example, maybe possible by this is Collecting data of what symbols are exported by each libraries Then finding out and using the raw interface again to run a new test on that and then find out which Programs might be conflicting with each other because the symbols are actually clashing with each other. Okay. Thank you very much Jose Jose he's not there. Okay Thanks, I'm Jose Pareda from Debian Venezuela This speak is a country independent talk Willing to provide some ideas on how to combines people with power to use Debian because making your country love Debian is a matter of convincing the people with power to use it So the first stuff about dealing with people with power is to handle their closed minds with solid arguments people with power usually have stupid arguments and especially if they are a Related to other free software projects like for example The red hat project in Venezuela We have several people related to that project and they usually make the war with the Debian community about the arguments we used to Convince the people with power so the first argument they use is the lack of support and the first lesson I'm willing to give you is to Respond to an argument with a better argument So for example when they say that the Debian lacks support You can say that Debian has two types of support It has commercial supports through enterprises and individuals and it has non commercial support For example, you can do auto support if you go to the book tracking system or the package tracking system Or if you ask on the mailing list or IRC channels In Venezuela, we have at least four enterprises doing support to Debian That means you can call them and tell them you have a problem with genome and they solve it to you Of course, it's a commercial support Also, it's important to tell them that Debian or the developership in Debian has a social nature for example, we're all here because of our social nature and also You can use the resources Debian has to provide more solid arguments. For example Nobody thinks that plant Debian could be exploitable to make people Convince convince people to use Debian But you can tell people that you can know about developers life in the planet Debian Or you can browse through their blogs or you can see eye-guards photographs in a in a webpage and all that stuff It's good because people usually don't have contact with the developers of their programs Also, there are dozens of non-government organizations using Debian We have to update the Debian web page about the who's using Debian web page needs Really good update because I only see one university in almost every country of Europe But I think that number is higher Also a university in almost every continent uses Debian Government organizations and if your country is left-wing like mine you can tell them that Greenpeace or blood banks or Internet social access centers in the in countries use Debian It's not ethical to use arguments for left and right-wing governments, but it's a tough word You can also Provide them the maps of the user and developers Maps that are made with X planet in the in the Debian webpage So they can see where is the people using Debian and all that stuff You need to have local developers for example in nationalistic countries like mine They need to have Venezuelan people working on Debian We're working on that also, but you need to have local developers You need to tell them that we have documentation and it's not a documentation like in the Fedora or Red Hat project It's an academic documentation For example the Martin craft book the Debian Bible or other documents like securing Debian from Javier Fernandez And this provides a harness for all the theoretical holes that might come in the distribution You can say hey, there's text. There's theoretical stuff that provides a Workaround for them. You can also Provide information about Debian net backwards sponsorships aliot or APT dash get org That are all community provided services for Debian. So in Venezuela we have a This is an unfair advantage over other countries because we have a law that states that we have to use free software So people in Venezuela usually says that the Debian community Doesn't give freedom to the users because we always tell them to use Debian What we give them freedom because they can use search edge or see it Now it's my turn. I'm Andreas Schulde. I will talk about Debian's role in the general Linux ecosystem. I noticed a recent change in The attitude of big multinational independent software vendors recently when They noticed that their current choices of certified platforms like Susie or Red Hat were not as Good as they wished anymore because Red Hat becomes more of a competitor now now that Red Hat moved into the middleware market and These companies do not want to support normal support perhaps but not further their competitors and the other Alternative Susie is not doing all that great actually Susie's market share is declining and Debian's for example is still rising and they are looking for additions or alternatives now and On the other hand side, they have a problem because the certification of their software to Platforms is really expensive And it's not cheaper to Yeah, well, it's as Expensive to add another Linux distro to the supported base As for example adding Windows for example, it's yeah, well and so for that reason they would like to reduce the supported platforms rather than to extend them their hope and their Plan whatever is that Debian becomes LSB compliant and that we are Will be able to become fully LSB compliant at all the other distros might at some point to be the same then they could just Do one Distro which they would support and that would be LSB We are in a very sweet spot right now because our release managers are willing to make LSB Bucks release critical and if given that the LSB community or workers committed to long-term support too and That would make That would make a Debian suddenly a first-class citizen in the Yeah, well Linux ecosystem regarding support and and Yeah, and we would be much closer to world domination all of a sudden Um that brings me right to my next point. That's the community Debian has a very lively and active community and it's growing and we and I think that research has shown that that Debian and Also Linux in general are doing so well because of their Community that is the edge that Linux has over commercial entities and I think that the great challenge and the Yeah, that we are facing right now is to have a community that is to improve our community and Further it in a way that it is able to compete with other Linux distros and projects We need to attract the smartest and brightest and best and socially apt people that we can get for that we need we need to be also more attractive than other distributions or Linux projects and we I Think the key key points to that are to be And I mentioned those in my platform for last to last two years and loving relationships and Empowering leadership and Small groups enable in order to become scalable Finally, I want to mention embedded systems Debian is market market leader in embedded systems and by a good margin there are Competitors which just repackage Debian packages into RPMs and ship them and They make money on this but Debian is still bigger. Please help our embedded systems developers to make Debian more Attractive to embedded systems even to a team to embedded systems vendors and producers and And help them to roll in the work that they are doing into the main Debian packages. Thank you Thank you Well, hello, my name is David more no Garza. I am talking about the WMPP books and how we are Working in this non very Attended area Firstly, obviously, what are the end end the only WMPP books? Well, these are just a kind of books Which are related to the WMPP met so the package We need to standardize all the WMPP thing because everything around it is a mess. I mean all the all this Processes we are doing around him all the reports all the the the people all everything is a mess. So we have to standardize it Yeah, well We have a huge a huge number of WMPP books. We have in total 4,890 books Both both closed and opens I mean in the whole BTS history But right now we have 1800 Opens books, which I think is like the the package with more books in the BTS Obviously is not, you know, like the same kind of books, but anyway So we started at least Some of the people I asked and me started to do some closings of needed books and We started to review the ITPs and the RFP RFPs So if if one of these have one year old We just close it one year old of inactivity. I mean and how do how do we do this by parsing all the inbox of the Book and read for the last Line starting with date colon, which is some kind of ugly, but it works most of the times So in total we have closed at 768 ITPs until now we do it we do this every week every week And we also review the RFPs and we have closed at 848 until today And we also work in the ITAs which are not closed but retitled into orphans and Well until now we have only one retitle Which is nice because This shows that the ITAs are quite Attended by the people I mean they are not They are not left alone So well the ITAs Are retitled after 250 days of of inactivity. We also are doing a page with ground title WNPPs Which means in in in our goal to standardize some process We are trying to every every WNPP book to have it a title Like ATP colon space then the the name of the package space dash dash Sorry main minus minus space and the description of the package even if for for all the all the books. I mean Request for helps or fans all of them And we I have at least one person working retitle Retitle these which who is Marcelo Tisnado? Who is? She likes to to to check the page and retitle all the books all the books reported. Yeah Well and some other interesting things report book Doesn't handle the correct titles in the In the orphanage books when when you report a book in report book to our final thing It only displays The title as O colon space and the name of the package and it doesn't show the description well You can use also WNPP alert, which is a very nice tool developed by Arthur corn and Well more people are working in the WNPP thing matta bella is Well somewhere Working on pinging on ITP's authors. He does this work Quite often and well marking me Martin Michael Meyer doing weekly reports and well, I think we could Help a bit by hacking the BTS to LDAP gateway, which is a very nice tool for most of the things in the BTS. Thank you Hi, I'm Raphael Herzog and I will speak about Collaborative maintenance it's something that I'm trying to push forward for a few years and I will start by explaining what we're where we are today and where we could go and Well right now what is collaborative maintenance for me? It's several persons working on one or more packages. It's rather Vague, I don't mean Debian developers. I say person people don't care who Usually they use a version control system or something similar to Work together on the package at least and of course they need a common communication channel I don't specify which one yet In the standard model right now, it's an alias project a Subversion repository and a mailing list It works very well for a Team like packaging. No, they have many mentors many different packages and they are all highly visible package so The the person on the team want to have good package and care a lot about all the packages So this works well and we have everything needed to make it work. So that's fine Now we have a second model of Collaborative maintenance, which I call low maintenance model. It's something for For example that we do which package a pearl or Python models I mean we have lots of and lots of packages which are one Python model or run Perl model which are doing many different things. I mean in the repository will find Models for desktop models for servers models for scripting whatever so There's no common feeling of a shared goal except improving pearl in general so that usually means that We don't care about all the models that are in the repository and we don't usually look at them Carefully and sometimes it happens that some of them get forgotten and Got a bit more beat right a bit over time so what we needed a kind of Overview this is partly achieved with the DDPO web pages Since the team is in the maintenance field or uploaders field you can have a good overview of all the packages and check if bugs are Coming and coming and when they are not fixed you can also check if there's a new app in version that you've forgotten and stuff like that This works quite well as well today So my idea is oh In this low maintenance model as well. It's always people who are They've been maintainers they've been developers But my third idea was a kind of collaborative maintenance with people outside of Debian It's kind of the similar idea with the deep and maintenance that we have we want to have help of external contributors because we have lots of package where We don't have Enough DD who are experts in that package and which could maintain it over a long time So collaborative maintenance could also be Maintaining between a sponsor which is a deep-in developer and an expert in a package which is external to it Of course to make this work. We need quite a bit of infrastructure and this is All which is about this is the goal of the collab dash main alias project that I created some of you have already seen that in the Recent announced that I sent to deep in their allowance. We have possibilities to do that now because we have We can have many different project and many totally unrelated project in the same Repository as long as we have a single communication channel per package which could be the pts in our case and And well on top of that we need to add a lot of QAC tools to be able to check the work of our it's not contributed and This is where we need a kind of web interface where each external maintainer could just request to upload when needed and The web interface would also show quite a lot of Quality information like beat logs of the latest Snapshot of the source code and stuff like that and Yeah, I'm almost done. So if you're interested to work on that, please Mail me and join call up dash main tonal yacht. Thank you I'm Matt Taggart one of the things I do for the devian project is that I am a local administrator for some Devian org machines and I'm going to talk about how to get devian admin to help you Okay, so first I should describe Who I'm talking about when I talk about devian admin because it's actually Kind of confusing there is the devian system administration team and this consists of Elmo and Nuro and Joey and Phil and their Email is devian dash admin at devian org now There was also a devian dash admin at list dot devian org address and that consists of the devian sys admin team Plus all the local administrators for those machines the machines are hosted all around the world And they need to have local administrators in case something goes wrong So there are four people on in the dsa team, but there are 11 people on the devian admin list and When sending requests related to machines or to request those sort of things It's it's better to use the list address because there are more people there that will be able to fill your request Okay, so when making requests The best way to get a response is to make it very easy to fulfill your request So this means researching the problem ahead of time and providing specific needed information Also ask clear questions if you send something that's very vague and and isn't a direct question or pointing out a direct problem It's hard for the devian admin team to figure out what you're talking about The devian admin team like Everybody else in devian is busy if if the request is clear And easy to fulfill it will often be done right away if it's vague or additional information is needed and That would require sending email that might get put off till later You want to avoid The need for back-and-forth emails if you don't provide all the information that's going to require the devian admin team to send email back to requesting more information and and These turnaround cycles add a lot of time The other thing too is also avoid adding unneeded information or attitude I've seen requests that say well you're you're probably not going to do this But I need you to do something and that kind of attitude is one of the best ways to get devian admin to not help you Okay, so the devian admin team is able to deal with devian org Machine system administration issues, you know running out of disk space or or processes run amok Also able to deal with a charoot install requests, you know, you need something installed on developer charoot Or in general machine usage questions. So say you want to run a cron job that Does some qa related activity or that kind of thing you should contact devian admin about What if it's appropriate to do that sort of thing and what machine to do it on And also maybe to look at the code just to make sure it's doing things efficiently Okay, there are a lot of things that people send requests to devian admin about That devian admin can't help with and so this is just going to slow down the process and cause devian admin to have to To reply to you and tell you that you need to contact somewhere else In particular alley off requests need to go to the alley off administrators even though it's a demi.org machine That is such a special service that they're a group of people that maintain that separately They also have a IRC channel that the administrators hang out in that you can ask questions there Anything having to do with the archive is not something devian admin can generally help with so you should contact ftp master You know likewise for the bug tracking system and lists and and web related issues devian admin doesn't do those So any requests sent to devian admin will Just have to be forwarded on and and we'll take it a while and take longer for you to get an answer Okay, so I wanted to go into a little bit more deal about to root requests Because this is probably the thing that devian admin gets asked most about So some of these things are going to sound like common sense, but you'd be amazed at how often people Don't think to do this So the first thing you need to do when making a true request is check the machine first and make sure that the things That you need aren't already there We get a lot of true requests and and in general the machines Already have a lot of Development packages installed so check first and then if there's anything missing that you need Just ask for the missing packages You need to specify which machine and which truth you're talking about it's kind of funny when requests come in and To install packages and they don't have this because you know devian admin can't read your mind and doesn't know Which machine you're talking about The other thing that makes things easier is When you send the list of packages that you want Send them as a space separated list and so that means you can't just cut and paste The depends from the package because it will often have commas or versioned dependency information So take that out make it easy to cut and paste and the request will be easier to fulfill Additional information is optional, but it may help if there are issues if devian admin is trying to install Packages for you and something's not installable if you if you provide additional information that might help. Okay. Thank you So hi again, I'm Joey Hess and I'm gonna be talking about learning from gen 2 Which isn't what I'd originally plan to be talking about here, but there's a guy here who did something which I think is very brave Hi, yeah, it's Yuri in the back there. He came to debcoff wearing an at gen 2.org email address and we had some yeah and I was privileged to have some very interesting talk and hopefully more later with him and One of the things that we talked about which I thought was interesting is the different ways that debian and gen 2 handle Demons and config files. So as you know in debian when you upgrade a package You have to resolve any conflict between the new version of its config file and the old version Before the demon gets started because it's gonna be started as part of the upgrade In gen 2 when you upgrade a package, you just get new files pulling your disk No demon has restarted your old config files are left where they are and the new one is put in a place where it can be found and Yeah, gen 2 has this tool called dispatched off dash conf which handles Finding the config files that are new and was and helping you resolve the differences and it can do things like Ignore white space issues ignore CVS IDs and that kind of thing which make it helpful if you're merging config files and Compared to this. I think that in some ways debian support is fairly primitive because if we have white space issues or CVS IDs or that kind of thing in config files We have to manually deal with that and we actually tend to remove that kind of thing and try not to ship config files That contain its significant differences and we also you know We have etsy default where we put config files for init scripts because we don't want to have to merge init scripts on upgrade and that kind of thing Some of you including me may keep things like your Zshrcs or your vim config files in your home directory instead of an etsy because it's just too much bother to have to deal with merging them all the Time so I was thinking about how can we learn from gen 2 here? So I think one thing we could do is we could run d package with this force confold script switch if you if you wanted to and not install the new config files and Then use something like dispatch off comp to merge to resolve them later. It could be an option I don't think it's something that debian wants to do by default But I think it'd be a great option for certain admins in certain situations and of course We also have invoke RC that invoke RC dot D now which allows you to Configure a system not to start a demon on upgrade or not to start a new install etc And it does this by this policy layer thing which has never actually been Included in Debbie and it's something that we expect system ins to write if they really want to not start a demon And so I'm thinking well, maybe we can just package all this up together We can put invoke RC dot D I'm sorry We can put dispatch off comp in it's in a package along with some policy scripts that do things like Don't start a demon upgrade or if you're if you're installing a package with a new demon in it Just don't start the demon then start it on upgrade. It depends on what you're trying to do with your system How you might want this to work? So I think we could have lots of different interesting options there We could also do things like collect a list of the demons that haven't started so you can go back After the install and manually resolve things which I think would be great on certain types of servers And I think there's all kinds of ideas here that we could elaborate on but I just you know This is just an idea that I had it sort of an ITP here at debcoff. I might I'll probably end up trying to work on this a little bit So the other thing that I wanted to mention I just think that I really do think that it's really brave that you came here I think it's great, and I hope that maybe in the future we can have More developers from other distributions tend debcoff or maybe go the other way if somebody's feeling brave and wants to go to a Gen 2 conference or wants to go to a red hat conference or something like that. I think that'd be great I think you could learn a whole lot doing that. So that's about it So thanks for your attention and hopefully somebody will do that Thank you Now I'm going to give a brief talk about data mining on Debian and Paxmata data Since five minutes is way too much for a talk. I'm going to do this in two minutes Well one of the problems when you want to have an overview for people to look at whether A list of all their packages major example is developer dot PHP also known as the DDPO pages You will discover that a lot of maintainers have they are using multiple email addresses or have multiple GPG keys or Alternatively have also multiple ways to write their name. So it's very hard to actually find out which how to Put up a page that is really About all the packages of a given maintainer In order to to work on this there is a small script called carnivore in the QA repository That is able to look through all the key ring files that is in Debian and the packages files and try smartly to actually Correlate the different email addresses GPG keys etc with each other so that developer dot p and p could for example use this This is going this is currently already in use in one of the QA systems the MIA system And it's not currently working yet for DDPO But I hope this will be able to be done Relatively soon Yeah, it's currently not entirely accurate yet because it's also trying to match on the real name and one famous example within Debian is we have to Brian Nelson's So it's always a trade off how to actually do this Now I want to continue about talking about tracking MIA developers where this is used for MIA developers Is always a bit a delicate subject Because there can be all kinds of different reasons that a given developer is not Attending to his packages very well In order to track this we have a number of different developers Very well in order to track this we have on Merkel a set of inbox files for each maintainer for which we have an indication that it might be Missing or simply not enough time for these packages Together with those inbox files. We have a file with summary tags By which we can have a sign the sort of severity Severity to maintainer Maybe someone is simply a little bit busy and has way too many packages and it's good pay off for this person to often a few of his packages But other maintainers have not been seen for two years and all the packages are in multiple enemies etc Every time The MIA team Wants to actually Work on this there's a script to be run that is called MIA dash to do Which will go through the database looks up which For each given Severeity what maintainers could need a plot meal a meal asking. Hey, what's up? Are you still there? How are you doing? Etc And when such a meal is sent and there's reply coming we can adjust the severity Accordingly and ultimately of course there is the possibility to often the packages Next to MIA dash to do there's also MIA dash query which is Superceeding the old MIA dash history script Which is able to look up for a given maintainer in case of there is some question about a maintainer What's the status of that? Together with these tools I Hope that the MIA team will be able to skill a bit more it's now much more Possible for multiple teams to work on this which I think is very important. You need to ensure that as late as Things as possible. I don't want one person. That's exactly the thing the MIA team is trying to address at some time So it's kind of weird that the MIA team itself was For quite a long time a single person effort And well through this work distribution and coordination We're getting more and more on top of actually finding out and also proactively mailing maintainers who have maybe Problems maintaining their packages Due to lack of time and not only react at the moment so much really totally Missing at all already If you're interested or have hints etc. Please email MIA at qa.com Thank you So wow, I think we've managed to Do this a little bit quicker than we expected we have three or four minutes left And so if you're in still has any breath left in and I thought we might pull him up here Oh really? Okay, well, I think we might pull him up here for how for his one last talk If that's okay with you Well within Debian Debian is a very worldwide distributed community and because of that we have very very many different names different cultures and According to this is also Pronunciation problems for names for example my own name is really really in causing a lot of problems. I will say it Once for myself I'm called your own van wolf a la and I would actually that there's some different Cultures, I mean Indian again Dutch and Japanese are yeah very have very different sounds And I would actually like to ask you all to try to practice So I Suggest that on the counter free we'll all try to pronounce my own name one to your own van wolf a la Okay, we can we can do better. We can do better. I think let's try again one two your own van Yeah, close close you're getting better at let's try it one more time one two your own van Your own van wolf a thank you, and now I would like to ask my knowledge. Is he in the room? Well, let's temporarily skip to where is You need to see Could you maybe pronounce your own name for us? Oh wait my not just first I would like to ask your favor. Could you maybe pronounce your name for the audience so that we all can practice a bit better? All right, I pronounce my name as Manoj Shrivastava the final a was added by my grandfather for reasons nobody knows And it's a little bit too late to get it off because then you have to talk to the Indian bureaucracy and say that You know all the property we own will have to be changed over So I'm kind of stuck with my spelling, but it is Manoj Shrivastava Well, I will try a suggest so actually practice this with the whole group so On three again one two Manoids Okay, thank you very much now from Again a different part of the world's Japan I would like to ask you. I'm not going to try To pronounce your name Okay, there's actually a pause between June and Ichi so this is pronounced as June Ichi Wake up one two June Ichi Wake up Thank you very much Actually, let me Give me the real reason why I was actually proposing this talk Actually, I cannot really care that much how you pronounce it as long as I understand what you mean But I just really wanted to have a whole crowd cheering my name and thank you very much for cooperating with that and thanks Thanks to Joey has for organizing this and introducing the lightning sword to that comp I think it's a great thing to have and I hope this will have a continuation next year. Thank you See, I completely agree. I completely agree that we should have it next year And maybe it should be a little bit longer if y'all can stand that I don't know if we have any time for questions But if we do here we are so Or if anybody remembers any of the talks to ask a question about them Hi, I have a question for Matt and I wanted to know all them Support requests requests that they've been at means get are archived or publicly somewhere or for security or Any other reason they're kept private that's all the list address is archived, but it's a private archive. I believe And I don't think the DSA addresses archived. Is there any good reason why it's not public or could we change that? Some of the requests I think are sensitive, but it might be the possibility that it could be opened up later on or something like that Okay, thank you The the question is for Andreas Where did you find the market share of figures if you know I think Andreas has left the building so I withdraw the question Hello Maybe I can answer the question from Thaddeus I spoke to Andreas about it and he said he has spoken if some embedded developers who told him that While searching for sponsoring money Yeah, he said that There was a very similar Paul on Linux devices which is Come to the same result as he got from the developer. We have time for one more question Okay, no more questions. Well, thank you all for attending