On 9 April 2005 at 20:57, Steve Langasek wrote: | On Sat, Apr 09, 2005 at 06:32:24AM -0500, Dirk Eddelbuettel wrote: | > On 8 April 2005 at 19:43, Steve Langasek wrote: | > | Package: quantlib-ruby | > | Version: 0.3.8-1 | > | Severity: serious | > | Tags: sid | > | Justification: FTBFS | | > | The most recent version of quantlib-ruby has failed to build on mipsel with | > | multiple source errors: | | | > The current version is a release candidate for the upcoming 0.3.9 release. | > I don't typically make ql-python and ql-ruby release for release | > candidate. Should I this time for mipsel? Or can this wait til 0.3.9 | > comes out ? | | It can wait, and be fixed by the t-p-u autobuilder for mipsel once sarge is | frozen; but it sounds to me in this case like the release-candidate version | of quantlib should not have been uploaded to unstable, as it's not actually | a candidate for the Debian release...
Well, it is for me (bug fixes upstream) and we're not yet frozen, are we? Also, 0.3.8 has been available since December. It's too bad it took so long for mipsel to get its infrastructure up to speed. | > Just as one further data point: | | > -- they attempted the build first on December 22, it failed as mipsel didn;t | > have Quantlib 0.3.8 yet | > -- they attempted again on March 11, it timed out | | > Mipsel is one of those arches where I asked for a longer timeout, and never | > heard back. So even if I upload the 0.3.9 rc for quantlib-ruby, it may | > simply timeout again. | | > I think the fault lies to some extent with the porters. I don;t mean to fan | > flames, but maybe we should consider to maybe just skip QuantLib on mipsel. | | quantlib-ruby (together with quantlib-python) is one of the last two | out-of-date packages on mipsel following the arch's problems earlier this | year. It *should* not be a problem to get fixed versions into testing via | t-p-u, unless there's an RC build problem that likely affects other I'm a little rusty on the details. How would I get 0.3.8 on mipsel into testing ? Do I need to upload anything new? Or do we ask the mipsel porters to build ql-python and ql-ruby 0.3.8 based on what is in testing? Or can we have an executive decision to just exclude mipsel's ql-ruby and ql-python? | architectures. If it is a problem, removing the old binaries from testing | will still be an option, but not one that I think we should pursue yet. Let me know how I can help. The more explicit you can make it the better :) Cheers, Dirk -- Better to have an approximate answer to the right question than a precise answer to the wrong question. -- John Tukey as quoted by John Chambers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
