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... > 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 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. Cheers, -- Steve Langasek postmodern programmer
signature.asc
Description: Digital signature
