Re: parmetis not in testing
[Cc'ing Christophe and Sébastien, uploader of suitesparse-metis and
suitesparse]
Hi Mattia, 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).
Thanks for the explanation and the link to update_output.txt. Added the link
to my bookmarks in the case that I need it again in the future.
Unfortunately the current suitesparse-metis[1] in unstable won't build against
parmetis (>4.x): #778540
IMHO there are the following options to continue:
1) Removing suitesparse-metis from unstable
I really don't know, weather this is a good idea or a really bad one.
2) Uploading a new version of suitesparse[2] build against metis and replacing
suitesparse-metis.
This would affect primarily two libraries in suitesparse (libcholmod and
libspqr). And could cause suitesparse move to contrib. (IMHO not preferable)
3) copying the current source of suitesparse to suitesparse-metis and
preparing a new version of suitesparse-metis with metis enabled.
The latter corresponds to the current state.
Any ideas anyone? Which of these options is preferable, if any?
Cheers
Wolfgang
[1] https://tracker.debian.org/pkg/suitesparse-metis
[2] https://tracker.debian.org/pkg/suitesparse
--
Jabber: yagharek@jabber.de
IRC #debian-science: wlfuetter
Reply to: