[ python-Bugs-978833 ] SSL-ed sockets don't close correct?
Bugs item #978833, was opened at 2004-06-24 11:57
Message generated for change (Comment added) made by kxroberto
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978833&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
>Group: Python 2.4
>Status: Open
>Resolution: None
>Priority: 8
Submitted By: Robert Kiendl (kxroberto)
>Assigned to: Brett Cannon (bcannon)
Summary: SSL-ed sockets don't close correct?
Initial Comment:
When testing FTP over SSL I have strong doubt, that
ssl-ed sockets are not closed correctly. (This doesn't
show with https because nobody takes care about whats
going on "after the party".) See the following :
---
I need to run FTP over SSL from windows (not shitty
sftp via ssh etc!)
as explained on
http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html
(good variant
3: FTP_TLS )
I tried to learn from M2Crypto's ftpslib.py (uses
OpenSSL - not
Pythons SSL) and made a wrapper for ftplib.FTP using
Pythons SSL.
I wrap the cmd socket like:
self.voidcmd('AUTH TLS')
ssl = socket.ssl(self.sock, self.key_file,
self.cert_file)
import httplib
self.sock = httplib.FakeSocket(self.sock, ssl)
self.file = self.sock.makefile('rb')
Everything works ok, if I don't SSL the data port
connection, but only
the
If I SSL the data port connection too, it almosts work,
but ...
self.voidcmd('PBSZ 0')
self.voidcmd('PROT P')
wrap the data connection with SSL:
ssl = socket.ssl(conn, self.key_file,
self.cert_file)
import httplib
conn = httplib.FakeSocket(conn, ssl)
than in retrbinary it hangs endless in the last 'return
self.voidresp()'. all data of the retrieved file is
already correctly
in my basket! The ftp server just won't send the final
'226 Transfer
complete.' on the cmd socket. Why?
def retrbinary(self, cmd, callback, blocksize=8192,
rest=None):
self.voidcmd('TYPE I')
conn = self.transfercmd(cmd, rest)
fp = conn.makefile('rb')
while 1:
#data = conn.recv(blocksize)
data = fp.read()#blocksize)
if not data:
break
callback(data)
fp.close()
conn.close()
return self.voidresp()
what could be reason?
The server is a ProFTPD 1.2.9 Server.
I debugged, that the underlying (Shared)socket of the
conn object is
really closed.
(If I simly omit the self.voidresp(), I have one file
in the box, but
subsequent ftp communication on that connection is not
anymore
correct.)
--
>Comment By: Robert Kiendl (kxroberto)
Date: 2005-09-24 21:06
Message:
Logged In: YES
user_id=972995
I retried that again with py2.4.1. The problem/bug is still
there.
In attachment I supplied a full FTPS client test_ftpslib.py
with simple test function - ready to run into the problem:
At the end of ftp.retrlines 'return self.voidresp()'
freezes : waiting eternally for response bytes at the
command port. the same at the end of .storelines after the
data is transfered on the data port.
My preliminary guess is still, that python's ssl has a
severe (EOF?) problem closing a socket/connection correctly.
obviously this problem doesn't show up with https because
everything is done on one connection - no dependency on a
correct socket/connect close signal.
(from other https communication with some proxies in between
my users get ssl-eof-error errors also. I still can't solve
that bug too. this shows python's ssl has a severe EOF bug
with complex https also - or cannot handle certain
situations correct.)
I learned the FTPS/TLS client from M2crypto's ftpslib. the
only difference in (transposed) logic, that I can see is,
that M2crpyto uses an additional line
"conn.set_session(self.sock.get_session())" during setup of
the data port ssl connection. I don't know what it is,
pythons ssl doesn't have sucht "session"-functions, but I
think it has no severe meaning.?
Robert
--
Comment By: Brett Cannon (bcannon)
Date: 2004-12-22 06:14
Message:
Logged In: YES
user_id=357491
Since I believe this was fixed with the patch Tino mentions and Roberto
has not replied, I am closing as fixed.
--
Comment By: Brett Cannon (bcannon)
Date: 2004-08-17 01:18
Message:
Logged In: YES
user_id=357491
Is this still a problem for you, Roberto, with Python 2.4a2?
--
Comment By: Tino Lange (tinolange)
Date: 2004-07-11 00:30
Message:
Logged In: YES
user_id=212920
Hi Roberto!
Today a patch for _ssl.c was checked in (see #945642) that
might solve your problem, too.
Could you please grab the
[ python-Feature Requests-1303434 ] Please include pdb with windows distribution
Feature Requests item #1303434, was opened at 2005-09-24 19:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1303434&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lyle Thompson (lylefile) Assigned to: Nobody/Anonymous (nobody) Summary: Please include pdb with windows distribution Initial Comment: Checking out the source files and rebuilding is not guaranteed to build a program database (pdb) file that represents the distribution python DLL. This may be due to a differences in the windows version or visual studio service pack on my system vs the one used to build the distribution, but tracking it down can be very time consuming. Including the pdb in the distribution should be trivial and avoid this problem entirely. Although I can fix the problem for future releases of our product, I am also supporting previous releases that included the standard DLL included in the distribution. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1303434&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-978833 ] SSL-ed sockets don't close correct?
Bugs item #978833, was opened at 2004-06-24 11:57
Message generated for change (Comment added) made by kxroberto
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978833&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 8
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Brett Cannon (bcannon)
Summary: SSL-ed sockets don't close correct?
Initial Comment:
When testing FTP over SSL I have strong doubt, that
ssl-ed sockets are not closed correctly. (This doesn't
show with https because nobody takes care about whats
going on "after the party".) See the following :
---
I need to run FTP over SSL from windows (not shitty
sftp via ssh etc!)
as explained on
http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html
(good variant
3: FTP_TLS )
I tried to learn from M2Crypto's ftpslib.py (uses
OpenSSL - not
Pythons SSL) and made a wrapper for ftplib.FTP using
Pythons SSL.
I wrap the cmd socket like:
self.voidcmd('AUTH TLS')
ssl = socket.ssl(self.sock, self.key_file,
self.cert_file)
import httplib
self.sock = httplib.FakeSocket(self.sock, ssl)
self.file = self.sock.makefile('rb')
Everything works ok, if I don't SSL the data port
connection, but only
the
If I SSL the data port connection too, it almosts work,
but ...
self.voidcmd('PBSZ 0')
self.voidcmd('PROT P')
wrap the data connection with SSL:
ssl = socket.ssl(conn, self.key_file,
self.cert_file)
import httplib
conn = httplib.FakeSocket(conn, ssl)
than in retrbinary it hangs endless in the last 'return
self.voidresp()'. all data of the retrieved file is
already correctly
in my basket! The ftp server just won't send the final
'226 Transfer
complete.' on the cmd socket. Why?
def retrbinary(self, cmd, callback, blocksize=8192,
rest=None):
self.voidcmd('TYPE I')
conn = self.transfercmd(cmd, rest)
fp = conn.makefile('rb')
while 1:
#data = conn.recv(blocksize)
data = fp.read()#blocksize)
if not data:
break
callback(data)
fp.close()
conn.close()
return self.voidresp()
what could be reason?
The server is a ProFTPD 1.2.9 Server.
I debugged, that the underlying (Shared)socket of the
conn object is
really closed.
(If I simly omit the self.voidresp(), I have one file
in the box, but
subsequent ftp communication on that connection is not
anymore
correct.)
--
>Comment By: Robert Kiendl (kxroberto)
Date: 2005-09-24 21:45
Message:
Logged In: YES
user_id=972995
Now I managed to solve the problem for me with attached
patch of httplib.py: a explicit shutdown ( 2 or 1 ) of the
(faked) ssl'ed socket solves it.
I still guess the ssl'ed socket (ssl dll) should do that
auto on sock.close()
Thus I leave it as a bug HERE. Right?
[ I also have the hope, that this also solves the
ssl-eof-errors with https (of some of my users; will see
this in future)
*** \usr\src\py24old/httplib.py Sat Sep 24 21:35:28 2005
--- httplib.py Sat Sep 24 21:37:48 2005
*** class SharedSocket:
*** 899,904
--- 899,905
self._refcnt -= 1
assert self._refcnt >= 0
if self._refcnt == 0:
+ self.sock.shutdown(2)
self.sock.close()
def __del__(self):
--
Comment By: Robert Kiendl (kxroberto)
Date: 2005-09-24 21:06
Message:
Logged In: YES
user_id=972995
I retried that again with py2.4.1. The problem/bug is still
there.
In attachment I supplied a full FTPS client test_ftpslib.py
with simple test function - ready to run into the problem:
At the end of ftp.retrlines 'return self.voidresp()'
freezes : waiting eternally for response bytes at the
command port. the same at the end of .storelines after the
data is transfered on the data port.
My preliminary guess is still, that python's ssl has a
severe (EOF?) problem closing a socket/connection correctly.
obviously this problem doesn't show up with https because
everything is done on one connection - no dependency on a
correct socket/connect close signal.
(from other https communication with some proxies in between
my users get ssl-eof-error errors also. I still can't solve
that bug too. this shows python's ssl has a severe EOF bug
with complex https also - or cannot handle certain
situations correct.)
I learned the FTPS/TLS client from M2crypto's ftpslib. the
only difference in (transposed) logic, that I can see is,
that M2crpyto uses an additional line
"conn.set_session(self.sock.get_session())" during setup of
the data port ssl connection. I don't know what it is,
p
[ python-Bugs-1303614 ] Bypassing __dict__ readonlyness
Bugs item #1303614, was opened at 2005-09-24 23:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: Bypassing __dict__ readonlyness Initial Comment: The __dict__ attribute of some objects is read-only, e.g. for type objects. However, there is a generic way to still access and modify it (without hacking with gc.get_referrents(), that is). This can lead to obscure crashes. Attached is an example that shows a potential "problem" involving putting strange keys in the __dict__ of a type. This is probably very minor anyway. If we wanted to fix this, we would need a __dict__ descriptor that looks more cleverly at the object to which it is applied. BTW the first person who understand why the attached program crashes gets a free coffee. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1303673 ] traceback on trying to load a file
Bugs item #1303673, was opened at 2005-09-24 21:46
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303673&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: nanotube (nanotube)
Assigned to: Nobody/Anonymous (nobody)
Summary: traceback on trying to load a file
Initial Comment:
When trying to load a file generated by hotshotmain.py
(attached), generates the following traceback:
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import hotshot.stats
>>> hotshot.stats.load("pyk.prof")
Traceback (most recent call last):
File "", line 1, in ?
File "C:\Python24\lib\hotshot\stats.py", line 12, in load
return StatsLoader(filename).load()
File "C:\Python24\lib\hotshot\stats.py", line 51, in load
assert not self._stack
AssertionError
This happened with both python 2.4.1 and with python
2.4.2 rc 1 on windows (just downloaded).
Seems similar to bug [ 900092 ] hotshot.stats.load
(link:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900092&group_id=5470
)
but according to that, bug has been closed, and patch
has been applied to python 2.4.2. not sure if that
applies also to 2.4.2 rc1
Attaching the output file that caused it.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303673&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1244610 ] 2.4.1 build fails on OpenBSD 3.7
Bugs item #1244610, was opened at 2005-07-25 09:31
Message generated for change (Comment added) made by lpd
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244610&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: L. Peter Deutsch (lpd)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.4.1 build fails on OpenBSD 3.7
Initial Comment:
Python 2.4.1, OpenBSD 3.7, gcc (GCC) 3.3.5 (propolice).
I'm including the logs here because they are short.
"./configure" printed the following:
checking curses.h usability... no
checking curses.h presence... yes
configure: WARNING: curses.h: present but cannot be
compiled
configure: WARNING: curses.h: check for missing
prerequisite headers?
configure: WARNING: curses.h: see the Autoconf
documentation
configure: WARNING: curses.h: section "Present But
Cannot Be Compiled"
configure: WARNING: curses.h: proceeding with the
preprocessor's result
configure: WARNING: curses.h: in the future, the
compiler will take precedence
configure: WARNING: ##
##
configure: WARNING: ## Report this to
http://www.python.org/python-bugs ##
configure: WARNING: ##
##
checking for curses.h... yes
This warning was printed for curses.h, ncurses.h,
sys/audioio.h, and sys/lock.h. (The reference to
"Autoconf documentation" is useless, because autoconf
is not used during the configure process, and is not
even installed on the system where I was doing the
build.) Then:
% make
gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3
-Wall -Wstrict-prototypes -I. -I./Include
-DPy_BUILD_CORE -o Modules/python.o Modules/python.c
In file included from /usr/include/sys/select.h:38,
from Include/pyport.h:116,
from Include/Python.h:55,
from Modules/python.c:3:
/usr/include/sys/event.h:53: error: syntax error before
"u_int"
/usr/include/sys/event.h:55: error: syntax error before
"u_short"
*** Error code 1
Stop in /usr/src/Python-2.4.1.
--
>Comment By: L. Peter Deutsch (lpd)
Date: 2005-09-24 19:10
Message:
Logged In: YES
user_id=8861
OK, I've found out what goes wrong. (Debugging a
20,000+-line 'configure' script that omits all useful
information from its output and throws away all its
intermediate files *even if it detects errors* is not fun.)
With the set of configuration options that the script
decides is appropriate (too long to include here),
compilation of a dummy .c file that #includes
fails thusly:
In file included from /usr/include/curses.h:14,
from t.h:54,
from t.c:1:
/usr/include/ncurses.h:251: error: conflicting types for
`wchar_t'
/usr/include/stdlib.h:51: error: previous declaration of
`wchar_t'
This apparently happens because of line 1483 of the
configure script, which reads:
OpenBSD/2.* | OpenBSD/3.[0123456])
I can't fathom why OpenBSD 3.7 and later are excluded here,
especially since (1) there are other places in the script
that include all OpenBSD/3.* versions, and (2) the situation
described by the comment just above this line is still true
in OpenBSD 3.7. In any case, changing this line to read
OpenBSD/2.* | OpenBSD/3.*)
causes configure (and a subsequent make) to complete with no
errors. So apparently other things are broken in the OpenBSD
headerfiles if _XOPEN_SOURCE is defined, not just select(2).
I hope someone authorized to do so will make this fix for
Python 2.4.. TIA.
--
Comment By: Hye-Shik Chang (perky)
Date: 2005-08-28 01:10
Message:
Logged In: YES
user_id=55188
For curses.h problem, it doesn't harm the build much in
fact. It's already reported to FreeBSD bugdb
http://www.FreeBSD.org/cgi/query-pr.cgi?pr=84219 and I think
it's identical problem on OpenBSD.
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-08-09 11:40
Message:
Logged In: YES
user_id=21627
Can somebody attach a config.log, or reproduce the fragment
that deals with the curses.h presence?
Does your system require any headers to be included for
curses.h to be usable? I.e. if you do
#include
int main(){}
will that program compile, or do you need additional
('prerequisite') headers?
--
Comment By: johnnie pittman (jp3g)
Date: 2005-08-08 23:34
Message:
Logged In: YES
user_id=1203137
Hey folks,
Also seeing this issue on 3.7. Same setup described above.
Loewis, not sure about the first part of your comment. If
your asking if those header files exist and are avai
[ python-Bugs-1244610 ] 2.4.1 build fails on OpenBSD 3.7
Bugs item #1244610, was opened at 2005-07-25 18:31 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244610&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4.1 build fails on OpenBSD 3.7 Initial Comment: Python 2.4.1, OpenBSD 3.7, gcc (GCC) 3.3.5 (propolice). I'm including the logs here because they are short. "./configure" printed the following: checking curses.h usability... no checking curses.h presence... yes configure: WARNING: curses.h: present but cannot be compiled configure: WARNING: curses.h: check for missing prerequisite headers? configure: WARNING: curses.h: see the Autoconf documentation configure: WARNING: curses.h: section "Present But Cannot Be Compiled" configure: WARNING: curses.h: proceeding with the preprocessor's result configure: WARNING: curses.h: in the future, the compiler will take precedence configure: WARNING: ## ## configure: WARNING: ## Report this to http://www.python.org/python-bugs ## configure: WARNING: ## ## checking for curses.h... yes This warning was printed for curses.h, ncurses.h, sys/audioio.h, and sys/lock.h. (The reference to "Autoconf documentation" is useless, because autoconf is not used during the configure process, and is not even installed on the system where I was doing the build.) Then: % make gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o Modules/python.c In file included from /usr/include/sys/select.h:38, from Include/pyport.h:116, from Include/Python.h:55, from Modules/python.c:3: /usr/include/sys/event.h:53: error: syntax error before "u_int" /usr/include/sys/event.h:55: error: syntax error before "u_short" *** Error code 1 Stop in /usr/src/Python-2.4.1. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-09-25 06:23 Message: Logged In: YES user_id=21627 The issue reported here results from a bug in OpenBSD: ncurses.h and stdlib.h have conflicting definitions of wchar_t. This means the system is simply broken, and should be fixed (or abandoned) eventually. Python has a work-around for the bug, for those versions in which the bug has been confirmed. So far, the bug had not been confirmed for 3.7. Now it is, so we should add 3.7 to the list of systems that still show the bug. Changing it to 3.* would be incorrect - we cannot know whether the bug will be present in 3.8, as that system has not been released yet. -- Comment By: L. Peter Deutsch (lpd) Date: 2005-09-25 04:10 Message: Logged In: YES user_id=8861 OK, I've found out what goes wrong. (Debugging a 20,000+-line 'configure' script that omits all useful information from its output and throws away all its intermediate files *even if it detects errors* is not fun.) With the set of configuration options that the script decides is appropriate (too long to include here), compilation of a dummy .c file that #includes fails thusly: In file included from /usr/include/curses.h:14, from t.h:54, from t.c:1: /usr/include/ncurses.h:251: error: conflicting types for `wchar_t' /usr/include/stdlib.h:51: error: previous declaration of `wchar_t' This apparently happens because of line 1483 of the configure script, which reads: OpenBSD/2.* | OpenBSD/3.[0123456]) I can't fathom why OpenBSD 3.7 and later are excluded here, especially since (1) there are other places in the script that include all OpenBSD/3.* versions, and (2) the situation described by the comment just above this line is still true in OpenBSD 3.7. In any case, changing this line to read OpenBSD/2.* | OpenBSD/3.*) causes configure (and a subsequent make) to complete with no errors. So apparently other things are broken in the OpenBSD headerfiles if _XOPEN_SOURCE is defined, not just select(2). I hope someone authorized to do so will make this fix for Python 2.4.. TIA. -- Comment By: Hye-Shik Chang (perky) Date: 2005-08-28 10:10 Message: Logged In: YES user_id=55188 For curses.h problem, it doesn't harm the build much in fact. It's already reported to FreeBSD bugdb http://www.FreeBSD.org/cgi/query-pr.cgi?pr=84219 and I think it's identical problem on OpenBSD. -- Comment By: Ma
[ python-Bugs-1302793 ] 2.4.1 windows MSI has no _socket
Bugs item #1302793, was opened at 2005-09-24 07:53 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1302793&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None >Priority: 9 Submitted By: IamPaul (heartlesshind) >Assigned to: Martin v. Löwis (loewis) Summary: 2.4.1 windows MSI has no _socket Initial Comment: The precompiled windows binary installer doesn't seem to provide a _socket module eg. >>> import urllib Traceback (most recent call last): File "", line 1, in ? File "c:\Python24\Lib\urllib.py", line 26, in ? import socket File "c:\Python24\Lib\socket.py", line 45, in ? import _socket ImportError: No module named _socket This bears some resemblance to [ 1298709 ] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1302793&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1298962 ] MSI installer does not pass values as SecureProperty from UI
Bugs item #1298962, was opened at 2005-09-22 19:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298962&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Leslie (matthewleslie) Assigned to: Nobody/Anonymous (nobody) Summary: MSI installer does not pass values as SecureProperty from UI Initial Comment: This appears to be an instance of the problem documented here: http://tinyurl.com/82dt2 aka: http://groups.google.nl/group/microsoft.public.platformsdk.msi/browse_thread/thread/2359de6cc83c3b2f/67ef84f8f0ba99db?lnk=st&q=%22Ignoring+disallowed+property%22+msi&rnum=4&hl=nl#67ef84f8f0ba99db I ran into problems installing as a 'power user' but not an admin on a windows XP box. The program was always installing in C:/ Running msiexec with logging revealed the following lines: MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property X MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property TARGETDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property DLLDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property USERNAME MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property COMPANYNAME MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property SOURCEDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property ROOTDRIVE Values were not being passed from the UI to the actual installation script. This is apparently a known issue which can be resolved by using SecureCustomProperties to pass them from the UI to the installer, as documented in the link above. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-09-25 06:35 Message: Logged In: YES user_id=21627 What specific problems did you run into? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298962&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1292634 ] The _ssl build process for 2.3.5 is broken
Bugs item #1292634, was opened at 2005-09-16 09:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1292634&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robert Cheung (robertcheung) Assigned to: Nobody/Anonymous (nobody) Summary: The _ssl build process for 2.3.5 is broken Initial Comment: I have attempted to build the _ssl library for 2.3.5 and it is broken (see attached output 1). Basically it is complaining that the _ssl.pyd file could not be build because several symbols (GetUserObjectInformation, etc) could not be linked. Those symbols are suppose to be located in User32.[lib|dll]. Appending User32.lib to line 15 of _ssl.mak fixed this problem (see attachment 2). Hopefully this will be helpful for other people that also had build problems with the ssl library. Regards Robert Cheung Attached output 1-- C:\downloads\python\Python-2.3.5\PCbuild>python build_ssl.py Found a working perl at 'C:\Perl\bin\perl.exe' Found an SSL directory at 'C:\downloads\python\openssl-0.9.8' Executing nmake over the ssl makefiles... Building OpenSSL copy nul+ .\crypto\buildinf.h tmp32\buildinf.h nul .\crypto\buildinf.h 1 file(s) copied. cl /nologo ../Modules/_ssl.c C:\downloads\python\openssl-0.9.8/out32/libeay32.lib C:\downloads\python\openssl-0.9.8/out32/ssleay32.lib /Ox /MD /LD /Fox86-temp-release/_ssl\_ssl.obj -I ../Include -I ../PC -I C:\downloads\python\openssl-0.9.8/inc32 /link /out:_ssl.pyd gdi32.lib wsock32.lib /libpath:C:\downloads\p ython\openssl-0.9.8/out32 libeay32.lib ssleay32.lib _ssl.c Creating library _ssl.lib and object _ssl.exp libeay32.lib(cryptlib.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _OPENSSL_isservice libeay32.lib(cryptlib.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _OPENSSL_isservice libeay32.lib(cryptlib.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _OPENSSL_isservice libeay32.lib(cryptlib.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _OPENSSL_showfatal _ssl.pyd : fatal error LNK1120: 4 unresolved externals NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. Attachment 2 - _ssl.mak line 15 - LIBS=gdi32.lib wsock32.lib /libpath:$(SSL_LIB_DIR) libeay32.lib ssleay32.lib User32.lib -- >Comment By: Martin v. Löwis (loewis) Date: 2005-09-25 06:38 Message: Logged In: YES user_id=21627 You are using an unsupported version of OpenSSL. Please try the version mentioned in PCbuild/readme.txt. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1292634&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1303673 ] traceback on trying to load a hotshot stats file
Bugs item #1303673, was opened at 2005-09-25 03:46
Message generated for change (Settings changed) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303673&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: nanotube (nanotube)
Assigned to: Nobody/Anonymous (nobody)
>Summary: traceback on trying to load a hotshot stats file
Initial Comment:
When trying to load a file generated by hotshotmain.py
(attached), generates the following traceback:
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import hotshot.stats
>>> hotshot.stats.load("pyk.prof")
Traceback (most recent call last):
File "", line 1, in ?
File "C:\Python24\lib\hotshot\stats.py", line 12, in load
return StatsLoader(filename).load()
File "C:\Python24\lib\hotshot\stats.py", line 51, in load
assert not self._stack
AssertionError
This happened with both python 2.4.1 and with python
2.4.2 rc 1 on windows (just downloaded).
Seems similar to bug [ 900092 ] hotshot.stats.load
(link:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900092&group_id=5470
)
but according to that, bug has been closed, and patch
has been applied to python 2.4.2. not sure if that
applies also to 2.4.2 rc1
Attaching the output file that caused it.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303673&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
