 Welcome to the Mathematical Software Birds of a Feather session. My name's David Bremner, and I'm in some sense a mathematician. I work in the computer science department, but about half, three quarters of the things that I publish, I publish in math journals. So I guess that's one definition of a mathematician. And I'm also in the Debian new maintainers queue. If you're listening for more, I'm waiting to hear from you. So like most people, I want to make Debian better for people like me, some universal truth. So I wanted to get together and just have a kind of informal discussion about what we think the state of Debian as a tool for mathematicians is. And if there's we should somehow be prioritizing some packages or what the challenges are. So there's a gobby session where I propose we can make some notes. Probably you, well, we can all make notes together. So to connect to that, if you can see the very bottom line there, if you have the package gobby0.5 installed, then it's just gobby0.5 minus cgobby.debian.net. And if you're listening to the video stream or I guess that's the only other option, you can do that from anywhere. So you can virtually participate in that way too. So maybe in the spirit of birds of a feather session, I could ask anybody else who wants to introduce themselves and say sort of what their interest in mathematical software in Debian is as an administrator supporting other users as a student, as a teacher, whatever. Anybody else want to chime in and give us some context? CJ Fernley, I came back for sage math in Debian. OK. So that's kind of in so much as we have an agenda that's on it. So great. Once again, I just kept saying my name today too often. My name is Yaroslav Khachinka, and I am not mathematician. It's OK. Hi, I'm Varun. I'm doing PhD at Cornell in mechanical and aerospace engineering, and I've been using some Python scientific software, like Python sci-fi, Python numpy. Right. And so I do a lot of post-processing, and I need to plot my results and all. So I use Macplotlib for plotting. That's kind of software. So for you, the Python library support is pretty important. Yeah. Great. Hi, my name is Raju Kusmanchi. I work in a finance firm called BlackRock. We do use free software, I mean for research and purpose and stuff like that, mostly to do, like, say, recreations, data analysis, like, say, Octave, TechMax, R Package, Laypack, and pretty much anything related to math and database-oriented stuff. So would you say your use is mostly numerical stuff? You mentioned? Yes, numerical analysis mostly. OK. And sometimes we do use, like, say, Laytech, but it doesn't exactly scientific, but we do use it for generating reports and stuff like that. Right. So in the sort of intro to scientific software session, which will happen later, yeah, well, one of the things I wanted to mention is that I think that part of supporting working scientists of all kinds, and my own interest is in supporting mathematicians, is supporting publishing. I mean supporting typesetting and diagramming tools. I think that's a crucial part of that. And the plotting software also, like, yeah. So all the things, like, go together as a group rather than, like, individual packages. Sure. Yeah. It's important to have everything working, like, right when you need them. So anybody else? Frank? Frank Brocken, University of Groningen in the Netherlands. I will be interested in hearing about any statistical software that would be available. In particular, the kind of software that could, for example, compare or cope with packages like SPSS and things like that. So you know about R? I've heard of it. I must admit that I never really looked into that. But maybe I should. I think you should track down at DebKonf, Don Armstrong, and say, tell me about R. I know he had a buff already, but there might be another. I think there's another R buff during DebKonf. So I would definitely check that out. I'm really R ignorant, but I know that a lot of, I think it's supplanted S completely now in academia, I would say. Thank you. Adam Powell, talking this afternoon about partial differential equations, solvers, and linear algebra and different things. But for the purposes of this session, I'm wondering if there are symbolic algebra software that's free. I'd love to hear more about that. So I guess the ones that I know about are Maxima, which is based on the old project from MIT and has mutated many times since then. And Axiom are both general purpose. You have also another library, which was China, which is C++, and it's pretty fine to use and pretty nice. Yeah. Well, you also have SimPy. It's a Python library for symbolic, which will be at some point integrated in Sage. Right. Ukraine, and we could package it at some point, and it provides convenience for differentiation, but not symbolic differentiation, but this automated differentiation based on the structure. Perry GP isn't maybe general purpose enough for symbolic algebra, but I've used it for lightweight stuff. I want to make a comment about the statistical package. Like Octave has quite a bit of support for usual statistics. But I mean, if you want to do just simple statistics, but if you want to do stuff like hypothesis testing, then you probably have to go to different things. But Octave is a good starting point if you're looking in statistical packages also. On R, I've used it a bit. It's a full-fledged programming language for statistics. And one of my partners was with a market research company. And they did everything with R, seeing it as full industrial strength, so just to add a couple more adjectives. And they are also a very strong community around R. Just a bit of an introduction. I'm working at Sylab on a daily basis. I'm employed to work on this. And I'm also trying to manage the Debian science team and trying to package many software on that with Adam, for example. And we're going to talk more about Debian science as a team in the afternoon. Yeah, I'm doing an introduction this afternoon about that. I would like to comment that for symbolic computation, while R isn't packaged, not R, while reduced isn't packaged for Debian yet, it is now under open source free license. Can you say something about the particular strength of reduce? Well, especially in physics, it's got a lot of historical routines available from various users, some of which are not free. But the basic package is free. And a lot of people know it. Right. Yeah, I've definitely heard of it. Someone else wants to? So I could mention one more package. So I'm a bit of an oddball in this room. I think I'm a discrete mathematician rather than working with PDEs and things like that. And for discrete mathematicians, the system gap is really useful. It's very nice for exploring things with permutations and groups and has OK interfaces to dealing with graphs. Are there any people here at all interested in things like graph isomorphism or it just doesn't come up? OK. So anyway, you know where to find me if you are. I'm interested in discrete math. I just don't use it every day. Right. Right. I love discrete math. OK, so we had a round of introductions. And I guess, are there things that are bugging people? I mean, I know there's this issue with sage math being essentially very difficult to package. I don't yet understand all the details. And I guess Rogerio's not here. But he's kind of the point person on this. OK, maybe we'll have an offline discussion or maybe we'll have a sage math specific thing when we track Rogerio down. Are there other? I mean, I can talk about sort of systematic things, packaging software for DBN. But I mean, from a user perspective, are there things that you wish were in DBN and aren't or it's not, DBN's not keeping up. OK, DBN's never really keeping up if you're looking at stable. Do we have any good meta packages? Sylvester, maybe we do. In fact, Andrea's style. I've been working on Debian blends. I don't know if you're familiar with it. I'm going to talk quickly about that this afternoon. But it is basically a kind of meta package in various scientific fields. So you've got mathematics, you've got engineering, physics, and so on. And this is a meta package which we try to reference all the package we've got in the archive or the one we want to package. So yeah, we've got that. Do you have anything? Can you use the mic? Sorry, I know it's a bit. You're a star. I would also be interested in something like knowing about an optimization package, like constraint optimization, non-linear optimization if anyone has experience with such kind of stuff. Linear optimization, we have GLPK, which I find to be a nice trade-off between sort of light weight and working quite well. Sorin, somebody has also been working on getting the coin OR packages. So IBM has been funding promoting this. I think we've got a few of coins into the archive, not all of them, because it's pretty long to package. Coin is almost its own distribution kind of thing. They have a lot of packages. But I would say if you look at the coin site and you see stuff there, I mean, the longest, there was some uncertainty about licensing for a while, but that seems to be okay now. And so I think if you look for coin-OR, and I know there's non-linear stuff there as well, which may not be packaged in Debian yet, but I would file a request for package and maybe CC the maintainer of the other coin packages. And I think it's at least possible that you get some positive response there. Like the closest I was able to find is like GLPK and GSL, like the GNU scientific library. They have some routines for non-linear optimization, but not like again, very extensive. Yeah. It's a bit of a, I mean, I don't know, is anybody here really a non-linear optimization expert? It seems to be a bit of a black art. There is also Python Open OPT, which provides all kinds of built-in optimizers, linear and non-linear, but also interfaces to many more, even commercial ones. Right. So it's within kind of unified interfaces. So if you're in Python world, you might try that one. Sure. Thanks. Can we take the mic to the back? Can we take the mic to the back? Now, if you're visiting Debian, do you have a number? You mentioned coin, you mentioned coin, there was also a couple, there's a simplex solver. Oh, there's LP OPT as well, I think. Yeah, what is it? LP solve. LP solve. LP solve. Which is also seems to be, I mean. That's MIT or something like that. I haven't solved huge problems with it. What? I haven't solved huge problems with it, but it seems, I would say it's definitely usable for teaching and for. I actually use it in like my day job. Okay, great. And if anybody's interested in a Ruby interface for that, I have that. I'm sure somebody is. You have that meaning, is it open source? Is it in Debian? Okay, I tried to get it back into the, whatever it was, the LP solve base. And I got a little bit of resistance there. So it's nowhere. It's just, it isn't publicly available yet. A company I'm working for is going out of business, so I'll probably put it. Out there. One of the things that I found cool about it as a, just using it. I mean, okay, so a little bit more. I actually, what I use this for is to solve network flow. Okay, with additional constraints. And so this was really, it's really used inside of a Ruby Rails application. And one of the cool things about that in particular is you can solve something. Change, you know, change the equations and all that and continue right from where you left. It'll take the last solution that you had and use that as the starting set. And it may have to throw out certain constraints because they're now violated in your new situation. But there is a Python interface, but I have a Ruby interface which I like better because it's more object-oriented. The Python, you know, so it was originally a C library and so there are a million C calls. And the Python, and there's also C++, they both were just front ends to the C. But then what I did was I actually used, created an object and methods in those objects and things like that. But I'll contact, if anybody is interested in it, contact me in probably about six months, I'll just put it up. Can you tell me your name? Rockyganu.org. Rockyganu? At. Ah, okay, that's not so hard. Ganu.org. Okay, so Ruby bindings for LPSol. Right. Okay, great. Thanks, I'm kind of doing some advertising for my software, but we've got some experts in this field in the Sylab team, so we've got something like 10 or 20 extension. We've got our own packaging system, but I am happy also to package some Sylab module into DBN. Just send me an email, I can package them. I've got direct access to the core developer. So that's pretty, and we've got some interface with LPSol, I'm sure Octave got it too. So that's, would you mind giving us a two minute sales pitch for Sylab? I think it's underappreciated. Yeah, it's not a clone of Matlab, but we are reaching the same target, and basically the sources, the very whole sources of Sylab are the same as Matlab when it used to be open source in the public domain. So basically Sylab is a numerical computing software, so you can do matrix computation, optimization, but you've got visualization, advanced visualization, with it, the data visualization. You've got also a kind of simulink, which is called XCOS, which allows you to do some simulations and some control, so you can do some real time and so on with it. So it is a big software. It is financed by, it used to be financed by Zinria, the French research institute in France, close to Versailles. Now we are starting to be leaving Zinria, and we are about 15 to 20 people working on the daily basis on Sylab. So we are open source. We used to be half free, semi free, because we had a crappy license, but we switched for the CECI license, which is basically a GPL compatible. It's a French one, license, but you can use it everywhere. So we are not like Octave, we are not trying to reach a full compatibility with Matlab. We are using the good idea, but when they are doing crappy things, which is pretty common, we decide to change it and to use it a better way. At least we believe. So I think that's what discouraged some people was the licensing for a while. But we are in the archive now. I have two questions from the RISC. The first one is, how many copies of minimization algorithms do we have in the archive, and how many more do we want? Do we just keep packaging everything we find? It's true, that's the general philosophy of Debian, but we could. So I assume, can you ask the questioner if they mean linear constraint? Minimization? Or maybe they're watching the video stream so that they can get the question. The question was made by Demir. I think it's a good question. I think that some of these packages are not hard to maintain, and some of them are. So I think that GLPK and LP-Solve don't put too much load on us as maintainers. And so one of the problems that I had with LP-Solve in particular was I just wanted to put like a auto comp style configure there. And I think there was maybe some conflict, and there's a maintainer and sort of like the guy who writes the code, and neither one of them actually believe in testing. So they take the kind of view that users will sort of find errors. And if you're doing this, if you're a business or something like that, you can't have this kind of thing that, that when a new release comes out, you discover bugs. And so a number of people, if you follow the LP-Solve forums, they don't upgrade to new releases because they don't want to be the ones to discover problems. And the ones that do are kind of annoyed that they are discovering problems. So I don't know if I have the latest bindings, for example, the latest LP-Solve, okay? But I also have a package, something that you can just like make config, you type configure make, make install, make test, or something like that. Maybe I can ask the questioner, how many bugs do we have outstanding on LP-Solve and GLPK? I mean, for me, if we have packages in the archive that are piling up bugs and they're under maintained and they're serving essentially the same clientele. I mean, I think that, I mean, unfortunately the APIs are different, but I think those two packages in particular really are serving the same purpose. Then that's a problem we should think about, whether we should concentrate our effort. Okay, well, the questioner didn't answer. Yeah, but as soon as he does, and but there's another question. Well, he has just said, it's also about whether to go out and package the next library that might be useful. I'm not sure I understand the question. Maybe somebody else wants to jump in, Adam. This may be related to the previous question that these new libraries, new software comes up and do we just want to package all of it and is it useful for people? And I guess this is the same thing that we have for 10 different linear algebra libraries and for that matter, multiple web browsers and desktop environments, et cetera. I think something that we have the opportunity to do in mathematical software perhaps, at least where there are somewhat standardized pieces that one can put together is to not just package things, but to takes a lot of effort, but to write or at least start writing some middleware that aggregates a lot of them so that one can then use front ends that can hook into a lot of these different ones. And so linear algebra is an example where there are no standard interfaces or storage formats for sparse matrices. There's some pretty common things that you have to do in storing sparse matrix, but different libraries do it different ways. But then there's this Petsy library, which connects to about eight different ones and presents a fairly standard API to an application that lets you choose whether you want spools or I don't go to conferences often so I don't know if they're standard pronunciations, but UMF pack or a Scala pack or other back ends that you can hook into. So this is something that I don't know if they're, again, they're similar straightforward APIs one can write for optimization software whether linear or nonlinear, but this is an opportunity that we have in something like Debian where we have so many packages and we can then choose on a, if not run time, then at least compile time basis what we wanna use and the best features in each one. So the risk of putting my own thoughts into things, I would say the question is the usual question that gets asked in Debian, which is are we expending our effort wisely? My impression is that in the scientific area, it's less of a problem people packaging the latest cool thing because, I'll just face it, the latest Fortran library for LU decomposition is not cool, right? I mean, and so my impression and I welcome other people's opinions on this is that most of us are packaging things for our work or for our users' work and I know my own error is that sometimes I start packaging things too early. I mean, I need something for a project and the first thing I do is make a Debian package. I know CJ approves of this mode, but I mean, then I don't end up uploading it, right? Cause I discover it's no good. So, but I think my impression is that as a group we're less guilty of this than saying the desktop widgets or other more sort of hobby driven, sorry, I don't wanna, so I hope everybody takes that in the right way, right? I mean, maybe people are doing this stuff as their hobby as well and that's what drives them to work on R or MATLAB or whatever, but somehow it's not something you kick around with the other kids in your CS201 class and say, hey, look, this is great new dropping bricks game that we should package. People disagree? Am I being too smug? I think it's always better if it's integrated with Sylab or SageMath or Maxima and you know, but people always wanna write libraries in their favorite tool and you know, it's maybe easier to write something yourself and if one of those tools is out there, it might, it would be ideal if someone would wrap it into one of the bigger packages, but you know, the people doing it are different and so it's not, it doesn't always happen. Well, may I suggest that we move the discussion to the afternoon session, because actually this is nothing to do with mathematical software and Debian, it's more scientific software and Debian in general. I think that- So maybe other people would be- That's a good point and it's also the kind of team management issue that I think the afternoon session has more focus on. So that's fine for me, yeah. Just one more question from Annas, I think. Sorry, do you think a Debian mathematics blend would find enough supporters? Okay, so this also I think is a good question to talk about this afternoon, but I'll give a short answer, which I think is not yet, because I think that the Debian science blend needs to be rolling first and if we can't get enough users for Debian science, then it's foolish to split in some sense. But is there already a task page? Is there a task page on Debian science blend? Yes, there is. Oh, okay. So this last question was from Andres Thiel. Andres, we're talking about your stuff. But then where's the threshold to come up with a blend, a separate blend? I mean, the major point in having a blend is that you do not have to do something else, right? You mean pieces of additional information that glues things together, right? And so what would you achieve by doing something separate for mathematics packages than what you would do for any other scientific field or science as a whole? So what I've heard articulated in this room today is people's conception of mathematical software being closely tied to my conception of scientific computing and numerical software. And I think that is, that's at the heart of the Debian science effort. So it may be a question of naming, I don't know. We have these ongoing debates, which again we can pick up later. Yeah, I agree. But so there is a task for mathematics and having a separate, I mean, this is math is only an example, right? The discussion is valid for any other field too. But do people believe that coming up with a separate blend actually increases visibility enough to be worth the effort? And that should be the goal, right? You need to have more people to package even more duplicates of more algorithms and figure out that there are actually duplicates, right? So you need to have people that take a close look and if you are one guy that packages everything, then you won't have the time, right? You do it for the first 10, maybe 20 packages and then you need to give up at some point. And so is creating a separate blend as opposed to just maintain a task within the blend, the major different thing to do that yields something that is worth doing it? I think that someone else will have to advocate that because for me, I'm not, I'm unfortunately not the user that the effort targets. I mean, I'm building my own packages and using my own packages and not using the mathematics task, right? Because for me, I mean, the point of the mathematics task as I understand it is I'm gonna sit down at this machine and install a bunch of things so that most of the tools I need will be there. And that's not really the way I use Debian. I used AppCache for that question. I mean, I don't, the distinction between installed on my machine and available in the archive is smaller. I think a useful thing that a task can do is help people find things, right? And so maybe we should think about it. Are we, I mean, it's documenting as much as anything else. What's somehow making it a bit more clear, the kind of tagging. I have one more comment from Andres that's a remark. The threshold for a blend is to have enough people who are doing the work. Right. And so we'll see if we have reached that threshold for the science blend, I guess. I just want to make a brief comment about this granularity thing. Like one of the things that attracted me to Debian in the beginning is you have like one mailing list like called Debian user. You have a problem with Debian and you're using Debian like you go and ask there. You don't need to think twice about like whether to go to this mailing list or whether to ask this guy. So it would be like nice to have like instead of having like, you know, like, okay, so there are five users, let me create like a group for it. And there are three users, let me create a group for it. And like there'll be another user who doesn't know where to ask, like whether to ask his question, like in the first group or in the second group or whether to create a third group altogether. Like, so I think it would be like, you know, I don't know like, but it would be better to have like just a wholesome group where you have a question related to something related to science. You go and ask there. I don't know, like I think that will be a better way to develop like the user base and like the applications, just my opinion. So I can respond to that in two different ways. I guess the direct answer to your question is there's a mailing list Debian Science which is friendly to both packaging and support questions. I think that everybody who's on the list would welcome users of scientific software in Debian to come there. So that, does that answer your question? So for example, like say a user using like, I mean doing research in physics might have a question with LAPAC. Then he doesn't know whether like, you know, like whether it falls in the mathematics group expertise or whether it falls in the physics group. Right. Or like, you know, I mean. So this is an argument against further specialization. Like I think it's better to have a bigger group than like having smaller groups, but a lot of them. Somebody pass Adam the mic. Thanks. I guess the difficult thing about Debian user of course is the bandwidth that is just lots and lots of messages but I don't think, I don't feel, I don't know if I think anyone here feels overwhelmed by the traffic on Debian Science. Yeah, that's true. Adding a mathematics to it, I think, or having mathematics in its scope but it is not a problem. So that's how I would decide on when to break it up. Plus there are bad people like me who read Debian Science and don't read Debian user. It's always better to have general purpose software and to integrate lots of stuff. But most people for reasons that I abhor are led to specialization and more specialization and they often just have one thing to do. We need more people who are able in their jobs and school to be more comprehensive and integrative and pull in all these different algorithms and libraries and components into larger. It just, the way of the world is that that comprehensive integrative approach is less common and it inherently always happens second. First you have 50 little pieces and then someone says this is great, I'm gonna integrate them but it's always, we always need more people doing integration work because the fragmentation to specialization happens first and most people's jobs encourages it and your boss doesn't give you enough time to integrate it with Maxima or SageMath or SyLab. So just a reality check. I would like a slightly contrary view which is that any time you're gonna put a lot of effort into integration, you better be ready to put twice as much effort into testing because you'll break things. So it's harder as well as on the tail end. If anyone else, but I'd like to talk about SageMath for a few minutes is now time or you're the moderator? I think so, sure. I guess it's an important issue for us to think about it. At the moment it doesn't look like it will be in squeeze. That's where we stand. So I mean it's gonna need some heroic efforts by people who care about this integrated. I mean SageMath is somehow the ultimate integrated math package, right? I mean I think almost everything we mentioned today is glued together by SageMath. Are you a SageMath user? Yeah? Very lightly, but would like to be more. Yeah, I had a look quickly a few months ago and if I understand correctly, they are merging everything so you need basically many dependency to be packaged before being able to have SageMath into the archive. And moreover, the main issue is that you have to follow the exact same version. So for example, if you got version X of SageMath, you will need version 5.2.1 of style app, for example, which makes very hard for the packageer to package SageMath because you have to follow pretty much the exact same version of the dependencies they are using in their distribution. And it is very hard to package for this because if they are not following the same way as we do in Debian, it will be hard to update SageMath for the library we are using into the archive. So I think it's a very big package, very hard to package also. I've been updating, I've been looking at the Wikipedia page updating things and haven't gotten nitty-gritty into it. But I'm 98% sure that every dependency is already in Debian. Now, you raised an excellent issue about the versioning and the versioning might kill us. It is killing us. I don't know if you saw the email going on the mailing list, but upstream is not very happy about the way we used to package SageMath. So I don't think they will be very helpful in this work. They say we don't want, basically they say we don't want SageMath into the archive of Debian. There is this meme that upstream isn't very happy. But what is upstream not happy about? The messages I've seen are not specific. And my guess is they're unhappy that the 3.0 version of SageMath that's in unstable is ancient compared to 4.4.4 and horribly buggy, which is why it's not in testing and why it probably should just be removed from the archive. It's not clear to me if upstream has split the hair. Oh, we don't want anything that diverges even a little bit from the current. We don't want distributors taking this up, or if more what they're unhappy with is just that the package produced a couple years ago is so bad and outdated. Maybe they're not familiar with the way we package software into distributions. I could maybe. It's not even a question, a comment. Actually, SageMath brings a good lesson, I think, or how these integrative software should be working together. We are Debian developers. We interact with upstream for us. Those little projects which gets incorporated into Sage, I bet they're fascinated by this fact in terms that they become popular because Sage uses them. And I'm not sure what Sage kind of opinion about those little projects is. So I think it's just a matter of communication and organizing the workflow so all parties participate in this project, which is starting from little projects, SageMath, and then Debian developers. That they just coordinate this effort to leap forward. I bet Sage is not interested to carry buggy version of some dependency all along, right? They are just not. On the other hand, SageMath provides probably nice testing framework for all those little projects in terms. Even I believe SimPy is used for unit testing of NumPy or something like that because it stresses it so much so it catches all the bugs. So there are multiple benefits and it's just lack of coordination, I think, which is kind of demolishing for all the projects. Little one, Sage and Debian. So I think it just should be some common effort. I had a thought. I mean, I think there's something which is, I've experienced in other projects with mathematical software is that they love convenience copies of code. They don't think it's a bad thing. They think it's a good thing. And their way of doing development is to take snapshots of other people's code and integrate it into their source tree and ship it. And so from their point of view, what Debian is doing is butchering their source tree, right? And trying to replace it with other, I mean, if you've been on hash Debian and you see the response to somebody who says, well, I replaced this Debian package with one from Ubuntu and you see the friendly reception they get. Oh, I can suppose leaving aside any Ubuntu hostility. I mean, I replaced this package in Debian with this thing from somewhere else. So although I don't agree with their point of view, I get a bit where they're coming from that they say they feel like we're breaking their software and making them look bad. And so although we don't feel that way, we should try and see their, I mean, we're never gonna resolve this conflict unless we understand what their objection is. And probably asking somebody would be way better than me speculating, but. I was talking with the project leader of Sage at EuroCypie a couple of weeks ago and actually the main problem is that they want to be platform independent. So Sage needs to work under Windows, for example, where you don't have a package manager. So you need to ship all the dependencies if you don't want people to go and download the stuff and install by hand. So they have good reasons to do what they do. And I even agree that it's much better as a user to have just a package that you download and everything works out of the box and you have to care about dependencies. And unfortunately, I have to say the word is not Debian. I mean, most of the users of Sage are not Debian user? Not yet. Not yet? Well, and okay, and another thing is that because their release cycle is pretty tight, so they have a lot of people working on Sage so they continuously fix bugs and release new versions. They of course don't like the idea that all Debian users are stuck with a particular version of Sage. So and this is the fate of every Debian package somehow. But for Sage, which is a relatively young package and really active. I mean, I see why they don't want it in Debian. And I am not sure if we should make an effort right now to have Sage in Debian as a Debian package, knowing that in three months, the Sage that is available from the website which will be much better, much less buggy. We'll have more dependencies. Well, the trade off is that to be a Sage user, according to the Sage way, you need to be able to build it and build all the dependencies. And that is not real. I don't know how hard that is, but I'm guessing for the average user of Sage, that's a challenge. Well, they offer binary packages, right? Don't they? Okay. He's saying it's less of a challenge when you use all of the upstream sources that are already packaged in the Sage source tree so you just compile and it does them all for you. And compiler versions. And it's not all Python, right? I mean, it's C++ and Fortran and Lisp, and I mean, it takes most of Debian to... No, I'm exaggerating, but you know what I mean. There's a lot there. You need five different language systems at least to build SageBath, and most people don't have those development tools. So I think the answer is they use the binary packages, is the, so I don't know the answer and to be honest, I'm one of these specialists that, I mean, I have, I don't use Sage because I use the tools that it glues together and so far I haven't needed, I mean, I already know it would be more work for me to learn how to use Sage because I already know how to use these other tools. I'm not saying there's anything wrong with this project. It's just I'm not motivated to push it myself. Well, of course, the people who are motivated will have to do it. I think, you know, if Sage were in Debian, we would end up with two or three versions. We'd end up with a version in stable which will be admittedly by the end of the cycle old. But then there'll be the version in unstable which if the maintainer is good will be relatively up to date, maybe not every three months, every six months or something. And via back ports that should be available to the, you know, people using stable. So maybe it's just an education effort we need to do with the maintainer upstream. Yeah, we're gonna have an old version but we'll take care of that and through back ports a new version will be available to everyone. And, you know, can we work together to iron out some of these versioning issues? Handling the version dependencies, I think that's the biggest hurdle I see. The license allows us to just fork it. I mean, we can just pack it. We don't need their permission. But does anyone see how to handle the version dependency problem? I think upstream might have different perception of the version dependencies than we have, right? And you have, if you package some software X and it has a bug and then it gets fixed in the Debian package and it gets fixed in the next upstream release, then upstream depends on the upstream fixed version, although we could have a much lesser dependency because we already fixed it earlier in Debian in the package. So those dependencies actually do not necessarily correspond to each other. And in my perception, the only way to get back ports correctly, because if you back port Sage from unstable to stable, you pretty much need to back port all of Python, at least, right? That's just about a thousand packages. So that's possible but unlikely. And so a much better way would be to have, and we'll probably discuss about this later on, is a framework where we can actually say that Sage is working with the versions and the compiler versions that we actually used in stable, in a back port. So it needs a proper regression test suite and that needs to be provided by upstream. And they will have that, otherwise they wouldn't say that we need this and that. They need to figure it out somehow. They might not have it in a way that we can use it. Because most of the tests, we cannot even run when the package gets built. So it needs something in addition to unit tests, and which is not there. But I think verifying that it works as intended is better than verifying that we have the version dependencies that upstream thinks we should have, which is not necessarily easier, of course. Excellent point. So we have five minutes left, according to our very generous talkmeister. So, my stress. So, we can certainly keep talking about Sage. I think it's a long-term project, and I know there's a mailing list, the package Sage develop or something on Elliott, isn't there? If there isn't, there can be. I guess the problem is the current Sage maintainer is not interested in doing it anymore? That's my impression. He's too busy. He's got a day job now. As some of us do, sadly. It's orphaned as far as I can tell. Essentially Sage is orphaned. So, you know, it's gonna need, I think it needs somebody who is involved with the upstream project and wants to see it in Debbie, who can really talk to people upstream and understand what's going on there. So, we can keep hammering at that for the three minutes that I left you, or is there anything else anybody wants to, a different topic anybody wants to pull in before we wrap up? I managed to kill that discussion pretty well. Okay, so carry on. Well, then the other approach to dependencies, version dependencies would be sort of like we've done with Python and others is to maintain two versions of some libraries, the version that Sage needs and maybe the latest. So, you know, and so obviously we'd have to decide. I like your idea, but whenever the API changes, my understanding of Sage is that it's Python glue to these C or Lisp or whatever the upstream that it's incorporating is. So, if the upstream changes in API, it's going to break and it's gonna be impossible to support. We would have to fork those libraries and support two versions or work with the Debian maintainer for those libraries and say, like with GCC, we pick a version and that's the release for squeeze or squeeze plus one or whatever. Quick resolution would be to bend, not bend even, Debian policy says that we should not provide copies of the software in other packages. It's not must not, right? So we could come up maybe with minimal set of packages which we really need these old versions in Sage to make it work and they will not be system wide available, they would just be part of the Sage. And that would provide simple solution and just those which we can rely upon fresh versions in Sage but that would depend on proper testing even with Sage what was, there were not that many bugs filed against Sage math I believe but then at some point I had to get new version of networks in Debian and I discovered that version which is in the Debian, it's already not working with Sage math so and it wasn't picked up because we don't have those tests and Python is really fragile in that sense, it's scripting language, right? Unless we provide good coverage of just somehow sweep through the package to run all the code we cannot be sure that it's workable and for that we need regression tests but shipping those buggy ones versions that might be. I think this is the last comment to make it clear. Yeah, I think you'll find that Sage because it's an agglomeration of multiple tools just glued together with Python. Very likely any particular version of it requires multiple versions of the libraries because the tools that it glued together use different versions. Okay, well thank you all and big thanks to the video team for helping us out here. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.