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" signature.asc Description: Digital signature
Re: SableVM stalled in SID again?
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). > 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? Thanks GBP -- Grzegorz B. Prokopski <[EMAIL PROTECTED]> Debian GNU/Linux http://www.debian.org SableVM - LGPLed JVM http://www.sablevm.org Why SableVM ?!? http://devel.sablevm.org/wiki/WhySableVM
Re: SableVM stalled in SID again?
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. 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. Matthias
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 versions. > 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 case. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: SableVM stalled in SID again?
On (27/04/04 22:33), Steve Langasek wrote: > Hi Grzegorz, > > On Tue, Apr 27, 2004 at 01:36:58PM -0400, Grzegorz B. Prokopski wrote: > > > sorry for bothering you, but there's something wrong (again) w/ migration > > of SableVM packages to testing. Last time 1.1.0-5 was "hinted", so I > > though that the "hint" is permanent and it would work this time also. > > > But the packages seem to be stalled again and for a reason no better > > than previously. It's 13 days since upload, no bugs or missing deps > > seem to invalidate transition to testing. The only thing is, that this > > group of packages should migrate to testing together: > > > libsablevm1-dev libsablevm-native1 libsablevm-classlib1-java sablevm > > jikes-sablevm libsablevm1 > > > Could you please take a look at what's going on? > > 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. > 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? GBP 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? -- Grzegorz B. Prokopski <[EMAIL PROTECTED]> Debian GNU/Linux http://www.debian.org SableVM - LGPLed JVM http://www.sablevm.org Why SableVM ?!? http://devel.sablevm.org/wiki/WhySableVM
Re: SableVM stalled in SID again?
Hi Grzegorz, On Tue, Apr 27, 2004 at 01:36:58PM -0400, Grzegorz B. Prokopski wrote: > sorry for bothering you, but there's something wrong (again) w/ migration > of SableVM packages to testing. Last time 1.1.0-5 was "hinted", so I > though that the "hint" is permanent and it would work this time also. > But the packages seem to be stalled again and for a reason no better > than previously. It's 13 days since upload, no bugs or missing deps > seem to invalidate transition to testing. The only thing is, that this > group of packages should migrate to testing together: > libsablevm1-dev libsablevm-native1 libsablevm-classlib1-java sablevm > jikes-sablevm libsablevm1 > Could you please take a look at what's going on? 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. 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. Thanks, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
SableVM stalled in SID again?
Hi, sorry for bothering you, but there's something wrong (again) w/ migration of SableVM packages to testing. Last time 1.1.0-5 was "hinted", so I though that the "hint" is permanent and it would work this time also. But the packages seem to be stalled again and for a reason no better than previously. It's 13 days since upload, no bugs or missing deps seem to invalidate transition to testing. The only thing is, that this group of packages should migrate to testing together: libsablevm1-dev libsablevm-native1 libsablevm-classlib1-java sablevm jikes-sablevm libsablevm1 Could you please take a look at what's going on? Thanks, Grzegorz B. Prokopski http://bjorn.haxx.se/debian/testing.pl?package=sablevm Checking sablevm * trying to update sablevm from 1.1.0-5 to 1.1.3-1 (candidate is 13 days old) * sablevm is waiting for sablevm-classlib o Updating sablevm-classlib makes 2 depending packages uninstallable on alpha: libsablevm1, sablevm o Updating sablevm-classlib makes 1 non-depending packages uninstallable on alpha: libsablevm-native1 * Updating sablevm makes 2 non-depending packages uninstallable on alpha: libsablevm1, sablevm -- Grzegorz B. Prokopski <[EMAIL PROTECTED]> Debian GNU/Linux http://www.debian.org SableVM - LGPLed JVM http://www.sablevm.org Why SableVM ?!? http://devel.sablevm.org/wiki/WhySableVM
