On Wed, Mar 30, 2016 at 08:07:44AM +0100, Ghislain Vaillant wrote:
> Hi Wolfgang,
>
> On 30/03/16 07:57, Wolfgang Fuetterer wrote:
> >Hi all,
> >
> >parmetis[1] was removed from testing a month ago.
> >Looking at [2] the removal was due to the openmpi-transition.
> >Since then parmetis is only in unstable, although it is a valid
> >candidate for migrating to testing.
> >
> >Did I miss something? Do I need to upload a new version to trigger the
> >migration again?
This is not a thing, the migration is always tried 2 times per day, no
matter how old the source is (if it is enough old, e.g. 5 days in this
case).
The reason why this doesn't migrate to testing can be seen in
https://release.debian.org/britney/update_output.txt the problem with
that page is that you need quite some background to understand it:
trying: parmetis
skipped: parmetis (11, 69)
got: 52+0: a-5:i-2:a-0:a-0:a-0:m-1:m-0:p-43:p-0:s-1
* mips: libparmetis3.1
This means that migrating parametis to testing would break and make
libparametis3.1 uninstallable.
Now, I can't understand how this is a problem now and wasn't in
September when it migrated, but anyway....
This is most probably a issue not restricted on mips, and mips is there
just because this check fails on the first failing arch, without
considering the next (and allegedly the archs are not sorted before
doing this check).
Now, this clearly needs a decruft, that should be done automatically by
the auto-decrufter once this dep issue is solved:
mattia@coccia ~ % dak rm -Rn -bp libparmetis3.1
Will remove the following packages from unstable:
libparmetis3.1 | 3.1.1-4 | arm64, ppc64el
libparmetis3.1 | 3.1.1-4+b1 | amd64, armhf, i386, kfreebsd-amd64, kfreebsd-i386, powerpc, s390x
libparmetis3.1 | 3.1.1-4+b2 | armel, hurd-i386, mips, mipsel
Maintainer: Debian Science Team <debian-science-maintainers@lists.alioth.debian.org>
------------------- Reason -------------------
----------------------------------------------
Checking reverse dependencies...
# Broken Depends:
suitesparse-metis/contrib: libsuitesparse-metis-3.1.0 [amd64 armel hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390x]
Dependency problem found.
Basically, suitesparse-metis needs to be rebuilded against the newer
parametis, and given that parametis is in non-free this won't happen
automatically, but somebody needs to rebuild suitesparse-metis locally
and upload the binaries.
Now, I could easily do this for amd64 and i386, but for some funny
reason suitesparse-metis was previously built on amd64 armel hurd-i386
i386 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390x, making this
work *hard*.
Please ask whoever uploaded those binaries to do the required transition
for parametis (because yes, this is a standard transition, that sadly
involved non-free and contrib, which always complicate the matters).
> You can try. You may take this opportunity to address some of, if not
> all, the package's current warnings:
this would be a nice thing anyway. In particular,
format-3.0-but-debian-changes-patch is so much worrying...
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: http://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
Attachment:
signature.asc
Description: PGP signature