Re: introduction of Knoppix-math : proposal for collaboration
Hello Hideki-sama, Was anyone else able to access ftp://fun.sci.fukuoka-u.ac.jp/pub/ ? I had a quick look through the site -- is there anywhere where you have existing debian packages that might need porting? I was unable to locate any debian source packages from my brief look. Thanks. --- On Sun, 9/12/10, Hideki Yamane henr...@debian.or.jp wrote: From: Hideki Yamane henr...@debian.or.jp Subject: introduction of Knoppix-math : proposal for collaboration To: debian-science@lists.debian.org, ham...@fukuoka-u.ac.jp Cc: henr...@debian.or.jp Date: Sunday, September 12, 2010, 12:56 PM Hi, I met debian-based derivative Knoppix-math(*) folks at Open Source Conference Tokyo, Japan. I hear they pressed their CD/DVD a lot (more than thousands) and distributed those at some mathematical conference. However, some of the package in their pressed LiveCD are packaged and maintained by themselves but have not enough manpower for maintenance and update (Also, one important software is not DFSG-free, but they cannot negotiate with upstream because of lack of human resources). *) http://knoppix-math.org/ I know there are guys who are working on this scientific package area - So, I hope Debian and knoppix-math collaborate with that - take packages from Knoppix-math to Debian itself and co-maintain it, think about license issue, improving their distribution with using Debian-live. How about this? :) I'm not sure about scientific applications but I can help with some packaging issue. Hamada-san, could please introduce yourself and Knoppix-math? I think we Debian can do some help for you. -- Regards, Hideki Yamane henrich @ debian.or.jp/org http://wiki.debian.org/HidekiYamane -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100912095651.611af3c6.henr...@debian.or.jp -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/158802.71420...@web110411.mail.gq1.yahoo.com
backports
Hello, how do you feel towards the idea that with the advent of backports as an official service of the distribution, we should use that in routine for the more frequently updated tools? In science, there is rarely (i.e. except for comparisons or for continuity) the need to use an older version, and then snapshot.debian.org comes to a rescue. And then there are these annoying cases when a new upstream release just fails to miss the freeze. Prime candidates IMHO are the autodocktools, gromacs, ... well ... almost anything in debian-science and debian-med, really. I would then even opt to take the autodocktools out of the main distribution towards an appearance in backports and testing only. Comments welcome. Best, Steffen -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c8d2548.2080...@gmx.de
Re: backports
imho all sounds great and had been our approach for non-official neuro.debian.net. 0.1cents in a form of aspects I think it might be worth keeping in mind: * backports friendly packaging do not overcome insufficiencies of *Depends versions specifications with strict limitations without necessity * convenient (transparent) backporting straightforward tools nd_backport and nd_build4allnd [1] Michael wrote for our use were sufficient so far in most of the cases to provide backports for majority of Debian and Ubuntu releases * distribution specific patchsets sometimes transparent backporting is not feasable without patching, so enabling distribution specific patch series should be provided. See backport-dsc from the same repo * testing important fact, often disregarded -- Scientific software, as nothing else, is in need of unit- and regression testing. Back- (or forward-porting for a distribution which might be slightly ahead, e.g. upcoming Ubuntu new release) ported software might not have higher chance to lead to incorrect behavior due to various factors... at least partially to prevent that -- testing during package building seems to be of great help and should be encouraged (if not enforced) [1] http://git.debian.org/?p=pkg-exppsy/neurodebian.git;a=tree;f=tools;hb=HEAD On Sun, 12 Sep 2010, Steffen Möller wrote: Hello, how do you feel towards the idea that with the advent of backports as an official service of the distribution, we should use that in routine for the more frequently updated tools? In science, there is rarely (i.e. except for comparisons or for continuity) the need to use an older version, and then snapshot.debian.org comes to a rescue. And then there are these annoying cases when a new upstream release just fails to miss the freeze. Prime candidates IMHO are the autodocktools, gromacs, ... well ... almost anything in debian-science and debian-med, really. I would then even opt to take the autodocktools out of the main distribution towards an appearance in backports and testing only. Comments welcome. Best, Steffen -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100913002618.ge...@onerussian.com
