Re: [Python-Dev] February bug day outcome
-On [20080226 08:09], Neal Norwitz ([EMAIL PROTECTED]) wrote: >I agree with the theory. However, we have only a single BSD box >currently working and it has been flaky. Primarily test_smtplib has >been failing sporadically on it. For example: What are the requirements for a build box? I have both a a 6.3-STABLE AMD Athlon XP 2200+ and an FreeBSD 7-PRERELEASE (STABLE once released) amd64 box I can let compile. The 6.3 box can do it (almost) continuously. I can probably add an Intel Pentium 4 6.3-STABLE box as well. I can probably get NetBSD build bots up as well, just need to ask some people for appropriate access. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ We shape clay into a pot, but it is the emptiness inside that holds whatever we want... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] February bug day outcome
On Tue, Feb 26, 2008 at 12:07 AM, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> wrote: > -On [20080226 08:09], Neal Norwitz ([EMAIL PROTECTED]) wrote: > >I agree with the theory. However, we have only a single BSD box > >currently working and it has been flaky. Primarily test_smtplib has > >been failing sporadically on it. For example: > > What are the requirements for a build box? I have both a a 6.3-STABLE AMD No requirements in particular. See http://wiki.python.org/moin/BuildBot Pretty much it should have good network connectivity and someone we can contact who can administer the box. For example, in the past we have had to have ports opened up so the tests can pass. Possibly we might want to get different version of libraries installed to test with (e.g., berkeley db v 4.x). > Athlon XP 2200+ and an FreeBSD 7-PRERELEASE (STABLE once released) amd64 box > I can let compile. The 6.3 box can do it (almost) continuously. I can > probably add an Intel Pentium 4 6.3-STABLE box as well. These boxes are fine and faster than half the current machines. > I can probably get NetBSD build bots up as well, just need to ask some > people for appropriate access. It would be best if we get configurations we don't already have. We have no NetBSD boxes. We have one FreeBSD (6.2 supposedly), although it's 32-bit. n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Python 2.6 and 3.0
> Martin v. Löwis wrote: > > I've looked at it, and I seriously doubt that. In WiX, you need to > > specify a fixed file list (perhaps with wildcards; I'm unsure). This > > will be tricky for Python, where the list of files to be installed > > changes all the time. > > > > You *need* to have a turing-complete packing language (such as > Python). > > You are most likely right. A pure XML based solution ain't going to > work > for Python. But how about a mixed solution? > > XML templates -> Python fu -> WiX XML -> MSI > > We take some XML templates, modify them from Python and add the files. > Finalliy we let WiX create the MSI installer from the resulting XML > file. > > What do you think? I'm inclined to agree with Martin that WiX doesn't offer us much value (it offers value in many places though - just not for our requirements given Martin's msilib). I believe that once we know how to solve a particular problem, it would not be significantly easier to implement using WiX than it would using the current infrastructure. My problem is still getting my head around various MSI issues at any level (eg, bdist_msi needs some tweaking to allow for different releases of the same "package" to be recognized as such, but I'm not sure what MSI concept I'm dealing with yet...) WiX is an excellent inspiration though - if a WiX example can be found for something, it should be a significant help in implementing it via msilib. Cheers, Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6 and 3.0 ...and applink.c?
Bugbee, Larry wrote: > Hi Barry, > > A question Do you know if OpenSSL's applink.c will be included in > the Windows builds? If so, and I hope it is, great! > > If not, I'd like to encourage its inclusion. Doing so will permit > Python to be used with OpenSSL 0.9.8x on Windows platforms without a > user trying to find somebody with the right compiler to rebuild a Python > for him/her. This is needed for M2Crypto, or any other OpenSSL wrapper > for that matter. A lot more can be said here, but in the interest of > brevity... ;-) I don't understand how applink is going to help you. The SSL libs are statically linked into the _ssl extension DLL. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbots for trunk are all red
2008/2/25, Thomas Hervé <[EMAIL PROTECTED]>: > I've worked on that problem during the bug day. I've open a ticket with > a patch at http://bugs.python.org/issue2168. Most of the buildbots are green now!!! Thank you all! This community is as awesome as Python itself, ;) Three remains in red, though: - Alpha Tru64: test_smtplib.py is flaky, and _ssl.c is not compiled correctly. Neil is hunting this, I think. - X86 XP-3: seems to crash after test_bsddb3.py. - X86 XP-4: idem. For this two, how can be tried if the bsddb lib in those windows is correctly installed? Thanks again. -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6 and 3.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 25, 2008, at 7:11 PM, Christian Heimes wrote: > Barry Warsaw wrote: >> From the follow ups, it sounds like others can pitch in here. A >> question though: is it reasonable to hold up the monthly release >> because >> a binary build we're going to make available can't be done at the >> same >> time? >> >> My preference (at least for the alphas) is "no". If we can make a >> source release, and if we can build a binary release from exactly the >> same revision, then we should go ahead and release. I'd rather get >> the >> alpha out there and in people's hands. >> >> We'll almost certainly be stricter for the candidates, finals, and >> maybe >> betas. > > I agree. It's not reasonable to hold of alphas because the Windows > binaries may be released a few days later. Do we need official Windows > binaries for alphas at all? Martin's buildbot creates nightly Windows > builds. We could point users to the nightly builds and ask them to > test > the version. That would be find with me. Where are those Windows binaries available for download from? >> Dang. I actually don't know how long it's going to take me to do the >> source release, but I hope it's no more than 3 or 4 hours. > > I guess it's less than 2 hours. You can prepare most of the work like > the announcements a couple of days earlier. I (perhaps naively) assume > you have to smack the whip to get everything in place, do the svn cp > to > tag, svn export, tar cz, tar xzf && ./configure && make && make test > dance and upload the tar.gz. Am I missing something important? :] Dunno yet! It's been years since I did a release and I really want to check out Anthony's welease tool this time. I may not have time before Friday to look at this though. >> When's the PSF gonna start hiring? :) > > Dunno :) But I'm probably the last in a long line of Python core > developers to get hired. Don't forget I'm still fresh and a junior > core > developer. *jk* :) >> So, as I mentioned in my last reply, I'm planning to only allow >> critical >> bugs (as described in roundup) hold up the release. Right now >> there are >> no critical bugs open. > > #1569 is critical but not important enough to stop an alpha. As I said > in the other mail it should be fixed for the first beta and must be > fixed for the first rc. It's not marked critical in roundup, and that's the only thing I'm going by! But it doesn't seem critical in the sense that it should hold up the alpha release, IMO. Cheers, - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR8QF5nEjvBPtnXfVAQJhrgP/Xz3IQrlCB9QPGsMGIL+xG3I5t+aThNg6 4n/bMjt4DRzTCRiNBjUllyCb5+VtPfTZu2wFVdi5I7NLMDG4WI4jfDGZlhvodbHW TPG/7bN/ykx9yE1hUPI5X+Kqrg0lG7Tbp9Zev5eHJCMwParSVu+hfWqD48+1bQqw JGfzz8AlqE0= =PQgE -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Buildbot health (was Re: February bug day outcome)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 26, 2008, at 12:04 AM, Neal Norwitz wrote: > > It's been pretty bad the last month or so. Although it's getting > better now. I would recommend these are the golden bots based on what > have traditionally been fairly stable help expose errors: > > sparc solaris10 > amd64 gentoo (this is really an ubuntu 6.10 box) > x86 gentoo (*) > g4 os x (this one has svn problems from time to time which is odd > given that it is the only box colocated with the svn server) > some win xp box (#4 wfm, i think that has been the most stable > recently) > ia64 ubuntu > ppc debian (this may be ubuntu also) > ppc64 debian (ditto) Cool, thanks for this list. > The biggest challenge will be having svn work on all the machines. > The tests are getting more stable. I worked on many of them. There > are still issues from time to time, but at this point I think more are > caused by bad checkins. Sometimes these machines go away, if they are > unavailable at time of release, so be it. > > If we can get more people watching the buildbots and ping those > responsible for a failure, we can keep the red to a minimum. If we > can fix the ~5 flaky tests, we will be in good shape. If we can fix > the svn problems, we'll be in great shape. Nearly all of the flaky > tests are due to networking problems. Sometimes transient conditions > like the host is unavailable, others due to races. > > (*) x86 gentoo should not be used for 3.0. There is a problem with > signal 32 that causes it to rarely work. I don't know the cause or > how to fix this. All of the 3.0 buildbots are currently red. Both test_cProfile and test_profile fail consistently for me on x86 Ubuntu Gutsy and Intel OS X 10.5.2. It looks like the buildbots are failing here too -- does anybody have time to fix these two tests? - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR8QaeXEjvBPtnXfVAQITQQQAlcjymy7ZV9y6cq4bFNM9/55CBj35ahOz M9S31WkxJgisk6q3ebS1NzQIAp7V1FeS14TZD0TYwYEAgDxQHQ/xJeB9RB63feNX DaJUa6zTPFY7lBvaOWJ8SMp5yvlwnbzykbh52tsKiikCUqFCjU6IC/p7ieebqadF UJxbVZ9nTdM= =Py4H -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] getpass and stdin
[please cc me on responses]
I was wondering if getpass could be changed to enable piped stdin to work.
For instance, the getmail program can read my email password in via
stdin using getpass functionality.
However, if I do
echo password | getmail4
it will fail due to stdin not being a terminal and therefore not being
able to do a old = termios.tcgetattr(fd) on it.
From what I can tell, the point of this is to only to prevent echoing
the password, which isn't a problem in the echo case I give (especially
if using bash, then it wont even be on the cmdline when run from a
script as it's a builtin, script can also read in the password and store
it in memory).
currently the code is
-
def unix_getpass(prompt='Password: '):
"""Prompt for a password, with echo turned off.
Restore terminal settings at end.
"""
try:
fd = sys.stdin.fileno()
except:
return default_getpass(prompt)
old = termios.tcgetattr(fd) # a copy to save
new = old[:]
new[3] = new[3] & ~termios.ECHO # 3 == 'lflags'
try:
termios.tcsetattr(fd, termios.TCSADRAIN, new)
passwd = _raw_input(prompt)
finally:
termios.tcsetattr(fd, termios.TCSADRAIN, old)
sys.stdout.write('\n')
return passwd
-
it would seem that if the tcgetattr() line is moved into the initial
try, my echo case would work as expected (as it would fail, but be
caught and then just run default_getpass() (which should just read it
from stdin).
Is there any reason not to do it this way?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6 and 3.0
Barry Warsaw wrote: > That would be find with me. Where are those Windows binaries available > for download from? The Windows builds are hidden in the development section. It took me 10 minutes to find them because I was searching in the download section and for nightly builds. The *daily* builds are available at http://www.python.org/dev/daily-msi/ Christian signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6 and 3.0 ...and applink.c?
> I don't understand how applink is going to help you. The SSL libs are statically linked > into the _ssl extension DLL. I personally have not used _ssl but on quick inspection I don't see any of the crypto algorithms implemented, AES, ECDSA, etc. What if we want to encrypt or sign content using OpenSSL? We'd import M2Crypto but when we go to load the key we'll get an OPENSSL_Applink error. Likewise for OpenSSL with xmlsec. Larry PS: This problem applies to vanilla builds of Python on Windows only when Microsoft tools and libraries are used to build Python. It does not apply to cygwin or mingw where gcc is used. Likewise, it does not apply to other platforms, only Windows. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] getpass and stdin
On Sun, Feb 24, 2008 at 1:02 PM, Shaya Potter <[EMAIL PROTECTED]> wrote:
> [please cc me on responses]
>
> I was wondering if getpass could be changed to enable piped stdin to work.
>
> For instance, the getmail program can read my email password in via
> stdin using getpass functionality.
>
> However, if I do
>
> echo password | getmail4
>
> it will fail due to stdin not being a terminal and therefore not being
> able to do a old = termios.tcgetattr(fd) on it.
>
> From what I can tell, the point of this is to only to prevent echoing
> the password, which isn't a problem in the echo case I give (especially
> if using bash, then it wont even be on the cmdline when run from a
> script as it's a builtin, script can also read in the password and store
> it in memory).
>
> currently the code is
>
> -
> def unix_getpass(prompt='Password: '):
> """Prompt for a password, with echo turned off.
>
> Restore terminal settings at end.
> """
>
> try:
> fd = sys.stdin.fileno()
> except:
> return default_getpass(prompt)
>
> old = termios.tcgetattr(fd) # a copy to save
> new = old[:]
>
> new[3] = new[3] & ~termios.ECHO # 3 == 'lflags'
> try:
> termios.tcsetattr(fd, termios.TCSADRAIN, new)
> passwd = _raw_input(prompt)
> finally:
> termios.tcsetattr(fd, termios.TCSADRAIN, old)
>
> sys.stdout.write('\n')
> return passwd
> -
>
> it would seem that if the tcgetattr() line is moved into the initial
> try, my echo case would work as expected (as it would fail, but be
> caught and then just run default_getpass() (which should just read it
> from stdin).
>
> Is there any reason not to do it this way?
It's certainly possible to have getpass() read from stdin
automatically, but it's traditionally understood that having it read
from a tty is much, much better. Suppose your program were meant to
use getpass, and then read a file from stdin. Now, all of a sudden,
you miss the first line of the file, and it becomes your password, for
no particular reason. getpass() works the way it does because it's
been working that way in C for decades.
If you really want to maintain a 'configuration file' for your
password, or have it available on command line, try adding an option
like -p or -p to whatever program you're writing.
--
Cheers,
Leif
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] getpass and stdin
Leif Walsh wrote:
> On Sun, Feb 24, 2008 at 1:02 PM, Shaya Potter <[EMAIL PROTECTED]> wrote:
>> [please cc me on responses]
>>
>> I was wondering if getpass could be changed to enable piped stdin to work.
>>
>> For instance, the getmail program can read my email password in via
>> stdin using getpass functionality.
>>
>> However, if I do
>>
>> echo password | getmail4
>>
>> it will fail due to stdin not being a terminal and therefore not being
>> able to do a old = termios.tcgetattr(fd) on it.
>>
>> From what I can tell, the point of this is to only to prevent echoing
>> the password, which isn't a problem in the echo case I give (especially
>> if using bash, then it wont even be on the cmdline when run from a
>> script as it's a builtin, script can also read in the password and store
>> it in memory).
>>
>> currently the code is
>>
>> -
>> def unix_getpass(prompt='Password: '):
>> """Prompt for a password, with echo turned off.
>>
>> Restore terminal settings at end.
>> """
>>
>> try:
>> fd = sys.stdin.fileno()
>> except:
>> return default_getpass(prompt)
>>
>> old = termios.tcgetattr(fd) # a copy to save
>> new = old[:]
>>
>> new[3] = new[3] & ~termios.ECHO # 3 == 'lflags'
>> try:
>> termios.tcsetattr(fd, termios.TCSADRAIN, new)
>> passwd = _raw_input(prompt)
>> finally:
>> termios.tcsetattr(fd, termios.TCSADRAIN, old)
>>
>> sys.stdout.write('\n')
>> return passwd
>> -
>>
>> it would seem that if the tcgetattr() line is moved into the initial
>> try, my echo case would work as expected (as it would fail, but be
>> caught and then just run default_getpass() (which should just read it
>> from stdin).
>>
>> Is there any reason not to do it this way?
>
> It's certainly possible to have getpass() read from stdin
> automatically, but it's traditionally understood that having it read
> from a tty is much, much better. Suppose your program were meant to
> use getpass, and then read a file from stdin. Now, all of a sudden,
> you miss the first line of the file, and it becomes your password, for
> no particular reason. getpass() works the way it does because it's
> been working that way in C for decades.
>
> If you really want to maintain a 'configuration file' for your
> password, or have it available on command line, try adding an option
> like -p or -p to whatever program you're writing.
the -p option is not good on multi user systems
the -p option is not particularly good on NFS based systems
(have to trust every user on every machine with access to NFS share)
and now, assuming what you say is part of the design behind the code
what's the point of this part of the code
>> try:
>> fd = sys.stdin.fileno()
>> except:
>> return default_getpass(prompt)
>>
i.e. the exception handler, default_getpass() is always going to read
from stdin at the end of the day.
line = sys.stdin.readline()
I'm assuming I'm missing something
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6 and 3.0 ...and applink.c?
> I don't understand how applink is going to help you. The SSL libs are statically linked > into the _ssl extension DLL. I personally have not used _ssl but on quick inspection I don't see any of the crypto algorithms implemented, AES, ECDSA, etc. What if we want to encrypt or sign content using OpenSSL? We'd import M2Crypto but when we go to load the key we'll get an OPENSSL_Applink error. Likewise for OpenSSL with xmlsec. Larry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] getpass and stdin
On Tue, Feb 26, 2008 at 12:43 PM, Shaya Potter <[EMAIL PROTECTED]> wrote: > the -p option is not good on multi user systems > the -p option is not particularly good on NFS based systems > (have to trust every user on every machine with access to NFS share) You seem somehow both worried about security, yet too lazy to type in your password. I think at some point, one of those concerns is going to have to give. > and now, assuming what you say is part of the design behind the code > > what's the point of this part of the code > > > >> try: > >> fd = sys.stdin.fileno() > >> except: > >> return default_getpass(prompt) > >> > > i.e. the exception handler, default_getpass() is always going to read > from stdin at the end of the day. > > line = sys.stdin.readline() > > I'm assuming I'm missing something Sorry, I only know my way around the libc version of getpass(), not the python one. In that version, typically we try to open /dev/tty for reading, and if that fails, we fall back to stdin. I presume that's what's going on here, but the first line appears to be getting stdin anyway, so I'm no longer sure. That said, why don't you just use default_getpass() in your code, if it reads from stdin to begin with? -- Cheers, Leif ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbots for trunk are all red
> - Alpha Tru64: test_smtplib.py is flaky, and _ssl.c is not compiled > correctly. Neil is hunting this, I think. Last time we looked at the _ssl problem, the machine had an out-of-date installation of OpenSSL. Don't know if that ever got rectified; I just crossed that buildbot off my list :-). Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] getpass and stdin
Leif Walsh wrote: > On Tue, Feb 26, 2008 at 12:43 PM, Shaya Potter <[EMAIL PROTECTED]> wrote: >> the -p option is not good on multi user systems >> the -p option is not particularly good on NFS based systems >> (have to trust every user on every machine with access to NFS share) > > You seem somehow both worried about security, yet too lazy to type in > your password. I think at some point, one of those concerns is going > to have to give. I want to run a program within a bash script, essentially daemonize a program that doesn't have a daemon mode. #!/bin/sh echo "What Is Your Passsword: " stty_orig=`stty -g` stty -echo read -r PASSWORD stty $stty_orig TIMEOUT=600 while [ 1 ] do echo $PASSWORD | program sleep $TIMEOUT done >> and now, assuming what you say is part of the design behind the code >> >> what's the point of this part of the code >> >> >> >> try: >> >> fd = sys.stdin.fileno() >> >> except: >> >> return default_getpass(prompt) >> >> >> >> i.e. the exception handler, default_getpass() is always going to read >> from stdin at the end of the day. >> >> line = sys.stdin.readline() >> >> I'm assuming I'm missing something > > Sorry, I only know my way around the libc version of getpass(), not > the python one. In that version, typically we try to open /dev/tty > for reading, and if that fails, we fall back to stdin. I presume > that's what's going on here, but the first line appears to be getting > stdin anyway, so I'm no longer sure. That said, why don't you just > use default_getpass() in your code, if it reads from stdin to begin > with? not my code, someone elses program, I can modify it, but that's a pain, was mostly wondering if it could be changed at the python level (or at least understand why python made the decision it did, sort of understand the eating stdin aspect) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] getpass and stdin
On Tue, Feb 26, 2008 at 1:18 PM, Shaya Potter <[EMAIL PROTECTED]> wrote: > I want to run a program within a bash script, essentially daemonize a > program that doesn't have a daemon mode. > > #!/bin/sh > > echo "What Is Your Passsword: " > stty_orig=`stty -g` > stty -echo > read -r PASSWORD > stty $stty_orig > > TIMEOUT=600 > > while [ 1 ] > do > echo $PASSWORD | program So...why won't `program -p $PASSWORD' work here? > sleep $TIMEOUT > done -- Cheers, Leif ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6 and 3.0 ...and applink.c?
> I personally have not used _ssl but on quick inspection I don't see any > of the crypto algorithms implemented, AES, ECDSA, etc. What if we want > to encrypt or sign content using OpenSSL? I suggested adding a class which gives you access to those. I think it's a good idea, and that serious use of SSL will require signing eventually. If you'd like to submit an RFE, particularly an RFE with a patch which includes a test case, that would move things along smartly. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6 and 3.0 ...and applink.c?
Bill Janssen wrote: [snip] Do you have an opinion on the initial proposal of applink.c? The proposal does neither seem harmful nor problematic but I also don't see how it is going to help the op. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [OT] Re: getpass and stdin
Shaya Potter <[EMAIL PROTECTED]> wrote: > Leif Walsh wrote: > > On Tue, Feb 26, 2008 at 12:43 PM, Shaya Potter <[EMAIL PROTECTED]> wrote: > >> the -p option is not good on multi user systems > >> the -p option is not particularly good on NFS based systems > >> (have to trust every user on every machine with access to NFS share) > > > > You seem somehow both worried about security, yet too lazy to type in > > your password. I think at some point, one of those concerns is going > > to have to give. That was exactly what I've been telling this user on the getmail mailing list for the last week. Apologies that he's decided to bother you with it. Charles -- -- Charles Cazabon <[EMAIL PROTECTED]> Software, consulting, and services available at http://pyropus.ca/ -- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [OT] Re: getpass and stdin
Charles Cazabon wrote: > Shaya Potter <[EMAIL PROTECTED]> wrote: >> Leif Walsh wrote: >>> On Tue, Feb 26, 2008 at 12:43 PM, Shaya Potter <[EMAIL PROTECTED]> wrote: the -p option is not good on multi user systems the -p option is not particularly good on NFS based systems (have to trust every user on every machine with access to NFS share) >>> You seem somehow both worried about security, yet too lazy to type in >>> your password. I think at some point, one of those concerns is going >>> to have to give. > > That was exactly what I've been telling this user on the getmail mailing list > for the last week. Apologies that he's decided to bother you with it. actually, 1) I am willing to type in the password, which is obvious to anyone who can read a simple script. That just doesn't work for a program you want to run in the background to type it in every time. 2) I was trying to understand why python made it's design decision, I don't need you apologizing for me trying to understand that (and I do ave a better understanding now) For those who want the background to make up their own minds about why I asked. Charles is the author of a program called getmail that is used for fetching email. - generally to fetch email you need a password. getmail will either read a passowrd in via getpass() or read it from a file. however, storing the password in a file is out of the question in this case (NFS), but reading the password in is fine, I'm not concerned with a threat of it being read out of memory. However, getmail doesn't have a daemon mode, charles recommends using the password in a file + cron, which I'd be fine with if I could store the password in a file. However, as I can't, I wanted to daemonize it via a script (already posted), that reads in a password from stdin and passes it to getmail via its stdout and getmail's stdin. However, that doesn't work with getpass() which getmail uses, and Charles isn't willing to change his program (it's his program he's allowed to do with it what he wants). I cam here after examining the python code and being confused by it and wanting to understand the design decision that went into it, as I sort of do now as I said in my last real email on the subject "understand the eating stdin aspect" That's it. Personally, I debated sending this email (don't need to waste people's time), but I don't appreciate being called out in public as Charles did when in truth while my question was spurred on by getmail it was something I was generally interested in understanding as well. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6 and 3.0 ...and applink.c?
> Bill Janssen wrote: > [snip] > > Do you have an opinion on the initial proposal of applink.c? The > proposal does neither seem harmful nor problematic but I also don't see > how it is going to help the op. > > Christian I know nothing about it -- it's a Windows thing. But reading the note at http://www.openssl.org/support/faq.html, I can see why Windows developers might like to have it: ``Note that debug and release libraries are NOT interchangeable. If you built OpenSSL with /MD your application must use /MD and cannot use /MDd. ``As per 0.9.8 the above limitation is eliminated for .DLLs. OpenSSL .DLLs compiled with some specific run-time option [we insist on the default /MD] can be deployed with application compiled with different option or even different compiler. But there is a catch! Instead of re-compiling OpenSSL toolkit, as you would have to with prior versions, you have to compile small C snippet with compiler and/or options of your choice. The snippet gets installed as /include/openssl/applink.c and should be either added to your application project or simply #include-d in one [and only one] of your application source files. Failure to link this shim module into your application manifests itself as fatal "no OPENSSL_Applink" run-time error. An explicit reminder is due that in this situation [mixing compiler options] it is as important to add CRYPTO_malloc_init prior first call to OpenSSL.'' Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6 and 3.0 ...and applink.c?
I appreciate the gesture but... At this juncture I'd prefer to see OpenSSL access to crypto APIs remain an external library like M2Crypto, at least until the Python community is willing to do a full implementation of all OpenSSL APIs. ...and maintain it. Larry -Original Message- From: Bill Janssen [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 26, 2008 10:14 AM To: Bugbee, Larry Cc: Christian Heimes; python-dev@python.org Subject: Re: [Python-Dev] Python 2.6 and 3.0 ...and applink.c? > I personally have not used _ssl but on quick inspection I don't see > any of the crypto algorithms implemented, AES, ECDSA, etc. What if we > want to encrypt or sign content using OpenSSL? I suggested adding a class which gives you access to those. I think it's a good idea, and that serious use of SSL will require signing eventually. If you'd like to submit an RFE, particularly an RFE with a patch which includes a test case, that would move things along smartly. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Python 2.6 and 3.0
> My problem is still getting my head
> around various MSI issues at any level (eg, bdist_msi needs some tweaking to
> allow for different releases of the same "package" to be recognized as such,
> but I'm not sure what MSI concept I'm dealing with yet...)
Don't hesitate to ask here. Not sure what problem you are talking to
specifically, but I guess you are asking for "upgrade codes"; there is
also upgrade codes and package codes.
Each package file should have its own unique *packageÜ code, mere
rebuilding should generate a new one. msilib does that correctly.
A package code code can be installed at most once on a system.
Related packages for the same software should share a *product* code.
Rebuilding should not change the package code (but might in msilib;
I'd have to check). Again, installer enforces that a specific package
code can only be installed once on a system. Python assigns a
separate product code for each bug fix release. Product codes
are most useful for uninstallation, e.g. to uninstall Python 2.5.1,
do
msiexec /x {3184-6386-4999-a519-518f2d78d8f0}
Use separate product codes if you want to allow for simultaneous
versions.
Subsequent versions of the same product should share an *upgrade*
code. MSI will check the Upgrade table, to see whether a package
with the same upgrade code (but a different product code) is
already installed, and if so, whether the version range matches.
If the installed product is newer, it will refuse to install the
older one. If the installed product is older, it will perform
an "upgrade installation", which involves uninstalling the older
version (possibly on a file-by-file basis), and possibly
migrating the feature selections.
Python uses a single upgrade code (until 2.5.2, which introduces
a separate upgrade code for Win64). It then uses version ranges
to make 2.5.2 an upgrade of 2.5.1 and 2.5.0, but not of 2.4.2
(say), essentially causing only one bug fix release per 2.5.x
to be installed on the system, but allowing simultaneous
installation of 2.5 and 2.4 (say). With 2.5.2, simultaneous
installation of Win64 and Win32 releases on a single system becomes
possible - which also requires to assign separate product codes
to Win64, namely
2.5.2, Win32: 6b976adf-8ae8-434e-b282-a06c7f624d2f
2.5.2, Win64: 6b976adf-8ae8-434e-b282-a06c7f624d20
> WiX is an excellent inspiration though - if a WiX example can be found for
> something, it should be a significant help in implementing it via msilib.
The current challenge is merge modules: How can I merge the VC msm into
the Python MSI (including support for SxS).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Python 2.6 and 3.0
>> No, I still haven't found a solution. I do want to use the merge >> module; anything else probably isn't going to work. > > Da...ng > Didn't you prepare a new MSI installer for 3.0a2 that includes the VS > Redist MSM for X86? I vaguely remember that you've replaced my installer > with a new one. Right. I produced a package that ships the CRT, but not by using the merge module. Instead, I arranged to include sufficient copies of the manifest file to make it work in the non-admin installation (and yes, you do need to install multiple copies of it - just see the 3.0a2 MSI file). > The issue should be resolved before Python 2.6 and 3.0 are reaching beta > stage. Maybe we can get some help from outside? Perhaps. I'm confident that I can find a solution when I get the time; I'm not so confident that I can find the time, though. Of course, I would prefer if the outside help would propose something better than "switch to this completely different technology; it may work" (unless a complete working solution is presented in that other technology, and as long as that other technology still creates MSI files with free-as-in-beer tools). In any case, contributions are welcome. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [OT] Re: getpass and stdin
On Tue, Feb 26, 2008 at 2:14 PM, Shaya Potter <[EMAIL PROTECTED]> wrote: > 1) I am willing to type in the password, which is obvious to anyone who > can read a simple script. That just doesn't work for a program you want > to run in the background to type it in every time. I recommend you just hack on this getmail program and give it a daemon mode. That shouldn't be too large of a task, and it will certainly be more secure (and you can even commit your changes as a new feature!). Otherwise, your best bet is probably, as Charles said, making the passfile work for you (maybe play with nfs and see if you can get it to hide things...I'm no wizard with it, but I'm willing to bet it's possible). > INTERNET DRAMA Let's just not continue this, shall we? -- Cheers, Leif ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Python 2.6 and 3.0
> What do you think? Feel free to try it out. I'm skeptical that it will be a better overall solution than the current one - the main difference would be that, rather than me being the only one who can realistically change the packaging chain, it would be you who is the only one - which, in principle, would be fine with me. I believe you need deep inside knowledge of the MSI database format for WiX, just as you do for using the automation API. I think I could learn WiX fairly quickly after all these years of learning MSI in the first place. I think the WiX designers did right in tying WiX so close to the MSI data model, but it means that WiX makes package creation not simpler - merely more productive for the experienced user (who I hesitate to call WiXers :-) In any case, when you work with WiX, I'm sure you'll gain a lot of expert knowledge on Windows packaging. Depending on your job situation, that might pay some day :-) Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [OT] Re: getpass and stdin
Leif Walsh wrote: > On Tue, Feb 26, 2008 at 2:14 PM, Shaya Potter <[EMAIL PROTECTED]> wrote: >> 1) I am willing to type in the password, which is obvious to anyone who >> can read a simple script. That just doesn't work for a program you want >> to run in the background to type it in every time. > > I recommend you just hack on this getmail program and give it a daemon > mode. That shouldn't be too large of a task, and it will certainly be > more secure (and you can even commit your changes as a new feature!). > Otherwise, your best bet is probably, as Charles said, making the > passfile work for you (maybe play with nfs and see if you can get it > to hide things...I'm no wizard with it, but I'm willing to bet it's > possible). I don't disagree (though nfs will never work, think root exploit on another machine, squash_root doesn't help). I wasn't posting here about how to change getmail (I can make those changes easily), the issue was simply understanding python's getpass(). Which you answered my question on, so thank you. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6 and 3.0 ...and applink.c?
> If not, I'd like to encourage its inclusion. Doing so will permit > Python to be used with OpenSSL 0.9.8x on Windows platforms without a > user trying to find somebody with the right compiler to rebuild a Python > for him/her. This is needed for M2Crypto, or any other OpenSSL wrapper > for that matter. A lot more can be said here, but in the interest of > brevity... ;-) > > applink.c is perhaps two dozen links and some error codes, and is benign > for those not calling these APIs. applink.c may be found in > /ms and the one line include stmt that would be > added to /Modules/python.c is: > #include "/applink.c" > That's it. As others said: please post a patch. I do believe that this it's *not* that. Including it in python.c does not help the least. Including it in pythonxy.dll may help. However, somebody would have to produce a patch, and a test case, and verify that the problem occurs without the patch, and is solved with the patch. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [OT] Re: getpass and stdin
On Tue, 26 Feb 2008 15:32:03 -0500 "Leif Walsh" <[EMAIL PROTECTED]> wrote: > On Tue, Feb 26, 2008 at 2:14 PM, Shaya Potter <[EMAIL PROTECTED]> wrote: > > 1) I am willing to type in the password, which is obvious to anyone who > > can read a simple script. That just doesn't work for a program you want > > to run in the background to type it in every time. > > I recommend you just hack on this getmail program and give it a daemon > mode. That shouldn't be too large of a task, and it will certainly be > more secure (and you can even commit your changes as a new feature!). > Otherwise, your best bet is probably, as Charles said, making the > passfile work for you (maybe play with nfs and see if you can get it > to hide things...I'm no wizard with it, but I'm willing to bet it's > possible). Actually, the easiest thing is probably to use a "file" that's not really a file, like /dev/stdin or <(cat -), http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6 and 3.0 ...and applink.c?
> Do you have an opinion on the initial proposal of applink.c? The > proposal does neither seem harmful nor problematic but I also don't see > how it is going to help the op. The specific change isn't going to help. What could help is the inclusion of applink.c into dl_nt.c. This is not about somehow exposing SSL routines to other libraries, but about exposing CRT stuff to openssl, specifically stdin/stdout/stderr, fprintf, fgets, fwrite, fsetmod, feof, ferror, clearerr, fileno, _open, _read, _write, _lseek, _close. Actually, re-reading OpenSSL, adding it to python.exe (and probably pythonw.exe) would help: They do GetModuleHandle(NULL) (which is the handle to the executable), then GetProcAddress for OPENSSL_Applink. So I think it's harmless and could help, except for the maintenance burden of having to update our local copy of applink.c every time OpenSSL adds a new slot to their applink table (which they should rarely do). Of course, the entire approach breaks in cases where Python gets embedded: if, e.g., IIS loads the Python interpreter as a COM scripting host, it would be the IIS executable which would have to include applink.c :-) As IIS doesn't, extension modules that link with their own OpenSSL will continue to produce a warning about the missing applink when they run in the context of a COM server (or some other Python embedding). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbots for trunk are all red
> - X86 XP-4: idem. For this two, how can be tried if the bsddb lib in > those windows is correctly installed? They check out bsddb from subversion, see Tools/buildbot/external. If you don't trust that they did so correctly, edit the script to remove bsddb, check that in, wait for them to delete it, then revert the script, check in again, and see how they build it. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6 and 3.0
> The Windows builds are hidden in the development section. It took me 10 > minutes to find them because I was searching in the download section and > for nightly builds. The *daily* builds are available at > http://www.python.org/dev/daily-msi/ The builds occur 11:00 UTC (2.5), 12:00 UTC (2.6) and 13:00 UTC (3.0). What that's at day or at night depends on where you live :-) Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbots for trunk are all red
2008/2/26, "Martin v. Löwis" <[EMAIL PROTECTED]>: > They check out bsddb from subversion, see Tools/buildbot/external. > If you don't trust that they did so correctly, edit the script to > remove bsddb, check that in, wait for them to delete it, then revert > the script, check in again, and see how they build it. No, I wasn't aware of this mechanisms at all. I don't even know how to build Python in a Windows... Anyway, I don't think it's a bad checkout or something, as the same error happens in two different machines. I don't know, :( -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbots for trunk are all red
On Tue, Feb 26, 2008 at 1:52 PM, Facundo Batista <[EMAIL PROTECTED]> wrote: > 2008/2/26, "Martin v. Löwis" <[EMAIL PROTECTED]>: > > > > They check out bsddb from subversion, see Tools/buildbot/external. > > If you don't trust that they did so correctly, edit the script to > > remove bsddb, check that in, wait for them to delete it, then revert > > the script, check in again, and see how they build it. > > No, I wasn't aware of this mechanisms at all. I don't even know how to > build Python in a Windows... > > Anyway, I don't think it's a bad checkout or something, as the same > error happens in two different machines. > > I don't know, :( Or we can get rid of bsddb and not have the problem anymore. =) -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6 and 3.0 ...and applink.c?
I won't pretend to know where the *best* place to put the include is, but python.c was suggested to me some time ago. Just so you know, we tried putting the include in some C code that is part of M2Crypto and it did not work because, as we discovered, the applink table needs to be part of main(). Extending that thought... If somebody wanted to somehow embed python is part of the same process in their program as with perhaps IIS, I submit it would not be part of main() and therefore benign. Now, I would like very much to be in a position to experiment with all the combinations and prepare a patch that worked, but I do not have the requisite Microsoft toolset. I primarily work with gcc under OSX, Linux, cygwin/mingw. This last raises a curiosity question. Is there a reason why Python.exe cannot be built using gcc instead of Visual Studio? Would not requiring the same VS version cause a problem in the field if someone were to receive an extension but had their Python built using a different version of VS? It seems building everything with gcc would get around the problem of having to match VS versions. ...or are we dependent on some specific Microsoft library? I dunno, I gotta ask. Larry -Original Message- From: "Martin v. Löwis" [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 26, 2008 1:10 PM To: Christian Heimes Cc: Bill Janssen; Bugbee, Larry; python-dev@python.org Subject: Re: [Python-Dev] Python 2.6 and 3.0 ...and applink.c? > Do you have an opinion on the initial proposal of applink.c? > The proposal does neither seem harmful nor problematic but I > also don't see how it is going to help the op. The specific change isn't going to help. What could help is the inclusion of applink.c into dl_nt.c. This is not about somehow exposing SSL routines to other libraries, but about exposing CRT stuff to openssl, specifically stdin/stdout/stderr, fprintf, fgets, fwrite, fsetmod, feof, ferror, clearerr, fileno, _open, _read, _write, _lseek, _close. Actually, re-reading OpenSSL, adding it to python.exe (and probably pythonw.exe) would help: They do GetModuleHandle(NULL) (which is the handle to the executable), then GetProcAddress for OPENSSL_Applink. So I think it's harmless and could help, except for the maintenance burden of having to update our local copy of applink.c every time OpenSSL adds a new slot to their applink table (which they should rarely do). Of course, the entire approach breaks in cases where Python gets embedded: if, e.g., IIS loads the Python interpreter as a COM scripting host, it would be the IIS executable which would have to include applink.c :-) As IIS doesn't, extension modules that link with their own OpenSSL will continue to produce a warning about the missing applink when they run in the context of a COM server (or some other Python embedding). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbots for trunk are all red
On Feb 26, 2008, at 5:04 PM, Brett Cannon wrote: > Or we can get rid of bsddb and not have the problem anymore. =) +1 for fewer problems. :) -Fred -- Fred Drake ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6 and 3.0
Martin v. Löwis wrote: >> The Windows builds are hidden in the development section. It took me 10 >> minutes to find them because I was searching in the download section and >> for nightly builds. The *daily* builds are available at >> http://www.python.org/dev/daily-msi/ > > The builds occur 11:00 UTC (2.5), 12:00 UTC (2.6) and 13:00 UTC (3.0). > What that's at day or at night depends on where you live :-) Trust me, the day and night cycle of our sun can be unrelated to the day and night cycle of my life. I define morning as the time span after my first coffee. I sometimes work until dawn so technically speaking 11:00 UTC could fit my definition of nightly build. :) Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbots for trunk are all red
On Tue, Feb 26, 2008 at 02:04:47PM -0800, Brett Cannon wrote: > Or we can get rid of bsddb and not have the problem anymore. =) +1 for smaller stdlib and fewer problems. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbots for trunk are all red
On 2/26/08, Brett Cannon <[EMAIL PROTECTED]> wrote: > > On Tue, Feb 26, 2008 at 1:52 PM, Facundo Batista > <[EMAIL PROTECTED]> wrote: > > 2008/2/26, "Martin v. Löwis" <[EMAIL PROTECTED]>: > > > > > > > They check out bsddb from subversion, see Tools/buildbot/external. > > > If you don't trust that they did so correctly, edit the script to > > > remove bsddb, check that in, wait for them to delete it, then revert > > > the script, check in again, and see how they build it. > > > > No, I wasn't aware of this mechanisms at all. I don't even know how to > > build Python in a Windows... > > > > Anyway, I don't think it's a bad checkout or something, as the same > > error happens in two different machines. > > > > I don't know, :( > > Or we can get rid of bsddb and not have the problem anymore. =) > > -Brett -1 Using that logic I prefer just getting rid of Windows to stop having these problems. That'd solve the ssl applink issue and msi installer building issue as well. =P My opinion on bsddb as a standard library module is based mostly on "its always been there" and a vague memory of the last time this came up I thought people piped up saying they liked batteries being included, including bsddb and sqlite, but I don't have a handy reference to that email thread. -gps ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbots for trunk are all red
On Tue, Feb 26, 2008 at 9:46 PM, Gregory P. Smith <[EMAIL PROTECTED]> wrote: > > > > On 2/26/08, Brett Cannon <[EMAIL PROTECTED]> wrote: > > On Tue, Feb 26, 2008 at 1:52 PM, Facundo Batista > > <[EMAIL PROTECTED]> wrote: > > > 2008/2/26, "Martin v. Löwis" <[EMAIL PROTECTED]>: > > > > > > > > > > They check out bsddb from subversion, see Tools/buildbot/external. > > > > If you don't trust that they did so correctly, edit the script to > > > > remove bsddb, check that in, wait for them to delete it, then revert > > > > the script, check in again, and see how they build it. > > > > > > No, I wasn't aware of this mechanisms at all. I don't even know how to > > > build Python in a Windows... > > > > > > Anyway, I don't think it's a bad checkout or something, as the same > > > error happens in two different machines. > > > > > > I don't know, :( > > > > Or we can get rid of bsddb and not have the problem anymore. =) > > > > -Brett > > -1 > > Using that logic I prefer just getting rid of Windows to stop having these > problems. That'd solve the ssl applink issue and msi installer building > issue as well. =P > =) Well, we can't have all our dreams come true. > My opinion on bsddb as a standard library module is based mostly on "its > always been there" and a vague memory of the last time this came up I > thought people piped up saying they liked batteries being included, > including bsddb and sqlite, but I don't have a handy reference to that email > thread. Well, in my opinion "batteries included" is great, but not when one of the batteries consistently acts up and requires a good shake to get working again. The bsddb module has consistent reliability issues when it comes to testing (and I suspect it has more to do with Sleepycat than the bindings). I know I am tired of getting buildbot errors saying that the bsddb tests died more consistently than most tests over their history. And I did some work on porting bsddb over to Python 3.0 and it was painful. Anyway, I am not pushing for this now. Any major removal plans will go through the stdlib-sig first and require justification before I even attempt to seriously suggest something beyond a joking line in an email (in other words, no one needs to worry about anything right now). -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Getting a second review on a rewrite of test_logging
I think over a week ago I applied some GHOP work that turned test_logging into a doctest, but it turns out it is still flaky. Luckily Antoine Pitrou rewrote test_logging using unittest and seems to have made it more sound. But before I replace test_logging again (especially with a more dramatic change) I would like to get a second pair of eyes on the patch as I really don't know the logging package that well. It's issue 1740 (http://bugs.python.org/issue1740). If you happen to know the logging package I would really appreciate it if you could give the patch a look. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
