 Welcome to the science track of this year's DebConf. My name is Michael Bank, and I'm organizing this. I just want to say hi to everybody who came here and hopefully back home on the streams. There's a wiki page for the Debian Science and Math track at DebConf 10, which I just put up there. It's wiki.debconf.org, wiki.debconf track science. And we have an IRC channel on ircdebian.org hash debconf-interschool where you can also, if you're well here or outside of DebConf, you can ask questions for the talks. So I hope the stream is working. And what we can also do, and I will put up the schedule in a second, is using gobby for gobby.debian.net. I put up a dc10-science-track channel. There's no content yet, and I'm the only one, but if people want to join, and we can collaboratively take notes of the tracks, you need gobby-0.5 for that. So might be a problem if you're running Lenny. I will soon hand over, but just saying that we got a couple of slots, and we split them up. So first, first Sylvester will introduce Debian Science, and David will introduce Debian Math in the first slot, and maybe David can also summarize a bit the math ball that just happened in the morning if there's time left. And then on the second slot, let's go back to the program. On the second slot, Michael Hanke and Jaroslav Falchenko will present Debian from two perspectives. Debian, the ultimate platform for neuroimaging research. And at 4 p.m., we will have a split slot for new developments in the science packaging. So Adam Powell will talk about MPI packaging, Sylvester Leidru will talk about linear algebra libraries packaging, and Jaroslav Falchenko and Michael Hanke will talk about citation reference infrastructure. And then at the end, we will have a Debian Science round table. So any questions or things that came up during this, or we can also try to flesh out the agenda during the track, we will discuss then. And if there's anything left, we can still schedule impromptu buffs tomorrow or the day after tomorrow. I wanna thank all the people who are contributing to the track, and yeah, with no further ado, I'll hand over to Sylvester. So thank you. So I'm going to talk about Debian Science because many things happened during the last two years. So basically here, it's a series of screenshots of various things we've packaged lately. I'm going to talk about that a bit deeper later. So first of all, I won't bother you about that, I'm just working for Sylabs, just see if I do some advertising about Sylabs, it's normal, it is basically what I'm paid for. I'm a Debian developer for one year and I've been a DM for three years before. Mainly involved in science and Java, and here we are. First, I'd like to explain what is Debian Science because it is pretty unclear. On the point of view, you are looking at what is Debian Science. So first, what I'm working on mainly, it's a team Debian Science, so it is hosted as IOT. There are about 70 people registered to this project. We are basically of 130 packages, and the main list is the one you can see on the screen. So it's debian-science at least.debian.org. After that, Debian can be also seen as other teams because some people have been working on a specific science field for the last few years. So one of the biggest is Debian Med. It's mainly managed by Andrea, hello Andrea because he's probably watching us, and Charles Clécy. So they are packaging a lot of packages for a while. Another team is also Debi Shem. Okay, I think it's mainly Michael Work. It's about chemistry in Debian. And the last one, I'm going to talk about that a bit deeper later, is a package science comp. It's mainly about numerical computing. So it used to be 60 packages, now it's 30, it's normal. This is what we are trying to do. So the goal of Debian Science, also the Debian Science team here, I'm talking mainly about the team. So the goal is to package the best offer and libraries in this different field. So there are many, many pretty good Swiss software releasing because on my point of view at least from my R&D project manager, I can see that government are like Europe and France because the two stuff I know pretty well. They are pretty happy to give money to finance free software project in science. And it's very common that the French government is giving a lot of money to finance free project. So we are trying to reach the same level as quality as property software. I know it's not the case in other free software area where free software are better, for example Apache and so on. But in science software, they usually were a bit less good because property software are very expensive. For example, a MATLAB license with an extension called Simulink. It's about 18,000 euros per license, per computer. So it's pretty expensive. So corporation and state are happy to finance. So we are starting to get more and more very high quality software which are usable for a lambda user, not for an IT guy or something like that. So we are trying also to create, to package things in various sector of science. So like math, physics, simulation, modellization and so on. And one of the things which is pretty important and we talk a lot about this this morning is to create some kind of glue. So how you can call one software from the other. How you can do that, how you can manage that thing. The two first examples that you can see on the screen is Salome and Codaster. I'm going to talk a bit deeper about these two software because they are pretty important in France and in Europe because they are produced by EDF which is one of the most big corporation in the world about nuclear. So they've got a lot of money to work on this. Other things in the deviant science that we try to do and I'm doing that on daily basis in France is connect people. So it's important to, when you know that some people are working on this software and other are working on something similar just to put them in touch. You never know what can happen. Sometimes it will take two or three years. This is basically what happened with Salome packaging but sometimes people start to work together and produce some amazing results. And also we are trying to educate. I don't really like the word educate but we are trying to explain to upstream how distribution are working. We all had one package once where upstream was included sources just because it is so convenient for them but for us it is very boring so it is a lot of work. So we are trying to explain them why they should not include third party sources into their base code and so on. And also we are trying to make them understand that it is very important for us that they accept our patch. So for example, if their building system is broken it's very important for the future maintenance that they accept our patch as soon as possible. Otherwise it will get very boring to update when they are doing a new release which is fantastic but they change everything inside. First I'm going to, sorry. Then I'm going to talk about the history of deviant science. The basic start was done by Andreas when he started to do CDD. It used to be custom deviant distribution. He started that a long time ago and now it is called deviant blends. So for me it is really the start of deviant science. By this I mean the creation of the basic packaging tools and environment and community and this into deviant. And after that, thanks to Andreas's support we started to, sorry, I'm going to explain quickly what is blends because I realize that not everybody know what it is. It is my understanding of blends because it's not very obvious to understand. It is just to put together and reference all scientific software. Don't hesitate to interrupt me if I'm wrong or if I'm missing things. But it is basically in one field we are trying to reference all the good software who are, which are in the archive but also the one we want to package in the future. So if I see a great software but I don't have time to package it I will put it into a task file of blend saying this one should be packaged. Here it is, what is the description and so on. So it really helps to reference what are the scientific software, the three scientific software that we could package and that's it. So we created the team on Haliot in the beginning of 2000 and Hayes. Now as I say, we are more than 70 people. We are packaging about 130 packages. Manual prints and Hayes, we wrote a policy in mid 2008. So the policy is very standard. So we are not seeing much. And it's really outdated. So if some people want to help on this to update it and to make it more 2010, it will be nice. So I'm going to quickly talk about the few work we've done in the science team. So one of the first one is work on MPI stuff. I'm not going into the detail because Adam is going to do that later but MPI is basically a norm and many vendor are implementing this norm. And in Debian we had a lack of coordination around the various MPI implementation. So we started to address this issue. It's not over because we have some migration to do but it's going pretty well. The linear algebra, it's me who I'm going to do a talk later but it's pretty much the same thing. Various implementation and lack of coordination and work on this. Open Cascade, the work has been done mainly by Donis Barbier and I think Adam helped pretty much. It is a huge library to do CAO conception assisted by computer. It is in French, sorry. And it is a huge library, which is widely used in France in some important projects. We have also PowerView, which is the visualization tool. So we package a huge software which is called Saturn. So I can see that's really interesting in this. As I say previously, EDF is one of the world leaders in energy and they developed many software to manage the nuclear power plant in France. In France we've got something like 65 power plant, nuclear power plant. It's the top country in nuclear and since it is very expensive, they decided to extend the life period of about 10 to 20 years for each nuclear plant. So they had a strong need of numerical computing software to do some simulation on degradation of the component of the nuclear power plant. So they developed many, many different software and they released as free and open source software, a lot of them. Like Code Saturn, Code Astaire, Salome. Those software are high quality, they are widely used and they are starting to be more and more used in France and in Europe. So we decided to package this one and especially because the response from a swim was very good. When I've been in touch with them, they will say, oh, okay, it would be great to have this into Dibyan because they all are using Dibyan, the researcher, and they are very interested to know what is a good way to package the scientific software. So we help them a lot to know what is the right thing to do, how to package the scientific software, what are the auto tools, auto make, and so on. And they have been applying a lot of patch and they've been very, very active on the various bug reports we submitted on their software. So here is one of the results. It is a CFD, so Computation Fluid Dynamics. So basically here's the example. It is into a pipe, we are injecting some CO2, some helium, and we are doing some strong computation. This software can run on clusters, where MPI can run also on my laptop. And here it is rendering the done part of you which is another software which is available in Dibyan Science. So we can do some pretty amazing stuff with this software. If some people are interested, I've got some video and so on. One of the work is Salome. It is also an EDF software that Adam started to package about two or three years ago. But the upstream response was pretty bad. It really didn't reply to any emails. And Adam had about 50 patches. So we say, okay, what can we do? It will be too hard to maintain because there are about 20 or 30 people working on this project. So they are releasing very oftenly and they are changing a lot of things. So the patch usually cannot apply from one person to the other. So what we did basically, we, thanks to Logilab, which is a small French corporation working on Python, mainly, we started a collaboration with Adam and Logilab and EDF because we know the people are from EDF and we educated them basically. So we had a long meeting explaining them how important it is to include upstream patches, downstream patches into their distribution and so on. So they've been very interested. It is very funny to see the contrast three years ago and now because now they are very happy about the inclusion of the software into Debian. So now it is already available. This one is more internal to Debian. As I said previously, we basically have got four team working on science in Debian. One of them is the package science camp. There is a strong overlap between the two teams. It's not very easy for a newcomer, for someone who is already involved in Debian but not in scientific field to understand and to know where is the best place to put this package. So we had some confusion. We also had some issue about cross mailing list discussion. Some package in Debian science are based on some library into the other distribution and also the maintainer of this group does not have too much time. So we decided to merge them but it is very long work and there is a lot of inertia. So the statue for now of the merge is basically we had 51 packages. Now we are 33. Some of them are already changed from package science camp to the other one but we still need to upload the packages. We don't want to upload this for nothing and it is a very slow process because nobody wants to upload a package for nothing. So the Debian science team needs some help. So as I said, as the DPL said, fixing RC bug is very, we should also and I think I'm not the only one who is interested in this update some documentation on our website and our wiki about the various teams that we've got because it is a very strong confusion for people coming into Debian to see that we basically have got four teams. So wiki is not very clear about that. We've got plenty of pages. So I think we really should work together to clean up this mess and to show on the world that we are pretty clear about what we want to do in science. So the merge obviously have to be finished. We still have some migration to do about the MPI. I hope we will be able to do it on squeeze but some maintainer of third party libraries are not very helpful for now. And as Andrea said previously on IRC, we still need some add on blend science to update everything because it's not very, it's a long walk, walk and walk and also some screen shooting. So some open discussions that I like to have. Maybe we can do that later at the open discussion but one of the things I would like to highlight is the confusion that we've got on the mailing list. We've got Debian science and we've got the Debian science mentor and I'm afraid that the first mailing list is too focused for now on packaging aspect and should be more for the user of the packages we've got and maybe switch the discussion we've got about packaging or request for sponsor and so on on the Debian maintainer for the time being the second one is not very used. So we should maybe do something. And finally, I said previously, create a hub. So on Debian on the website maybe say, okay, if you want to work on chemistry or in the medical aspect, here is a team and so on. So maybe we should do some more advertising and so on on the Debian website. So your turn, David. Okay. Well, maybe if there's some questions. We'll take questions now. Yeah, that's right. Thanks for your talk first. You're welcome. Is it, okay. I can just hand it over. Is there any questions? Well, I got a question. The Debian science maintainer's list, does it right now get all the bug traffic? And that kind of stuff or where is that going? But we could change that. Or we could create another one. Right. So you, I guess you don't. Because that sometimes is sort of like an issue that people get flooded with that kind of stuff. But, okay, on the other hand, they should probably read it anyway. Yeah. Well, okay. But for now it's not too noisy. I think we've got about one or twice a day, something like that. We don't receive many bugs. Except when Cyril or Luca are launching many builds and reporting 2,000 bugs in one day. And the upload notifications and that kind of stuff also goes. Sorry? Upload notifications. Ah, yeah. That things also, yeah. Well, okay. For now we don't have to. Anybody can just filter it out if they want somewhere else, okay. Is there any other questions? Okay, then we'll, yes? So, well. So we are supposed to freeze quite soon. What would be the big things that you would want to do in squeeze plus one? Fixing the, ah, in the squeeze plus one. Package more stuff. No, I'm not answering to your question right now because I'd like to see MPI and Atlas fixed now. Not in the plus one. That would be nice. Yeah, but it might be for the next one, especially for MPI. I hope Atlas, I'm going to chat about that and do an upload in the next Tuesday. I hope it is going to be fixed pretty soon. But it is, I'd like to also package more library about linear algebra and start to work on GPU things. It is very efficient this day. So it is something I'd like to do. But I don't have, I haven't saw yet about the N plus one. Any more questions? Okay, then thank you. And we'll go to the second talk. So, I guess it's okay, is the mic? Good. So, I guess I'm not sure why Michael asked me. Well, I know why, but let's not talk about that. So anyway, I guess I wanted to give just a little bit different perspective on the rest of the things that are at least one more aspect of what Debian science is working on. It's a bit of an umbrella group and a lot of things in it are numerical, but not everything. And even not everything mathematical in it is numerical. So, I'm a mathematician and a Debian maintainer. So, it's a bit confusing. We seem to have more discussions than necessary about naming, but anyway, I wanted to settle the topic for my little mini talk here. So, we decided what I'm talking about. And there's a lot of intersection between what I'm thinking about as mathematical software and versus what I'm calling numerical software, but you might also think about as scientific computing and education actually. There's a lot of overlap. When I use a tool, I tend to use very, I mean, I'm lazy, right? So, I use the same tools for teaching and for research when I can. And in particular, for making pictures, making material, I think most people are the same way. So, you know, probably tech is the most important piece of scientific software in existence. So, this mathematical software, please accept my definition at least for the next 10 minutes or so, has something in common with a lot of these other efforts that Sylvester is talking about. So, in particular, licensing is often an issue with the university labs. And my own experience is that academics tend to make eccentric licenses, right? Don't use this software for evil, that kind of well-meaning, but in the end counterproductive license is quite common in this domain. We have a lot of old code. Well, two different problems here. So, Maxima is very old. It's maintained by Cam McGuire. He's been maintaining it for many years. It's based on GCL. He's also maintaining that. The code in Maxima really goes back to the 60s. It's older than, I think, most people in this room. SageMath has a different problem, which is that it has convenience copies of most of Debian in it. I exaggerate a little bit, but... So, those are, this embedded library's problem is a big problem for, I think, maybe everybody packaging, but it feels to me like it's a particular problem for work coming out of academic environments. We're all, and this is one thing I wanted to mention, is that, and it's something that as a, is one of the interests of the Debian science team is publishing, and I don't mean just getting things in journals, but I mean making nice documents, right? And so, this is mostly tech, but also managing bibliographies, which we'll come back to this afternoon, and making pictures. And I suppose not all mathematicians are very interested in high performance computing, but I am, so there's a group of experimental mathematicians, I would call us, who heat a lot of rooms, trying to find particular mathematical objects. So, we're searching usually quite clumsily some big search space, and running SAT solvers, and these kinds of things. And so, to do that, we get involved with batch, so some of you were at the batch processing bot this morning, so there's some things in common. Some things which are a bit different is that, as a mathematician, I publish things in journals claiming things are true based on what my computer tells me. And so, if you know anything about floating point arithmetic, you know, you have to be very brave to do something like that based on floating point arithmetic. So, I would say in GMP is mathematician essential, right? So, I don't think that you're really doing computation as a mathematician or GMP, or is there any equivalent exact? It's really the standard, right? I mean it's one area where we don't have a plethora of choices. The other thing that I wanted to mention was that we're pretty interested in non-numerical computation. Symbolic algebra is a topic that came up this morning in the math book. That, I mean a lot of people are interested in just because it's a tool, a general tool that many different people use. But also working with objects which are not numbers, so groups and graphs and permutations and other kinds of combinatorial structures. I don't know, maybe in Sylvester you can correct me, but I feel like this is true, right? That there's more Lisp and less Fortran in the codes. You also have Lisp in this, both Sylab. Yeah, maybe, I don't know what's going. So, and this comes back to publishing by mathematical diagramming tools. I mean tools which draw correct diagrams. So, in particular, the picture on the page should really be a 3D projection of whatever you like and it's not about surface shading, it's about giving, say, equations or something that describe your figure. That's another aspect. In my work, I think, or at least in the 10 minutes this morning I thought about it, there's really three different ways that I use tools. I think these are all tools in Debian. Part of it is as a software developer and here I'm using, and we're all using libraries and language systems that are in Debian, to varying degrees of success, right? The temptation to just embed upstream libraries, therefore, even those of us who know better. And the other thing I think is, here there's quite a big overlap with educational use and, but I think it's quite interesting because it's not programming, it's doing math. So, again, symbolic algebra packages, GAP is a kind of specialized symbolic algebra package. I'm using Haskell, who here is a Haskell programmer? There's two of us, yeah, it's like that. Mathematicians love Haskell. I mean, particularly discrete mathematicians, it somehow appeals to something in them. And I'm using Perl because sometimes Haskell is just too much work, so you need to do something fast. Even for generating permutations of numbers and so forth, I'm sometimes using Perl for things like that. Yeah, and I think everything under here, I mentioned already bibliography managing, making pictures. I'm ashamed to say that I only use R for plotting. I should use it for more reasonable things, but it's really good at plotting, so that part's good. Okay, so I just wanted to give you a bit of a flavor of sort of how Debian supports mathematicians. This morning we talked a bit also about mathematical software and there was some discussion of gluing things together. I mean, that these codes, which are somehow a noble ambition and also a real challenge for Debian. These omnibus packages, right, which depend on many libraries and so as you mentioned already, I guess version, I mean this problem of upstream requiring particular versions of libraries. And to preempt the question about what do I think about squeeze plus one, I think if we are lucky we can get Sage packaged for squeeze plus one, but it really takes, it's one of, it's a typical situation where the people who are most involved with creating the libraries and so forth and maintaining the individual libraries are not as motivated to use the glue package that puts them all together. So I think we have a problem pulling together, well, so far we don't have a team. It's a huge effort and I think if we want Sage and Debian there's gonna need to be a team to pull that together. And I guess I'm kind of un-volunteering for that, sorry. Okay, so that's enough from me. Thank you. Any question, comments? Yeah, that's great. Quick question, so if you're talking about Sage and you've never mentioned Python, are you going to learn it? I should have mentioned Python as well. I use Python as well. That was a no mission. I use both Python and Perl. I guess on the scale of quick and dirty to must be correct, I go Perl, Python, Haskell. Also, have you heard about such new, well it's not new, Fortress. I've heard about it. I don't know much about it. Well, besides that it was owned by San as well to some extent. Okay, Sylvester? For information, GMP, you have also another library. It's called MPFR for multi-precision library, which is based on GMP, but extending it. Right, GMP is kind of hostile. I don't know what the story is with that. I don't know exactly, but MPFR now is pretty good and you can use it to do such tasks, just for information. Okay. Isn't it in GCC or got it out of GCC? I thought it was part of GCC. No, this one is out. It's a library, it's done by the Inreal. I wonder if it's not from Nancy, but it is, it's pretty good now. And in the archive. Okay. Can I stand up? Can I stand up? Could you comment on the exotic languages that you mentioned? Sure. It was in quotes. I mean, why is this more exotic than Fortran? Yeah, like for example, I mean, I have seen industrial production level quotes that run Fortran and people still develop Fortran. Do you mean like, I don't know what you meant by exotic. Okay. So how many people here could, if forced, program in Fortran? Okay. Now, other than knowing there's lots of parentheses, who could write some list? Not so bad. It's closer to balance than I thought, but I mean, if you look at the people doing numerical algebra and doing high performance computing, they're working in Fortran and maybe C++, depending on, it's kind of a generational thing, but there's a community of list programmers. I don't deny that, but it's much smaller. And the intersection with scientific computing is relatively small. I've definitely forgotten what I'm maintaining. Have you heard about LUSH? LUSH, no, tell me about LUSH. LUSH. LUSH. L-S-H. L-U-S-H. I know it's a description of somebody who- It's a least universal shell, I believe, if I'm not wrong. And it was, it is developed by quite known guys in machine learning. Okay. And it's quite, it was presented in NIPS community for a while. And what its emphasis is, is to create least like language, right? Or it's usually it's least, but very efficient for numerical computation. They compile modules from she and it does on demand compilation. So it's quite cool too. And they're now maybe already released even LUSH too, which is redesigned in many places. So if someone is really eager, because I'm not using it myself, I even forgotten that I'm maintaining it. But if someone from Debian could commentate it or even pick it up, that would be more beneficial for Debian. And it's quite cool thing. So maybe the way to put it is, who would rather program in LISP than in Fortran? Yeah, I mean, I don't know it well, but I guess it's a question of, it's LISP essentially. Please. If you ask about closure and such things, the moment you have a virtual machine, it's really hard to do numerical computation as well. So, you know, all those layered architectures or layered languages have big trouble with this kind of stuff. That's the main reason Fortran is still around because they have these hacked up libraries from way back when that, you know, manipulate the bits in a way that nobody would bother to write today. Yes, sorry, sorry, sorry. Fortran is not running on the JVM. No, no, no, but closure runs on the Java JVM, which was, I imagine, the most worked on JVM. Well, the standard classes in Java for numerical stuff are awful, you know, big decimal and those things. It's really bad. So, you know, that's the big problem. Okay, but then this brings up one other small, the issue about virtual machines being too slow and all that, and you gotta slide on using, yeah, GMT. There it is, JMP. Most of the programming languages, like Ruby has an exact, and Python probably has, doesn't that have exact math libraries? No? I know Ruby, I knew Ruby definitely has, you know, exact procedure. So my bias summary would be that the clever implementers use JMP rather than writing their own, the only people who write their own have a GPL issue. Okay, so that's my, it's probably an incomplete picture, but as a short summary. Well, I also think that you always have to keep in mind that manpower is limited, so if you have a research group or something and a new PhD student comes in and they have to learn Ruby first, but they know Foughton already or something, it could be a barrier of entry of just different program languages sometimes. My feeling. Adam. Mike. Sorry, I'm curious, in terms of similar barriers to entry, do you find as a mathematics educator that some people see tech as such a barrier to entry? Coming in. So I don't make undergrad students use tech, and in fact, my career is a bit strange that at the undergrad level, I'm mostly teaching computer science and my mathematics teaching is at the graduate level, and at the graduate level, they don't mind. They're invested enough in a single project that the overhead of learning tech is not so bad. I can comment on that. So I taught psychology for quite a while, and I made undergraduates use it, and it's for all of them, shock and awe, and about, you know, my own sample is about 30% love it afterwards, and the others hate me. That's a useful. In fact, I was a tech hater, I can confess, as an undergraduate, and I thought, oh my God, how can this be the right way of doing things? And well, when I was an undergraduate confession time, I mean, you know, the first max were coming out, and the question is, these things are so easy to use, and why can't we do tech that way? I think now that I've done these things for a while, I think most people in this room probably know that it's always a trade-off between a learning curve and how easy it is to use when you're an expert, right? I mean, there are things which are easy to use for experts, and there are things which are easy to get started with, and there are not so many which are both. And that's a quick start, there is leaks. Mike, give him the mic. Excuse me. Just a brief comment so you could ease your students' life. There is leaks, L, Y, X. Yes. And it's really, really easy to start, but it puts you in this kind of right culture of how you compose the document and use styles and enforce proper formatting. So, and then many people just jump off, or many people stay, and it's quite powerful. So, for many applications, it's really, really appropriate. Right. How is leaks maintained these days? I have vague memories that, does anybody know the leaks story? Go now. I can't really give you details on how leaks is updated. I know it's, it works well and it's regularly maintained, but I don't know the status regarding upstream. I am trying to start my people, I mean, I am the technical guy in a social science institute. So, well, neither the professors, not even the publication department know anything about the publishing with the or similar, and I'm starting to try to teach them with leaks. So far, I've seen their comments as looks okay, but interesting, but then how can I leave a larger gap or make sure that this is, you know, all those things that you're used to with a word processor. So, yeah, their minds are badly shaped, but I think there is hope. Okay, thank you. There is a package called TecMax. Yes. I don't know if people are familiar. It provides like a very less barrier of entry to do anything like typesetting, and another advantage I find is like, it has like, like, you know, for example, say, you're writing a document and you want to plot something, it provides an interface for like GNU plot, you can plot graphs, and then like you can call languages like Octave and like R programming language. So you can like, for example, like typeset something, and then like do demonstrate like an R session, and then like generate graphs all in the same document. I personally find it like very useful. Yeah, maybe give it a try. So, thanks for that recommendation. So one question I had, I know Lix, the underlying format is Tec, or at least it's easy to get Tec out of it. So, suppose, do you know, have you ever tried to take a document from TecMax and export it to some other tool, or how easy that is? You should do some maintenance work for TecMax, sometime back, long time back. Yeah, they, I mean, the underlying format is actually like similar to, very similar to Tec, but not exactly Tec as such. But they do have like stuff like export to PDF and export to Latex, and you can import Latex classes into TecMax and do some work. But I mean, couple of years back when I tried it, like the conversions are like not so great, but when you bring up the issue on like TecMax mailing list, usually the developer responds, and like maybe you can work out some customer solution or something like that. So, I mean, expect some rocky road. But on the other hand, upstream is responsive and helpful. Yes, upstream is like, I find it responsive here. Thanks. Any more questions or comments? The questions for Sylvester as well, I feel like I took over your session. I got sort of like a question. How many are there of you in the math? Is there any so like team going on? Or is it just like that math software is, you're just using basically as a mathematician, you're just using the good stuff from the rest of the archive and then these linear algebra or whatever symbolic stuff, which might also be used by others. So there's not really a core math package type of set. So a team isn't, well, except for Sage, maybe apparently needed. So Sage, a team is needed just because it's a hard packaging problem. What are the biggest, is it just because it's so convoluted with other stuff or is it licensing or what are the biggest issues? Okay, so one, it's Python, which is either good or bad, but from a packaging point of view, apparently has some challenges. The other is it's using a huge number of dependencies, really an astonishing number of dependencies. But the killer point is that it's, so upstream embeds everything. And so I'm summarizing a bit what I learned this morning. Upstream's point of view is they want it to be, the system to be usable on systems like Windows where there's no package manager. And so they want to ship essentially binary packages or in worst case, one big blob of source code that you can build. And they have strict version dependencies on libraries. And it's also releasing once a month. So I think those are all, I think that's all the challenges that I know about. I guess one more challenge that I do know about is that it's not just using library packages, it's using other systems. And it's a kind of front end interpreter to other interpreters. And well, my own experience with this is that it's fragile when I've tried to do things like this. But it would be worthwhile to package it, apparently. According to some, it has a large, it has a vibrant user community, I think. So that's why else should we package things, right? Other than, so there are people who would care more about using Sage than using Debian. Did anybody follow on ISC or so? Is there any questions from there? Just wondering, because my notebook's sitting there so I couldn't, I'll try to fix it. Posted it yet. They can say, hi, I have a question. Just ask. Don't ask, don't ask. Yeah, no matter questions. Bombard them with the d-package bot. Is there a question? Oh, sorry. Do you have a question? Do I have a comment? Say something about Sage, which is while the licensing issues in the package that they release for downloading on private systems probably are not an issue. There are, in fact, components on their main system, which you can use through their web, which would have licensing issues. If the question from ISC hasn't come through yet, I could bring forward one thing that we'd bring forward. It has. Okay. You talked about EDF software, Code Saturn. What is the status of Code Aster packaging? We are currently working on it. Most of the previous version, everything is on SVN version, on the Deviant Science Repository. And we are working on uploading the package. But as it is separated in small packages, we have to put it one by one. So it is an ongoing work, and I hope we will be able to do it for squeeze plus one. Probably. There was one item in the math box that we thought could be discussed this afternoon, which is sort of, it's a bit of an internal question. So I don't know how many people here are actually involved with packaging. Good thing, I forgot about that in the beginning. So who of you, how many of you are scientists in a sense? Okay, and how many of you are like size admins who work because they work in the scientific department? Okay, as well. Yeah, that's quite some overlap, I guess. I know. And yeah, how many of you are, what was your question? So I guess the question is, how many people are involved with packaging scientific software for Debian? As well. Okay. Well, I am your as well, right? Yeah, a bit. So the question on IRC this morning was, are we falling victim to the not unprecedented problem of packaging too many things and spreading our efforts too thin? And do we have too many packages which do the same job? That's an actual question. I think we should discuss that. I also wanted to discuss that in the round table because yeah, I think we should make a short break and fix the setup and then we'll get to the second talk. So in like five to seven minutes. Okay. Thanks, thanks, David.