Garrett Cooper added the comment:
Another note: mixed endianness might have been a factor as previous versions of
the product that were shipped used bi-arch x86 (32-bit userland on 64-bit
kernel.
--
___
Python tracker
<http://bugs.python.
Garrett Cooper added the comment:
Yes, it's a duplicate. That being said, documentation alone it should be
unsigned long for Darwin (OS/X), FreeBSD, OpenBSD. Looking at the definition
for ioctl(2), the below example would cause a failure.
I need to hunt around for a practical example
New submission from Garrett Cooper:
telnetlib.Telnet.__init__ supports keyword arguments, but the documentation for
2.7.8 ( https://docs.python.org/2/library/telnetlib.html ) claims they're
non-keyword arguments.
The py3k docs are much better (
https://docs.python.org/3/li
Changes by Garrett Cooper :
--
versions: +Python 2.7, Python 3.4
___
Python tracker
<http://bugs.python.org/issue21915>
___
___
Python-bugs-list mailing list
Unsub
Garrett Cooper added the comment:
Please note that when I said "the code" I was looking at python 3.3 on OSX
(compiled with MacPorts):
$ python3.3
Python 3.3.5 (default, Mar 11 2014, 15:08:59)
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.79)] on darwin
Type "help", &
Garrett Cooper added the comment:
The code doesn't appear to be conforming to RFC-3164 or RFC-5424:
(From RFC-3164):
4.1 syslog Message Parts
The full format of a syslog message seen on the wire has three
discernable parts. The first part is called the PRI, the second part
i
Changes by Garrett Cooper :
Removed file: http://bugs.python.org/file33986/patch
___
Python tracker
<http://bugs.python.org/issue20558>
___
___
Python-bugs-list mailin
Garrett Cooper added the comment:
Updated patch to incorporate Vinay's comments. Thanks :)!
--
Added file: http://bugs.python.org/file34030/patch
___
Python tracker
<http://bugs.python.org/is
Changes by Garrett Cooper :
Removed file: http://bugs.python.org/file33985/patch
___
Python tracker
<http://bugs.python.org/issue20558>
___
___
Python-bugs-list mailin
Garrett Cooper added the comment:
Good to know!
I updated the patch to remove the errno abstraction, grab the errno attribute
from the OSError, and sort the imports.
--
Added file: http://bugs.python.org/file33986/patch
___
Python tracker
<h
New submission from Garrett Cooper:
The logging module checks for ECONNRESET if it's equal to 104. This is valid on
Linux, but not [some] other OSes. On FreeBSD and OpenBSD [*] it's 54, not 104.
The attached patch fixes the logging code to check for errno.ECONNRESET in
!win32 en
Changes by Garrett Cooper :
--
components: +Library (Lib)
type: -> behavior
versions: +Python 2.7, Python 3.5
___
Python tracker
<http://bugs.python.org/issu
New submission from Garrett Cooper:
I was a bit surprised when I ran into this issue when porting some nose tests
from Windows to Linux:
#!/usr/bin/env python
with open('/etc/services') as fd:
lines = fd.readlines()
lines.append('')
SERVICES = [line.split()[
Garrett Cooper added the comment:
The whole permissions setting operation seems a bit convoluted.
I was hoping there was something formalized with install_data.py where I could
specify a default or fine-grained user/group/mode for files, but it doesn't
appear to be possible. I'll i
Garrett Cooper added the comment:
Feel free to close this. I don't have any interest in pursuing it further.
--
nosy: +Garrett.Cooper
___
Python tracker
<http://bugs.python.org/i
Garrett Cooper added the comment:
... g'night.
--
Added file: http://bugs.python.org/file27955/python-issue16124.patch
___
Python tracker
<http://bugs.python.org/is
Garrett Cooper added the comment:
Grr... Let's try again.
--
Added file: http://bugs.python.org/file27954/python-issue16124.patch
___
Python tracker
<http://bugs.python.org/is
Changes by Garrett Cooper :
Removed file: http://bugs.python.org/file27953/python-issue16124.patch
___
Python tracker
<http://bugs.python.org/issue16124>
___
___
Pytho
Garrett Cooper added the comment:
And I missed the int -> unsigned int part. Resubmitting one last time for
tonight..
--
Added file: http://bugs.python.org/file27953/python-issue16124.patch
___
Python tracker
<http://bugs.python.org/issu
Changes by Garrett Cooper :
Removed file: http://bugs.python.org/file27951/python-issue13500-test.patch
___
Python tracker
<http://bugs.python.org/issue16124>
___
___
Garrett Cooper added the comment:
Sorry; previous patch is not applicable to this issue. This one is.
--
Added file: http://bugs.python.org/file27952/python-issue16124.patch
___
Python tracker
<http://bugs.python.org/issue16
Garrett Cooper added the comment:
$ uname -a
FreeBSD bayonetta.local 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0 r240836M: Sat
Sep 22 12:30:11 PDT 2012
gcooper@bayonetta.local:/usr/obj/store/freebsd/stable/9/sys/BAYONETTA amd64
$ ./configure --prefix=/scratch/python-bin/3k/
...
$ make all
Garrett Cooper added the comment:
Yes. Submitting a patch to fix this based on hg master shortly..
--
___
Python tracker
<http://bugs.python.org/issue16
New submission from Garrett Cooper:
As discussed in ID # 1471, the type for request is not 100% correct on some
platforms (FreeBSD, NetBSD, and OpenBSD, for instance) and the custom platform
that I'm using unfortunately uses non-32-bit int ioctls. An autoconf test needs
to be added for
Garrett Cooper added the comment:
Hahaha... you're right:
$ perl -e 'use POSIX; print strftime("%m-%d-%y %H:%M:%S", localtime)."\n";';
date
09-13-12 23:25:49
Thu, Sep 13, 2012 3:25:49 PM
$ python -c 'import time; print time.strftime("%m-%d-%y %H:
Garrett Cooper added the comment:
Ok. Turns out I got this backwards. The BIOS clock is set to UTC (which works
with the CentOS install on the same drive) and Windows assumes the clock is set
to local time [1]. I'll follow it up with the my $work lab team, but it would
be nice if this
Garrett Cooper added the comment:
Except it wasn't built within the Cygwin environment...
$ python -c 'import sys; print sys.version'
2.6.1 (r261:67515, Dec 5 2008, 13:58:38) [MSC v.1500 32 bit (Intel)]
$ ldd `which python` | grep -i ygwin || echo "no
Garrett Cooper added the comment:
1. http://pubs.opengroup.org/onlinepubs/009695299/functions/localtime.html
--
___
Python tracker
<http://bugs.python.org/issue15
New submission from Garrett Cooper:
Windows doesn't return sane values for localtime(3) (per POSIX [1]) when
the BIOS is set to the local time (the host is a Win2k8-R2 machine):
$ python -V; python -c 'import time; print time.strftime("%m-%d-%y %H:%M:%S",
time.localtime
Garrett Cooper added the comment:
Here's a unittest patch for the py3k branch.
{{{
1 items passed all tests:
32 tests in test.test_cmd.samplecmdclass
32 tests in 19 items.
32 passed and 0 failed.
Test passed.
doctest (test.test_cmd) ... 32 tests with zero fai
Garrett Cooper added the comment:
Ok. I'll see if I can provide a unittest for this by the 12th.
--
___
Python tracker
<http://bugs.python.org/is
Garrett Cooper added the comment:
I'll verify the fix in another day or two.
FWIW unless python is willing to import pexpect, or provide an equivalent, I'm
not sure how items like this which require interactive input can be run via
the python project testing
Garrett Cooper added the comment:
Sure -- the repro steps are pretty easy:
1. Startup an interactive python shell.
2. Enter in the following code:
{{{
import cmd
class Foo(cmd.Cmd):
def do_bar(self, arg):
"""bar"""
Foo().cmdloop()
}}}
3. You wil
New submission from Garrett Cooper :
The attached patch enables libedit support in a generic way via configure.in,
so I can pass in --with-readline=editline, --with-readline=readline,
--with-readline=yes, or --with[out]-readline[=no] and it will do one of the
following:
1. Enable editline
New submission from Garrett Cooper :
Pressing produces no output with cmd.py whenever ^D has been entered
in; after I enter in ^D it gets into an infinite loop spewing out messages via
cmd.Cmd.default() about EOF because self.lastcmd isn't being reset properly.
The attached patch fixes
Garrett Cooper added the comment:
Other potential issues are provided below:
configure:9015: checking if PTHREAD_SCOPE_SYSTEM is supported
configure:9038: gcc -pthread -o conftest -I/usr/include/edit conftest.c >&5
conftest.c: In function 'main':
conftest.c:101: warn
New submission from Garrett Cooper :
Was poking around config.log and I saw that gcc was complaining of some
undefined built-in symbols for the broken nice test in configure. This patch
fixes that.
--
files: configure-fix-broken-broken-nice-test.patch
keywords: patch
messages: 148554
Garrett Cooper added the comment:
Here's a version incorporating your suggestion and better documenting the
choices and the method for overriding purposes. I have a few reservations with
the current implementation:
1. As noted, the information for the class really could be and shou
New submission from Garrett Cooper :
1. The current code in cmd.get_names does a dir on the derived class for
cmd.Cmd object instead, which means that if I do something similar to
the following:
class CLI(cmd.Cmd):
def register_subcommand(self, cmd, cli_class):
def call_cli(self
Garrett Cooper added the comment:
I realize that this bug is closed, but I just had a comment to make.
Handling EOF is simple:
def do_EOF(self, arg):
pass
For my purposes I want to raise an EOFError so I can trickle up the chain to
the appropriate caller because I'm coding a CLI wh
Garrett Cooper added the comment:
As a note for future reference, FreeBSD/NetBSD/OpenBSD doesn't use the term
"bug", but instead uses the term "problem report" (the NetBSD website says
"bug" though BTW).
The PR system for NetBSD can be accessed here:
http:
Garrett Cooper added the comment:
Is svn not being updated anymore (in lieu of hg)?
--
___
Python tracker
<http://bugs.python.org/issue12433>
___
___
Python-bug
New submission from Garrett Cooper :
Running 'make clean' leaves libpython*.a behind. The attached patch removes it
when make clean is run.
This was resolved on py3k, not trunk; the attached patch matches what was done
on py3k.
--
components: Build
files: cleanup-libpy
Garrett Cooper added the comment:
I apologize for taking so long with this. The attached patch is for test_posix
against trunk (I shuffled around some code and extended some things to improve
PosixTester.tearDown). Let me know if I need to wash, rinse, repeat for py3k,
etc.
Thanks
Garrett Cooper added the comment:
On Mon, Jan 17, 2011 at 5:11 PM, Ned Deily wrote:
>
> Ned Deily added the comment:
>
> There is an existing test_lchflags in Lib/test/test_posix.py. Additional
> test cases should go there.
Ok, but again this isn't POSIX functio
Garrett Cooper added the comment:
Sorry -- got off-track for a while.
I assume these should go into Lib/test/test_os.py ?
--
___
Python tracker
<http://bugs.python.org/issue8
New submission from Garrett Cooper :
The following patch fixes the help docstring as time.tzset when called doesn't
require any arguments (as noted in the source and also in the library
documentation).
The patch produced was against trunk, but this appears to be an issue on
release-ma
Garrett Cooper added the comment:
*NOUNLINK was not implemented by OSX, so there's actually a bug with the
compile tests if you take that into consideration. And again, only FreeBSD
defines *NOUNLINK. The other BSDs, not so much.
As far as the reason why I implemented the flags
Garrett Cooper added the comment:
Do you prefer exhaustive tests, or just smoke tests? Honestly IMO, the OS
should come prepackaged with tests to ensure that things function according to
the requirements set forth in the manpage, so I would prefer the latter because
the os methods in the
Changes by Garrett Cooper :
Added file: http://bugs.python.org/file18849/issue8746-py3k.patch
___
Python tracker
<http://bugs.python.org/issue8746>
___
___
Python-bug
Garrett Cooper added the comment:
I'll add new tests in the next submit for the bug, but here's the code to add
the relevant symbols for common to *BSD and OSX, and the Snow Leopard+ and
FreeBSD specific chflags of importance for python 2.7 and py3k.
--
Added
Garrett Cooper added the comment:
That definitely fixes detection for FreeBSD CURRENT with 2.7 and py3k for me.
I'm looking into providing some unit-tests, but the problem is that whether or
not chflags functions on the underlying filesystem is problematic. For
instance, it won't f
Garrett Cooper added the comment:
The issue is still present.
The overall problem I suppose is with consistency and presentation of features
in the python language.
Many features cannot be presented in a 100% portable manner, and the problem is
that such features that aren't
Garrett Cooper added the comment:
My initial analysis was incorrect after talking with the bash(1) folks. test(1)
is doing things wrong too:
case FILEX:
/* XXX work around eaccess(2) false positives for superuser */
if (eaccess(nm, X_OK) != 0
Garrett Cooper added the comment:
My initial analysis was incorrect after talking with the bash(1) folks. test(1)
is doing things wrong too:
case FILEX:
/* XXX work around eaccess(2) false positives for superuser */
if (eaccess(nm, X_OK) != 0
Garrett Cooper added the comment:
Well, bash screws up in this dept:
$ ls -l typescript
-rw-r--r-- 1 gcooper gcooper 37875 Jul 12 22:19 typescript
$ sudo sh -c 'test -x typescript; echo $?'
1
$ sudo bash -c 'test -x typescript; echo $?'
0
$ csh
%if (-x typescript) then
New submission from Garrett Cooper :
As seen in the nose bug [1], I stumbled upon an OS quirk with FreeBSD, where
apparently (as superuser) due to the wording of the POSIX spec for access(2),
it's considered free game to return 0 for the system call (True) for
os.[RWX]_OK.
Only pytho
Garrett Cooper added the comment:
.
--
Added file: http://bugs.python.org/file17414/config.log
___
Python tracker
<http://bugs.python.org/issue8746>
___
___
Pytho
New submission from Garrett Cooper :
A number of features are being blindly enabled on python that aren't correct
from a porting standpoint; a handful in configure.in I noticed are:
# The later defininition of _XOPEN_SOURCE disables certain features
# on Linux, so we need _GNU_SOURCE
New submission from Garrett Cooper :
os.chflags isn't `available' even though chflags support is available on the
system:
>>> filter(lambda x: x.startswith('chflags'), dir(os))
[]
>>> platform.uname()
('FreeBSD', 'bayonetta.local', &#
Changes by Garrett Cooper :
Added file: http://bugs.python.org/file16468/clean.log
___
Python tracker
<http://bugs.python.org/issue8079>
___
___
Python-bugs-list mailin
Changes by Garrett Cooper :
Added file: http://bugs.python.org/file16467/all.log
___
Python tracker
<http://bugs.python.org/issue8079>
___
___
Python-bugs-list mailin
New submission from Garrett Cooper :
When attempting to install and deinstall lang/python26 to run some unit tests
for a change I was going to provide to the maintainer, I ran into this issue:
install -o root -g wheel -m 444 ./../Include/ucnhash.h
/usr/local/include/python2.6
install -o root
Garrett Cooper added the comment:
Ok. Taking a look at trunk...
The following could be converted to AC_TRY_COMPILE statements for the
3rd AC_TRY_RUN tuple:
1. $ac_enable_profiling : 697
2. $ac_cv_no_strict_aliasing_ok : 921
3. $ac_cv_opt_olimit_ok : 1070
4. $ac_cv_olimit_ok : 1092
5
Garrett Cooper added the comment:
On Sun, Nov 1, 2009 at 5:50 AM, Mike Frysinger wrote:
>
> Mike Frysinger added the comment:
>
> AC_TRY_RUN is already documented:
> http://www.gnu.org/software/autoconf/manual/html_node/Obsolete-Macros.html#index-AC_005fTRY_005fRUN-1992
>
&
Garrett Cooper added the comment:
I'm trying to resolve this issue on:
2.6-releasemaint
trunk
3.1-releasemaint
py3k
first by resolving issues configure.in, but there are a TON of
AC_TRY_RUN's, which means that this code cannot be cross-compiled as-is
(25 on 2.x -- 27 on 3.x).
Is
Garrett Cooper added the comment:
__linux is legitimate too, so the patch looks ok, but...
1) It won't apply cleanly against 2.4.5, most likely.
2) Why __linux instead of __linux__ ?
gcoo...@orangebox ~ $ echo "" | gcc --std=c89 -E -dM -c - | grep linux
#define __linux 1
#def
New submission from Garrett Cooper :
The following files are looking for the `linux' constant, when it fact
they should be looking for `__linux__' (from 2.6.2 release's sources):
Modules/_ctypes/libffi/src/mips/ffitarget.h:#ifdef linux
Modules/socketmodule.c:#ifdef linux
Modules
Garrett Cooper added the comment:
Coming back to this issue, I really want to resolve it on TRUNK and for
it to make its way into 2.6.3 and 2.x trunk, as well as 3.0.2 and 3.x
trunk. I am more than happy to sign a contributor agreement if this will
push things along quicker.
Thanks,
-Garrett
Garrett Cooper added the comment:
Priorities shifted again at work, so I'll get around to this some time
around early June when I get an opportunity to implement multiprocessing
in my work code...
Thanks!
--
___
Python tracker
Garrett Cooper added the comment:
Cool! Thanks for all of the hard work Michael :D.
--
___
Python tracker
<http://bugs.python.org/issue5679>
___
___
Python-bug
Garrett Cooper added the comment:
Maybe the documentation for other examples should be referenced then?
--
___
Python tracker
<http://bugs.python.org/issue5
Garrett Cooper added the comment:
BTW, the documentation item that this should be attached to is:
http://docs.python.org/reference/datamodel.html#emulating-container-types
--
___
Python tracker
<http://bugs.python.org/issue5
New submission from Garrett Cooper :
This is just an example that I want to offer to the community to help
improve overall documentation in the handbook.
I've attached the example file, but it's also available on my journal
post with example output: http://yaneurabeya.livejournal.com
Changes by Garrett Cooper :
Removed file: http://bugs.python.org/file13701/unittest-sa_fix-r71263.diff
___
Python tracker
<http://bugs.python.org/issue5771>
___
___
Pytho
Garrett Cooper added the comment:
Ugh... The `...@staticmethod fix' was invalid.
--
Added file: http://bugs.python.org/file13702/unittest-sa_fix-r71263.diff
___
Python tracker
<http://bugs.python.org/i
New submission from Garrett Cooper :
A handful of valid bugs were reported with pylint when I was backporting
unittest.py r71263 to 2.4/2.5 from HEAD for
<http://code.google.com/p/python-unittest-backport>. The attached diff
fixes them.
--
components: Extension Modules, Tests
New submission from Garrett Cooper :
A handful of valid bugs were reported with pylint when I was backporting
unittest.py r71263 to 2.4/2.5 from HEAD. The attached diff fixes them.
--
components: Extension Modules, Tests
files: unittest-sa_fix-r71263.diff
keywords: patch
messages: 86018
Garrett Cooper added the comment:
Thanks for noting that George Y. and thanks for fixing the documentation
on SVN Benjamin :).
--
___
Python tracker
<http://bugs.python.org/issue5
New submission from Garrett Cooper :
The example under multiprocessing.managers.BaseManager.connect has 2 typos:
>>> from multiprocessing.managers import BaseManager
>>> m = BaseManager(address='127.0.0.1', authkey='abc))>>>
m.connect()
Garrett Cooper added the comment:
Ugh... nevermind. Bad case of PEBKAC. Sorry for the noise :(...
--
status: open -> closed
type: -> feature request
___
Python tracker
<http://bugs.python.org/
Garrett Cooper added the comment:
Sorry -- the info for my python2.6 was out of date. Here's the info (I
had to set PYTHONPATH to "" to avoid a multiprocessing module conflict):
bash-3.00$ PYTHONPATH=""; python2.6 `which nosetests`
~/test_managers_support.py
Python v
New submission from Garrett Cooper :
I'm not sure why but my copy doesn't have a managers module. I'm really
confused because multiprocessing.managers exists in
Lib/multiprocessing/managers.py and it should have been installed with
easy_install...
Please see the attached testcas
Garrett Cooper added the comment:
I did some quick inspection and it appears to be tied purely into
setuptools, not distutils. distutils does support the environment
variables properly.
So I take this item and submit it to PEAK I suppose? Fun times ><.
Thanks for the help.
--
New submission from Garrett Cooper :
In the API for connections.Client, it says:
multiprocessing.connection.Client(address[, family[, authenticate[,
authkey]]])
In the final paragraph is says:
`If authentication is True or authkey '
As per the API provided it should be:
`If authentica
Garrett Cooper added the comment:
How about this? I'll do both :).
I'm avoiding sync + semaphore stuff because it's still non-portable
(Issue 3770 fun), even though I have a functioning copy of FreeBSD...
but I do have a Mac, VMware fusion, etc, and I'll toss in a working
New submission from Garrett Cooper :
The last example on the multiprocessing documentation page is clearly
wrong. It references a lot of renamed / deprecated API's from processing
that are no longer in multiprocessing.
I'll try and come up with a comparable working example on all pl
New submission from Garrett Cooper :
I realize that cross-compilation isn't supported yet, _but_ setuptools
needs to be modified such that standard compilation variables are
supported, e.g. CC, CFLAGS, CPPFLAGS, LD, LDFLAGS, LDLIBS.
The -i, -l, and -L flags with setup.py with build_ext pr
Garrett Cooper added the comment:
I see the validity in the concern raised by Virgil:
I think this can be simplified from a user perspective by saying `I'm
electing to use cleanUp over tearDown'. The two systems are similar, but
also very different semantically as tearDown gets execu
Garrett Cooper added the comment:
I think some perspective is required on this enhancement request. I
originally filed this issue -- http://bugs.python.org/issue5538 --
because of the unneeded complexity involved with duplicating
teardown-related code in setUp because of a step in setUp failing
Garrett Cooper added the comment:
As an FYI, I'm going to push this off until next week or the week after
because I have more pressing things to take care of and have an OK
workaround for this issue.
--
___
Python tracker
<http://bugs.py
Garrett Cooper added the comment:
Unfortunately we're still stuck on 2.4.5 because I don't have enough
buy-in from tech leads and architects to upgrade right now -_-... Good
idea though :] *stores for later*.
--
___
Python trac
Garrett Cooper added the comment:
Excellent point Kumar.
Here's what I'm trying to accomplish...
I'm a part of a team that's testing out IOSd on an up and coming Unix
foundation platform. This requires starting up a series of services,
ensuring that they have come up, a
Garrett Cooper added the comment:
Before I forget though -- should the requirements for the functionality
be that it be called strictly in setUp on failure, or should it be
executed as a part of tearDown as well?
Thanks!
--
___
Python tracker
Garrett Cooper added the comment:
Ok, sounds good then ;). I'll open another issue with the enhancement
later on this week.
Cheers!
--
___
Python tracker
<http://bugs.python.org/i
Garrett Cooper added the comment:
And maybe the addCleanup components could be a stack of callable objects?
This would make life easier for folks like me and would make the overall
flow much cleaner / clearer as it would allow us to break things down
into atomic steps which could be reverted
Garrett Cooper added the comment:
I agree with you guys to a certain extent, but doing so only complicates
my setup procedure to the extent that I'm calling a lot of my teardown
code in a dumb manner, unless I actually kept track of how far into the
setup process I got before everything
Garrett Cooper added the comment:
If someone will provide a link to a page with instructions on how to
checkout python from cvs / svn / etc I'll gladly apply a patch to the
sources on 2.x and 3.x HEAD.
Thanks,
-Garrett
--
___
Python tracker
Changes by Garrett Cooper :
Removed file: http://bugs.python.org/file13397/issue-blah-2.4.5.diff
___
Python tracker
<http://bugs.python.org/issue5538>
___
___
Python-bug
Garrett Cooper added the comment:
That patch wasn't complete -_-... here's a more complete 2.4.x patch.
--
Added file: http://bugs.python.org/file13398/issue-5538-2.4.5.diff
___
Python tracker
<http://bugs.python.
1 - 100 of 108 matches
Mail list logo
