You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
3.4 cherry-pick: eef7899ea7ab use system doc toolchain instead of checking out of svn #64860
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=<Date2014-02-18.08:54:00.293>created_at=<Date2014-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=<Date2014-02-18.10:01:38.997>user='https://github.com/birkenfeld'
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.
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.
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.
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.
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.
Activity
birkenfeld commentedon Feb 17, 2014
3.4 cherry-pick: eef7899ea7ab use system doc toolchain instead of checking out of svn
larryhastings commentedon Feb 17, 2014
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 commentedon Feb 17, 2014
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 commentedon Feb 18, 2014
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 commentedon Feb 18, 2014
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 commentedon Feb 18, 2014
Also Martin should give his blessing wrt the Windows installer builds.
birkenfeld commentedon Feb 18, 2014
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 commentedon Feb 18, 2014
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 commentedon Feb 18, 2014
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 commentedon Feb 18, 2014
Thanks, Georg.