On 02/21/2014 01:30 AM, Ned Deily wrote: > In article <53070A8A.8080101 at hastings.org>, > Larry Hastings <larry at hastings.org> wrote: >> As before you'll find the results here: >> >> http://midwinter.com/~larry/3.4.status/ > Status says that: > > eef7899ea7ab Doc: do not rely on checked-out Sphinx toolchain from > svn.python.org anymore > > is unmerged, which is what Georg and I agreed upon in Issue20661. Yet, > in the current python.3.4.2014.02.21.00.07.42.tgz tarball, that change > appears to be present and, as such, causes installer builds to fail. > Whoopsie! My local branch is actually correct. But! I effectively did this in my automation: % hg clone 3.4 python-{time} % cd python-{time} % rm -rf .hg* .bzr* .git* % cd .. % tar cvfz python-{time}.tgz python-{time} Can you spot the error? That's right: when you clone, the clone always starts out in "default". So all the tarballs I've published so far have been wrong. ARGH. Sorry! I've added a "hg branch 3.4" in a judicious spot in my automation. The resulting tarball doesn't have the sphinx toolchain change. Look for a new tarball in a few minutes, once "make test" finishes, //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20140221/80231274/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4