Bug#415968: Not a bug
This is not a bug in Python, but in the individual scripts. Scripts should not rely on being able to write Unicode strings to stdout. Instead, they need to encode strings explicitly, according to whatever protocol is defined for whatever file they send the data to. In absence of a more specific guidance from the user (or the protocol that they follow), they should use locale.getpreferredencoding(). I propose to close this as won't fix. Python 3 has resolved this issue in a different way, explicitly distinguishing between text files (which get encoded in the locale's encoding unless specified differently), and binary files (which don't support writing Unicode to them). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522478: libio-socket-inet6-perl: AF_UNSPEC fails for IPv6 hosts
I tracked this down to the resolution of an unspecified local
address. On some systems, getaddrinfo('',0,0,2,17,1) returns
127.0.0.1, then ::1; on other systems, it's vice versa. The order
apparently depends on /etc/gai.conf; apparently, there was also
a recent change in the library defaults (to return IPv4 before
v6).
INET6 determines that the remote address is IPv6, and creates
an IPv6 socket. It then tries to bind it to '' (as no local
address was given); this determines that '' is an IPv4 address,
so binding fails.
I think the real error is that it tries to bind at all even
if no local address or port was given. It does so because
lres is defined, i.e. because it was able to resolve the
name '' (around line 211). As it is overwriting laddr for Win32,
it should remember the value of laddr before that, and then
bind only if either laddr or lport were given.
If no local address was given, but a local port, binding needs
to occur, but it needs to consider the server address family,
so it needs to redo getaddrinfo (passing AI_NUMERICHOST to avoid
name lookups).
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#468998: bug verified, patch attached, will NMU during the BSP
It will be uploaded during the BSP next weekend or earlier with your OK. The patch looks right to me, so please go ahead. Regards, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458839: aiccu: Fails to configure: Unknown configuration statement proto
Package: aiccu Version: 20070115-7 Severity: normal After installing aiccu, every attempt to configure it fails with the message: Setting up aiccu (20070115-7) ... Unknown configuration statement on line 2 of /tmp/aiccu1agHXXconf: protoco Unknown configuration statement on line 3 of /tmp/aiccu1agHXXconf: serve dpkg: error processing aiccu (--configure): subprocess post-installation script returned error exit status 1 -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (650, 'testing'), (600, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages aiccu depends on: ii debconf 1.5.17 Debian configuration management sy ii iproute 20071016-2 Professional tools to control the ii iputils-ping3:20071127-1 Tools to test the reachability of ii iputils-tracepath 3:20071127-1 Tools to trace the network path to ii libc6 2.7-5GNU C Library: Shared libraries ii libgnutls13 2.0.4-1 the GNU TLS library - runtime libr ii lsb-base3.1-24 Linux Standard Base 3.1 init scrip Versions of packages aiccu recommends: ii ntp 1:4.2.4p4+dfsg-2 Network Time Protocol daemon and u ii ntpdate 1:4.2.4p4+dfsg-2 client for setting system time fro -- debconf information: * aiccu/username: MVL3-SIXXS aiccu/nobrokers: aiccu/notunnels: aiccu/badauth: * aiccu/tunnelname: T13726 * aiccu/brokername: :// -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#201584: xserver-xfree86: __divsi3 is unresolved
About 3 years ago, you reported a bug to the Debian BTS regarding __divsi3 being unresolved in the X server on ia64. It was supposed to be fixed in experimental. Did you reproduce this problem recently? No, I stopped using X on that platform a long time ago. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405996: Fails to configure
Indeed, py_compilefiles uses os.path without importing it. I fail to see the problem. It imports os, and that should automatically give you os.path, unless 'posix' is not in builtin_module_names (which is hard to imagine). Notice that the original report said 'import site' failed, which means the Python installation on the submitter's machine is broken. Wouter, can you please run python -v and report its output? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405996: Fails to configure
Wouter Verhelst schrieb: Wouter, can you please run python -v and report its output? Attached Thanks. Unfortunately, I can't make sense out of it: when run this way, Python doesn't fail at all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400130: iceweasel-l10n-de: German localization still calls itself Firefox
Package: iceweasel-l10n-de Version: 2.0-1 Severity: normal In the German translation, iceweasel still uses the name Firefox, at least in these places: - Window title (is Mozilla Firefox) - Hilfe/Über Mozilla Firefox (translation of Help/About Iceweasel) - Help system (Mozilla Firefox Help, Willkommen auf den Hilfeseiten von Mozilla Firefox, Mozilla Firefox anpassen, etc) - Bearbeiten/Einstellung (Settings) gives a window titled Firefox Einstellungen - Settings include strings like Wenn Firefox gestartet wird Festlegen, wie sich Firefox mit dem Internet verbindet -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-2-686 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages iceweasel-l10n-de depends on: ii iceweasel 2.0+dfsg-1 lightweight web browser based on M iceweasel-l10n-de recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373533: diff for 1.1.1-2.1 NMU
Pierre HABOUZIT wrote: Attached is the diff for my python-fam 1.1.1-2.1 NMU. Why did you ignore python-fam 1.1.1-2? It already fixed the bugs. Regards, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#375930: python2.3-nevow: Package is uninstallable
Package: python2.3-nevow Version: 0.7.0-1 Severity: grave Justification: renders package unusable The package depends on python2.3-twisted-web, yet that package does not exist (anymore). -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-686-smp Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#279000: Python curses bindings and UTF-8
This bug has now been fixed with the SF patch http://www.python.org/sf/1428494 which has been committed as revisions r42320 and r42321; Debian could probably just copy that code. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#279000: Python curses bindings and UTF-8
Martin Michlmayr wrote:
Martin, can you please look into this?
Thomas is right: Python sets the locale first to , then back
to POSIX. This is intentional: it tries to obtain the CHARSET
during startup, but wants to leave locale control to the script.
So the test script has a bug: it should explicitly perform
setlocale (if ncurses requires that for proper operation).
I'll attach the corrected test script.
I then manually tried to link _curses.so with ncursesw,
and tried running the script, with no success. Investigating
further, it turns out that python links with readline,
and readline links with ncurses, not ncursesw. For some
reason, it is only svn trunk Python which links with
readline, not Debian python, so there is hope.
Regards,
Martin
#!/usr/bin/python
# -*- coding: utf-8 *-
import curses
import time
import locale
locale.setlocale(locale.LC_ALL, )
a = 'Ã'
b = 'â¢'
c = '人'
u_a = unicode(a, utf-8)
u_b = unicode(b, utf-8)
u_c = unicode(c, utf-8)
print a
print u_a
print b
print u_b
print c
print u_c
time.sleep(3)
w = curses.initscr()
w.addstr('umlaut A: ' + a)
w.addstr(\n)
w.addstr('bullet: ' + b)
w.addstr(\n)
w.addstr(Chinese ren: + c)
w.addstr(\n)
w.addstr(\n)
w.addstr('umlaut A: ' + u_a.encode(utf-8))
w.addstr(\n)
w.addstr('bullet: ' + u_b.encode(utf-8))
w.addstr(\n)
w.addstr(Chinese ren: + u_c.encode(utf-8))
w.addstr(\n)
w.addstr(\n)
w.refresh()
time.sleep(3)
curses.endwin()
Bug#341022: Access to root directory
Ritesh Raj Sarraf wrote: Agreed. But instead why not think the other way. The default configuration shouldn't allow symlink access. If people need it, it should get explicitly mentioned in their config. If the default configuration should disallow symlinks, then this what the patch should say, instead of doing host-based access. As a patch, I would have expected this to be formulated as a diff file against the sources, also. Regards, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#279000: Python curses bindings and UTF-8
Martin Michlmayr wrote: Strange. What x-terminal-emulator are you using? I normally use pterm. I just tried xterm and it in I don't see the bullet at all with the Python and I see a ' @ ' in curses. I was confused. I didn't wait the three seconds to see the ncurses actually start. I also tried compiling/linking with ncursesw instead; this didn't change anything. Regards, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#279000: Python curses bindings and UTF-8
Martin Michlmayr wrote: Woo, thanks for the note. I can confirm that this works now - I see the Chinese character too. However, while I can see the umlaut a and the Chinese ren, the bullet is not displayed properly. Do you get this too? Instead of • I see [EMAIL PROTECTED] I can see the bullet just fine. Regards, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#279000: Python curses bindings and UTF-8
Martin Michlmayr wrote: Strange. What x-terminal-emulator are you using? I normally use pterm. I just tried xterm and it in I don't see the bullet at all with the Python and I see a ' @ ' in curses. uxterm, from xterm 208-3.1. Locale is set to de_DE.UTF-8. Regards, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#279000: Python curses bindings and UTF-8
I just tried to reproduce the problem, with python 2.3.5-9 and libncurses5 5.5-1, and it just worked. I couldn't try the original problem (since I don't know what to use cplay for), but in Martin Michlmayrs test case, the bullets display fine (the Japanese characters show as a dotted box, due to a lacking glyph). I also tried with stock trunk Python, and it also work, so it is unlikely that something has changed in Python; instead, it appears that ncurses does now do the right thing. Regards, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347302: 347302: Can you give more reproduction detail?
Max Bowsher wrote: Can you give more detail about how to reproduce the error? Unfortunately, no - it is hardly reproducable. I was hoping that somebody was immediately apparent from the error message. It certainly isn't a common error, so it must be being triggered by something unique to your system. It would be useful to know what access method you are using (file:///, svn://, http://), as well as anything else you think might be relevant. It was https:// It might have something to do with me operating in a subdirectory, when the repository was locked. I'll try to reproduce it later this month. It's not likely that anything can be done with the information currently in the bug report. Ok, if you don't hear from me again, please close it. Regards, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324051: Bogus free space display on Alpha
With python 2.4_2.4.2-1 and libc6.1-dev 2.3.5-7 I get exactly the same
code, except that statvfs is now declared
Somebody will need to debug through the code. I cannot see anything
wrong with the code, and on the systems I have access to, it always
produces the correct results. As another test, running the program
below may provide insights: it does exactly what Python does, so
it might reveal a compiler, C library bug, or kernel bug.
#include sys/statvfs.h
#include stdio.h
void print(struct statvfs value)
{
printf(%ld\n, (long)value.f_bavail);
}
int main(int argc, char*argv[])
{
struct statvfs st;
if(argc!=2){
printf(usage: checkstat path\n);
return 1;
}
statvfs(argv[1], st);
print(st);
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338572: FHS: Python distutils should be configured to install under /usr/local by default
Seo Sanghyeon wrote: Instead of referring confused users to the distutils manual all the time, Debian's Python should be configured to install under /usr/local when using distutils to do local install by default. This will break the build process of many Python-based packages, right? They don't give an explicit prefix when running setup.py, so they would install into /usr/local, which in turn would violate Debian policy. Regards, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324051: Bogus free space display on Alpha
Looks like it. doko, can you please look at this? This is in both
2.3 and 2.4. I'm surprised that Python would have such a bug that's
still not fixed but maybe it's just not compiled with the right
options or something?
It looks like a 64-bit issue indeed: 4912214227121058 in hex is
0x1173A2001173A2L, so the real value apparently should be 0x1173A2.
I tried reproducing this on the SF compile farm (Debian 3.0),
with stock Python 2.3.5, but I couldn't: it just works correctly
there. So there must be something wrong with the build process,
the C library, or the kernel.
It would be helpful to get the preprocessor output for posixmodule.i.
I'll include the relevant fragments from SF below; on the real build
environment, you should see the same (somewhat differently formatted).
One cause for these results would be if a 64-bit struct statvfs
would be used to call the 32-bit statvfs(2).
Regards,
Martin
struct statvfs
{
unsigned long int f_bsize;
unsigned long int f_frsize;
__fsblkcnt64_t f_blocks;
__fsblkcnt64_t f_bfree;
__fsblkcnt64_t f_bavail;
__fsfilcnt64_t f_files;
__fsfilcnt64_t f_ffree;
__fsfilcnt64_t f_favail;
unsigned long int f_fsid;
unsigned long int f_flag;
unsigned long int f_namemax;
int __f_spare[6];
};
extern int statvfs(__const char *__restrict __file,
struct statvfs *__restrict __buf)
__asm__ ( statvfs64) ;
static PyObject*
_pystatvfs_fromstructstatvfs(struct statvfs st) {
PyObject *v = PyStructSequence_New(StatVFSResultType);
if (v == ((void *)0) )
return ((void *)0) ;
(((PyStructSequence *)( v ))-ob_item[ 0 ] =
PyInt_FromLong((long) st.f_bsize) ) ;
(((PyStructSequence *)( v ))-ob_item[ 1 ] =
PyInt_FromLong((long) st.f_frsize) ) ;
(((PyStructSequence *)( v ))-ob_item[ 2 ] =
PyInt_FromLong((long) st.f_blocks) ) ;
(((PyStructSequence *)( v ))-ob_item[ 3 ] =
PyInt_FromLong((long) st.f_bfree) ) ;
(((PyStructSequence *)( v ))-ob_item[ 4 ] =
PyInt_FromLong((long) st.f_bavail) ) ;
(((PyStructSequence *)( v ))-ob_item[ 5 ] =
PyInt_FromLong((long) st.f_files) ) ;
(((PyStructSequence *)( v ))-ob_item[ 6 ] =
PyInt_FromLong((long) st.f_ffree) ) ;
(((PyStructSequence *)( v ))-ob_item[ 7 ] =
PyInt_FromLong((long) st.f_favail) ) ;
(((PyStructSequence *)( v ))-ob_item[ 8 ] =
PyInt_FromLong((long) st.f_flag) ) ;
(((PyStructSequence *)( v ))-ob_item[ 9 ] =
PyInt_FromLong((long) st.f_namemax) ) ;
return v;
}
static PyObject *
posix_statvfs(PyObject *self, PyObject *args)
{
char *path;
int res;
struct statvfs st;
if (!PyArg_ParseTuple(args, s:statvfs, path))
return ((void *)0) ;
{ PyThreadState *_save; _save = PyEval_SaveThread();
res = statvfs(path, st);
PyEval_RestoreThread(_save); }
if (res != 0)
return posix_error_with_filename(path);
return _pystatvfs_fromstructstatvfs(st);
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324161: debhelper: dh_installdocs does not install symbolic links
Package: debhelper Version: 4.9.5 Severity: normal dh_installdocs skips symbolic links. This makes it unusable for python-xlib, where index.html is a symlink to python-xlib_toc.html. The cause of the problem is in dh_installdocs line 136, which finds using '-type f'. Using '\\( -type f or -type l \\)' would work better. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13-rc6mvl Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages debhelper depends on: ii binutils 2.16.1-2 The GNU assembler, linker and bina ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii debconf-utils 1.4.57 debconf utilities ii dpkg-dev 1.13.11package building tools for Debian ii file 4.12-1 Determines file type using magic ii html2text 1.3.2a-2 An advanced HTML to text converter ii perl 5.8.7-4Larry Wall's Practical Extraction ii po-debconf0.8.23 manage translated Debconf template debhelper recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#183150: ITP: python-fam -- Python bindings of FAM routines
I have a python-fam package ready; I just need to find a sponsor to upload it. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293932: [Python-Dev] license issues with profiler.py and md5.h/md5c.c
Phillip J. Eby wrote: I personally can't see how taking the reasonable interpretation of a public domain declaration can lead to any difficulties, but then, IANAL. The ultimate question is whether we could legally relicense such code under the Python license, ie. remove the PD declaration, and attach the Python license to it. I'm sure somebody would come along and claim you cannot do that, and because you did, I cannot use your code, because it is not legally trustworthy; people would say the same if the PD declaration would stay around. It is important for us that our users (including our commercial users) trust that Python has a clear legal track record. For such users, it is irrelevant whether you think that a litigation of the actual copyright holder would have any chance to stand in court, or whether such action is even likely. So for some users, replacing RSA-copyrighted-and-licensed code with PD-declared-and-unlicensed code makes Python less trustworthy. Clearly, for Debian, it is exactly the other way 'round. So I have rejected the patch, preserving the status quo, until a properly licensed open source implementation of md5 arrives. Until then, Debian will have to patch Python. But again, IANAL, certainly not a famous one like Mr. Rosen. I *am* most curious to know why his article seems to imply that a promise not to sue someone for copyright infringement isn't a valid defense against such a suit It might be, but that is irrelevant for open source projects that include contributions. Either they don't care too much about such things, in which case anything remotely free would be acceptable, or they are very nit-picking, in which case you need a good record for any contribution you ever received. Regards, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#279000: Python curses bindings and UTF-8
Martin Michlmayr wrote: I received a bug report against cplay (a front-end for audio players written in Python and using ncurses) that it doesn't support UTF-8. While trying to solve this problem, the bigger question came up whether the Python bindings actually support UTF-8. In Debian, we have a libncurses5 library and a libncursesw5 for wide characters. Is it just a matter of compiling the Python bindings against libncursesw5 or is there work needed on the bindings itself so they support UTF-8? I'm uncertain as to how ncurses deals with multi-byte characters - one might think that UTF-8 is just a multi-byte encoding (where a single character can require multiple bytes), and that they can be sent to the terminal as-is. This, of course, would require that control sequences are sent to the terminal only at character boundaries - something that the application would have to guarantee. The other issue with multi-byte characters is columnns - you cannot equate single byte == single column. OTOH, in true non-ASCII applications, you cannot thus equate, anyway, since some characters (e.g. Hanji full-width characters) take two columns, anyway. Not sure how curses deals with that phenomenon. I guess once there are UTF-8 aware Python curses bindings, I have to change cplay to use UTF-8 internally (however that may work), but right now I'm wondering about the bindings itself. The libncursesw5 is certainly not about UTF-8, and Python does not support it at the moment. It probably should, which would mean that, on the C API, you don't pass char/char* anymore, but wchar_t/wchar_t*. On the Python API, you would pass Unicode objects, instead of string objects. IOW, there seem to be two options: 1. Use char*, and UTF-8, and Python byte strings. Make sure you always keep the multiple bytes of a byte string together; this is easiest to achieve by converting them to Unicode temporarily. So instead of for c in data: if condition: output escape sequence output c do udata = data.decode(UTF-8) for c in udata: if condition: output escape sequence output c.encode(UTF-8) 2. Implement a true Unicode API for curses, using libncursesw. This would check the actual parameters to see whether they are byte strings or Unicode strings, and invoke the appropriate curses library (assuming you can mix curses and cursesw in single terminal - or choke if somebody tries to mix byte strings and Unicode strings in a single terminal). Then, above loop becomes udata = data.decode(UTF-8) for c in udata: if condition: output escape sequence output c So the difference would be that you can directly send Unicode characters, instead of encoding them as UTF-8 first. In either case, you might need to deal with the issue of full-width characters (i.e. characters that consume horizontally twice as much space as the latin letters). Not all terminals support full-width in the first place; xterm is an example for a terminal that does. Regards, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
