--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian.org@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:
Checking reverse dependencies...
# Broken Depends:
alot: alot
assword: assword
bmap-tools: bmap-tools
nautilus-dropbox/non-free: nautilus-dropbox [amd64 i386]
# Broken Build-Depends:
assword: python-gpgme
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.
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.
4. Pandas FTBFS on some archs (#790024 and #790025). It's a leaf package, so
it could either be partially or fully removed.
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.
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).
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.
If the above status is acceptable, then the transition is ready to proceed.
Scott K
[1] https://release.debian.org/transitions/html/python3.5.html
[2] https://titanpad.com/1XNQ2l7MdS
[3] http://paste.debian.net/361351/
--- End Message ---
--- Begin Message ---
On 13/01/16 15:02, Scott Kitterman wrote:
> On Wednesday, January 06, 2016 03:39:15 PM you wrote:
> ...
>> 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:
>>
>> Checking reverse dependencies...
>> # Broken Depends:
>> alot: alot
>> assword: assword
>> bmap-tools: bmap-tools
>> nautilus-dropbox/non-free: nautilus-dropbox [amd64 i386]
>>
>> # Broken Build-Depends:
>> assword: python-gpgme
>
> Discussing this before we started the transition with pochu, he indicated "b"
> was the preferred RT option. I did try and binNMU it again to make sure and
> as expected, it failed, so these packages will need to be removed from
> testing.
>
>> 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.
>>
>> 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.
>
> Both these magically fixed themselves, so are no longer an issue.
>
>> 4. Pandas FTBFS on some archs (#790024 and #790025). It's a leaf package,
>> so it could either be partially or fully removed.
>
> This will need removal.
>
>> 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.
>
> python3.5 has been fixed. We're still waiting for the fixed python3.5 to build
> on mips and a few ports archs, but the binNMUs of borgbackup and s3ql have
> otherwise been successful. With a little more buildd time, I expect these
> issues will be fully resolved.
>
>> 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].
>
> LO is mostly rebuilt, but depending on which builder and when it's picked up
> for mips, it may take long enough to delay things a bit.
>
> There are a few other builds I'm waiting on to finish, but everything's been
> uploaded/scheduled so modulo the issues above, we should be finished this week.
After some hints, this finally went in!
Cheers,
Emilio
--- End Message ---