Re: Announcement: New bugs pages, status of renaming
Andreas Tille [EMAIL PROTECTED] writes: On Thu, 13 Nov 2008, Chris Walker wrote: 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. I do not think that the age of a bug should have an influence on the result. Open bugs are just open bugs and should be fixed. Help is needed for old and new bugs. That's true, though if the although a normal bug fixed The reason IYes, that's true. The rationale behind suggesting it was that it 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). Yes, I realised that my measure is quite harsh and I see the problem that if people who are willing to work on the bugs will not see any result on the status might loose interest. So we should take this serious. So if enybody wants to make suggestions on better limits for the assessments (see Legend on overview page) I keen on hearing this. After lenny is released would be a better time to tune the number - at the moment there is, quite rightly, some relectance to upload new packages. Moreover I wonder whether I should make theses limits configurable per Blend. There is a configuration file per Blend anyway - putting the limits there to adapt to the specific blend (metapackages with less dependencies will be easier to get into shape than those with more). That's probably a good idea. 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. I agraa this was a rough estimate for the first shot. I was guided by the fact that all of these three are release critical and so all of them should be fixxed immediately. That's true, but there is a difference between not meeting policy requirments and breaking the whole system and causing severe data loss. So what would be the proper score for even more immediately??? I did wonder about suggesting: AB C wishlist: 11 1 minor: 23 4 normal:49 16 important: 8 27 64 serious: 16 81256 grave:32 243 1024 critical: 64 729 4096 ie one normal bug is worth 2 (or 3, or 4) minor bugs, and so on. Chris PS if you added an orange level, you would have one more level to play with. I'm assuming here bug severity goes in the order of colours of the rainbow. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcement: New bugs pages, status of renaming
On Thu, 13 Nov 2008, Chris Walker wrote: That's true, though if the although a normal bug fixed The reason IYes, that's true. The rationale behind suggesting it was that it ... ups this paragraph is unfinished ... After lenny is released would be a better time to tune the number - at the moment there is, quite rightly, some relectance to upload new packages. This after lenny remark brings up another issue: The current bug pages do not respect any stable / frozen / testing / unstable differentiation. This might be interesting, but currently I do see more urgent problems to solve - feel free to spend some time on it if you regard this as an urgent problem. A bit more interesting might be to leave out bugs tagged wontfix (and it is simpler to implement). That's true, but there is a difference between not meeting policy requirments and breaking the whole system and causing severe data loss. Sure. I did wonder about suggesting: AB C wishlist: 11 1 minor: 23 4 normal:49 16 important: 8 27 64 serious: 16 81256 grave:32 243 1024 critical: 64 729 4096 ie one normal bug is worth 2 (or 3, or 4) minor bugs, and so on. Understand the principle. The much higher score of the critical ones also might reduce the influence of a lot of minor / normal bugs in a metapackage with much dependencies. Do you have any suggestions for the limits that fit these scores. PS if you added an orange level, you would have one more level to play with. I'm assuming here bug severity goes in the order of colours of the rainbow. Well, any volunteer to work on a proper css file. I wished some people would start working in SVN on this stuff. Testing is easy by just doing rsync -a alioth.debian.org:/var/lib/gforge/chroot/home/groups/cdd/htdocs . and you have your local copy of the result. Than you can play with the CSS file (which differentiates those bugs). Then you can check in the new css if you are happy about it. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: [Elmerdiscussion] Re: Debian package for Elmer - Re: ITP: Elmer -- Finite element software for multiphysics problems
Hi, The configure files are tuned by the authors with the -m64 compilation flag. I have made the package only available for the amd64 architectures. Migrating to different architectures and even to i386 means patching more the configure system and has to be checked with the authors. Ah, I didn't notice this, thanks for the heads-up. I'll make sure to take care of this before uploading. Actually the configure tries by default to figure out whether your current system is capable of 64 bit. You can force to drop the-m64 by using the configure option --with-64bits=no. Regards, Juha -- 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: On Thu, 13 Nov 2008, Chris Walker wrote: That's true, though if the although a normal bug fixed The reason IYes, that's true. The rationale behind suggesting it was that it ... ups this paragraph is unfinished ... What I meant to say is: As the aim of these pages is to encourage people to take an overview of where help is required, packages where the maintainer deals with bugs in a timely manner are much less in need of help than packages where the bugs have built up over time. But, as you say, a bug is a bug, so it's not clear how much advantage there is in implementing this. After lenny is released would be a better time to tune the number - at the moment there is, quite rightly, some relectance to upload new packages. This after lenny remark brings up another issue: The current bug pages do not respect any stable / frozen / testing / unstable differentiation. This might be interesting, but currently I do see more urgent problems to solve - feel free to spend some time on it if you regard this as an urgent problem. A bit more interesting might be to leave out bugs tagged wontfix (and it is simpler to implement). Yes, that makes sense. That's true, but there is a difference between not meeting policy requirments and breaking the whole system and causing severe data loss. Sure. I did wonder about suggesting: AB C wishlist: 11 1 minor: 23 4 normal:49 16 important: 8 27 64 serious: 16 81256 grave:32 243 1024 critical: 64 729 4096 ie one normal bug is worth 2 (or 3, or 4) minor bugs, and so on. Understand the principle. The much higher score of the critical ones also might reduce the influence of a lot of minor / normal bugs in a metapackage with much dependencies. Do you have any suggestions for the limits that fit these scores. An immediately attractive idea would be the value of one critical bug - in which case, suggestion B might be better than A. Then perhaps a linear spacing: red: 729 *4/4 (80+ normal bugs) yellow: 729*3/4 (60+ normal bugs) green: 729*2/4 (40+ normal bugs) blue: 729*1/4 (20+ normal bugs) but I haven't actually tried it to see if it would work. PS if you added an orange level, you would have one more level to play with. I'm assuming here bug severity goes in the order of colours of the rainbow. Well, any volunteer to work on a proper css file. I wished some people would start working in SVN on this stuff. Testing is easy by just doing rsync -a alioth.debian.org:/var/lib/gforge/chroot/home/groups/cdd/htdocs . and you have your local copy of the result. Than you can play with the CSS file (which differentiates those bugs). Then you can check in the new css if you are happy about it. I'll see if I can make time to have a look, but don't hold your breath. Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: yacas and Mathematics task
Jordi Gutiérrez Hermoso [EMAIL PROTECTED] writes: 2008/11/13 Chris Walker [EMAIL PROTECTED]: Alternatives packaged for Debian seem to be Maxima, axiom/openaxiom/FriCAS, sympy - any comments on these? I asked this in private e-mail rather than to the list. I find the answer really helpful and Jordi is happy for me to post it to the list. Maxima is probably the most mature of these... which isn't saying much, unfortunately. Maxima can often be coaxed to get you the answer you want for a large class of problems, but it can be maddeningly difficult to do so. A recent example is that Maxima won't give you the solution to something like sqrt(x-1) = x -3 in any obvious way unles you go ahead and square both sides yourself before feeding it to it. Yacas faces the same problem with this one! Axiom is also mature, but it seems to be almost completely abandoned! They released it, but nobody seems to be maintaining it -- while Maxima development which is fast-paced and active. I think Openaxiom is a fork to address this abandonment, but it doesn't seem to be very developed itself either! These comments are really useful. If I get time, I'll collate these and other comments and put them on the debian science wiki. I don't know about FriCAS or sympy. Ask someone else about those. Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian package for Elmer - Re: ITP: Elmer -- Finite element software for multiphysics problems
On Thu, 2008-11-13 at 08:05 -0500, Adam C Powell IV wrote: On Thu, 2008-11-13 at 09:55 +, Antonio Amorim wrote: Dear Colleagues, I have previously created a debian package for Elmer that does not claim to fulfill the official debian policies but might be useful to trigger the debian work. The package is available as source and for the amd64 architecture. It is available form the repositories: deb http://mirror.sim.ul.pt/debian-paipix etch main contrib non-free where one can replace deb by deb-src and etch by lenny or sid. In the backport to etch, I also backported libqt4 that is available from the same repository. The packages are elmerfem and elmerfem-doc. All packages are build under pbuilder so the dependencies should be Ok. Thank you. I'm afraid I'm already well-enough along that the only issue remaining is finding Scotch functions corresponding to METIS_MeshPartNodes and METIS_MeshPartDual. I'm in contact with upstream, which is helping with this (off-list). I've posted my first two versions 5.4.1-1 and 5.4.1.dfsg-1 at http://lyre.mit.edu/~powell/elmer/ . The former includes the full source, and works (as far as I can tell), but doesn't have the versioned shared library. The latter omits mathlibs, umfpack and elmergrid/src/metis, and has a complete copyright file for what's left, but ElmerGrid linking fails because of the missing Metis functions as mentioned. Both are supposedly in section contrib. The first should really be non-free because of the inclusion of Metis. I'm afraid I realized *after* putting a lot of time into this that neither one is acceptable to Debian, because Debian considers ARPACK to be non-free, and will almost certainly refuse to distribute a GPL program linked to a non-free library. The only two ways to get around this are: * Get the ARPACK people to drop the non-free requirements of their license (see http://bugs.debian.org/491794 ). * Change the license of Elmer either to something like LGPL or to grant an explicit GPL exception to link with ARPACK (and maybe Metis?). Both of these are, of course, beyond the scope of this maintainer... :-( In the meantime, feel free to enjoy and add to these two packages. I'd welcome any patches to improve them. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
RE: [Elmerdiscussion] Re: Debian package for Elmer - Re: ITP: Elmer -- Finite element software for multiphysics problems
Hello Adam, First of all, thank you for your effort, it is greatly appreciated. The only two ways to get around this are: * Get the ARPACK people to drop the non-free requirements of their license (see http://bugs.debian.org/491794 ). * Change the license of Elmer either to something like LGPL or to grant an explicit GPL exception to link with ARPACK (and maybe Metis?). Both of these are, of course, beyond the scope of this maintainer... :-( I do understand the problem, but could you please elaborate the Debian point of view? I think we are good wrt the licence of Arpack (we reproduce the copyright notice in the documentaion, at least, as required by Arpack license for binary distributions, as well as for source). LGPL for Elmer is unfortunately not possible at the moment, but an GLP exception might be taken under consideration. How would you like to see the exception be documented for being compatible with Debian policies? Regards, Mikko Lyly From: Adam C Powell IV [EMAIL PROTECTED] Sent: Thursday, November 13, 2008 10:10 PM To: debian-science@lists.debian.org Cc: [EMAIL PROTECTED] Subject: [Elmerdiscussion] Re: Debian package for Elmer - Re: ITP: Elmer -- Finite element software for multiphysics problems On Thu, 2008-11-13 at 08:05 -0500, Adam C Powell IV wrote: On Thu, 2008-11-13 at 09:55 +, Antonio Amorim wrote: Dear Colleagues, I have previously created a debian package for Elmer that does not claim to fulfill the official debian policies but might be useful to trigger the debian work. The package is available as source and for the amd64 architecture. It is available form the repositories: deb http://mirror.sim.ul.pt/debian-paipix etch main contrib non-free where one can replace deb by deb-src and etch by lenny or sid. In the backport to etch, I also backported libqt4 that is available from the same repository. The packages are elmerfem and elmerfem-doc. All packages are build under pbuilder so the dependencies should be Ok. Thank you. I'm afraid I'm already well-enough along that the only issue remaining is finding Scotch functions corresponding to METIS_MeshPartNodes and METIS_MeshPartDual. I'm in contact with upstream, which is helping with this (off-list). I've posted my first two versions 5.4.1-1 and 5.4.1.dfsg-1 at http://lyre.mit.edu/~powell/elmer/ . The former includes the full source, and works (as far as I can tell), but doesn't have the versioned shared library. The latter omits mathlibs, umfpack and elmergrid/src/metis, and has a complete copyright file for what's left, but ElmerGrid linking fails because of the missing Metis functions as mentioned. Both are supposedly in section contrib. The first should really be non-free because of the inclusion of Metis. I'm afraid I realized *after* putting a lot of time into this that neither one is acceptable to Debian, because Debian considers ARPACK to be non-free, and will almost certainly refuse to distribute a GPL program linked to a non-free library. The only two ways to get around this are: * Get the ARPACK people to drop the non-free requirements of their license (see http://bugs.debian.org/491794 ). * Change the license of Elmer either to something like LGPL or to grant an explicit GPL exception to link with ARPACK (and maybe Metis?). Both of these are, of course, beyond the scope of this maintainer... :-( In the meantime, feel free to enjoy and add to these two packages. I'd welcome any patches to improve them. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcement: New bugs pages, status of renaming
On Thu, 13 Nov 2008, Chris Walker wrote: I did wonder about suggesting: AB C wishlist: 11 1 minor: 23 4 normal:49 16 important: 8 27 64 serious: 16 81256 grave:32 243 1024 critical: 64 729 4096 ie one normal bug is worth 2 (or 3, or 4) minor bugs, and so on. An immediately attractive idea would be the value of one critical bug - in which case, suggestion B might be better than A. Then perhaps a linear spacing: red: 729 *4/4 (80+ normal bugs) yellow: 729*3/4 (60+ normal bugs) green: 729*2/4 (40+ normal bugs) blue: 729*1/4 (20+ normal bugs) but I haven't actually tried it to see if it would work. Well, it sounds reasonable to go with B because I have this additional feature that bugs in dependent packages are weighted three times higher than those that are only suggested. So a grave bug in a dependent package would score the same as a critical bug in a suggested package and we get color red for both cases. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
