Hi Dirk, On Thu, May 12, 2005 at 08:39:18PM -0500, Dirk Eddelbuettel wrote: > My QuantLib packages in testing are in an inconsistent state: > Name testing unstable > ---------------------------------------------------------- > quantlib 0.3.8.rc.20050412-1 0.3.9-1 > quantlib-python 0.3.8-2 0.3.9-1 > quantlib-refman 0.3.8-1 0.3.9-1 > quantlib-refman-html 0.3.8-1 0.3.9-1 > quantlib-ruby 0.3.8-1 0.3.9-1 > Here QuantLib is the binary library, -ruby and -python depend on it. > We now have a pre-relesae of 0.3.9 in testing which is __incompatible__ with > the quantlib-ruby and quantlib-python versions in testing as the API still > changes between releases. > I would suggest to move the whole 0.3.9 block into testing once the ten day > window is up. The packages are all bug-free and "mostly" built. We currently > lack a) a few m68k builds and b) quantlib-python on mipsel . For m68k, Rick > Younie and I hashed out that we should stop providing QuantLib. For mipsel, > I wish we could agree on the same -- the build simply timed out after 150 > mins in the heavy C++ template code (which would have completed). However, I > think mipsel wasn't part of the previous release and is generally behind as > per > http://packages.debian.org/cgi-bin/search_packages.pl?keywords=quantlib-python&searchon=names&subword=1&version=all&release=all > so maybe we can overlook this as a showstopper? > Lastly, and for completeness r-cran-rquantlib 0.1.12 is the only other > dependency of QuantLib, and it could be pulled in too. > Please email back if there are questions. No questions; however, to get these packages in, you'll need to follow through on this agreement with Rick regarding m68k quantlib binaries, and get them removed from the archive. As the maintainer, please file a bug against ftp.debian.org asking for the m68k binaries to be removed from unstable for libquantlib0, libquantlib0-dev, quantlib-examples, quantlib-ruby, quantlib-python, and r-cran-rquantlib. (If you are not actually the maintainer of all of these packages, the ftpmasters may ask for you to consult with the other maintainers as well.) The quantlib-python problem on mipsel shouldn't block getting these other packages in since it's a problem that already affects testing (as we've discussed), but we should still try to get it resolved before release. It would be a dubious honor for quantlib-python to be the only package that ships in sarge with an out-of-date per-arch binary. :) Anyway, the changes for quantlib itself are trivial, and as discussed previously, quantlib-ruby and quantlib-python need to be brought up-to-date to fix a FTBFS problem, so those updates are all ok. Does the same build problem apply to quantlib-refman and quantlib-refman-html? If not, I don't think we'll want to update those if it's not necessary. Likewise, it doesn't sound like r-cran-rquantlib needs updating. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature