 It's OK. I would like to talk today about the application of the ultimate Debian database, as you have seen in the talk before me, in the Debian poor-blends effort. Debian poor-blends tries to harvest several information about packages for specific work fields, and I learned that UDD is really a cool tool to realize this. At first, I want to give a short introduction about Debian poor-blends, what features we are using, which web tools we are using. Then I give a very short introduction into UDD because you have seen a long one, and I just want to focus on the stuff I'm using. And finally, I want to talk a little bit about the future, what we want to implement for Debian poor-blends, and what we have to do. So for the short introduction of Debian poor-blends, oops, I think. So formally, this effort was called Custom Debian Distribution. And this name was so frequently misunderstood that we decided to rename this effort. The problems were that the main understanding was CDD somehow sounded if it was something, would be something else in Debian. But we always told people explicitly, it's inside Debian because we are not strong enough to do something else in Debian. And so we had a big focus to make sure that we are inside Debian, and the formal name just did not work. And so we just dropped the misleading names and found the name, which is not optimal, but it forces you to read the docs what it actually is. And so if you Google for Debian poor-blends or I've given some links, then you can read more about it. And I will explain it in a little bit more detail. The main point is that Debian poor-blends, or in short also blends, if I proceed in the talk, I will talk about blends, is a subset of Debian that is configured to support a particular target group out of the box. So please remind the basic goals. I always propagate it for custom Debian distributions formally and now for blends. In Debian we have more than 22,000 packages. And it's a whole lot. And no user can install all on this machine. And there's no sense. And so the problem is how to pick the subsets you really want on your computer. The main focus of blends is on some specialized users. So think of teachers in schools or income from the field of medicine. Or if you are a scientific researcher, for instance, also in chemistry, you have also some focus of very specific applications. And you always are seeking for an easy way to install this application without doing much research. Imagine you would have to read all this 22,000 package description. You will at best understand 10% of this. I do not understand everything myself. So it would be nightmare if you want to do it. And so we try to make a focus on this specific application while Debian stays general. And at the universal operating system we want to provide support for specialists. So I mentioned it once more. It is no derivative from Debian. It is just the basic idea is to make not a separate distribution, but make Debian fit to provide support for special purpose. For all these purposes, where people take the work and do the effort to work on such a custom distribution. There could be much more than currently existing. But I hope that the idea to support these special applications would a little bit more penetrate. Moreover, I want to stretch a little bit the connection we as Debian developer are building between upstream developers and users. Especially if you have some specific applications which are not used by a big user group. So we have packages with low popcorn values. The upstream needs really support to get his software published. And so we try as a Debian developer tie a network between upstream developers and users. Because the upstream developers are so specialist. We are who are our target group as well. Reginald is an expert in this field. He needs help to package their software. I have very frequently observed that they provide tar bars with not so optimal build system. Don't use auto build, auto make, all this stuff. And so they are really, really happy if they get the support of skilled developers who know how to install programs properly and make a solid installation system or build system. And so they are really happy if we as Debian developers look at their code. So upstream anticipates enhancement of their build system and also a security audit. And finally, the upstream developers also support Debian because they learn if we support them that they could also bring their software to more people. And so they are really happy and support us as a maintainers. And in my opinion, it would be a nice thing if we get more upstream developers to become even Debian developers. So how do I want to attract people for the Debian problems effort? On one hand, I would like to get some more Debian developers involved in this effort. And my idea is if we provide some interesting techniques, which I will show you later, then people are convinced. Debian developers are technique freaks and want to have catchy things. And so I hope the connection to UDD is a nice way to go. I learned that several Debian developers are interested to categorize their packages. There are things like depth tags. And we are using it in a UDD effort with so-called task files, which enable an easy classification in which category your package fits. And you can define some dependencies to group package to certain work tasks. And that's why it's called task files. We are not competing with depth tags. Actually, we rather try to merge the depth tags and task files stuff. I have not made up my mind how to do it really, but we want to work together. So we try to provide some key documentation feature in the form of the task page I will show you later. And we also have some so-called box pages, which makes a good QA measure. Because if a developer looks at the box pages where all the bugs, according to a certain work field related packages, are listed, then you can easily pick those bugs you are really interested in, that these packages are OK, or you work with these packages, and so you have a good overview. I also plan to include the DEHS system, which means it is a Debian external health system where the watch files seek to find out if the Debian package is the current version, like upstream, or if we are lagging behind. And so these pages will follow soon after Debconf and I hope this will be also a very useful tool. On the other hand, we want to attract users. That's why I have a strong focus to internationalize the web pages to display the relevant packages. This is basically a thing if people ask me, what are you doing? I'm running this Debian Meet project, and they ask me, what actually is Debian Meet? Then I can lead them to this task page and then see we have some certain tasks. It is a practice management. It is digital imaging, or this is biology. And they can see all this stuff is inside Debian and you can view them with one view in their language as long as this is translated, what we are doing. And this is an important point, because if you are talking about specialists, for instance, specialists here in Spain, they are not necessarily able to speak English fluently enough to understand all these descriptions. And so these task pages really help to make people understand what actually is inside Debian. So we try to provide a complete working environment for these people. We didn't succeed in every field. We succeeded, for instance, in Debian Edu efforts quite good. This is a system which is implemented also in some variation here in extra Madura in the schools. But other plans are lagging behind Debian Edu for certain reasons. We can come back later if you are interested. And finally, we want to raise the interest of users to have ready to install software. Quite frequently, you have some software lists in the internet. So in principle, we also make some, we provide some lists of software ABC. And there are many, many lists I know for biology also. But none of these lists provides ready to install software. And this is a good thing in Debian, because you can fire up, for instance, synaptic and just install the software and test it, which makes a huge effort if you have just a linked list to home pages. So in principle, a specified user looks at Debian like this and has no idea what packages are inside. And we, as a Debian Blends effort, try to make this focus specific application. In my opinion, this graph says actually what the Blends is doing. Focusing the interest of the user to specific work fields and there should be more of these lenses to make sure that more people or more specific fields will be attracted by Debian. So what actual features we have in the Blends effort? Basically, we define a set of dependency relations. So if you have certain tasks, say medical imaging, and we have about 20 packages in Debian which are doing or which are serving for this task, then we say depends and add a list of these packages. This, in the tool set, the dependencies are verified in case they are not available. The package just will be added as a suggests. If I install the meta package, which results out of this dependency, you get, for instance, the meta package made medical imaging, then you get four packages which are lacking only as suggests because we have not these packages in Debian Main. It might be in 1.3 or it might be in any other mirror which is not specified. But in this way, we make sure that the list of dependencies will be really certified. This way, we create from this task file which specifies the dependency control file to build valid meta packages. And also, we build a task cell input file which can be used with a task cell tool. Then we have some web tools which provide information about these packages of interest which are in this actual meta package. And the task files are right out the SVN of the blend. So the web tool is more up to date than the meta package because the meta package will be updated only from time to time if there is some request or some need for it. So it shows the dependency relations of packages inside Debian. And it also shows some additional information because if there is an interesting package to have in Debian, then we can add this information to the task file. And for instance, the NPP bug to get some kind of a to-do list and see what we are working on. I will demonstrate shortly. So we try on this web page to gather all the information about the packages which are defined as dependency in the task file. The intention of the task pages is to be a key entry point for the user and to give a very quick overview what's actually done in the task which is dealt in the blend. We have also a first slide connection to Deptex in the task pages. And when I built it, these task pages I just learned that this is a really good QA tool to make sure that the descriptions are OK and the home page text is really good set or really correctly set. And so I will try to demonstrate a little bit of these pages. Here you see the result of such a task page. I mentioned the medical imaging page. And the colors are not very good. This color is basically green. It is not very different on this projector from yellow. You will see below. What can you see here? You see that medical imaging is depending from the package SQL app, which is a medical image viewer. You have the home page. You know who maintains the package. You know how many users are using this. It is about 23 users. It is derived from the popcorn data. You have an overview which versions are in which release in Debian. You can also see the Deptex, which are tagged for the package. And here you can even see a screenshot of this package. This is more or less the optimal situation because we have not so many screenshots for all the application inside Debian. So if you feel you would like to support not only these task pages but everything else, you can go and take some screenshots and make this better and Debian also better. If you have a certain interest or certain world field, just go to the according task page. You can ask me if you don't find it. And here is a link how to upload a screenshot. Here is directly a link. So if the screenshot is missing, you can go and try to make a good screenshot and upload it to make this better. And as well, you can also provide some Deptex here. In this case of the next program, which is called carrot, these Deptex are missing. So then we have some packages which are in the new queue. So that means the package is ready from developer and you are waiting now what's here. And so this is a yellow section. I told you this is green here and here we go to yellow. We expect Slyther to be in a short time to be inside Debian and can be used. And we also have a section where some external people build Debian packages, where some development has been done. This information has to be provided in the task files explicitly because we can't draw it from any information source inside Debian. And finally, we have this red section. This should be red here. It's supposed to be red. Here we just provide some information about what we want to do. There is a bug file, this VNPP bug, where we say, well, we are working on this and you can provide some information to inform the users that there's some work going on and we try to, we can ask for help or he can try to work on the packaging. And so we try to involve users in our effort to make it better. Some other examples here for, this is from Debian Edu chemistry. Here we have also the screenshot. And well, okay, I just noticed that it's not really translated. I tried to change the language and then you can see, well, it makes no sense to change the language here. I just will scroll down and you can explicitly ask for, for instance, Espanol. And you see here the Spanish translation in case it is provided. In this case, in the next case, it is not provided. And if I make the screen a little bit slower, this is not optimized for this size. You can, well, it will not be shown here, no idea why. Oh, here. Here you can say translate description. There is a link. So if you see, there is a description missing for the package and you are native speaker, for instance, of Spanish, then you can click on this link and you go directly to the DDTP server and you can provide a translation and it will show up later. So your fellow coworkers who are working in the same field, they have a profit and understand the description. Or if you realize the description is not really correct, you would like to correct it. There's also a link you can fix the translated description. So this hopefully makes clear we want to involve the users with this task page and we try to involve the users who are working in this specific field. These are the main features of the task pages. As I wanted to show here in the more dry way of explaining things, but I hope the demonstration makes things more clear. So the next thing is more development related. I try to find some measure to how we can make sure that the packages we are providing to the users are on a good quality. And so I try to find a way to display how the bugs are of all the dependent packages of a meta package. And currently we have the problem that the bug statistic looks from the first few quite bad because if you have a meta package which depends from a lot of applications, then they gather some bugs and mostly they are colored terribly red. And but I didn't do the normalization to the number of meta packages because I think if there's a bug it should be fixed. And so I do not want to get bugs lost because there are many dependencies. I'm not really sure if this is a good idea. So I try to find some rating numbers for different severities ranging from 10 for these critical bugs to zero for which list bugs. I do not think that we don't should fix which list bugs but normally if a package has any bugs you go to the page and see the which list bugs and then you can fix them. So for instance, if you have one serious bug in any dependent package of a meta package, you get one bug which is serious, which gets a factor 10. And because it's a dependent package, we multiply with dry and so you get the right of 30 for this bug. Then you have for instance, two important bugs in a dependent package two important bugs makes five and dependent package multiplied by three because the dependent packages are more important for us than the only suggested packages. So suggested packages get only the one as a factor. So one important bug with a five, only factor one with this. Then we have for instance, one normal bug for in a dependent package with three and we have here nine. And if there's a minor bug, it gets a value of one, one three. And if you sum this up, you get the so-called weighted sum of 77. So this number is not the number of bugs but the rate I try to evaluate for a meta package. How it looks in reality. If you go to the bugs page, for instance, of deviant science, you see here is a red colored, let's look in astronomy for instance. The deviant science astronomy package meta package depends from a certain amount of applications. And you see you have here one red colors bug which is released critical and that's why red. And you have certain important bugs. They are yellow and the green bugs are normal. And so you see you have some, a certain number of bugs. And this sums up to 91 total bugs, 74 are open and 17 are fixed. And here you have the number of critical grave series bugs. And all these numbers result in a rate of 468. I just discussed it in the deviant science book. We have to make sure that this rate is a little bit better. What you currently see, you have a quite quick overview of which package is buggy and where are the problems. So according to this rate, I tried to make some kind of evaluation. So the idea was a meta package cannot be, if the start is good, if there is at least one series or higher bug in the dependent package, that means if there's one series bug, independent gets a 30 and so it can't be good because good means lower than 30. Or the package cannot be very good if there is one RC bug in also in a suggested package. So these are quite strong rules and we have to adapt it a little bit. But I hope you get the idea. I tried to find a way to attract users to problematic meta package, or better the meta package is not problematic but the dependencies of the meta package are problematic and I tried to catch the users or the developers to fix these bugs. So now we come to UDD. As a short introduction, we have seen in the last talk, these are the tables we are having in UDD. It is a PostgreSQL database which tries to provide information. You have seen more or less the same slide from Leucar. I'm very, very happy with this DEHS because this really helps us to make another new page which is very important for us to make sure we provide up-to-date packages. It will be, I intend to make it quite similar to the Bux page and I hope to provide this too soon. The information is updated via Chrome jobs from different public sources and for the sake of Debian problems, I just added the translations from the Debian description translation project. This is what I showed you with the internationalization when I switched to the Spanish page. This is a very interesting effort and I can't repeat it enough. Try to provide package translation to enable your fellow coworkers in your language to learn about Debian packages. I also added the screenshots data which are missing on this slide and I also added the news data because I use it as well. And finally, we have some Ubuntu information in the UDD package which is currently not that interesting except for the bugs in Ubuntu Launchpad. I intend to add these also to the bugs overview because I think if we know that there is a bug according to a certain software, we should not really hide this information. I have no real idea how to display it but I think it's a valuable information we should not hide on this page. The features of UDD are easy to write gatherers from gatherers for new information sources. Well, I have to admit I was quite new to UDD and it was not really hard. I used some examples from other galleries and then I was quite easy to able to write new ones. You need a little bit of Python skills and you have some copy and paste from the other and you are basically done. So I added this DDDP in UQ and screenshots gatherers which were actually in UDD because I wanted to build these pages. And I like also the possibility to compare Debian version numbers. You know, they are a little bit hard. It's not a simple string comparison because you can have certain additional characters inside which do not fit to a string comparison and this is very, very helpful to get the right version out of the database. And UDD just contain all relevant information about packages we are needing for Blends and so it's the ideal tool. And since I'm using UDD about four or five months, the speed, how can I add new features to this Blends stuff increase drastically? It is amazing. So what are the advantages of using UDD for Blends? Formally, I built these task pages by just parsing packages GTAT files and for the sake of performance and well, I could perfectly parse all the packages GTAT files for all Archie detectors and for all releases but it make no sense for this purpose. And so the task pages were not always really correct, basically correct, but not always. And now I get it very easy to meet with just one select statement and they are correct. I had also to do a large effort to download all the DDP translations from the original source. And now after I injected them in UDD, I get them very quickly with one select statement and this is really easy and it's just fun to use UDD. And also when I build it, it's a box pages. The BTS has some sort of interface, which is okay, it works, but on my machine, it just took so much time and with the select on UDD, it's just faster and then you have a consistent interface. You just gather all the information from UDD and this is really cool. So we have all information in one place. This is a very important thing because you have easy access to the information you need and as I said, it is very easy to add new information. You get the information about all releases which was not possible formally. You get all available versions, all architectors and even experimental was excluded formally for, yeah, because it was not so important but now you get it just for free. The DDP injecting helped a lot and the BTS information you get with this quick select. What are the new features? For UDD, I added this features for the DVM Blends effort and the task pages got the popcorn results while they're formally not included because it would be very hard to gather information from a new source and also Deptex. Deptex also came for no effort at all. We have also the VTS usage because it's interesting. If you see there is a bug in a package and you know where the package source is in BTS, you have easy access and just informed about the things and this is also very easy to get and we got the information about the new queue because some packages are just hanging around in new queue for a while and we want to inform our users the package is well nearly there, hopefully nearly there and screenshotsdavion.net is also really cool effort. If you find some time in DeptConf, I'm considering sending announcements to DeptConf announce, please everybody fire up one application of your choice and provide a screenshot every day and if all the 250 people would do every day, I think we could make a really good success in screenshotting davion. I don't know if any other distribution has this feature and it's really cool because if you connected to Synaptic and a new user want to install a program and just see the screenshot, I think it would be amazing. So what are the planned features for davion plans? So I told you I want to make more QA overviews and DHS feature is there in UDD and so no effort anymore. I also want to give a lindian overview to make sure that packages have a really good quality we are using in the blend. I also wanted to add Ubuntu bugs to make sure that no information is hidden. I have no idea how we can make sure that there are no duplicates between davion and ubuntu. Perhaps don't know an answer also. Furthermore, I want to base a blend step which is used to build a meta package which you finally can install. Use UDD, we have the problem that currently we built meta package with architecture all because the current meta package build system has the same problem as I had in the task pages. We just look into one architecture packages file to find out which dependencies are resolved inside davion. But this is not correct because there might be some dependencies which are not available for all architecture. So we shouldn't build architecture all but architecture any meta package and this can be solved easily if I would port the blend step towards UDD. And I will do so in perhaps I hope to do it in fall. Then I was thinking about including the information which is stored in the task file also into UDD. Then currently the task file is read from the SVN. Which works somehow but if it would be also injected from SVN perhaps with upload script that is automatically synced to UDD or whatever I will use then I could stick completely inside the UDD universe which might make some sense. I haven't made up my mind completely but this might be a thing I might do. Yeah, what's to do? So as I said, we have to do further enhancement. I will rewrite the blend step stuff to use UDD. And I would like to make even more projects to use this blend stuff. The DBChem project which is basically doing framework for chemist is a very good candidate to be a full pure blend. I'm in contact with Michael Bank and I hope we finish it here at DevCon. It's the same with Davian Giss and missing on this frame is the Brazilian desktop project. We want also to apply all this framework. Some start is done and I think this will take not so much time to implement for the Brazilian desktop. These techniques I explained and I will work together with Djago Tune and perhaps it will also happen at DevCon. Yeah, and then I also try to bring back some external projects. This is as I explained in the beginning the custom Davian distribution were also considered as external efforts and so some people just took Davian and turned it a little bit into some more, for instance for audios recording also. And so they build a new distribution from Davian which is perfectly okay from the license but we think it's much more effort if you try to make some clones or forks from Davian. So I want to try to convince these people to look at the nice tools we have or I think they are nice and helpful and if they are interesting for them they might be interested to merge back to Davian so that we get a Davian audio project or whatever. I was in contact with some people and I hope to revitalize this to get some more blends inside Davian and finally more strengthen Davian on other fields. So that's all, thanks for your attention. My talk is online, it is not yet linked but I will do it this evening so you can download it from there and you can tell any questions. There's a mailing list where you can join if you are interested and I would be happy if you are interested. Thank you. Any questions? Hey. In the VR desktop that's Brazilian blend we receive a lot of feedback from users that by mailing list that wants to remove some packages and adding other packages and sometimes they started to find in the list for choosing such audio player, et cetera. And I think I'm working in a specific popcorn server for VR desktop because for us it's important to have a real feedback about which package users from VR desktop are removing and are installing. And I think the popcorn from Davian you cannot get this information so can you imagine some way to integrate like from it met a package that package wants to install it, something like, do you think is it important? Well, I think I have two answers. At first I think we could, Luka you might correct me, we could probably include also your popcorn data into UDD to make it at least visible. As well as Ubuntu packages import you can be a desktop popcorn tables and then it's at least there. This is the second question. I have no idea whether you can have a connection between a meta package and the package which is installed on behalf of this meta package because we have no real trace. You can install the dependent package manually before the meta package, then you can install the meta package which has no influence on this package because it's there and you can even remove the meta package and the package remains because we turn all the depends into recommends. The rationale behind this is that Davian Edu people learned that if you have hard dependencies from a meta package you are not flexible enough anymore and so we decided to use only recommends which is fine because up get installed somewhere default so you have to force your installer to not to install recommends. I'm thinking about making the task file more explicit that we use real recommends in a task file and if we mean it depends then should be depends safe that's not implemented but I see no means to have a relation to popcorn. Yeah, the thing is we need to know which packages BR desktop users are removing and are installing, that's important for us and I'm trying to imagine some kind of integration with maybe alternative popcorn for planes that, I don't know. Yeah, you mean that we in general implement popcorn BR desktop, popcorn made, popcorn Edu or what? Yeah, that's I'm working now but I don't know if it's a good solution because actually we try to release Davian testing release, BR desktop testing stable release and we need to select new packages and that's good to know which one are most used to release to the next release. Yeah, the problem is perhaps you have a hard time to know who is actually a Blends user. Is the Blends user a user who installed one specific meta package or is it not or is a Blends user one who installed made physics and science physics? They both exist, they have a little different dependencies. So is this user belonging to the Davian made or Davian science? This is a little bit difficult to know how to decide who is a Blends user. It might be another different case in BR desktop because you are providing Insta media and if you have an Insta media you can set some flex somewhere or Davian Edu also provides Insta media. In principle it is planned for every Blends to have Insta media but we are not so much advanced that we have generalized tools to create this media. So if this is a definition Insta medium then we could most probably have a specific popcorn data. I was going to say just on that last point surely all you need to do is obtain from the guys who have got the data. People who have the popcorn data from people who have installed the Brazilian desktop. I mean how to ask them is a slightly different question but the information surely is in the popcorn database for who has the Brazilian desktop package installed and who has everything else installed. So it's just a question of performing the right database query I would think. No, no, I think that the difference is Brazilian desktop and Davian Edu provides Insta media, dedicated Insta media with pre-configured depth context question and so. And in my opinion this is a key point if you want to have a specific popcorn data then you have to set some popcorn flag or whatever to flag this as a specific blend user. Any other question? On a more generic note, as you showed in your slides the blends basically focus the attention of both users and developers on specific functionality. Have you considered more generic blends like a Davian desktop blend or a Davian server blend? It's just a question who does the work. That's simple, there is a Davian desktop effort which started if you read the old documentation as a CDD or blend and Davian server might be Davian Enterprise. There is a Davian Enterprise list. It's very funny, I did this list statistics. You can, perhaps I did something like this if you go to any of these blends list you get this list statistic who is active in a blend and so this is for instance an accessibility list and you can see in the mailing list the active poster over all the time was Samuel Thibault, it's a French developer who started development in 2004 and became even more active this year, it's not finished or it's not relevant and second most active developer is Mario Lange. He's also at Debcon here and I made also this graph for the Davian Enterprise list and last year there was even two spammers who made the most active posters of this list. So yeah, it's just because there is a need. There's a big need and I would really love if some people would take the effort and make Davian Enterprise blend and I see some very interesting tasks in this but actually there's nobody doing the work and so yeah, as always. If you find somebody who's interested, just go on. On the question of install media, just before the last release I had a little bit of time and tried to get a live image, a science live image produced and I think I ran out of time but in fact it looked like it was incredibly easy for the live image guys to say, hey, you've got a meta package, all we need to do is install all the packages on the meta package. So for science specifically, I think it was about two and a half gigabytes ended up on the DVD and that's something that potentially is interesting to people, it's something that I could put a little bit of effort into but I don't have time to spend an enormous amount of effort on but it's just looked so simple to do. Yeah, this is completely right. It's also mentioned in the blend stocks. I would like to make some one line or one click methods to build live DVD of all the meta package dependencies but somebody has to do it. I was also, as you, I was not able to finish this and though I didn't talk about this here, yeah, if somebody wants to do it, you're very welcome and it's definitely a nice thing. Okay, so I will leave this space for the next speaker. One more question, you can come back to me every time. Thank you for your attendance.