akira added the comment:
Antoine, I've signed the agreement. I've added ssl_cert_time_toseconds.patch
with code, tests, and documention updates.
--
keywords: +patch
Added file: http://bugs.python.org/file34201/ssl_cert_time_to_sec
New submission from akira:
subprocess' stdout pipe is open for *reading* but its value is documented as an
argument for `BaseEventLoop.connect_write_pipe`. It should be
`BaseEventLoop.connect_read_pipe` instead. As it currently is for subprocess'
stderr.
The patch i
akira added the comment:
Related: issue4926 "putenv() accepts names containing '=', return value of
unsetenv() not checked"
`os.environ.clear()` also fails if the environment contains names with `=`:
>>> import os
>>> os.environ['a=b']
akira <4kir4...@gmail.com> added the comment:
Minor notes:
msg107186:
1. The constructor now accepts only whole number of minutes in [-23:59,
23:59] range.
rfc 3339 provides the following example:
1937-01-01T12:00:27.87+00:20
This represents the same instant of time a
New submission from Akira Kitada :
Modules/mmapmodule.c contains code that makes it incompatible with C89 compiler.
People using recent gcc can check this by running following commands.
$ ./configure CFLAGS='-Wdeclaration-after-statement' && make
Attached patch fixes th
New submission from Akira Kitada :
Building Python 2.7 fails on FreeBSD 4.11 with gcc 2.95.4 as below:
"""
gcc -pthread -c -fno-strict-aliasing -g -O2 -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -o
Python/dtoa.o Python/dtoa.c
Py
New submission from Akira Kitada :
Some platforms have uintptr_t in inttypes.h but Python bulid system
assumes it's defined in stdint.h and it causes build failure:
"""
building 'select' extension
gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -DNDEBUG -g -O3
Akira Kitada added the comment:
This patch fixes this.
--
keywords: +patch
Added file: http://bugs.python.org/file19173/issue10054.diff
___
Python tracker
<http://bugs.python.org/issue10
New submission from Akira Kitada :
I found some C99 code in _json.c.
Attached patch makes it C89.
The C99 part is only used for ucs4 Python. That's probably the reason
it's overlooked.
--
components: Build
files: _json.c.diff
keywords: patch
messages: 118255
nosy: akitad
Akira Kitada added the comment:
> 1. Have you tested this with Python 3.x at all? I'd expect the same issues
> to show up for Python 3.1 and 3.2.
Yes, I can reproduce this in 2.7, 3.1 and 3.2.
> 2. Also, do you have the relevant configure output to hand? On my machine,
>
Akira Kitada added the comment:
It seems this problem was introduced by a patch in issue7211.
3.1 branch does not have this problem because that patch was not applied to
release31-maint. Is this intentional?
--
versions: +Python 3.2
___
Python
Akira Kitada added the comment:
Forgot to mention that there's no _MAX macro for exact-width integer types.
$ egrep -r 'INT[0-9].*_MAX' /usr/include/ | wc -l
0
How about adding those macros when the system does n
New submission from Akira Kitada :
Build fails on FreeBSD 4 due to the lack of sem_timedwait.
"""
gcc -pthread -Wl,--export-dynamic -o python Modules/python.o libpython3.2.a
-lutil -lm
libpython3.2.a(thread.o): In function `PyThread_acquire_lock_timed':
/home/aki
Akira Kitada added the comment:
It works fine with USE_SEMAPHORES commented out.
--
___
Python tracker
<http://bugs.python.org/issue10062>
___
___
Python-bug
Akira Kitada added the comment:
The patch does fix the build error.
Thank you!
--
___
Python tracker
<http://bugs.python.org/issue10062>
___
___
Python-bug
Akira Kitada added the comment:
I understand FreeBSD 4.x is old platform (4.11, the last 4.x series, is
released 5 years ago) but, in my opinion, as long as it does not make Python
code cluttered, supporting old platforms is not that bad idea.
Anyway, I would like to leave the decision to
Changes by Akira Kitada :
Removed file: http://bugs.python.org/file13673/issue5736.diff
___
Python tracker
<http://bugs.python.org/issue5736>
___
___
Python-bugs-list m
Changes by Akira Kitada :
Removed file: http://bugs.python.org/file13674/issue5736.diff
___
Python tracker
<http://bugs.python.org/issue5736>
___
___
Python-bugs-list m
Changes by Akira Kitada :
Removed file: http://bugs.python.org/file13682/test_issue5736.diff
___
Python tracker
<http://bugs.python.org/issue5736>
___
___
Python-bug
Changes by Akira Kitada :
Removed file: http://bugs.python.org/file13676/issue5736.diff
___
Python tracker
<http://bugs.python.org/issue5736>
___
___
Python-bugs-list m
Akira Kitada added the comment:
This patch just uses PyObject_GetIter to get an iter.
(I just copied the idea from issue9523)
--
nosy: +ysj.ray
versions: +Python 3.2 -Python 2.7
Added file: http://bugs.python.org/file19250/issue5736.diff
___
Python
Akira Kitada added the comment:
This patch is specifically targeted at FreeBSD 4.
tested on FreeBSD 4.11 and OS X 10.6.4
I don't know how to accommodate SGI IRIX's case.
--
keywords: +patch
Added file: http://bugs.python.org/file19254/issue
New submission from Akira Kitada <[EMAIL PROTECTED]>:
I was trying to build Python 2.6 on FreeBSD 4.11 and found it failed
to build some of the modules.
"""
Failed to find the necessary bits to build these modules:
_bsddb _sqlite3 _tkinter
gdbm
Akira Kitada <[EMAIL PROTECTED]> added the comment:
Attached patch fixes build problem of math and mmap.
Apparently, FreeBSD 4 does not make some math functions available when
_XOPEN_SOURCE is defined and unlike newer FreeBSD, it cannot be fixed
with __BSD_VISIBLE macro.
As for readli
Akira Kitada <[EMAIL PROTECTED]> added the comment:
Thanks Christian,
Now all modules are working.
$ ./python
Python 2.6 (r26:66714, Oct 14 2008, 15:18:41)
[GCC 2.95.4 20020320 [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "
Akira Kitada <[EMAIL PROTECTED]> added the comment:
Here's the one.
I tested this patch on FreeBSD 4.11 and 6.3.
Both worked. :)
Added file: http://bugs.python.org/file11892/Modules_readline.c.diff
___
Python tracker <[EMAIL PRO
Akira Kitada <[EMAIL PROTECTED]> added the comment:
I will.
Would it be enough to test on trunk and py3k branch?
By the way, trunk seems to have some problem building now.
./Parser/asdl_c.py -h ./Include ./Parser/Python.asdl
env: python: No such file or directory
*** Error code 127
S
Akira Kitada <[EMAIL PROTECTED]> added the comment:
Attached is the patch containing all fixes.
I tested this on py3k and trunk on FreeBSD 4.11.
The test was done by using unitests in Lib/test.
Because I could not find a test for readline and
multiprocessing's test does not work on s
Akira Kitada <[EMAIL PROTECTED]> added the comment:
Here's the output of configure.
Just as Mark said, it looks this is due to a libm bug.
"""
$ grep tanh config.log
configure:22062: checking whether tanh preserves the sign of zero
|and tanh(-0.) == -0. */
|
Akira Kitada <[EMAIL PROTECTED]> added the comment:
Roumen,
in Darwin, there is a macro called _DARWIN_C_SOURCE,
which re-enables things disabled by _XOPEN_SOURCE or the like.
(At least on OS X 10.5.5)
___
Python tracker <[EMAIL PROTECTE
Changes by Akira Kitada <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11890/configure.in.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Akira Kitada <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11892/Modules_readline.c.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Akira Kitada <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11897/issue4204.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Akira Kitada <[EMAIL PROTECTED]> added the comment:
Thank you for pointing that out, Roumen!
I didn't realize that.
I updated the patch again.
Added file: http://bugs.python.org/file11901/issue4204.diff
___
Python tracker <[EMAIL PRO
Akira Kitada <[EMAIL PROTECTED]> added the comment:
Christian,
Thank you for the review.
Let me know if there is anything I could help with this.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
New submission from Akira Kitada <[EMAIL PROTECTED]>:
I get a number of "cannot find -lpython2.5" error when building Python
2.5.2 on FreeBSD 2.5.2 with gcc 2.95.4.
This problem is only occured when I build it with "--enable-shared"
configure option.
This is how you
Changes by Akira Kitada <[EMAIL PROTECTED]>:
--
nosy: akitada
severity: normal
status: open
title: a bug in ncurses.h still exist in
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
New submission from Akira Kitada <[EMAIL PROTECTED]>:
Excerpt from configure.in
"""
# On FreeBSD 4.8 and MacOS X 10.2, a bug in ncurses.h means that
# it craps out if _XOPEN_EXTENDED_SOURCE is defined. Apparently,
# this is fixed in 10.3, which identifies itself as Dar
Akira Kitada <[EMAIL PROTECTED]> added the comment:
Christian's patch fixed this problem!
(tested on 4.11-RELEASE)
I'm not sure why the other platforms don't suffer this problem.
___
Python tracker <[EMAIL PROTECTED]>
<ht
New submission from Akira Kitada <[EMAIL PROTECTED]>:
Some compilers don't understand "%zd" format specifer
and gcc 2.95.4 is one of them.
(You can find more on http://www.and.org/vstr/printf_comparison)
When building Python with such compilers, you will see a lot
Akira Kitada <[EMAIL PROTECTED]> added the comment:
Yes, that change was not merged into 2.5 branch.
I Hope it's not yet been too late for 2.5.3.
I confirmed this fixes the problem on FreeBSD 4.11.
___
Python tracker <[EMAIL PRO
Akira Kitada <[EMAIL PROTECTED]> added the comment:
I looked into the code and found these warnings about 'z' were
not from printf family but PyString_FromFormat.
Apparently PyString_FromFormat handles the 'z' itself, without
delegating that to printf family.
Then why a
Akira Kitada <[EMAIL PROTECTED]> added the comment:
Amaury,
thank you for pointing that out.
Attached patch disables this "__attribute__"
when PY_FORMAT_SIZE_T is undefined after configure script.
I confirmed this eliminate warnings in FreeBSD 4.11
--
keywords: +patch
Akira Kitada <[EMAIL PROTECTED]> added the comment:
Changing the title because this is not 2.5.x specific.
--
title: cannot find -lpython2.5 when buinding Python 2.5.2 on FreeBSD 4.11 ->
cannot find -lpython2.X when buinding Python on FreeBSD 4.11
versions: +Python 2.5.3, P
Akira Kitada <[EMAIL PROTECTED]> added the comment:
Changing the title again because this problem is not FreeBSD 4 specific.
Build on recent FreeBSD also has the same problem.
(I tested this on 6.3, too)
--
title: cannot find -lpython2.X when buinding Python on FreeBSD 4.11 -&g
Akira Kitada <[EMAIL PROTECTED]> added the comment:
I tested this on FreeBSD 6.3 and it worked. (release25-maint)
waiting for review.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Akira Kitada <[EMAIL PROTECTED]> added the comment:
Roumen,
Thanks for the feedback!
This patch disables __attribute__ when PY_FORMAT_SIZE_T isn't defined,
not always.
About the name of the macro, I think you are right.
Py_GCC_FORMAT_ATTRIBUTE would be much better name if it is n
Akira Kitada <[EMAIL PROTECTED]> added the comment:
Thank you again for the feedback.
I think those warnings are not so useful, or even misleading,
when we know they are handled appropriately.
with these warnings hidden, it would get much more easy to read
build log and find real warnings
Changes by Akira Kitada <[EMAIL PROTECTED]>:
--
versions: +Python 2.5.3, Python 2.6, Python 2.7, Python 3.0, Python 3.1
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Akira Kitada <[EMAIL PROTECTED]> added the comment:
Martin,
Two questions:
1. Isn't Christian's patch enough for this?
2. How about Python 3.0 and 2.6.1? Are they also out of scope for this?
___
Python tracker <[EMAIL PROTECTED]>
&
Akira Kitada <[EMAIL PROTECTED]> added the comment:
I'm having similar problem with distutils.
http://mail.python.org/pipermail/python-dev/2008-November/083670.html
Is there any reason customize_compiler
- only get CPPFLAGS in env, not ones from sysconfig?
- doesn't get OPT fro
Akira Kitada <[EMAIL PROTECTED]> added the comment:
The new patch attached renamed Py_GCC_ATTRIBUTE to Py_GCC_FORMAT_ATTRIBUTE.
As Roumen pointed out, "the current python code use Py_GCC_ATTRIBUTE
only for 'format(printf(...)) ' attribute.", so this change sh
Changes by Akira Kitada <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file12124/pyport.h.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Akira Kitada <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file12160/issue4370.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Akira Kitada <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file12159/issue4370.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Akira Kitada <[EMAIL PROTECTED]> added the comment:
Tested my patch on
* FreeBSD 4.11 (gcc version 2.95.4, does not support "z")
* FreeBSD 6.3 (gcc version 3.4.6, supports "z")
and it worked fine on both. (using trunk)
___
Python
Akira Kitada <[EMAIL PROTECTED]> added the comment:
Martin,
Thank you for the feedback.
I think we can avoid the problem that would be introduced by the removal
of Py_GCC_ATTRIBUTE by leaving it as is
(probably adding "#warning this macro is deprecated. Please use
Py_GCC_FORMA
Changes by Akira Kitada <[EMAIL PROTECTED]>:
--
versions: +Python 2.5.3
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4368>
___
__
Akira Kitada <[EMAIL PROTECTED]> added the comment:
I'm just curious to know which is the right behavior.
# Python 3.0
Traceback (most recent call last):
File "bad_range.py", line 7, in
print(range(MyInt(2**3), MyInt(2**3+10)))
TypeError: 'MyInt' obj
Akira Kitada <[EMAIL PROTECTED]> added the comment:
Updating versions.
--
versions: +Python 2.5.3, Python 2.6, Python 2.7, Python 3.0
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Akira Kitada <[EMAIL PROTECTED]> added the comment:
Attached patch just leaves Py_GCC_ATTRIBUTE as it is now.
Here is the highlight.
/*
* Hide GCC's format attribute from compilers if one of the following is
true:
* a) the compiler does not support it and not on RISC OS
* b) t
Changes by Akira Kitada <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file12160/issue4370.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Akira Kitada <[EMAIL PROTECTED]> added the comment:
OS X 10.5.5 seems to have the problem just as described,
whereas there seems no problem on FreeBSD 6.3.
--
components: +Build, Macintosh
nosy: +akitada
___
Python tracker <[EMAIL PROTECTE
Changes by Akira Kitada <[EMAIL PROTECTED]>:
--
versions: +Python 2.5.3, Python 2.6, Python 2.7, Python 3.0
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.
Akira Kitada <[EMAIL PROTECTED]> added the comment:
I think this patch is harmless and also deserve to be merged
into 2.5.3 release. (As I mentioned earlier, this has been already
merged into 3.0 and 2.6 branches)
___
Python tracker <[EMAIL PROTECTE
Akira Kitada added the comment:
Is there anyone knowing the historical reason for this?
In that case I will take this and submit a patch here soon.
--
versions: +Python 2.5.3, Python 2.7
___
Python tracker
<http://bugs.python.org/issue4
Akira Kitada added the comment:
Could you also fix the indentation of "Queues" example code at
http://docs.python.org/library/multiprocessing.html#exchanging-objects-between-processes
?
--
nosy: +akitada
___
Python tracker
<http://bu
Changes by Akira Kitada :
--
nosy: +akitada
___
Python tracker
<http://bugs.python.org/issue1180>
___
___
Python-bugs-list mailing list
Unsubscribe:
Akira Kitada added the comment:
How about svn rm "svn.python.org/projects/distutils/" to avoid confusion?
--
nosy: +akitada
___
Python tracker
<http://bugs.python.
New submission from Akira Kitada :
It might be not a bug, but I think it's weird to see
an ancient What's New link on the new Python tutorial page.
http://docs.python.org/tutorial/
--
assignee: georg.brandl
components: Documentation
messages: 80109
nosy: akitada, georg.brand
Changes by Akira Kitada :
___
Python tracker
<http://bugs.python.org/issue1054967>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/o
New submission from Akira Kitada :
In distutils package, there are many files that saying
"This module should be kept compatible with Python 2.1."
According to Tarek Ziadé, this is not valid statement anymore.
--
components: Distutils
messages: 80507
nosy: akitada
severi
Akira Kitada added the comment:
If PEP 291 is still valid, distutils needs "only remain compatible with
the version of Python it is distributed with."
___
Python tracker
<http://bugs.python.
New submission from Akira Kitada :
Distutils-SIG page [1] and links there are considerably outdated.
They need to be updated to reflect current situation.
[1] http://www.python.org/community/sigs/current/distutils-sig/
--
assignee: georg.brandl
components: Distutils, Documentation
Changes by Akira Kitada :
--
nosy: +tarek
___
Python tracker
<http://bugs.python.org/issue5055>
___
___
Python-bugs-list mailing list
Unsubscribe:
Akira Kitada added the comment:
I think this is a duplicate of issue4137.
Please close this.
___
Python tracker
<http://bugs.python.org/issue5055>
___
___
Python-bug
Changes by Akira Kitada :
--
assignee: -> georg.brandl
components: +Documentation
nosy: +akitada, georg.brandl, tarek
___
Python tracker
<http://bugs.python.org/iss
Akira Kitada added the comment:
Is there any PEP describing we have to keep compatibility with 2.3
release? I'm not against the idea but just curious.
___
Python tracker
<http://bugs.python.org/i
Akira Kitada added the comment:
Could you tell me where the right place to ask this kind of problems?
I could not find any other trackers...
___
Python tracker
<http://bugs.python.org/issue5
Akira Kitada added the comment:
Attached patch changes distutils to pass CPPFLAGS to compiler.
--
nosy: +tarek
Added file: http://bugs.python.org/file12868/issue4010.diff
___
Python tracker
<http://bugs.python.org/issue4
Akira Kitada added the comment:
Any update?
Is this patch going to be included in 2.6.x/3.0.x in near future?
--
nosy: +tarek
___
Python tracker
<http://bugs.python.org/issue1
Akira Kitada added the comment:
It seems the version number has been bumped now.
Was it okay?
--
nosy: +akitada, tarek
___
Python tracker
<http://bugs.python.org/issue1
Akira Kitada added the comment:
Python 3.0 has --skip-build, too.
Can we close this ticket?
--
nosy: +akitada, tarek
___
Python tracker
<http://bugs.python.org/issue1
Akira Kitada added the comment:
This is reproducible, but I'm not sure why this could be a problem...
Is there any use cases that you think it could be better than failing?
--
nosy: +akitada, tarek
___
Python tracker
<http://bugs.py
Akira Kitada added the comment:
Sorry, but I don't understand this report.
Is reported problem fixed already?
--
nosy: +akitada, tarek
___
Python tracker
<http://bugs.python.org/iss
Akira Kitada added the comment:
Here's the usage of setup.py
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
or: setup.py --help [cmd1 cmd2 ...]
or: setup.py --help-commands
or: setup.py cmd --help
and '--dry-run' is a global opti
Akira Kitada added the comment:
I doubt "strip-extensions" has to be in distutils.
Isn't a simple script like below enough for this?
$ for i in *.py; do mv $i ${i%.py}; done
--
nosy: +akitada, tarek
___
Python tracker
<http
Akira Kitada added the comment:
Similar problem report: http://bugs.python.org/issue1019715
--
nosy: +akitada
___
Python tracker
<http://bugs.python.org/issue1294
Akira Kitada added the comment:
It seems this problem was fixed already.
Can we close this?
--
nosy: +akitada, tarek
___
Python tracker
<http://bugs.python.org/issue1076
Akira Kitada added the comment:
Tarek,
I think this is not a bug and would be safe to close.
What do you think?
--
nosy: +akitada, tarek
___
Python tracker
<http://bugs.python.org/issue977
Akira Kitada added the comment:
I'm having the same problem.
This is a real headache, especially on systems that
run both 32-bit and 64-bit apps, where I often see
"lib64", "include64" and "bin64".
In my opinion, lib, include and bin shouldn't be hard-
Akira Kitada added the comment:
"""
from distutils.core import setup
setup(name="foo", author="bar", maintainer="baz")
"""
gives me
"""
Metadata-Version: 1.0
Name: foo
Version: 0.0.0
Summary: UNKNOWN
Home-page: UNKN
Changes by Akira Kitada :
--
type: -> behavior
___
Python tracker
<http://bugs.python.org/issue1019715>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Akira Kitada :
--
type: -> feature request
versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1 -Python 2.3
___
Python tracker
<http://bugs.python.org/issue
Changes by Akira Kitada :
--
type: -> behavior
versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1 -Python 2.3
___
Python tracker
<http://bugs.python.org/issue
Changes by Akira Kitada :
--
nosy: +tarek
type: -> feature request
versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1 -Python 2.3
___
Python tracker
<http://bugs.python.org/issue
Changes by Akira Kitada :
--
assignee: -> georg.brandl
components: +Documentation
nosy: +georg.brandl, tarek
versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1
___
Python tracker
<http://bugs.python.org/issue
Changes by Akira Kitada :
--
nosy: +tarek
type: -> compile error
___
Python tracker
<http://bugs.python.org/issue4577>
___
___
Python-bugs-list mailing list
Un
Changes by Akira Kitada :
--
nosy: +tarek
type: -> behavior
versions: +Python 2.6, Python 2.7, Python 3.0, Python 3.1 -Python 2.5
___
Python tracker
<http://bugs.python.org/issue1
Akira Kitada added the comment:
Still present in 2.6/3.0
--
nosy: +akitada, tarek
type: feature request -> behavior
versions: +Python 2.7, Python 3.0, Python 3.1
___
Python tracker
<http://bugs.python.org/issue1
101 - 200 of 443 matches
Mail list logo
