On 2022-11-24 09:47:51 -0500, Scott Talbert wrote: > On Thu, 24 Nov 2022, Sebastian Ramacher wrote: > > > Hi Scott > > > > On 2022-11-23 19:38:26 +0100, Paul Gevers wrote: > > > Hi Scott, > > > > > > On 23-11-2022 15:26, Scott Talbert wrote: > > > > Hi Release Team, > > > > > > > > I'm trying to understand why this package (haskell-copilot-theorem[1]) > > > > isn't migrating to testing. It looks like it is saying that it is being > > > > blocked by haskell-what4, but haskell-what4 has already migrated to > > > > testing on October 17. Also, if I look at excuses for haskell-what4, > > > > there aren't any. > > > > > > > > The only thing I can possibly think is that it is referring to migration > > > > of binNMU's, but I can't see any way to see the status of those. Is it > > > > possible? > > > > > > > > Thanks, > > > > Scott > > > > > > > > [1] https://qa.debian.org/excuses.php?package=haskell-copilot-theorem > > > > > > > > > > It says: > > > haskell-copilot-theorem haskell-parameterized-utils/ppc64el (not > > > considered) > > > > > > Which means that haskell-copilot-theorem on ppc64el depends on > > > src:haskell-parameterized-utils. > > > > > > Picking one of the binaries from that source and asking rmadison says: > > > paul@mulciber ~ $ rmadison libghc-parameterized-utils-dev > > > libghc-parameterized-utils-dev | 2.1.5.0-2+b1 | testing | amd64, > > > arm64, > > > armel, armhf, i386, mips64el, mipsel, ppc64el, s390x > > > libghc-parameterized-utils-dev | 2.1.5.0-2+b2 | unstable | mips64el, > > > mipsel, ppc64el > > > libghc-parameterized-utils-dev | 2.1.5.0-2+b3 | unstable | armhf, i386, > > > s390x > > > libghc-parameterized-utils-dev | 2.1.5.0-2+b4 | unstable | amd64, > > > arm64, > > > armel > > > > > > So indeed, the binNMU's of that source are out-of-sync between testing and > > > unstable. > > > > > > Searching in the excuses [2] I see this: > > > Depends: haskell-parameterized-utils/amd64 <a > > > href="#haskell-th-abstraction">haskell-th-abstraction</a> > > > > > > So that points at haskell-th-abstraction.... (which seems in a similar > > > situation but then with haskell-clash-prelude) > > > > And if you go down the rabbit hole far enough, you'll eventually reach > > #1023149 which needs to be taken care of. > > Yes, that's the same conclusion I came to. Thanks!
The next blocker is #1023020. Cheers -- Sebastian Ramacher