[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: SableVM stalled in SID again?

On Sun, May 02, 2004 at 06:01:36PM -0400, Grzegorz B. Prokopski wrote:
> On (02/05/04 21:56), Matthias Klose wrote:
> > Steve Langasek writes:
> > > So the issue is that libsablevm-native1 is built on all architectures,
> > > but sablevm hasn't been built on mips and mipsel, resulting in an
> > > unsatisfiable dependency.

> agrh... now i remember - I tightened the inter-dependencies to disallow
> partial upgrades, that is - when you upgrade sablevm but not the java
> library (which consists of two: one native and one pure-java packages).

Are there concrete reasons why partial upgrades must not be allowed?

> > It's the build dependency on libffi2-dev, which is still missing on
> > mips/mipsel. If/when gcc-3.4 moves to unstable, libffi will be
> > available on all architectures.

> Good point. By the time we release 1.1.5 (we're at 1.1.3 now) this
> problem will be solved one way or another. I'll try to figure something
> out on our own so that we didn't have to bother you every single time
> in longer term. Now I have much better overview of what's happening.

> Meanwhile - could you please KICK SableVM 1.1.3 to go into testing?

I don't have that power, sorry.  The testing scripts will only let a
package in when all of the binary packages it creates are up-to-date on
all architectures, and all of the binary packages are installable using
just those packages that are already in testing[1].  This means you must
solve the problem of uninstallable libsablevm-native1 packages on mips
and mipsel before it can get into testing, either by having an
ftp-master remove those binary packages or by fixing the problem that
keeps them from being uninstallable.

Steve Langasek
postmodern programmer

[1] Technically, the rule is "must not increase the number of
uninstallable packages in testing"

Attachment: signature.asc
Description: Digital signature

Reply to: