Re: Axiom FTBFS on sparc
David Bremner [EMAIL PROTECTED] writes: At 11 Nov 2008 12:40:02 +, Chris Walker wrote: I've just tried to build axiom on sparc on a lenny system- and get exactly the same build error. It builds fine on an i386 system. Unfortunately I suspect that to track this down needs someone with a good understanding of GCL and access to a sparc. A friend of mine has offered access to a sparc for this sort of thing in the past. Anyone with a good understanding of GCL feel this is important to them? [ forking discussion snipped ] So is axiom maintained upstream, or should the Debian package be replaced by one or both of OpenAxiom or FriCAS - and is there a comparison between the two? I don't know about what among the three is the best option, but it looks like axiom continues to release as well: http://article.gmane.org/gmane.comp.mathematics.axiom.devel/19751 Sorry if this is obvious, but I doubt very much that the release managers will allow a new upstream release or fork into Lenny at this point. I did know - but it does bear repeating. Partly I was wondering if it was worth spending time on an old version of the package, and partly I was hoping that the bug fix might be easy to port from the most recent version of axiom. The question now is should we spend the effort trying to fix the bug and get the package into lenny, or should we ask the release team to remove the package from lenny and try to do better next time? Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcement: New bugs pages, status of renaming
Andreas Tille [EMAIL PROTECTED] writes: Ahh, yes. This is definitely planed. I also wanted to link from the tasks pages to the bugs pages somehow indicating the bug status as well. But I wanted to gather some comments on my estimation of the status first. I really like the idea - so here are my comments: The biology status doesn't take into account the bugs in the two metapackages it depends on (though how you'd do this, I'm not quite sure). As we've said in private e-mail, absolute bug counts are a measure of help required, whereas quality would best be measured by normalising to number of packages. I think you've made the right choice here. You might also want to ignore, or reduce the weight of bugs under a certain age - perhaps an absolute cut off of 28 days, or perhaps a sliding scale depending upon severity - with critical bugs becoming important immediately. This might not be worth the effort of implementing though. With the exception of Mathematics-dev and biology, all the tasks have the red status, and biology would too if it reflected the state of the underlying tasks. I think therfore you're too harsh - and should make it easier to obtain satisfactory status (but if/when we get good at fixing bugs you could change it). I don't think you should give different severities the same score - as you do for critical grave and serious, but I'm not sure I can come up with a better set of numbers than you have. Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: yacas and Mathematics task
On Wed, 12 Nov 2008, Jordi Gutiérrez Hermoso wrote: It is, however, mathematical software, marginally useful, and it doesn't have a large footprint, so I wouldn't mind having it as a mathematics task (this is tasksel we're talking about, right?). I think we talk about integration into the tasks/mathematics file of the debian-science source package. Besides other things this information will propagate to a debian-science tasksel file, but it also will become a dependency inside the science-mathematics metapackage and will be incorporated in the tasks and bugs pages (which I talked about in the latest announcement). So considering your evaluation I would vote for a Suggests inside the tasks file. Kind regards Andreas. -- http://fam-tille.de
