2.3.6 for the unicode buffer overrun

On Friday 13 October 2006 16:59, Fredrik Lundh wrote:
> yeah, but *you* are doing it.  if the server did that,
Martin and
> other trusted contributors could upload the files as
soon as they're
> available, instead of first transferring them to you,
and then waiting
> for you to find yet another precious time slot to spend
on this release.

Sure - I get that. There's a couple of reasons for me doing
it. First is gpg 
signing the release files, which has to happen on my local
machine. There's 
also the variation in who actually builds the releases; at
least one of the 
Mac builds was done by Bob I. But there could be ways around
this. I don't 
want to have to ensure every builder has scp, and I'd also
prefer for it to 
all "go live" at once. A while back, the Mac
installer would follow up "some 
time" after the Windows and source builds. Every
release, I'd get emails 
saying "where's the mac build?!" 

> > The problems are with the other bits of the pages.
I keep thinking "next
> > release, I'll automate it further", but never
have time on the day.
>
> that's why you have to have an overall infrastructure
that lets you make
> incremental tweaks to the tool chain, so things can get
a little better
> all the time.  Pyramid obviously isn't such a system.

I can't disagree with this.



-- 
Anthony Baxter     <anthonyinterlink.com.au>
It's never too late to have a happy childhood.
_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com

On 10/13/06, Anthony Baxter <anthonyinterlink.com.au> wrote:
> On Friday 13 October 2006 16:59, Fredrik Lundh wrote:
> > yeah, but *you* are doing it.  if the server did
that, Martin and
> > other trusted contributors could upload the files
as soon as they're
> > available, instead of first transferring them to
you, and then waiting
> > for you to find yet another precious time slot to
spend on this release.
>
> Sure - I get that. There's a couple of reasons for me
doing it. First is gpg
> signing the release files, which has to happen on my
local machine. There's
> also the variation in who actually builds the releases;
at least one of the
> Mac builds was done by Bob I. But there could be ways
around this. I don't
> want to have to ensure every builder has scp, and I'd
also prefer for it to
> all "go live" at once. A while back, the Mac
installer would follow up "some
> time" after the Windows and source builds. Every
release, I'd get emails
> saying "where's the mac build?!"

With most consumer connections it's a lot faster to download
than to
upload. Perhaps it would save you a few minutes if the
contributors
uploaded directly to the destination (or to some other fast
server)
and you could download and sign it, rather than having to
scp it back
up somewhere from your home connection.

To be fair, (thanks to Ronald) the Mac build is entirely
automated by
a script with the caveat that you should be a little careful
about
what your environment looks like (e.g. don't install fink or
macports,
or to move them out of the way when building). It downloads
all of the
third party dependencies, builds them with some special
flags to make
it universal, builds Python, and then wraps it up in an
installer
package.

Given any Mac OS X 10.4 machine, the builds could happen
automatically. Apple could probably provide one if someone
asked. They
did it for Twisted. Or maybe the Twisted folks could
appropriate part
of that machine's time to also build Python.

-bob
_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com

On Friday 13 October 2006 20:35, Bob Ippolito wrote:
> With most consumer connections it's a lot faster to
download than to
> upload. Perhaps it would save you a few minutes if the
contributors
> uploaded directly to the destination (or to some other
fast server)
> and you could download and sign it, rather than having
to scp it back
> up somewhere from your home connection.

I actually pull them down to both dinsdale and home, then
verify they're the 
same with SHA and MD5 before signing, and uploading the
keys. The only thing 
I upload directly are the keys and the source tarballs.


> Given any Mac OS X 10.4 machine, the builds could
happen
> automatically. Apple could probably provide one if
someone asked. They
> did it for Twisted. Or maybe the Twisted folks could
appropriate part
> of that machine's time to also build Python.

We have one, macteagle. For some reason builds fail on it
right now - Ronald 
might be able to supply more details as to why.

Anthony
-- 
Anthony Baxter     <anthonyinterlink.com.au>
It's never too late to have a happy childhood.
_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com

 
On Friday, October 13, 2006, at 01:10PM, Anthony Baxter
<anthonyinterlink.com.au> wrote:

>On Friday 13 October 2006 20:35, Bob Ippolito wrote:
>> With most consumer connections it's a lot faster to
download than to
>> upload. Perhaps it would save you a few minutes if
the contributors
>> uploaded directly to the destination (or to some
other fast server)
>> and you could download and sign it, rather than
having to scp it back
>> up somewhere from your home connection.
>
>I actually pull them down to both dinsdale and home,
then verify they're the 
>same with SHA and MD5 before signing, and uploading the
keys. The only thing 
>I upload directly are the keys and the source tarballs.
>
>
>> Given any Mac OS X 10.4 machine, the builds could
happen
>> automatically. Apple could probably provide one if
someone asked. They
>> did it for Twisted. Or maybe the Twisted folks
could appropriate part
>> of that machine's time to also build Python.
>
>We have one, macteagle. For some reason builds fail on
it right now - Ronald 
>might be able to supply more details as to why.

IIRC it has the wrong version of Xcode installed (or rather
another one than I use and test with). It also has
darwinports installed at the default location, which can
cause problems because the setup.py adds that directory to
the include/link paths. I don't want to release installers
that require that the user has darwinports installed 

I can supply a newer version of Xcode if someone with an
admin account is willing to install that. I don't know if
the admin of that machine has GUI access to the machine, if
not I'd have to investigate how to ensure that the proper
subpackages get installed using a command-line install
(using RemoteDesktop to administrator servers has spoiled me
a bit in that regard).

I guess this comes down to the usual problem: I have a
working setup for building the mac installer and fixing
macteagle takes time which I don't have available in great
amounts (who does?). 

Ronald
_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com

 
On Friday, October 13, 2006, at 12:36PM, Bob Ippolito
<bobredivi.com> wrote:

>
>To be fair, (thanks to Ronald) the Mac build is entirely
automated by
>a script with the caveat that you should be a little
careful about
>what your environment looks like (e.g. don't install
fink or macports,
>or to move them out of the way when building). 

That (the "don't install Fink or macports" part)
is because setup.py explicitly adds those directories to the
library and include search path. IMHO that is a misfeature
because it is much to easy to accidently contaminate a build
that way. Fink and macports can easily add their directories
to the search paths using OPTS and LDFLAGS, there's no need
to automate this in setup.py.

The beauty of macports is that /opt/local is the default
prefix, but you can easily pick another prefix and most
ports work fine that way (or rather not worse than with the
default prefix).

Ronald

_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com