3.4 cherry-pick: eef7899ea7ab use system doc toolchain instead of checking out of svn

[birkenfeld]

BPO	20661
Nosy	@loewis, @birkenfeld, @larryhastings, @ned-deily

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/larryhastings'
closed_at = <Date 2014-02-18.08:54:00.293>
created_at = <Date 2014-02-17.16:35:57.372>
labels = ['release-blocker']
title = '3.4 cherry-pick: eef7899ea7ab use system doc toolchain instead of checking out of svn'
updated_at = <Date 2014-02-18.10:01:38.997>
user = 'https://github.com/birkenfeld'

bugs.python.org fields:

activity = <Date 2014-02-18.10:01:38.997>
actor = 'ned.deily'
assignee = 'larry'
closed = True
closed_date = <Date 2014-02-18.08:54:00.293>
closer = 'georg.brandl'
components = []
creation = <Date 2014-02-17.16:35:57.372>
creator = 'georg.brandl'
dependencies = []
files = []
hgrepos = []
issue_num = 20661
keywords = []
message_count = 10.0
messages = ['211423', '211443', '211453', '211479', '211480', '211482', '211488', '211494', '211495', '211505']
nosy_count = 4.0
nosy_names = ['loewis', 'georg.brandl', 'larry', 'ned.deily']
pr_nums = []
priority = 'release blocker'
resolution = 'rejected'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue20661'
versions = ['Python 3.4']

[birkenfeld]

3.4 cherry-pick: eef7899ea7ab use system doc toolchain instead of checking out of svn

[larryhastings]

Okay. I'll do the first round of cherry-picking Tuesday or Wednesday (my time). I'm waiting for the list of requests to settle down so I can do them in chronological order.

[ned-deily]

Georg, why do you want to cherry-pick this for 3.4.0? As noted in bpo-20644, it definitely breaks OS installer builds and it may break Windows installer builds as well. We would need to address those problems as wee before rc2, which seems to me to make this out of scope for a release candidate fix. I would prefer to see this deferred to 3.4.1.

[birkenfeld]

Well, I thought the installer script can surely be fixed in time. If not, I agree that this shouldn't be picked yet.

[ned-deily]

The installer script wasn't broken, neither was the dmg buildbot. I'm still not seeing how this change qualifies as one that should be allowed in after rc1. Perhaps if there were a bug tracker issue that justified it. Still I'll see what I can do to implement the needed changes in the installer script included in the release and in the behind the scenes build process in time. As long as Python 2.5 can still be used for sphinx-build for now, it shouldn't be too bad.

[ned-deily]

Also Martin should give his blessing wrt the Windows installer builds.

[birkenfeld]

The change was requested by doko for Debian/Ubuntu. As for changing it after rc1, I agree it is unfortunate. But it doesn't affect the distributed content, only how the release is built, which I think is exactly what *can* go in the rc phase.

The Python requirement didn't change, you "just" have to have the toolchain lying around somewhere.

[ned-deily]

It does affect the distributed content in that the installer scripts for OS X and Windows are part of the source release and both Martin and I try very hard to build installers from unmodified source. And the OS X installers are built from a known vanilla environment each time which will now have to change. And I believe at least some third-party packagers use our installer build scripts as a basis for their own installer builds. So for all those reasons I think in an ideal world it's not appropriate for rc2 inclusion. But let's see what Martin says and I'll go with Larry's call.

[birkenfeld]

I see. I don't want to make your life miserable, so let's make a compromise and keep it for 3.4.1, and Debian will have to patch it locally for 3.4.0.

[ned-deily]

Thanks, Georg.