On 13 May 2005 at 16:31, Steve Langasek wrote: | 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.)
Done! | 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. :) I'll email the mipsel folks and tell them :) | 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 Those are binary all, and they don't really "build". I just re-wrap the upstream tarball of html files (from doxygen) and the pdf file for these two. | think we'll want to update those if it's not necessary. Likewise, it | doesn't sound like r-cran-rquantlib needs updating. Well yes -- 0.1.11 corresponded to the 0.3.8 we are replacing in testing. So 0.1.12 would make more sense. Thanks as always for all that! Dirk -- An economist is an expert who will know tomorrow why the things he predicted yesterday didn't happen today. -- Laurence J. Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
