[ python-Bugs-963494 ] packman upgrade issue
Bugs item #963494, was opened at 2004-05-31 11:39
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=963494&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: Macintosh
Group: Feature Request
>Status: Closed
>Resolution: Wont Fix
Priority: 3
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Jack Jansen (jackjansen)
Summary: packman upgrade issue
Initial Comment:
When you upgrade a package using packman the installer doesn't
remove the old version before installing the new version. The end
result is that old files might interfere with the correct operation of
the upgraded package.
I ran into this with an upgrade from PyObjC 1.0 to PyObjC 1.1.
Some extension modules have moved between those two releases.
When upgrading using PackMan the old extension modules still
exists, and cause problems when you try to use the package.
Three possible solutions:
1) Remove the existing package directory before installing the
upgrade
2) Add pre/post install/upgrade scripts
3) Use a real package database
--
>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-06-11 11:16
Message:
Logged In: YES
user_id=580910
PackMan was dropped in 2.5
--
Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 12:51
Message:
Logged In: YES
user_id=580910
I propose closing this bug as WontFix, PackMan is dead in the water.
--
Comment By: Jack Jansen (jackjansen)
Date: 2005-01-04 21:48
Message:
Logged In: YES
user_id=45365
I don't like the extra_path idea: it's meant for something else really. I
think I'll just go for it and try the uninstaller trick. Don't know whether
I'll
have it in place before additions build 3, though, we'll see.
As to the other issue (missing dependencies and such): I want to solve
that differently, eventually. Currently there's only one test (installed) per
package that's supposed to be as cheap as possible. I want to have at
least one more (consistency) and maybe even two (consistency and full
selfcheck). But that'll have to wait.
--
Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2005-01-04 17:34
Message:
Logged In: YES
user_id=580910
That might work. It does require that packman installs dependencies
before installing the package itself.
Another problem is smart GUI's. One useful feature for a PackMan GUI
would be a listing of missing dependencies (e.g. you've installed _tkinter
and somehow didn't install AquaTk, it would be nice if PackMan said that
AquaTk is missing). Such a feature would have to know about uninstall
packages, otherwise it would complain that 'foo-uninstall' is missing after
you've installed 'foo'.
Another solution (at least for PyObjC) is making sure that every package
uses the 'extra_path' feature of distutils, add that value to the packman
database, and remove $extra_path before installing a package. The
extra_path key in the database could be optional: only add it when the
previous version must be uninstalled before installing a new version.
--
Comment By: Jack Jansen (jackjansen)
Date: 2005-01-04 17:03
Message:
Logged In: YES
user_id=45365
All of these are difficult. But I was just wondering whether we could
implement something simple: uninstall packages. For example, a
package "PyObjC-uninstall" (normallly hidden) would somehow contain
enough info to eradicate any known PyObjC installation. It's "installed"
status would be true if PyObjC is *not* installed, false if it is.
PyObjC-1.3-{source,binary} could then depend on PyObjC-uninstall, and
when the user installed either of these they would first "install" PyObjC-
uninstall, which would erase any previous installation.
An uninstall package would probably consist of a list of files and dirs that
would need to be removed. The package would be flagged as "installed"
if any of these exist.
There's probably packages that need something more complex (like
editing config files or whatever), but I think this scheme would handle
most common cases.
"installing" an uninstall package, possibly as a result of a dependency,
should probably put up a warning dialog first.
Does this sound workable?
--
Comment By: Jack Jansen (jackjansen)
Date: 2004-06-03 15:14
Message:
Logged In: YES
user_id=45365
I'm moving this to the feature requests category: it requires major
surgery, and it could be argued that this functi
[ python-Bugs-1504333 ] sgmlib should allow angle brackets in quoted values
Bugs item #1504333, was opened at 2006-06-11 08:58
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=1504333&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: Sam Ruby (rubys)
Assigned to: Nobody/Anonymous (nobody)
Summary: sgmlib should allow angle brackets in quoted values
Initial Comment:
Real live example (search for "othercorrections")
http://latticeqcd.blogspot.com/2006/05/non-relativistic-qcd.html
This addresses the following (included in the file):
# XXX The following should skip matching quotes (' or ")
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504333&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1366250 ] incorrect documentation for optparse
Bugs item #1366250, was opened at 2005-11-25 07:22 Message generated for change (Comment added) made by gward You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1366250&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: Documentation >Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michael Dunn (popuptoaster) Assigned to: Greg Ward (gward) Summary: incorrect documentation for optparse Initial Comment: The page http://www.python.org/doc/current/lib/optparse-parsing-arguments.html in the current documentation has text with an incorrect example: """ 6.21.3.7 Parsing arguments The whole point of creating and populating an OptionParser is to call its parse_args() method: (options, args) = parser.parse_args(args=None, options=None) where the input parameters are args the list of arguments to process (sys.argv[1:] by default) options object to store option arguments in (a new instance of optparse.Values by default) """ The example should be changed to: (options, args) = parser.parse_args(args=None, values=None) ^^ And then there should be a correstponding substition below in the explanation of the keyword arguments: values ^^ object to store option arguments in (a new instance of optparse.Values by default) Cheers, Michael -- >Comment By: Greg Ward (gward) Date: 2006-06-11 10:43 Message: Logged In: YES user_id=14422 Actually, I prefer the terminology in the example code, and think that the text is wrong. So I fixed the text instead. Also made a few other small tweaks to this section. Fixed upstream in Optik svn, rev 519. Fix on Python trunk, rev 46860. -- Comment By: Georg Brandl (birkenfeld) Date: 2005-11-26 11:37 Message: Logged In: YES user_id=1188172 Assigning to Greg as he maintains the upstream Optik distribution. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1366250&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1498146 ] optparse does not hande unicode help strings
Bugs item #1498146, was opened at 2006-05-31 07:52 Message generated for change (Comment added) made by gward You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1498146&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: Unicode Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tom Cato Amundsen (tomcato) Assigned to: Greg Ward (gward) Summary: optparse does not hande unicode help strings Initial Comment: Unicode strings with non-ascii chars in generate a UnicodeEncodeError File "/usr/lib/python2.3/optparse.py", line 1370, in print_help file.write(self.format_help()) UnicodeEncodeError: 'ascii' codec can't encode characters in position 200-202: +ordinal not in range(128) I'm subclassing OptionParser and adds the following method to get it to work. Should something like this be done for python 2.5? def print_help(self, file=None): if file is None: file = sys.stdout file.write(self.format_help().encode(file.encoding, 'replace')) Tom Cato -- >Comment By: Greg Ward (gward) Date: 2006-06-11 12:25 Message: Logged In: YES user_id=14422 Fixed pretty much as suggested in upstream Optik repository: r520. (However, I had to use getattr(file, 'encoding', sys.getdefaultencoding()) to maintain compatibility with Python 2.0 .. 2.2). No doc changes, since help generation isn't really documented all that well anywhere. ;-( Fixed on Python trunk: r46861. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1498146&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1501330 ] failure of test_ossaudiodev; elapsed time .1 sec faster
Bugs item #1501330, was opened at 2006-06-05 20:23 Message generated for change (Comment added) made by gward You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501330&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Greg Ward (gward) Summary: failure of test_ossaudiodev; elapsed time .1 sec faster Initial Comment: I am getting a consistent failure of test_ossaudiodev on Ubuntu Hoary on an HP xw4300 Workstation. The failure is that the test is printing out "elapsed time: 3.0 sec" while the test expects 3.1 sec. I don't know anything about sound recordings so I don't know if there is any way to calculate the expected length of the test sound file and thus know that this is a true error or the test is just working faster than normally expected. -- >Comment By: Greg Ward (gward) Date: 2006-06-11 12:54 Message: Logged In: YES user_id=14422 Brett -- I'm not sure why I put 3.1 sec in there. It's probably just what popped out the first time I ran this test on my machine. Anyways, simple math reveals that the theoretical running time of the test file is ~2.93 sec: (23493 bytes) / (1 byte/sample) / (8000 samples/sec) = 2.93 sec which of course ignores the overhead of the file header, but that seems to pretty small. "sox" agrees: $ time /usr/bin/play Lib/test/audiotest.au Input Filename : Lib/test/audiotest.au Sample Size: 8-bits Sample Encoding: u-law Channels : 1 Sample Rate: 8000 Time: 00:02.93 [00:00.00] of 00:02.93 ( 100.0%) Output Buffer: 23.46K Done. /usr/bin/play Lib/test/audiotest.au 0.03s user 0.02s system 1% cpu 3.127 total Can you try that on your machine and put the output here? Anyways, the likely culprits are 1) faster hardware (less overhead opening audio device, reading file, etc) and 2) variations in sound chip frequency (8000 Hz is not always exactly 8000 Hz). I'll try to fix the test so it's a little fuzzier. -- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-07 09:04 Message: Logged In: YES user_id=11375 Yes, the length is calculable -- you have N bytes in the file, with so many bits per sample and so many samples per second. Perhaps the driver now buffers more and the write() returns earlier? Or you could try printing the exact duration without rounding; maybe it's 3.099 or something and the print is just truncating. Assigning to Greg Ward, in case he gets around to looking at it. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501330&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1504456 ] xmlcore needs to be documented
Bugs item #1504456, was opened at 2006-06-11 15:50 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=1504456&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: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 6 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: xmlcore needs to be documented Initial Comment: The change from the "xml" package to the "xmlcore" package needs to be documented for Python 2.5. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504456&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
