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

Re: SableVM stalled in SID again?

On Thu, Apr 29, 2004 at 11:01:56PM -0400, Grzegorz B. Prokopski wrote:
> > Yes, this is definitely going to require a hint; I just hadn't gotten to
> > the point yet of figuring out what the hint needed to look like.

> > I now have a hint in place for sablevm-classlib 1.1.3-1.

> Sounds good, but according to
> 	http://ftp-master.debian.org/testing/update_excuses.html#sablevm
> 1.1.3-1 is still stalled in sid for no good reason.

Trying to hint sablevm-classlib in results in the following
uninstallable packages in testing:

    * i386: libocl-argo-java
    * mips: libsablevm-native1
    * mipsel: libsablevm-native1

The packages that were being considered together were:

    sablevm-classlib dresden-ocl sablevm

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.  (It looks like the libocl-argo-java problem
is spurious.)  Please update sablevm-classlib so that it doesn't
generate binary packages for architectures where they won't be usable.
(Does a build-depend on sablecc make sense here?)

> > Hints are actually a one-shot deal, in part because too many of them
> > would tax the system running the build scripts -- this is the reason
> > they're necessary at all, in fact.

> Oh!  It's ugly!  So what is the long term solution?  Will I have to mail
> debian-release each time I want sablevm to be migrated to testing?!
> (don't you guys have better things to do? ;-)

> BTW: In the good old days of SableVM 1.0.x (8 months ago?) the packages
> were migrating w/o troubles, so I don't understand why there's a problem
> currently.  I've never had to mail debian-release or anybody before.

> What has changed?

You have two source packages, sablevm and sablevm-classlib, whose binary
packages are interdependent in such a way that they both have to be
updated at the same time.

Package: libsablevm1
Source: sablevm
Version: 1.1.3-1
Depends: libsablevm-native1 (>> 1.1.3)
Conflicts: libsablevm-native1 (>> 1.1.4)

Package: libsablevm1
Source: sablevm
Version: 1.1.0-5
Depends: libsablevm-native1 (>> 1.1.0)
Conflicts: libsablevm-native1 (>> 1.1.1)

If you can work out a way to do without the strict versioned
dependencies here, it will make life a little easier for all of us. :)
It would be preferable if libsablevm-native1 maintained
backwards-compatibility, so that no conflicts: was needed with later

> PS: The only thing that comes to my mind is sablevm-nativelib source package
> 	ftp://ftp.debian.org/debian/pool/main/s/sablevm-nativelib/
> lying around.  It's not used anymore and is not part of sid nor testing.
> Hmm...  I guess I'll file a bug for ftpmaster to remove it.  Could that
> be the culprit?

It doesn't appear to be.  I've requested its removal from testing in any

Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature

Reply to: