Control: tags -1 confirmed On 06/01/16 21:39, Scott Kitterman wrote: > Package: release.debian.org > Severity: normal > User: release.debian....@packages.debian.org > Usertags: transition > > This is the tracking bug for the transition to make python3.5 the default > python3. The transition tracker is already in place [1]. > > The archive is generally ready for this transition, but there are a few issues > outstanding: > > 1. pygpgme is FTBFS due to test failures (#797776). There has been no > response from the maintainers and I have been unable to determine the > source of the failures. I do not believe it is python3 version related (the > package builds with python3.5 on Ubuntu). I see two possible options: > > a. NMU to disable tests so it can be rebuilt with python3.5 support (without > at least this python3-gpgme will be totally broken once python3.5 is default) > > b. Remove pygpgme from Testing. It has rdepends so it would kill off a few > other packages as well:
This can be removed. In fact, I believe it should have been autoremoved, except that #797776 was only tagged sid. > 2. Elektra is FTBFS due to unrelated test failures (#810069). The impact of > this is that python3-elektra will become uninstallable. It has no rdepends. > Presumably elektra could be temporarily removed from testing. Yes. > 3. Geis is FTBFS for reasons unrelated to python3 (#810071). Similarly, > python3-geis will become uninstallable. Geis does have one external rdepend, > libgrip (which has no rdepends). I don't see a reason they couldn't be > temporarily removed from testing. That could be done. > 4. Pandas FTBFS on some archs (#790024 and #790025). It's a leaf package, so > it could either be partially or fully removed. Yes. > 5. Cython3 not currently working [3]. This appears to be due to a change in > python3.5. It affects borgbackup and s3ql only. As these are rather late in > the transition, we could probably go ahead while this is getting sorted. > These > are both leaf applications that would become temporarily uninstallable. We > believe we have identified the problematic python3.5 commit (it's also in the > next python3.4 release, so it's not inherently a transition issue) and are > working with upstream to evaluate the correctness of the change and if as a > result cython needs to be changed. Since you have a fix in the pipeline and a workaround in case that fix turns out to be insufficient, let's not block on this. > I have test built (as of this writing libreoffice is still building) all the > unknown/bad packages that need rebuilding for this transition as well as > reviewing all the unknown packages. Due to the number of unknowns, I have > created a pad to track the status of the transition [2]. > > I'm not providing wb commands since I plan on taking care of the binNMUs (I > can if the release team would prefer). You can handle it. > There are some additional issues with packages not in testing, but those > packages are already broken for various reasons so doing this transition will > not make anything worse. Those are not a problem. > If the above status is acceptable, then the transition is ready to proceed. Please go ahead. Thanks, Emilio
