 So, well, this is the Deviant Science booth. I have not prepared a lot of stuff because it's a common event to get some input. I just have prepared my usual graphs. Who is the Deviant Science team? It is the people who are uploading packages which are now considered as Deviant Science. And, well, these are the people, these are just the first names. You will know them. One, two, on the room. Somebody else? Since Alves and me are listed there. No. Then we had the Piccadilly Skyco group which is more of a legacy thing, I think. It's not really existing anymore. We should probably merge also the graphs to make some real image. The thing was in 2006 or 2007, there was another group created which it's basically the same thing and nobody was aware who is doing what. And so we somehow merged this. This is about the discussion on the Deviant Science user list. There are some other people showing up somehow which is fine because some people are discussing more than providing code but this is also valuable input. This is a Deviant Science develop mailing list where we talk about actual packaging issues. There's also Yukar Nussbaum. I think he is more here because of his QA work than actually doing something and it would be good if he would reach that the QA people are not showing up on the top 10 people. It would be nice that QA is something not so important anymore. And I know Matthias Klose is the same. He's not in the room but he's frequently criticizing Deviant Science. It would be nice, criticizing is fine but he could be a little bit more nice, more friendly. So same for the Skycom mailing list. These are the bug hunters, people who are fixing bugs in Deviant Science. It would be also nice if there are some more people here. And Skycom packages also bug hunters and the commits to the Deviant Science VCS. This more or less matched to the uploads and in PKG Skycom. Well, and I would like to repeat my slide from the morning what I understand as a team. It's just waking up in the morning and realizing that somebody else had solved your problem from yesterday. And this is, I have observed this frequently in Deviant Media Team and in Science we have a lot of packages and a lot of people who are working in parallel which is a sign that Deviant Science is some kind of umbrella for a lot of scientific stuff. My vision would be that we could a little bit split these signs in topics like mathematics, physics, electronics and so on. And science is left over for some general things like graphing data, publishing and something like this. Well, here are some packages in some topics. We have packages from chemistry. We have packages from electronics and engineering, geography and so on. And I had made this graph somehow. Well, Deviant Science packages exist since 2009 and so the development over four years is not that visible like for Deviant Mates for 10 years. But what I'm missing is a little bit the increasing tendency here. We are kind of stagnating. I will not say it's good or bad. I'm just saying it's a fact that it's more or less the same number with the exception here of geography. But I think the point is rather that I was sitting down and adding the geography packages to the task and not that we have more packages. It was just a matter of maintaining the task. Well, this is... No, no, I mean... Yeah, what does it mean? Yes, the question is this direction is clear. It's the topics, the meta-package and these are the releases of the Deviant Science. This is Deviant Science 1.0. This is Deviant Science, say 0.8. 0.9 Deviant Science, 0.8 or so. The meta-package releases of Deviant Science. This one? Okay, now the point is that on the topic axis you see chemistry, electronics and something in the middle. I cannot interpolate chemistry and electronics to give a valid topic. Well, it is science. We have Deviant Science and it is the assembly of some sciences. You know? Wait a minute. Wait a minute. Ah, yeah, yeah, yeah, okay. I have just shown the tasks which have a lot of packages. Okay. Yeah, this is okay. You are lucky in this one. The one with the peak is mathematics. Okay. It's okay? Yes, yes. You are losing? What's the problem? Yeah, okay. So this is a comparison with Deviant Meet where I see this some kind of development that we get more with stress. But if I draw a cut here, it's probably also quite similar. Well, in recent Debcons we had a wiki page which has a title Problems to Work on and I would like to continue with this. We can also work in gobby, which can be done like this. Install gobby in phenote, gobby-cgobby.debian.org and you will find the document which I have also opened here. And here's also the wiki page with the problems we should discuss here. I will open this also on the browser. I should have prepared this better. She's a wine party, okay. So it's always a burning topic. We want to create BipTec files and historically there were some people who are providing directly BipTec files. We had some stuff in Debian Copyright. We had some Debian slash Bip files and we have the Debian upstream file. The Debian upstream file is what currently is implemented and I don't know how much it is used. The result is what we can do. These Debian upstream files contain scientific publication information and I'm importing this into UDD and no, it's badly prepared, sorry. And from UDD I'm generating a PDF file which shows all the publications information we have in Debian packages. So I announced this on the mailing list one year ago or so. And is anybody using this? Can you get the mic? The PDF is not a very nice format for text, in my opinion. Well, it starts to display what we have. This is just to check the result. I'm importing plain text from these upstream files. Put them in UDD. That's what I want to do. And just to see if it works, if all the literature can be converted to a BipTec file which can be processed by tech. This is how to generate, just to verify that it works. The PDF does some test case. It's potentially useful to have an HTML export as well. If you know a way from latex to HTML, I guess tech for HTML might work, but that's always a minefield to get into. And you want it here for the page? Pandak, Pandak, Pandak, Pandak. Jonas volunteers. Ah, great. So you don't need to speak if you volunteer? I got the mic. Do you want to use it? Oh, it works. Pandak, that was the only word I wanted to say. Pandak is the tool that can convert and include the bibliographic. Yes, I am a volunteer. We have a BipTec file and you can do something with it. Thank you. The BipTec file is also in the same location. I can re-send the mail about the location and the UDD query on the mailing list. Are you reading the Debian Science mailing list? Why not? Yes. I send it to you. Future tense, yes. I will read the mailing list. Okay, that's great. But finally, I think the main use for the publications is rather the task page. We have, I don't know if, maybe on the Debian Chem, you can really see it as well, blend.debian.org, Debian Chem. They are making also use of this. Yes, they are using it. The main use of the publication is currently on the task pages where it is displayed here to make sure that upstream developers of the software get some extra reward. And we have also this please register thing. The main thing about putting these citations somewhere is to ensure that the upstream authors get some extra Google for their citation and see that Debian is friendly to them. This is the main thing. I have no other application for this. I don't know if you see some other applications. That means, in other words, do you agree that we just stick to this upstream file and remove this to-do topic from the Wiki? Who do you think it's done now? We are happy with this. David, is this okay? Well, if there are no opinions, then it's okay. I mean, BipTec files are helpful, I guess. Is it hard to just get some parser that creates a BipTec code block? I mean, that would probably be the easiest. Then we can have one file. This is what I said. Each package has a Debian upstream file. This Debian upstream file is imported into UDD. And there exists a query that generates one BipTec file, which is not installed, but it's there. You can get it. I was more thinking about if I work in my laptop and then just start to write my thesis, whatever. I'd like to get all those files generated on my laptop. I mean, of course, just pull that from the HTTP. You can pull this or you can even package this, but I don't think that's maintainable because it's in flux. If every new upload could bring a new publication. No, I would package the tool that creates from the installed software a BipTec file. If that's easy, but that was just an idea. This is a simple shell script, two lines of... Well, the SQL query is a little bit longer, but yeah, it's not really a package. You can log in to Elliott and just do the query. It should be a little bit better documented, but yeah. So the point is, I mean, I guess it's interesting to just get everything you have, what you have installed, but we don't install the upstream files on the inside the packages. So you always have to query UDD. Otherwise, you could install the upstream file into the package and then just crawl your file system for them and those... The upstream files are jammel files. Yeah, sure, you always have to generate something out of it, of course, again, but I mean to do it locally. Otherwise, you always need network. Why don't we install them in user shared doc or something? Good question. We could agree to say, well, write a depth helper sign or something like this, which looks for upstream files and moves it to user shared science package name also. Put in the wiki. Oops. Yeah, or something like this. But it's actually... these jammel files are not yet usable. That's why you also need a script to finally process everything, what's there into a BibTek file. But it's also easy to create. Yes. The data science would be development time that you make sure to include something into the package. And what I see, also what you were talking about is at runtime, you could optionally install something that was as a trigger to packaging triggers that generate extracts from your file system the BibTek data and store it somewhere. You can use a trigger which always updates a BibTek file. Yeah, every time it is a BibTek... these jammel files, it will regenerate the BibTek. The question is, which other parts of the upstream file are interesting? If your data science just put... just generates the BibTek file at package generation time and puts just the BibTek file in the binary package, and no triggers, no nothing, you just have the information you need. Yes, if you want to limit yourself to only have it working for BibTek, yes. If you instead, at the user space or the runtime tool, make it a .de files so that you can hook into it and do other things than BibTek extraction. I'm not volunteering for this, no. I'm not the one who said that it was two lines of shell script. Well, the extraction of all the possible is actually... I posted this shell script. No, I'm volunteering not for the trigger, but I might do it, but I do not declare it. But getting all the certations in Debian we have is just done, it's posted on the mailing list, it's the UDD query. Actually, the upstream files currently contain these references, and... Better? They contain the references, and they might contain something like... From the DBXM team, I have seen this. Oops. Oh, she's in wine. This is too dominant today. What we also have in the upstream files is where you should register for the software. The problem is some upstreams are depending from the number of users that are using their software. And so they put usually on their web page, even if it's free software, a button, please register and let us know how many people are using the software. And when building a Debian package, we somehow circumvent the system. And so we try to help them to get the data anyway. What we can provide is the popcorn values, but mostly these are not very reliable. So it would be better if people would register. This is some data we can use for Debian science in upstream, and I think... What are you using as well? You have another data point, I think. If not, I'm... Well, you are using... Ah, we can donate donations. We have also donations, the way where you can donate something. These are three data entries which are interesting in the Debian upstream files for Debian science. Otherwise, I don't know. Well, no, the bug reports are not in the Debian upstream files. The upstream files are... It might be a place where to point to an upstream bug tracker. An upstream sets up a certain URL where you can inject the bugs. But Debian upstream files only try to collect data which is related to upstream. And the bug reports are not upstream. These are the Debian stuff. So this is not... And I also think in Debian science we have basically so specific software that the authors do not mind about setting up a bug tracker system. I have quite rarely seen it. I have seen it, but it's rare. So... Yeah, this comes up from time to time. Yeah? Well, I have a comment on the upstream stuff. Recently I saw... Well, we can have these publication information and sometimes we have the URL to the printed version or something. Yes. And what I recently saw is that apparently there is this open archive initiative or something where you can put archive, like with an ax or whatever it like, preprints of PDFs which are open access and free day label. And it seems to be some kind of initiative and we should look at that. So if there is a paper and it's behind a paywall we might rather point to the open archive initiative or what I'm not quite sure what the thing is right now. Yeah, that's a good thing because sometimes you have not this... this tech which is called EPUB. I can show you, by the way, I can show you the potential fields. Upstream metadata. There's a wiki page. Syntax fields. This is a reference field and you have a jama formatted files and you can insert multiple entries for the references and all are regarded. On the task page is only the first one. Registration, repository, screenshots. This is... screenshots is a general thing. Donation. Yeah, bugs-up-mit and bug-database. These are the points where... if there is an upstream bug tracker but it's also not very science-specific. You should... if you know this you should insert it in Davion upstream files. Who's using Davion upstream files in his packages? It is not that common. There is also a DEP about these upstream files. So... Back to the topic, as I said in the beginning. Do we need either more fine-grained tasks, more fine-grained in the sense that mathematics is quite... where large-bees or electronics is quite large-bees? Or do we rather want to create a new blend which is, as I said in this morning, quite some work but potentially work the worst doing it if there are some three, four, five people working on the same field? You have quite a lot of people in astronomy and so do you think... do you personally think you would consider running your own blend and making some subset of what is a sample in science? No. You don't have the... you don't want the real fun out of it. Well, nobody can force you to volunteer. Well, the next topic would be make better use of DEP tags. Who is DEP tagging his packages? Who are really... two-and-a-half, three, four? Yes. The problem I was discussing with my Google Summer of Code student who is rewriting the meta-packaged stuff, we really want to merge the DEP tags with the blend's techniques. And the problem is we have no match between all the DEP tags. We work for science, but I doubt that every task file is covered by an according DEP tags file, and we also can't relay on the fact that packages are really DEP tags. So do we have any idea how we could increase this? Should we make some more or better DEP tags or... it is fine as it is. Are you using DEP tags if you're not taking... there are ways to install via DEP tags or so. As always, if it comes into categorization of packages, all the people say, well, there's DEP tags. Yes, there's DEP tags, but if it comes to the usage of DEP tags, yes, I don't know. Why do we have DEP tags if nobody's using it? You really don't really feel need. The problem is, for me, that users who are new to Debian don't find their stuff. They are not aware of stuff. I personally think that the blend techniques as we are using are quite helpful to say what's inside Debian. I just created some stuff just to tell my colleagues what's there. And DEP tags is an alternative way, and I think we don't care good enough for our users to telling them what they are. We are putting one package after the other into the archive because we need it ourselves. This is a main motivation, but we fail in telling our users what's there and how they could profit from this work. One example of how DEP tags is real use is if you try to install the package, go play. Go play was originally written for games, so you could find out the kind of games that you like. And it is pulling off, depending on the DEP tagging of games. So you can say, well, give me all the board games that is currently installed on my system, and then it also links up with the screenshots. Yes, screenshots is maybe not the kind of thing that is most funky and interesting for science people. I can imagine. But for some things it might be. For visualizations you might be interested in what kinds of examples of visualizations could this tool produce. But even if you're not using this part of it, the navigation is very user-friendly and it was hacked into supporting also navigating educational stuff. Go learn. And I don't remember the other ones, but this has been split into that you have multiple use cases angles into the DEPian archive of packages. And obviously it could be used for DEPian science also, for science-related packages, but only shows those that are tagged up. So you can browse the tagged packages. So even if you don't need it, some of your users might need it. Is there anybody who could fix JavaScript that just doesn't blink? So these are some use cases for screenshots in science, right? I don't have an idea why this is blinking. I'm not a JavaScript programmer, I just took this over. So, yeah. Use one of the image display libraries. They look overkill, some of them are very lightweight. Yeah, this is also some library, but Paul is the wrong one. It's not my code. But perhaps we talk together. Well, how did you know? So, but just... I think we could also... I think there are more than go-players. There are also go-something. There are multiple. I don't remember the... I actually recognized the importance of having things tagged. And actually, when I remember I tried to tag my packages, I still... I never felt the need of resorting to that text myself to solve the problem I had, but maybe I was just lucky or too unlucky. I have to say that there is a thing that I'm somewhat concerned for about, which is the fact that beside, of course, the package, the main package metadata that we keep in the main archive along with the Debian control files, we have quite a few other databases of metadata about Debian packages, which are more or less independent. There is DevTax. There are information contained in the Debian plans and probably others that do not come to my mind at this moment. And I think it would be easier if all these set of metadata were not collected on different websites with different interfaces, a way to modify them, but if there was some sort of better way to access to all of them with a consistent user experience, I think that this would enhance a lot the usability of these kind of metadata. Yeah. Well, we have actually not so many, but we have two methods and I don't regard these two methods as competing because one thing you can't approach with DebtX, you can't list not yet available packages, which the blend stuff can do. We have some, I should probably switch to the Debian Meet stuff, but I just know it better. We are listing stuff which is just in our SVN or in U, right? These packages are in U and you can't adapt something what is in U, right? And we are listing something which is just inversion control system. You can't work with this. So this is one reason why we can't use DebtX exclusively, right? But what we could do is to say, well, if there is a DebtX, there is no requirement to put this in the task file, but we could say, well, maybe I use DebtX something and this could also work with the blend framework. This would be your common interface. But to come back to your point, you say you don't DebtX and you don't use task files because you are confused. Would you use one if there would be only one system? I wasn't speaking only for myself. Personally, I know about DebtX and Blends. In that, in my case, it's just that I never happen to fill the need of it. But I think that in general, well, as a developer I would be more motivated to contributing to these metadata repositories if I didn't have to understand again how one specific metadata service works every time I need to. For example, I'm not pushing a new package that I've been archiving every day. If I do it after six months from the last one, of course I have to at least check again the help files, the guidelines to remind me what am I supposed to actually do. If this requires going to a few different web pages, to a few different services because they are independent, they ship, they're independent one from each other, that's more difficult. And the same thing as a user, although it doesn't specifically happen to me. I agree with you, but what about if you just send an email to DebianScienceList, I have uploaded a package which would fit in the scope electronics, physics, and please add it for me to the task. It is okay for you? You don't need to read any, send an email and I will put those two packages into the task file and it's done. This would work. Maybe it is it's still, okay, what I'm mainly concerned about is having to do a different thing for each different context in which I have to operate. For example, if I have to push a science package, maybe I have to write to DebianScience mailing list. If I have to push another package for another team, maybe the workflow there is different instead of writing an email, for example, ask me to go on a website and add my package name to a to-do list. Another team may ask... No, it's not that fractional. It's just... Maybe it's not, but the point is having something that easily reminds you of that without requiring you to check a lot of documentation just to find the single line that tells you the single thing that you have to do. Well, I think you describe it more complicated than it really is. Do we have an answer? Probably it also depends on the fact that I never even thought writing to some mailing list to... What I'm doing is I'm watching the WNPP if people are submitting a WNPP or ITP bug to write to this person, would you please consider it into Davion Science Team or something like this and in what tasks you would think it would fit best or in what tasks. I'm just doing all the work but I need the information because I can't really follow everything and I have not even the competence to follow this stuff. I don't know if in what field it... Could you please introduce yourself and say in what field you are? It's a bit complicated now because I'm here I'm not maintaining any packages in Davion Science although I'm considering this. Also because until now the main package I was working on along with its long list of dependencies was GeoGebra actually related to Davion Science but I was maintaining it under the Java team and it is educational software for mathematics geometry like powered up rewriting of the Capri software that probably is a bit more famous. Unfortunately it recently became non-free at least later last versions are not free anymore and upstream I wrote upstream but they were not very interested in to make it free again so most of the packages I was working on the moment are more or less dead are not of my interest anymore because there was just dependencies for GeoGebra which is not going further anymore. So it's difficult for me to say what I'm working on is a bit more working in Davion Science I study mathematics for the record but the point is that I think that most of the difficulty or not of the things you are saying mostly depend on whether one has the habit of working on that or not if you are working on say Davion Science Blend once every week or even more you are used to old procedures on things you have a complete workflow in mind my experience as a Davion developer unfortunately is that the amount of free time that I have varies a lot during the year for example so maybe there are some months in which I'm sorry if I'm interrupting it's not so much what you need to do you can feel free to cope to every team I just want to we don't fight for people that they put there I wasn't there if you stick to the Java team do your usual maintenance but just give us a signal this package is interesting for this task and this task and you are done what you need to do you are maintaining your packages but if you want to see your package in a context with other packages which fit somehow and you see the whole picture inside Davion and you want to show your colleagues I'm maintaining this and these other packages fit and you see them all assembled on one web page I think this is something what interests people of course it is I wasn't denying that I may this Go Play tool actually does include a Go Science facet so there's seven different alternatives to Go Play and one of them is Go Admin and then there's Go Office and Go Science and if I take Go Science and say that I want to show type mathematics then there's a whole pile there's a lot of mathematics things so specifically for your case you can just lean back and relax someone else has done the for you studying of documentation is finished for you thanks for your contributions so the discussion about remembering how to do stuff for Davion Science or I mean not so much enforcing team policies as reminding people of things we're trying to do as a team made me think about a discussion we've been having on the Perl team of making a team specific lintian profile now I'm not volunteering for this but so if somebody likes things that that would be valuable then I don't know if we could discuss it further but I just wanted to toss that out there because it's an interesting idea to me because I'm working on a lot of different teams and most of them don't have an upstream file or whatever so or it could be hey I see you're packaging a new package like Clippy right so command line based Clippy so I see you're packaging a new package would you like to send Andreas an email about the test file or something anyway so I think time is close to over any other comments since so I conclude that we have some DH Science it was also somewhere way below on my to-do list but volunteers are perfectly welcome and everything else is not really changed we wanted to write something about this you can check the references this is in linjan task but it's also general it's not really science specific but something is there somebody who has ever written a linjan test can do this I would have to read the documentation how to write linjan text I can help you write linjan test okay so thank you everybody for attendance I think we are sticking to the science topic for today somehow and we can keep on discussing all the depth points thank you