It seems logging is broken in 2.6.3. Should we release 2.6.4 quickly?
http://bugs.python.org/issue7052
Regards, Martin
Martin v. Löwis schrieb:
It seems logging is broken in 2.6.3. Should we release 2.6.4 quickly?
It also reports a 2.6.3rc1 version number on windows:
Python 2.6.3 (r263rc1:75186, Oct 2 2009, 20:40:30) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information.
Thomas
Le dimanche 04 octobre 2009 à 12:14 +0200, Thomas Heller a écrit :
Martin v. Löwis schrieb:
It seems logging is broken in 2.6.3. Should we release 2.6.4 quickly?
Perhaps we should leave a one-week delay between rc and final next time, so that this kind of late-minute issues have an opportunity to be discovered ?
Antoine> Perhaps we should leave a one-week delay between rc and final
Antoine> next time, so that this kind of late-minute issues have an
Antoine> opportunity to be discovered ?Yeah, I was a little surprised the final release followed rc1 so quickly. We were working through some problems on Solaris at work (I submitted several bugs as a result), but couldn't pump them out fast enough to get them seen before the final release went out.
Skip
On Oct 4, 2009, at 2:06 PM, skip@pobox.com wrote:
Antoine> Perhaps we should leave a one-week delay between rc and
final Antoine> next time, so that this kind of late-minute issues have an Antoine> opportunity to be discovered ?Yeah, I was a little surprised the final release followed rc1 so
quickly. We were working through some problems on Solaris at work (I submitted several bugs as a result), but couldn't pump them out fast enough to
get them seen before the final release went out.
But no release blockers in that set of bugs?
-Barry
Barry> But no release blockers in that set of bugs?I've no idea. By the time I could submit the reports the final release was out so I didn't even consider whether they would have been release blockers or not.
Skip
On Oct 4, 2009, at 7:38 AM, Antoine Pitrou wrote:
Perhaps we should leave a one-week delay between rc and final next
time, so that this kind of late-minute issues have an opportunity to be discovered ?
I'm skeptical it would have made a difference, and I seemed to have
misplaced the copy of Guido's time machine keys that I had, but it's a
worthwhile experiment anyway :).
Shall we say 2.6.4rc1 tomorrow-ish and if no rc2 is necessary, a final
release on Friday the 16th?
-Barry
I'm skeptical it would have made a difference, and I seemed to have misplaced the copy of Guido's time machine keys that I had, but it's a worthwhile experiment anyway :).
Shall we say 2.6.4rc1 tomorrow-ish and if no rc2 is necessary, a final release on Friday the 16th?
I'll likely be able to produce binaries only on Saturday (17th), but otherwise, the schedule sounds find to me (in particular as I'm travelling next week and won't be able to produce binaries between this Saturday and next Friday).
Regards, Martin
On Oct 5, 2009, at 5:00 PM, Martin v. Löwis wrote:
I'm skeptical it would have made a difference, and I seemed to have misplaced the copy of Guido's time machine keys that I had, but
it's a worthwhile experiment anyway :).Shall we say 2.6.4rc1 tomorrow-ish and if no rc2 is necessary, a
final release on Friday the 16th?I'll likely be able to produce binaries only on Saturday (17th), but otherwise, the schedule sounds find to me (in particular as I'm travelling next week and won't be able to produce binaries between
this Saturday and next Friday).
I could probably do a release on Saturday or Sunday.
-Barry
On Sun, 04 Oct 2009 12:14:23 +0200, "Thomas Heller" theller@ctypes.org said:
Martin v. Löwis schrieb:
It seems logging is broken in 2.6.3. Should we release 2.6.4 quickly?
It also reports a 2.6.3rc1 version number on windows:
Python 2.6.3 (r263rc1:75186, Oct 2 2009, 20:40:30) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information.
I did an upgrade in-place on Win XP. In c:\Python26 I found
python26.dll 2,084KB 4/14/2009 10:42 PM python.exe 26KB 10/2/2009 8:42 PM
When I ran python.exe from c:\Python26 I got
Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information.
I then re-ran the installer and 'repaired' Python. No difference.
I used the Control Panel to uninstall Python2.6. It didn't completely remove - python26.dll, msvcr90.dll, and Microsoft.VC90.CRT.manifest remained.
Reinstalled Python2.6 - no difference. Uninstalled Python26, deleted the Python26 directory, reinstalled Python 2.6.3. Now have correct version.
Found python26.dll in c:\Windows\System32\ with 10/2 date. Clearly this was being shadowed by the python26.dll in c:\Python26\. I have no idea where that came from - as far as I know, I had a vanilla 2.6.2 installation, and I don't build Python on Windows.
FWIW to the Windows gurus.
-- KBK
Found python26.dll in c:\Windows\System32\ with 10/2 date. Clearly this was being shadowed by the python26.dll in c:\Python26\. I have no idea where that came from - as far as I know, I had a vanilla 2.6.2 installation, and I don't build Python on Windows.
FWIW to the Windows gurus.
The final 2.6.3 release mistakenly identifies its svn tag as 263rc1. It still actually is the final release, as can be seen when looking at sys.version_info.
Regards, Martin
On Sun, 04 Oct 2009 20:20:33 +0200, ""Martin v. Löwis"" martin@v.loewis.de said:
Found python26.dll in c:\Windows\System32\ with 10/2 date. Clearly this was being shadowed by the python26.dll in c:\Python26\. I have no idea where that came from - as far as I know, I had a vanilla 2.6.2 installation, and I don't build Python on Windows.
FWIW to the Windows gurus.
The final 2.6.3 release mistakenly identifies its svn tag as 263rc1. It still actually is the final release, as can be seen when looking at sys.version_info.
Yes, but what I experienced is much worse - I was actually getting the 2.6.2 version of python26.dll due to shadowing, instead of the 2.6.3 version.
-- KBK
On Sun, 04 Oct 2009 20:47:28 +0200, ""Martin v. Löwis"" martin@v.loewis.de said:
Yes, but what I experienced is much worse - I was actually getting the 2.6.2 version of python26.dll due to shadowing, instead of the 2.6.3 version.
Ah. Did you get a message "[TARGETDIR] exists. Are you sure you want to overwrite existing files?"
I may well have, but that wouldn't surprise me when doing an upgrade in place.
The real problem, it seems, is there was a spurious python26.dll in c:\Python26, which shadowed the one in c:\Windows. That file may have been unique to my installation (I don't recall duplicating it - no reason to do so). But if other people have it subsequent to a 2.6.2 install, they will probably have the same difficulty I had.
-- KBK
Yes, but what I experienced is much worse - I was actually getting the 2.6.2 version of python26.dll due to shadowing, instead of the 2.6.3 version. Ah. Did you get a message "[TARGETDIR] exists. Are you sure you want to overwrite existing files?"
I may well have, but that wouldn't surprise me when doing an upgrade in place.
Ok, so I need to make the message more clear that this is an error, and that most likely you do not want to proceed. If this was an upgrade in place, the message would have read "This update will replace your existing [ProductLine] installation."
The real problem, it seems, is there was a spurious python26.dll in c:\Python26, which shadowed the one in c:\Windows.
Not spurious. Most likely, your previous installation was "just for me"; in this case, it cannot install into system32.
If you then do a "for all users" installation into the same location, you get the behavior that you observed: python26.dll gets installed to system32, and you end up with two copies of the DLL.
Regards, Martin
On Sun, 04 Oct 2009 21:42:29 +0200, ""Martin v. Löwis"" martin@v.loewis.de said:
Yes, but what I experienced is much worse - I was actually getting the 2.6.2 version of python26.dll due to shadowing, instead of the 2.6.3 version. Ah. Did you get a message "[TARGETDIR] exists. Are you sure you want to overwrite existing files?"
I may well have, but that wouldn't surprise me when doing an upgrade in place.
Ok, so I need to make the message more clear that this is an error, and that most likely you do not want to proceed. If this was an upgrade in place, the message would have read "This update will replace your existing [ProductLine] installation."
Well, I'm not at all sure that I saw the 'exists' message. That one is raised whenever the directory tree isn't empty?
The real problem, it seems, is there was a spurious python26.dll in c:\Python26, which shadowed the one in c:\Windows.
Not spurious. Most likely, your previous installation was "just for me"; in this case, it cannot install into system32.
Ah so! I think that is quite likely. I'm not a big Windows user and it took me a bit to realize the disadvantages of a 'just for me' installation on my netbook.
If you then do a "for all users" installation into the same location, you get the behavior that you observed: python26.dll gets installed to system32, and you end up with two copies of the DLL.
Is there a way to configure the installer so that if an 'all users' installation was being done, any python26.dll in c:\Python26 would be deleted? I'm surely not the only person who's going to run into this.
Thanks for the analysis.
-- KBK
Ok, so I need to make the message more clear that this is an error, and that most likely you do not want to proceed. If this was an upgrade in place, the message would have read "This update will replace your existing [ProductLine] installation."
Well, I'm not at all sure that I saw the 'exists' message. That one is raised whenever the directory tree isn't empty?
No, only if the directory exists, and isn't considered as having a version to upgrade.
Is there a way to configure the installer so that if an 'all users' installation was being done, any python26.dll in c:\Python26 would be deleted?
Unfortunately, no. That's why the warning message is issued that this kind of installation is probably the wrong thing to do.
Regards, Martin
On Oct 4, 2009, at 5:02 AM, Martin v. Löwis wrote:
It seems logging is broken in 2.6.3. Should we release 2.6.4 quickly?
I believe both the logging fix and the distutils fix is in the tree
now, right? There are no other release blockers in the tracker.
Unless there are objections, I will tag the tree for 2.6.4rc1 tomorrow
morning UTC-0400 and make the release as soon as the Mac image and
Windows binaries are available.
-Barry
Unless there are objections, I will tag the tree for 2.6.4rc1 tomorrow morning UTC-0400 and make the release as soon as the Mac image and Windows binaries are available.
-Barry
I think it will be nice if issue6869 will be fixed before 2.6.4. (This is crash bug, so)
And I'm happy if r74952 will be backported as well. :-)
On Oct 6, 2009, at 5:46 AM, Hirokazu Yamamoto wrote:
Unless there are objections, I will tag the tree for 2.6.4rc1
tomorrow morning UTC-0400 and make the release as soon as the Mac
image and Windows binaries are available. -BarryI think it will be nice if issue6869 will be fixed before 2.6.4. (This is crash bug, so)
And I'm happy if r74952 will be backported as well. :-)
I want to keep 2.6.4 tightly focussed on fixing the brown paper bag
bugs in logging and distutils. Sorry, but this will have to wait for
2.6.5.
-Barry
participants (7)
-
"Martin v. Löwis" -
Antoine Pitrou -
Barry Warsaw -
Hirokazu Yamamoto -
Kurt B. Kaiser -
skip＠pobox.com -
Thomas Heller