New tarballs
Locked
 
|
Hi all,
I just uploaded into http://quantlib.org/gm the candidate tarballs for version 0.3.4 of the Python, Ruby, MzScheme and Guile modules, as well as a new tarball for the C++ version. Please play with themand report any problems. (Dirk: as for the new C++ tarball, it was just that some accessory files weren't included into the dist, so you might want to wait and see if anything else changes before going through the Debian thing with this one.) Later, Luigi |
|
|
On Thu, Nov 06, 2003 at 02:46:02PM +0100, Luigi Ballabio wrote:
> > Hi all, > I just uploaded into http://quantlib.org/gm the candidate > tarballs for version 0.3.4 of the Python, Ruby, MzScheme and Guile > modules, as well as a new tarball for the C++ version. Please play with > themand report any problems. Ok, will follow-up with python and ruby as usual. > (Dirk: as for the new C++ tarball, it was just that some accessory > files weren't included into the dist, so you might want to wait and see > if anything else changes before going through the Debian thing with > this one.) Hm can you be more specific? Either we need them or we don't. The build completed so they must have been truly accessory. Docs? Help files? But thanks for the heads. Will save me and the autobuilders some cpu cycles, and precents the bootstrapping problem of python + ruby having to depend on the new library. What is your sentiment about how good these 'gm' versions are? Are we close to a release? (I am trying to figure out if I have at least a remote chance of not needing to rerelease given the (arguable cosmetic) problem with the version number.) Ciao, Dirk -- Those are my principles, and if you don't like them... well, I have others. -- Groucho Marx |
|
|
On 2003.11.06 15:58, Dirk Eddelbuettel wrote:
> On Thu, Nov 06, 2003 at 02:46:02PM +0100, Luigi Ballabio wrote: > > (Dirk: as for the new C++ tarball, it was just that some accessory > > files weren't included into the dist, so you might want to wait and > see > > if anything else changes before going through the Debian thing with > > this one.) > > Hm can you be more specific? Either we need them or we don't. The > build > completed so they must have been truly accessory. Docs? Help files? Windows stuff. I guess it's accessory enough for a Debian build :) > What is your sentiment about how good these 'gm' versions are? Are we > close to a release? (I am trying to figure out if I have at least a > remote chance of not needing to rerelease given the (arguable > cosmetic) problem with the version number.) I think we're close enough. If all changes are as the latest ones, your binaries would be identical to the ones you created already. But one never knows... Later, Luigi |
|
|
In reply to this post by Dirk Eddelbuettel
Hi Dirk,
>Hm can you be more specific? Either we need them or we don't. The build >completed so they must have been truly accessory. Docs? Help files? One Borland make file and one Visual C++ project file were missing. Win32 only problem. That is, I would love the Debian distribution to include them too, but they are not really needed and cannot make any difference in the *nix builds. >What is your sentiment about how good these 'gm' versions are? Are we close >to a release? My bet is that the new 'gm' C++ tarball will be final, since everything worked fine on Unix and also on Win32 adding the 2 missing files: now they're included and this should be final. Just wait one/two days for the confirmation that everything is OK on Win32 before making it going through the Debian thing I haven't checked the SWIG stuff yet. ciao -- Nando |
|
|
Hi Nando
On Thu, Nov 06, 2003 at 04:16:35PM +0100, Ferdinando Ametrano wrote: > Hi Dirk, > > >Hm can you be more specific? Either we need them or we don't. The build > >completed so they must have been truly accessory. Docs? Help files? > > One Borland make file and one Visual C++ project file were missing. Win32 > only problem. That is, I would love the Debian distribution to include them Agreed in principle. Pristine upstream sources are a good thing. As I mentioned, I did make a slight mistake by calling it 0.3.4 in the first line of the changelog paragraph: quantlib (0.3.4-1) unstable; urgency=low * Upgraded to 'golden master' pre-release of 0.3.4 dated 2003-11-04 * debian/rules: Really make sure 'test' is run before 'install' -- Dirk Eddelbuettel <[hidden email]> Tue, 4 Nov 2003 16:35:15 -0600 but sort-of hedged this with the file date 2003-11-04 which would allow for a comparison if dates were to be considered too. > too, but they are not really needed and cannot make any difference in the > *nix builds. So it's a trade off. If we really feel that the tarballs must be identical, I do a new upload -- but then I must also use a higher number such as 0.3.4.1 or 0.3.4.final or whatever. As we'd trade one inconsistency for another, shall we agree to sit tight. Unless of course real bugs surface? > >What is your sentiment about how good these 'gm' versions are? Are we close > >to a release? > My bet is that the new 'gm' C++ tarball will be final, since everything > worked fine on Unix and also on Win32 adding the 2 missing files: now > they're included and this should be final. > Just wait one/two days for the confirmation that everything is OK on Win32 > before making it going through the Debian thing > > I haven't checked the SWIG stuff yet. I just uploaded the ql-python and ql-ruby packages. I'll pass on guile and mzscheme which are to esoteric for me :) Regards, Dirk -- Those are my principles, and if you don't like them... well, I have others. -- Groucho Marx |
|
|
Dirk:
>Agreed in principle. Pristine upstream sources are a good thing. > >As I mentioned, I did make a slight mistake by calling it 0.3.4 in the first >line of the changelog paragraph: >[...] >So it's a trade off. If we really feel that the tarballs must be identical, >I do a new upload -- but then I must also use a higher number such as >0.3.4.1 or 0.3.4.final or whatever. > >As we'd trade one inconsistency for another, shall we agree to sit tight. Today I fixed 3 more doc files, and at least one of them is relevant in my opinion: the list of copyright holder in the License. If everybody agree I would also fix 2 more minor issues: 1) remove the Intel OnTheEdgeRelease configuration (Marco: this is the last call ;-) 2) remove the 'typedef double Real' line in types.hpp, so to close the following bug report: http://sourceforge.net/tracker/index.php?func=detail&aid=824364&group_id=12740&atid=362740 As general cosideration on the release process, I noticed that the problems we usually have are about: 1) missing Win32 files in the tar.gz distribution 2) documentation updates The first point could be smoothed next time if I check Luigi's tarball before it is processed for Debian/RPM, the second one if everybody help revise the TXT files in the distribution and the first 50-60 pages of the doxygen documentation (in whatever format you prefer: pdf/ps/html/man/WinHelp) Of course it is of help to know as soon as possible if the build was ok with Debian on their multiple platforms, so we might assume that 2 rounds of Debian builds will be usual :) >I just uploaded the ql-python and ql-ruby packages. I'll pass on guile and >mzscheme which are to esoteric for me :) I checked QuantLib-Python and it works on Win32 QuantLib-Ruby 0.3.4 doesn't work, as it was for 0.3.3: Luigi, do you plan to investigate this for 0.3.4 or should we just take Ruby as a Unix only package? I haven't finished with QuantLib-MzScheme, but it should be ok ciao -- Nando |
|
|
Dirk,
I took a look at the Debian build logs and noticed that the test-suite is not executed, because the library cannot be linked. Luigi confirmed me that this is a problem he also has on any box which doesn't have a previous QuantLib installed. This was not a big issue for 0.3.3 since the test-suite was executed by QuantLib-Python. Unfortunately for 0.3.4 all QuantLib-SWIG 0.3.4 packages do not include a full test-suite anymore, but only test their own language-specific features, relying on the QuantLib C++ test suite for the base library features. Is there a way to have the C++ test-suite executed on all those Debian platform? ciao -- Nando |
|
|
On Fri, Nov 07, 2003 at 03:41:07PM +0100, Ferdinando Ametrano wrote:
> Dirk, > > I took a look at the Debian build logs and noticed that the test-suite is > not executed, because the library cannot be linked. Luigi confirmed me that > this is a problem he also has on any box which doesn't have a previous > QuantLib installed. > > This was not a big issue for 0.3.3 since the test-suite was executed by > QuantLib-Python. Unfortunately for 0.3.4 all QuantLib-SWIG 0.3.4 packages > do not include a full test-suite anymore, but only test their own > language-specific features, relying on the QuantLib C++ test suite for the > base library features. Right. I just enabled that in ql-ruby, and saw that the tests where quick. > Is there a way to have the C++ test-suite executed on all those Debian > platform? It generally works. AFAIK this is my only where package where I invoke it ... and nothing happens. It must be some LD_LIBRARY / libtool / ... magic that is beyond. If Luigi can fix it, great. If not, well, .... I guess it won;t be fixed. I do not suspect a problem at Debian's end. As a sledgehammer solution, I could always purge prior or other QL installations in the chroot in which I am building the packages. But that is somewhat brute ... Dirk -- Those are my principles, and if you don't like them... well, I have others. -- Groucho Marx |
|
|
On 2003.11.07 15:58, Dirk Eddelbuettel wrote:
> On Fri, Nov 07, 2003 at 03:41:07PM +0100, Ferdinando Ametrano wrote: > > I took a look at the Debian build logs and noticed that the test- > suite is not executed, because the library cannot be linked. Luigi > confirmed me that this is a problem he also has on any box which > doesn't have a previous QuantLib installed. > > > Is there a way to have the C++ test-suite executed on all those > Debian platform? > > It generally works. AFAIK this is my only where package where I > invoke it... and nothing happens. It must be some LD_LIBRARY / > libtool / ... magic that is beyond. If Luigi can fix it, great. If > not, well, .... I guess it won;t be fixed. I do not suspect a > problem at Debian's end. I don't suspect it either---it should be some libtool glitch (which I fix on my box by running ldconfig, but one has to be root, hasn't one?) I guess it stays this way for this release. Later, Luigi |
|
|
On Fri, Nov 07, 2003 at 04:20:25PM +0100, Luigi Ballabio wrote:
> On 2003.11.07 15:58, Dirk Eddelbuettel wrote: > >On Fri, Nov 07, 2003 at 03:41:07PM +0100, Ferdinando Ametrano wrote: > >> I took a look at the Debian build logs and noticed that the test- > >suite is not executed, because the library cannot be linked. Luigi > >confirmed me that this is a problem he also has on any box which > >doesn't have a previous QuantLib installed. > > > >> Is there a way to have the C++ test-suite executed on all those > >Debian platform? > > > >It generally works. AFAIK this is my only where package where I > >invoke it... and nothing happens. It must be some LD_LIBRARY / > >libtool / ... magic that is beyond. If Luigi can fix it, great. If > >not, well, .... I guess it won;t be fixed. I do not suspect a > >problem at Debian's end. > > I don't suspect it either---it should be some libtool glitch (which I > fix on my box by running ldconfig, but one has to be root, hasn't one?) Both manual and autobuilders do run as root -- commonly via the fakeroot utility -- as they e.g. have to create files with root.root ownership etc pp. That wouldn't be a constraint. > I guess it stays this way for this release. Yep. Dirk > > Later, > Luigi > -- Those are my principles, and if you don't like them... well, I have others. -- Groucho Marx |
«
Return to quantlib-dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |