[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 > <[email protected]> > > ------------------- 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: [email protected] IRC #debian-science: wlfuetter
