Re: [Python-Dev] February bug day outcome
2008/2/25, A.M. Kuchling <[EMAIL PROTECTED]>: > Should we have one next month? The PyCon sprint will fall on Monday > through Thursday, and few people not at PyCon will be available during > the work week. OTOH, if we scheduled a bug day for the 29th, that's > two weeks after the conference, and we may have recovered from our > PyCon burnout at that point. What do people think? I'd try to avoid that weekend and the next one, because of PyWeek: http://www.pyweek.org/6/ Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Buildbots for trunk are all red
All fail in test_compiler.py. -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list [email protected] 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
Facundo Batista wrote: > All fail in test_compiler.py. Thomas Herve has worked out a patch: http://bugs.python.org/issue2177 Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] optimizing out local variables
Gregory P. Smith wrote: > On 2/24/08, Guido van Rossum <[EMAIL PROTECTED]> wrote: >> Let's only do it for -O; the optimization may interfere with debugging the >> code. > > > Does anyone ever actually bother to use -O? People may start bothering to use -O when it's giving them a speedup for real. How does -O affect Python code nowadays? IIRC it set __debug__ to false and removes asserts from the byte code. Christian ___ Python-Dev mailing list [email protected] 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
Mark Hammond wrote: > Me too - I still regularly build the svn version of Python, and although I > don't regularly turn them into .MSI files, I'm confident I could learn how to > do that ;) I understand that over time the binary process will need some > tweaking, but in the general case, I expect that turning the crank for a test > build needn't be that much or a burden. I expect the biggest problem is that > I could no longer ignore certain extensions I don't care about, such as Tk. It's not too hard. Tkinter, bsddb and friends are explained in PCbuild/README.txt. You should be able to compile them in less than half an hour. For the MSI installers you also need Python 2.5, your pywin32 package and some additional tools like the help compiler and cabarc.exe. Martin: Have you solved the problem with the VS CRT redist (http://bugs.python.org/issue1569)? Maybe Mark is able to assist you. Christian ___ Python-Dev mailing list [email protected] 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
-On [20080225 16:02], Christian Heimes ([EMAIL PROTECTED]) wrote: >For the MSI installers you also need Python 2.5, your pywin32 package >and some additional tools like the help compiler and cabarc.exe. Have you looked at http://wix.sourceforge.net/ ? -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ What good will it be for a man if he gains the whole world, yet forfeits his soul? ___ Python-Dev mailing list [email protected] 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
Jeroen Ruigrok van der Werven wrote: > Have you looked at http://wix.sourceforge.net/ ? WiX looks interesting but I'm neither in the position to change the installer nor do I have a strong opinion. It's Martin's area of expertise. On the one hand a XML based MSI generator could be easier to maintain. On the other hand it would introduce another dependency to a 3rd party tool and things may get complicated if we leave the road. Automation tools tend to make common things really easy but special and uncommon stuff really hard. Christian ___ Python-Dev mailing list [email protected] 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 Sun, Feb 24, 2008 at 07:06:42PM -0800, Neal Norwitz wrote: > I'd rather push it out to mid-month assuming Barry starts releasing > alphas at the end of each month. That should provide some time to > stabalize. Any one see the buildbots recently? :-( > http://www.python.org/dev/buildbot/all/ I've fixed a failure caused by test_curses.py. The test_compiler failure is due to the backporting of class decorators in rev. 60978; compiler/ast.py is out of the date, and the rest of compiler/ doubtless needs updating to actually support class decorators. --amk ___ Python-Dev mailing list [email protected] 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, Christian Heimes <[EMAIL PROTECTED]>: > Thomas Herve has worked out a patch: http://bugs.python.org/issue2177 After reviewing, testing and etc, I commited it. Let's see the buildbots! :) -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list [email protected] 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
Christian Heimes wrote: > Jeroen Ruigrok van der Werven wrote: > >> Have you looked at http://wix.sourceforge.net/ ? >> > > WiX looks interesting but I'm neither in the position to change the > installer nor do I have a strong opinion. It's Martin's area of expertise. > > On the one hand a XML based MSI generator could be easier to maintain. > On the other hand it would introduce another dependency to a 3rd party > tool and things may get complicated if we leave the road. Automation > tools tend to make common things really easy but special and uncommon > stuff really hard. > We build all our installers at Resolver Systems using Wix - dynamically generating parts of the templates and doing all sorts of weird and wonderful stuff (creating shortcuts, setting registry entries, testing dependencies, conditional includes in the installers and so on). Michael Foord > Christian > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk > ___ Python-Dev mailing list [email protected] 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, Facundo Batista <[EMAIL PROTECTED]>: > 2008/2/25, Christian Heimes <[EMAIL PROTECTED]>: > > > Thomas Herve has worked out a patch: http://bugs.python.org/issue2177 > > After reviewing, testing and etc, I commited it. Let's see the buildbots! :) Some are green, now, but others still are in red, failing in test_shelve.py, because of errors like this: == ERROR: test_get (test.test_shelve.TestAsciiFileShelve) -- Traceback (most recent call last): File "/opt/users/buildbot/slave/trunk.loewis-sun/build/Lib/test/mapping_tests.py", line 271, in test_get self.assert_(d.get(self.other.keys()[0]) is None) File "/opt/users/buildbot/slave/trunk.loewis-sun/build/Lib/shelve.py", line 104, in get if key in self.dict: TypeError: argument of type 'dbm.dbm' is not iterable Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list [email protected] 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 24, 2008, at 10:06 PM, Neal Norwitz wrote: > On Sun, Feb 24, 2008 at 6:52 PM, A.M. Kuchling <[EMAIL PROTECTED]> wrote: >> Yesterday's bug day was another success, closing 48 issues. Several >> committers were there: Facundo Bastista, Georg Brandl, and Christian >> Heimes. Facundo organized a local group of participants, and we >> committed a number of contributions from new people. >> >> Should we have one next month? The PyCon sprint will fall on Monday >> through Thursday, and few people not at PyCon will be available >> during >> the work week. OTOH, if we scheduled a bug day for the 29th, that's >> two weeks after the conference, and we may have recovered from our >> PyCon burnout at that point. What do people think? > > I'd rather push it out to mid-month assuming Barry starts releasing > alphas at the end of each month. That should provide some time to > stabalize. Any one see the buildbots recently? :-( > http://www.python.org/dev/buildbot/all/ That's a really good idea. At least for the alpha's I would like to have a policy that the monthly release goes out unless 1) There are critical bugs open for 2.6 and/or 3.0 2) The important buildbots are red (maybe) In either case, it should probably be a priority for bug day to repair those failures. On #1, I don't think there's a way to get roundup to give me exactly that report, e.g. all critical open bugs on both 2.6 and 3.0. Maybe I'm missing something, but given my intent, I'd find that useful. I know I can get search for each Python version independently, so that's good enough for now. Right now, I believe there are no critical bugs open on either version. On #2, clearly we can't wait for greens across the board, so which platforms are important enough to hold up a monthly release? I'd say something representative of the source release and each of the binary releases we make, so maybe: 2.6: source = x86 gentoo trunk, windows = x86 xp-4 trunk, mac = g4 osx. 4 trunk 3.0: source = x86 gentoo 3.0, windows = x86 xp-4 3.0, mac g4 osx.4 3.0 Unfortunately, basing release status on buildbot health doesn't look very encouraging. :( - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR8Mq53EjvBPtnXfVAQK9UwP/WFnuMNS3P93iO2z6sAMph9FXe733ErBW 6rey9i6EV1+P+iafzvA1V2d1tls166/JXmdz8VnGQI8ZmAWimzYgs4LsmKogeUCr Ttrioc4ZKMT2EWPUwzEQatzcbdgG3gpt+imJHT+KrIgMvSLFmLJiwH36f/Jk/rKS Bv6TYL1AO9g= =AFix -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] 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 24, 2008, at 9:19 AM, Christian Heimes wrote: > Barry Warsaw wrote: >> I'd also like for us to consider doing regular monthly releases. >> Several other FLOSS projects I'm involved with are doing this to very >> good success. The nice thing is that everyone knows well in advance >> when the next release is going to happen, and so all developers and >> users know what to expect and what is needed from them. >> >> I'd like to propose that we do a joint release the last Friday of >> every month. For the alphas, it's basically what's in svn. This >> gives us some time to experiment with the process out and see if we >> like it enough to keep it going through the betas and final releases. > > Thanks for volunteering for the job, Barry! > > +1 for release early, release often but I want to point out a resource > issue that may speak against a monthly release cycle. The Windows > binaries still require a large amount of attention and human > interaction. The last Windows binaries were build by me and I spent > half > the night ironing out issues and testing the installers. As far as I > know the team only Martin and I have the infrastructure and tools to > build the Windows binaries. 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. > We could cut down the time requirements by shipping only normal > binaries > instead of PGO (profile guided optimization) binaries. IMHO we could > also skip the AMD64 builds until we have reached beta stage. But it's > still going to cost either Martin or me the better half of a Friday > night. 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 won't have time to assist with the Windows builds next Friday. I'm > more than busy with personal life and job interviews. Hopefully I'm > going to find a job that allows me to work on the Python core as > much as > during the past few months. When's the PSF gonna start hiring? :) > That's for the Windows builds. Now I have a list of bugs and > features I > like to see fixed / applied before the next release: > > http://bugs.python.org/issue1692335 Fix exception pickling: Move > initial > args assignment to BaseException.__new__ > > http://bugs.python.org/issue1792 (trivial performance patch for > marshal) > > http://bugs.python.org/issue1569 MS VCRT redist issue. IIRC Martin > had a > working solution for it in his sandbox. > > http://bugs.python.org/issue1657 my kqueue and epoll patch, just needs > another review 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. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR8MuAHEjvBPtnXfVAQJ4JQP9F8AijArF8KhyxC7lp0ePDBGphgZjq7h8 9vZZ13oGOCtED/6M4bGDaZWrI1LEcj3iuf61Kdk6KwaeAi3dnGHkrP1XOTxZbLcz 8euKbC8JhBHan/A4SO4+xzxx4ZI9vCMRQqe+sLOQJsE9vH+4UMU1FDrhROxYwLbb aG0+fzGPdzA= =zpPQ -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 24, 2008, at 1:57 PM, Martin v. Löwis wrote: >> It very well might. See Christian Heimes's follow up re: Windows >> builds. OTOH, I'm okay if at least for the alphas, the binary >> builds lag behind the source releases, though I'd like to get the >> process as streamlined as possible. > > I can continue to provide Windows binaries if desired. Great, thanks! - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR8MuDXEjvBPtnXfVAQJeJwP/R8MMAhOsyRtpxIISEUoqMGDJksI5EtVM PcsxNO1p0MGcHfm5lNg0YNYwxsfc/0ghkRbsidegvcyN6BZWgHSaA7I0O1cBTG1x R4eNmLJBWCOcJNmTGgxCA7G8eEHTNTxneaQ0APO+yQbbHS/eyGGMcmFldNMkDqNO ycqikt0XiWI= =M3eC -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] 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
Facundo Batista a écrit : > 2008/2/25, Facundo Batista <[EMAIL PROTECTED]>: > > >> 2008/2/25, Christian Heimes <[EMAIL PROTECTED]>: >> >> > Thomas Herve has worked out a patch: http://bugs.python.org/issue2177 >> >> After reviewing, testing and etc, I commited it. Let's see the buildbots! :) >> > > Some are green, now, but others still are in red, failing in > test_shelve.py, because of errors like this: > > == > ERROR: test_get (test.test_shelve.TestAsciiFileShelve) > -- > Traceback (most recent call last): > File > "/opt/users/buildbot/slave/trunk.loewis-sun/build/Lib/test/mapping_tests.py", > line 271, in test_get > self.assert_(d.get(self.other.keys()[0]) is None) > File "/opt/users/buildbot/slave/trunk.loewis-sun/build/Lib/shelve.py", > line 104, in get > if key in self.dict: > TypeError: argument of type 'dbm.dbm' is not iterable > Hello, I've worked on that problem during the bug day. I've open a ticket with a patch at http://bugs.python.org/issue2168. -- Thomas ___ Python-Dev mailing list [email protected] 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
> On the one hand a XML based MSI generator could be easier to maintain. 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). > On the other hand it would introduce another dependency to a 3rd party > tool and things may get complicated if we leave the road. Automation > tools tend to make common things really easy but special and uncommon > stuff really hard. Exactly so. When I started with MSI generation, and tried what comes with Visual Studio, and found it unusable - it did not support Itanium, and could not be changed to support it. Regards, Martin ___ Python-Dev mailing list [email protected] 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
>> For the MSI installers you also need Python 2.5, your pywin32 package >> and some additional tools like the help compiler and cabarc.exe. > > Have you looked at http://wix.sourceforge.net/ ? Yes. Martin ___ Python-Dev mailing list [email protected] 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
> Have you solved the problem with the VS CRT redist > (http://bugs.python.org/issue1569)? Maybe Mark is able to assist you. No, I still haven't found a solution. I do want to use the merge module; anything else probably isn't going to work. Regards, Martin ___ Python-Dev mailing list [email protected] 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?
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... ;-) 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. And the OpenSSL FAQ: http://www.openssl.org/support/faq.html#PROG2 Tx, Larry ___ Python-Dev mailing list [email protected] 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?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Larry, On Feb 25, 2008, at 5:20 PM, Bugbee, Larry wrote: > 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! Honestly, I have no idea! I don't have any Windows machines so really have no way of testing this either. Maybe one of the other Windows gurus on this list can answer the question. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR8NFB3EjvBPtnXfVAQKZ1wP8Dv1aMdcbLM2NqpbWDdZLoeL7+91zVfTk VvyQzm4JkTjQtSVs/2ngHPjoIW3fNp6frQAwaf3pWICdyMj1OUXe/dRdhNaOwb44 guv5kIHtJmty3BHLJWUlFEC0IheWLRJuJhu0dz95E8jc21hEES7wVxg8jAwPcLqV 3TbscCqD+UI= =6qOy -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] 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 <[EMAIL PROTECTED]> writes: > On Feb 24, 2008, at 1:57 PM, Martin v. Löwis wrote: > >>> It very well might. See Christian Heimes's follow up re: Windows >>> builds. OTOH, I'm okay if at least for the alphas, the binary >>> builds lag behind the source releases, though I'd like to get the >>> process as streamlined as possible. >> >> I can continue to provide Windows binaries if desired. > > Great, thanks! Note that my buildbot is still also building MSIs each night based on the svn head for 2.5, 2.6 and 3.0, and uploading them back to python.org (viewable at http://www.python.org/dev/daily-msi). So at least for an alpha based on the current SVN trunk, that might be an easy place to grab a binary snapshot from, unless I'm missing something. Conversely, the machine is there to make builds upon request, I presume, depending on the master configuration. I know Martin set the current scheme up. -- David ___ Python-Dev mailing list [email protected] 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?
On Mon, Feb 25, 2008 at 2:20 PM, Bugbee, Larry <[EMAIL PROTECTED]> 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. The best way to encourage its inclusion is with a patch. :-) n ___ Python-Dev mailing list [email protected] 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 Mon, Feb 25, 2008 at 12:53 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > > That's a really good idea. At least for the alpha's I would like to > have a policy that the monthly release goes out unless > > 1) There are critical bugs open for 2.6 and/or 3.0 > 2) The important buildbots are red (maybe) > > In either case, it should probably be a priority for bug day to repair > those failures. > > On #2, clearly we can't wait for greens across the board, so which > platforms are important enough to hold up a monthly release? I'd say > something representative of the source release and each of the binary > releases we make, so maybe: > > 2.6: source = x86 gentoo trunk, windows = x86 xp-4 trunk, mac = g4 osx. > 4 trunk > 3.0: source = x86 gentoo 3.0, windows = x86 xp-4 3.0, mac g4 osx.4 3.0 > > Unfortunately, basing release status on buildbot health doesn't look > very encouraging. :( 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) 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. n ___ Python-Dev mailing list [email protected] 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
-On [20080225 23:03], "Martin v. Löwis" ([EMAIL PROTECTED]) wrote: >No, I still haven't found a solution. I do want to use the merge >module; anything else probably isn't going to work. I updated the ticket with some links to how to approach this issue. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ To conquer fear is the beginning of wisdom... ___ Python-Dev mailing list [email protected] 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 [20080226 06:05], Neal Norwitz ([EMAIL PROTECTED]) wrote: > 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) Might make sense to add at least one BSD box to the mix, generally when 1 BSD build works it should be quite similar on the rest. The above is a bit heavy on the Linux (glibc) side and will not really expose problems on that front aside from the commercial Solaris and OS X. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ The spirit indeed is willing, but the flesh is weak... ___ Python-Dev mailing list [email protected] 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 Mon, Feb 25, 2008 at 10:35 PM, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> wrote: > -On [20080226 06:05], Neal Norwitz ([EMAIL PROTECTED]) wrote: > > 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) > > Might make sense to add at least one BSD box to the mix, generally when 1 > BSD build works it should be quite similar on the rest. The above is a bit > heavy on the Linux (glibc) side and will not really expose problems on that > front aside from the commercial Solaris and OS X. 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: test test_smtplib failed -- Traceback (most recent call last): File "/usr/home/db3l/buildarea/trunk.bolen-freebsd/build/Lib/test/test_smtplib.py", line 375, in testBasic smtp = smtplib.SMTP(HOST, PORT, local_hostname='localhost', timeout=3) File "/usr/home/db3l/buildarea/trunk.bolen-freebsd/build/Lib/smtplib.py", line 237, in __init__ (code, msg) = self.connect(host, port) File "/usr/home/db3l/buildarea/trunk.bolen-freebsd/build/Lib/smtplib.py", line 294, in connect (code, msg) = self.getreply() File "/usr/home/db3l/buildarea/trunk.bolen-freebsd/build/Lib/smtplib.py", line 335, in getreply line = self.file.readline() File "/usr/home/db3l/buildarea/trunk.bolen-freebsd/build/Lib/socket.py", line 369, in readline data = self._sock.recv(self._rbufsize) timeout: timed out Ugh. I just looked at the test and see all the sleeps. I'll speed this test up by using events which will also hopefully reduce the flakiness. It currently takes 28 seconds. That should be decreased significantly. n ___ Python-Dev mailing list [email protected] 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: > 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. The issue should be resolved before Python 2.6 and 3.0 are reaching beta stage. Maybe we can get some help from outside? Christian ___ Python-Dev mailing list [email protected] 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? > Exactly so. When I started with MSI generation, and tried what comes > with Visual Studio, and found it unusable - it did not support > Itanium, and could not be changed to support it. Yeah, been there, got frustrated, went back :/ Christian ___ Python-Dev mailing list [email protected] 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: > 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. > 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? :] > 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. Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
