Bug#465769: libc gets some strtod() cases wrong
Package: libc6
Version: 2.3.6.ds1-13etch4
GNU libc seems to get some of the odder reaches of the C99 strtod()
spec wrong. Observe:
mnementh$ cat strtod-test.c
#include stdlib.h
#include stdio.h
int main(int argc, char **argv) {
double d;
char *endp;
char *s = argv[1];
if (argc != 2)
{
printf(Usage: %s string\n, argv[0]);
return 1;
}
d = strtod(s, endp);
printf(Got value %g, string tail %s\n, d, endp);
return 0;
}
mnementh$ gcc -g -Wall -o strtod-test strtod-test.c
mnementh$ ./strtod-test 0xYOW
Got value 0, string tail YOW
[Should be tail xYOW -- C99 7.20.1.3 para 3 says the hex digits after
the 0x must be a non-empty string. So the longest initial subsequence
matching the expected form is just 0, not 0x.]
mnementh$ ./strtod-test 'Nan(anana)ana'
Got value nan, string tail )ana
[Should be tail ana -- the trailing ')' is also part of the expected
form in the NAN(n-char-seq-opt) form. 7.20.1.3 p3 again.]
-- PMM
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#50949: why did this get tagged 'wontfix' ?
I've just noticed that this bug (50949, xbase-clients: [xmodmap] all line numbers are off-by-one) was tagged 'wontfix' back in April by Brice Goglin with no explanation (at least, Automatically generated email from bts, devscripts version 2.10.2 doesn't seem very explanatory to me...) Can somebody provide an explanation? Or did somebody typo a bug number? thanks -- PMM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459075: nmh: doesn't know where sendmail is on amd64 (probably insufficient Build-Depends)
Package: nmh Version: 1.1-release-4 Architecture: amd64 The amd64 package of nmh doesn't know where sendmail is. If you try to send a message with the default configuration it fails with: post: problem initializing server; [BHST] premature end-of-file on pipe send: message not delivered to anyone strace reveals that it's trying to execute a program called 'no' when it ought to be executing 'sendmail'. This is because when nmh was configured the configure script failed to find a sendmail binary. The Build-Depends ought to be changed so that the build environment is guaranteed to have a sendmail in the right place. (Or I suppose you could hardwire the configure script somehow.) (You can also check with 'strings /usr/lib/mh/post | grep sendmail': this should give (perhaps with some other output) a string which is the full path to sendmail. On amd64 it doesn't.) For users, the workaround is to add to mts.conf the line sendmail: /usr/sbin/sendmail -- PMM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443238: uniprint doesn't complain if the font specified doesn't exist
Package: yudit Version: 2.8.1-2 If you specify a .ttf file to the -font option of uniprint but the ttf file doesn't exist, then uniprint doesn't complain at all, it just outputs a file full of little boxes with numbers in: mnementh$ uniprint -out /tmp/zz9.ps -font /nosuch.ttf /tmp/zz9 uniprint: printed 4 pages. mnementh$ It ought to at least warn and perhaps fail when the user specifies a non-existent file by mistake. -- PMM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#441824: libc6-dbg: /usr/lib/debug/ld-2.3.6.so should be executable
Package: libc6-dbg
Version: 2.3.6.ds1-13etch2
The dynamic loader shipped in libc6-dbg doesn't have the executable bit set.
This means you can't specify it to ld as the dynamic loader, which in turn
means that you can't get source line information in gdb for crashes inside
the dynamic loader.
Watch:
mnementh$ cat /tmp/t.c
#include stdio.h
int main(void) { printf(Hello world\n); return 0; }
mnementh$ gcc -g -Wall -O2 -o /tmp/t /tmp/t.c -Xlinker --dynamic-linker
-Xlinker /usr/lib/debug/ld-linux.so.2
mnementh$ /tmp/t
-bash: /tmp/t: Permission denied
mnementh$ ls -l /tmp/t
-rwxrwxr-x 1 pm215 pm215 8777 2007-09-11 12:09 /tmp/t
mnementh$ su
Password:
mnementh# chmod 775 /usr/lib/debug/ld-2.3.6.so
mnementh# exit
mnementh$ /tmp/t
Hello world
It would be nice if you could make the dynamic loader executable so
this just worked.
-- PMM
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#441317: kernel-package: created kernel postinst silently ignores 'image_in_boot' in kernel-img.conf
Package: kernel-package Version: 10.067 The postinst scripts in packages created by make-kpkg in this version of kernel-package fail to honour the 'image_in_boot' setting in the /etc/kernel-img.conf config file. Symlinks are silently created in / rather than in /boot, resulting in the system not booting the correct kernel. The kernel-img.conf(5) manpage says: The old, and very confusing, name image_in_boot is deprecated, since it is the symbolic link that is usually being relocated. This implies that it should still be supported, even if it would be better to update the config file to use the new value. At a minimum, at some point in the sequence there should be an error telling the user to update their config file to use the new keyword. Silently doing the wrong thing is very unhelpful. -- PMM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428287: zsafe: prints debugging messages to stderr
Package: zsafe Version: 2.1.3-2.1 Here's a transcript of starting zsafe from the command line, entering the password and then quitting: mnementh$ zsafe getDocPassword Width : 600 Height: 370 Width : 1598 Height: 1164 QUIT... It looks as if some debugging output has been accidentally left enabled; this should be taken out. A quick grep for 'qWarning' in the source code reveals quite a lot of these messages, which should probably all be disabled (perhaps by having a macro to turn them off unless compiling for debug purposes). -- PMM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421363: mplayer debconf question about RTC is confusing
Package: mplayer Version: 1.0~rc1-12etch One of the debconf questions mplayer asks on install is: On older kernels MPlayer can use the RTC (Real Time Clock) to provide better timing in reproduction, with less CPU cost; to this end, though, the device /dev/rtc must be accessible to group audio, and the default max-user-freq must be raised to 1024. Any needed change must be done by root. If you wish, MPlayer will automatically do this at boot, so that any user can enjoy this feature. Note that there may be security issues with this (although none are known now). This is confusing; specifically, the reference to 'older kernels' is too vague. Does it mean that if you have a newer kernel: * making the change is a bad idea * making the change is harmless but pointless, and mplayer will have as good a performance as it would have done on older kernels with RTC access * making the change is harmless but pointless, and mplayer will have the same poorer no-RTC-access performance Finally and most obviously, it should say what it means by 'older' -- 2.4? 2.2? 2.6.5 ? Without this information it's impossible to answer the question sensibly. Looking at upstream's website the answer would appear to be 'with newer kernels making the change is somewhere between pointless and a bad idea' -- but I couldn't find any indication of which kernel version counts as 'new' or indeed why the change. -- PMM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421279: x2x: error messages to stderr if 'to' display doesn't support DPMS [PATCH]
Package: x2x
Version: 1.27.svn.20060501-1
If you start x2x where the 'to' display doesn't support DPMS, x2x will
print a warning message to standard error every time the mouse is moved
across to the 'to' display:
zircon$ x2x -to blackrock:0.0 -resurface -west
Xlib: extension DPMS missing on display blackrock:0.0.
Xlib: extension DPMS missing on display blackrock:0.0.
(In this case the target display is a Tektronix X terminal which was
manufactured before the DPMS extension was designed...)
It shouldn't be printing this at all, since if the target display does
not support the extension x2x can simply fall back to its traditional
behaviour of doing nothing (on the assumption that the display doesn't
support blanking and unblanking).
Here's a patch to x2x.c which fixes this -- the first time we try to
do any DPMS action we use DPMSQueryExtension() to see if the display
supports it; if it doesn't we don't do anything.
This works for me. I've tried to put in code so that compiling it for
Cygwin still works, but I haven't tested that at all. I also haven't
checked that it still does the right thing if the target display is
DPMS capable, but I can't see how it could possibly be broken :-)
Hope this helps.
===begin patch===
--- x2x-1.27.svn.20060501/x2x.c 2006-04-30 16:13:50.0 +0100
+++ x2x-1.27.svn.20060501-patched/x2x.c 2007-04-27 15:41:21.935158688 +0100
@@ -103,6 +103,8 @@
#define DPMSModeOn0
extern Status DPMSForceLevel(Display *, unsigned short);
+/* We always support this: */
+#define DPMSQueryExtension(DPY, EVBASE, ERBASE) TRUE
#else
#include X11/extensions/dpms.h
#endif
@@ -139,6 +141,7 @@
#ifndef WIN_2_X
static int ErrorHandler();
#endif
+static voidDoDPMSForceLevel();
static voidDoX2X();
static voidInitDpyInfo();
static voidDoConnect();
@@ -292,6 +295,7 @@
struct _shadow *pNext;
char*name;
Display *dpy;
+ int DPMSstatus; /* -1: not queried, 0: not supported, 1: supported */
} SHADOW, *PSHADOW;
/* sticky keys */
@@ -453,6 +457,7 @@
/* toDpy is always the first shadow */
pShadow = (PSHADOW)malloc(sizeof(SHADOW));
+ pShadow-DPMSstatus = -1;
pShadow-name = toDpyName;
/* link into the global list */
pShadow-pNext = shadows;
@@ -691,6 +696,7 @@
} else if (!strcasecmp(argv[arg], -shadow)) {
if (++arg = argc) Usage();
pShadow = (PSHADOW)malloc(sizeof(SHADOW));
+ pShadow-DPMSstatus = -1;
pShadow-name = argv[arg];
/* into the global list of shadows */
@@ -1386,6 +1392,27 @@
} /* END InitDpyInfo */
+static void DoDPMSForceLevel(pShadow, level)
+PSHADOW pShadow;
+CARD16 level;
+{
+ /* Do a DPMSForceLevel(), but only if the display supports it */
+ if (pShadow-DPMSstatus == -1) {
+/* Need to see if this display supports the DPMS extension.
+ * If it doesn't then trying DPMSForceLevel() will display
+ * a spurious error message to stderr.
+ */
+int t1, t2;
+if (DPMSQueryExtension(pShadow-dpy, t1, t2))
+ pShadow-DPMSstatus = 1;
+else
+ pShadow-DPMSstatus = 0;
+ }
+
+ if (pShadow-DPMSstatus != 0)
+DPMSForceLevel(pShadow-dpy, level);
+}
+
static void DoConnect(pDpyInfo)
PDPYINFO pDpyInfo;
{
@@ -1395,7 +1422,7 @@
PSHADOW pShadow;
for (pShadow = shadows; pShadow; pShadow = pShadow-pNext) {
-DPMSForceLevel(pShadow-dpy, DPMSModeOn);
+DoDPMSForceLevel(pShadow, DPMSModeOn);
XFlush(pShadow-dpy);
}
@@ -1616,7 +1643,7 @@
for (pShadow = shadows; pShadow; pShadow = pShadow-pNext) {
if (doDpmsMouse)
{
- DPMSForceLevel(pShadow-dpy, DPMSModeOn);
+ DoDPMSForceLevel(pShadow, DPMSModeOn);
}
XTestFakeMotionEvent(pShadow-dpy, toScreenNum,
@@ -2324,7 +2351,7 @@
PSHADOW pShadow;
for (pShadow = shadows; pShadow; pShadow = pShadow-pNext) {
-DPMSForceLevel(pShadow-dpy, DPMSModeOn);
+DoDPMSForceLevel(pShadow, DPMSModeOn);
XFlush(pShadow-dpy);
}
@@ -2852,7 +2879,7 @@
for (pShadow = shadows; pShadow; pShadow = pShadow-pNext) {
if (doDpmsMouse)
{
-DPMSForceLevel(pShadow-dpy, DPMSModeOn);
+DoDPMSForceLevel(pShadow, DPMSModeOn);
}
XTestFakeMotionEvent(pShadow-dpy, toScreenNum,
pDpyInfo-xTables[toScreenNum][x],
pDpyInfo-yTables[toScreenNum][y], 0);
===endit===
-- PMM
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404329: nethack-console doesn't handle terminal resizing
Package: nethack-console Version: 3.4.3-6 Nethack-console doesn't seem to correctly handle the SIGWINCH signal which indicates that the terminal has been resized. The effect is that if you resize the window, nethack doesn't display properly. It ought (like any good curses program) to catch the signal, query the terminal for its new size and redisplay correctly. -- PMM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404328: nethack-console: should support --help
Package: nethack-console Version: 3.4.3-6 Severity: wishlist It would be nice if nethack-console supported --help to print a brief usage message. (At the moment it seems to ignore the unknown option completely and just dumps you into the game.) -- PMM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401613: chiark-utils-bin Description undersells itself
Package: chiark-utils-bin Version: 4.1.10 The Description for chiark-utils-bin says it only contains 'with-lock-ex'. However it now also includes 'summer' and 'xacpi-simple', so the description should probably be updated. -- PMM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401611: chiark-backup should depend on chiark-utils-bin
Package: chiark-backup Version: 4.1.10 chiark-backup now includes the backup-snaprsync script. This script uses the 'summer' program from chiark-utils-bin, so there should be a dependency on (an appropriate version of) that package. (PS: I'm currently looking at writing a manpage for backup-snaprsync.) -- PMM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401640: chiark-utils-bin: manpage for summer
Package: chiark-utils-bin Version: 4.1.10 There's no manpage for the summer utility, so I wrote one. I have guessed the copyright dates as 2003-2006 based on information in chiark's /info/new. Feel free to adjust. I should probably file a bug about the bug noted in the BUGS section, but I haven't yet... -- PMM ---begin--- .TH SUMMER 1 December 2006 Debian Chiark-utils-bin .SH NAME summer \- print checksum and system metainformation for files .SH SYNOPSIS .B summer -ACDbfhqt .RI [\| startpoint ...] .br .SH DESCRIPTION .B summer prints the MD5 checksum of the contents, and the system metainformation (ownership, permissions, timestamps, etc.), for a file, or recursively for a whole directory tree. Each command line argument should be a file or directory to be processed; if it is a directory then it will be processed and then its contents will also be processed, recursively. If no .IR startpoint s are specified on the command line then .B summer will read a list of newline-separated startpoints from standard input. Since .B summer correctly handles devices, FIFOs and other non-regular files it is useful for generating and comparing summaries of arbitrary directory trees where md5sum alone would not be. .SH OUTPUT FORMAT .B summer prints one line of information for each filesystem object it processes. Each line has the following columns: .TS tab (@); l l. @MD5sum or file type information @Size of file in bytes @File access rights (in octal) @User ID of owner @Group ID of owner @atime (time of last access) @mtime (time of last modification) @ctime (time of last status change) @Filename .TE For regular files, the first column is the MD5sum. For directories, pipes, symlinks and sockets it is the literal string `dir', `pipe', `symlink' or `socket' as appropriate. For devices it begins with `c' for character or `b' for block devices, followed by the device number as a single 32 bit hex number and as four separate 8 bit hex numbers. Note that certain characters in the filename (including spaces and `\\' characters) are escaped using .B \\\x\c .I NN syntax, where .I NN are two hex digits. This makes the output unambiguous. Filenames will be relative if the relevant .I startpoint was relative, and absolute if it was absolute. For symlinks the filename column includes an indication of the target of the link. .SH OPTIONS .TP .B \-A Do not print the atime (time of last access). The `atime' column will be omitted. .TP .B \-C Do not print the ctime (time of last status change). The `ctime' column will be omitted. .TP .B \-D Do not print directory sizes. The `size' column for directories will read `dir'. .TP .B \-b Do not print mtime (time of last modification) for symbolic links. The `mtime' field for symbolic links will read `link'. .TP .B \-f Include information about errors encountered (for example, unreadable files) in the output, and continue processing. The default is to print error information to standard error and stop immediately an error is encountered. .TP .B \-h Print a brief usage message (and do nothing else). .TP .B \-q Suppress the progress information which .B summer normally prints to standard error. .TP .B \-t Set the field separator between the information and the filename to a tab character (default is space). .SH BUGS .B summer requires switches to be specified in a single argument; that is, .B -ACf is accepted but .B -A -C -f is not. .SH AUTHOR This Manual page was written by Peter Maydell [EMAIL PROTECTED] but may be used by anyone. .SH COPYRIGHT Copyright (C) 2003-2006 Ian Jackson [EMAIL PROTECTED] .br This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ---endit--- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#359167:
Jonathan Amery wrote in bug 359167: The following command segfaults on a particular mailbox that I will attach in follow-up to this bug-report. There doesn't seem to be any attachment in the BTS. Either you didn't send it or it got tagged as spam by somebody... Don't suppose you still have it? -- PMM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387648: jack: dies with curses.error: addstr() returned ERR
Martin Michlmayr wrote: * [EMAIL PROTECTED] [EMAIL PROTECTED] [2006-09-19 15:59]: Yes. It definitely looks like it's a bug in the display side: --silent-mode=yes causes it to complete OK. Can you please send me the jack.* files from this CD? In particularly, jack.freedb http://www.chiark.greenend.org.uk/~pmaydell/misc/bug387648-jackfiles.tgz This is what was in the directory from after I finished the ripping of the CD with --silent-mode=yes. -- PMM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387648: jack: dies with curses.error: addstr() returned ERR
Martin Michlmayr wrote:
* [EMAIL PROTECTED] [EMAIL PROTECTED] [2006-09-15 16:58]:
File /usr/lib/python2.3/site-packages/jack_t_curses.py, line 262, in
dae_stat_upd
status_pad.addstr(map_track_num[num], 0,
(jack_ripstuff.printable_names[num] + : + jack_status.dae_status[num] +
+ jack_status.enc_status[num]))
curses.error: addstr() returned ERR
Is this bug reproducible?
Yes. It definitely looks like it's a bug in the display side: --silent-mode=yes
causes it to complete OK.
zircon$ jack -w /tmp/jackbug -t 13
This is jack 3.1.1 (C)2004 Arne Zellentin [EMAIL PROTECTED]
*info* querying...
/tmp/jackbug/jack-b40d950d
Info: cwd now /tmp/jackbug/hitomi/thermo plastic
Traceback (most recent call last):
File /usr/bin/jack, line 225, in ?
global_error = jack_main_loop.main_loop(mp3s_todo, wavs_todo, space,
dae_queue, enc_queue, track1_offset)
File /usr/lib/python2.3/site-packages/jack_main_loop.py, line 374, in
main_loop
jack_status.dae_stat_upd(i['track'][NUM], :DAE: + new_status)
File /usr/lib/python2.3/site-packages/jack_status.py, line 49, in
dae_stat_upd
jack_term.tmod.dae_stat_upd(num, string)
File /usr/lib/python2.3/site-packages/jack_t_curses.py, line 262, in
dae_stat_upd
status_pad.addstr(map_track_num[num], 0,
(jack_ripstuff.printable_names[num] + : + jack_status.dae_status[num] +
+ jack_status.enc_status[num]))
curses.error: addstr() returned ERR
*warning* abnormal exit
zircon$ jack -w /tmp/jackbug -t 13 --silent-mode=yes
This is jack 3.1.1 (C)2004 Arne Zellentin [EMAIL PROTECTED]
[completes OK and rips the track]
I pulled the sources to jack-3.1.1+cvs20050801 and added some test code
to jack_t_curses.py:
print sys.stderr, dae_stat_upd: num , num, , map_track_num[num]
, map_track_num[num]
print sys.stderr, calling addstr: ,
jack_ripstuff.printable_names[num] + : + jack_status.dae_status[num] + +
jack_status.enc_status[num]
just before the offending call to addstr. (NB that I didn't install so
I'm probably using this version of the .py files with the installed curses
C module; if that's a problem please give me a command line which says
load the module from the build directory :-))
The resulting output doesn't look particularly implausible. Here it is,
in UTF-8, uuencoded to avoid anything in the mail system mangling it en
route:
begin 664 trace-output
M9%E7W-T871?=7!D.B!N=6T@(#$S(P@;6%P7W1R86-K7VYU;5MN=6U=(`P
MF-A;QI;F@861DW1R.B`@,3,@,#,Z-#@Y9;XXNXXHXXJXX***$)O
M;G5S(%1R86-K*3H@(`ID865?W1A=%]U0Z(YU;2`@,3,@+!M87!?=')A
M8VM?;G5M6VYU;5T@(#`*8V%L;EN9R!A91S='(Z(`Q,R`P,SHT-R#ED)OC
M@:[C@:CC@:[EMAIL PROTECTED],@5')A8VLI.B`Z1$%%.B!W86ET:6YG(9OB!S
M=%T=7,@F5P;W)T+BXN(`ID865?W1A=%]U0Z(YU;2`@,3,@+!M87!?
M=')A8VM?;G5M6VYU;5T@(#`*8V%L;EN9R!A91S='(Z(`Q,R`P,SHT-R#E
MD)OC@:[C@:CC@:[EMAIL PROTECTED],@5')A8VLI.B`Z1$%%.B!;/B`@(`@(`@
M(`@(`@(`@(`@(`@(`@(`@(#(T,SDQ,B`P,!=(#T](#I1`@E1R
M86-E8F%C:R`H;6]S=!R96-E;[EMAIL PROTECTED];!L87-T*3H*(!:6QE((N+VIA
M8VLB+!L:6YE(#(S-2P@:6X@/PH@([EMAIL PROTECTED]F]R(#T@:F%C:U]M
M86EN7VQO;W`N;6%I;E]L;V]P*UP,W-?=]D;[EMAIL PROTECTED]U]T;V1O+!S%C
[EMAIL PROTECTED]%E7W%U975E+!E;F-?75E=64L('1R86-K,5]O9F9S970I[EMAIL
PROTECTED]
M92`B+W5SB]L;V-A;]SF,O:F%C:RTS+C$N,2MC=G,R,#`U,[EMAIL PROTECTED],2]J86-K
M7VUA:6Y?;]OYP2(L(QI;F4@,ST+!I;B!M86EN7VQO;W`*(`@(IA
M8VM?W1A='5S+F1A95]S=%T7W5P9AI6R=TF%C:R==6TY535TL((Z1$%%
M.B`B(L@;F5W7W-T871URD*(!:6QE((O=7-R+VQO8V%L+W-R8R]J86-K
M+3,N,2XQ*V-VS(P,#4P.#`Q+VIA8VM?W1A='5S+G!Y(BP@;EN92`U,2P@
M:[EMAIL PROTECTED]%E7W-T871?=7!DB`@(!J86-K7W1EFTN=UO9YD865?W1A=%]U
M0H;G5M+!S=')I;FI[EMAIL PROTECTED]B]L;V-A;]SF,O:F%C:RTS
M+C$N,2MC=G,R,#`U,[EMAIL PROTECTED],2]J86-K7W1?8W5RV5S+G!Y(BP@;EN92`R-C0L
M(EN(1A95]S=%T7W5P9`H@(`@W1A='5S7W!A9YA91S='(H;6%P7W1R
M86-K7VYU;5MN=6U=+`P+`H:F%C:U]R:7!S='5F9BYPFEN=%B;5?;F%M
M97-;;G5M72`K((Z((@*R!J86-K7W-T871URYD865?W1A='5S6VYU;5T@
M*R`B((@*R!J86-K7W-T871URYE;F-?W1A='5S6VYU;5TI*0IC=7)S97,N
=97)R;W(Z(%D9'-T[EMAIL PROTECTED](')E='5R;F5D([EMAIL PROTECTED]
`
end
-- PMM
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387648: jack: dies with curses.error: addstr() returned ERR
Package: jack Version: 3.1.1-3 I have a CD which I tried to rip with jack. It was OK on 1-12 but has some problem with track 13, so that it dies like this: zircon$ jack This is jack 3.1.1 (C)2004 Arne Zellentin [EMAIL PROTECTED] *info* querying... /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ track_12.flac track_13.wav These files will be deleted, continue? y Traceback (most recent call last): File /usr/bin/jack, line 225, in ? global_error = jack_main_loop.main_loop(mp3s_todo, wavs_todo, space, dae_queue, enc_queue, track1_offset) File /usr/lib/python2.3/site-packages/jack_main_loop.py, line 374, in main_loop jack_status.dae_stat_upd(i['track'][NUM], :DAE: + new_status) File /usr/lib/python2.3/site-packages/jack_status.py, line 49, in dae_stat_upd jack_term.tmod.dae_stat_upd(num, string) File /usr/lib/python2.3/site-packages/jack_t_curses.py, line 262, in dae_stat_upd status_pad.addstr(map_track_num[num], 0, (jack_ripstuff.printable_names[num] + : + jack_status.dae_status[num] + + jack_status.enc_status[num])) curses.error: addstr() returned ERR *warning* abnormal exit NB that this is a CD with Japanese language titles on it, which jack is handling in its usual abysmal fashion. -- PMM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319951: Not sure that #319951 is still here
Christian Perrier wrote: Could you please purge/install the package again [As before, this is running stable on an Alpha. I get the same message on a stable ix86 box as well, though.] Actually, I'm morei interested in unstable as there's nothing we can do to fix such bugs in stable. Yes, but you still need to find out whether the lack of a warning is because (1) the font system has been upgraded to support spaces in font names (2) somebody has silently taken the space out of the hints file in the unstable version of your fonts packages (3) some change in defoma means that the warning has gone away but the system still doesn't support spaces in names (which would mean that in future it might all break again, perhaps worse than before). The action you need to take to resolve this bug report differs in each case. As a more general point, if users find that bug reports are always met with an attitude that they will be ignored if they aren't reproducible in unstable they may drift away to other distributions :-( -- PMM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319951: Not sure that #319951 is still here
Christian Perrier wrote:
I've just taken ttf-farsiweb over and while cleaning out the bug log,
I went on this one.
Actually, installing ttf-farsiweb results in:
[Use of uninitialized value in print]
but that's alland it seems harmless.
I'm not sure that this is what you reported. I'm even inclined to
think that these problems are more problems in defoma than problems
in the package itself. Indeed the same messages show up when I
purge/install *other* font packages such as ttf-arabeyes.
See bug 267433 (same bug in ttf-arabeyes) and bug 318854 (same bug in
ttf-{bengali,devanagari,gujarati,punjabi,tamil}-fonts)...
The other font packages have taken the approach of removing the spaces
from the font names in the .hints file. I think you should either do
the same or find some definite defoma documentation that says it's OK
to have spaces (in which case it is a defoma bug because it doesn't
work, perhaps a bug that has been fixed in unstable?) See also bug
134593 (wishlist against defoma suggesting that it support spaces).
I think the 'uninitialized value' stuff is probably bug 325598 in
defoma, and not related.
Could you please purge/install the package again
[As before, this is running stable on an Alpha. I get the same message on
a stable ix86 box as well, though.]
golanth:/home/pm215# dpkg --purge ttf-farsiweb
(Reading database ... 52680 files and directories currently installed.)
Removing ttf-farsiweb ...
Regenerating /etc/vfontcap... done
Purging configuration files for ttf-farsiweb ...
dpkg - warning: while removing ttf-farsiweb, directory
`/usr/share/fonts/truetype/ttf-farsiweb' not empty so not removed.
golanth:/home/pm215# apt-get install ttf-farsiweb
Reading Package Lists... Done
Building Dependency Tree... Done
The following NEW packages will be installed:
ttf-farsiweb
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0B/136kB of archives.
After unpacking 356kB of additional disk space will be used.
Selecting previously deselected package ttf-farsiweb.
(Reading database ... 52670 files and directories currently installed.)
Unpacking ttf-farsiweb (from .../ttf-farsiweb_0.4-1_all.deb) ...
Setting up ttf-farsiweb (0.4-1) ...
Debian::Defoma::Id::defoma_id_register at line 60 in
/var/lib/defoma/scripts/vflib2.defoma: (Nazli Bold,
/usr/share/fonts/truetype/ttf-farsiweb/nazlib.ttf, 20): Illegal argument.
Regenerating /etc/vfontcap... done
golanth:/home/pm215#
-- PMM
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#185006: w3m: doesn't complain if it tries to download file to full disk
Karsten Schoelzel wrote:
Here is a patch which solves the problem by:
If there is a short write in save2tmp stop trying and return with a error
code.
In the main program examine the return code of child processes on SIGCHLD.
If an error occured say so in the Download List Panel.
It's a shame you can't propagate the actual error code through, but
this is definitely better than the previous code :-)
@@ -6400,7 +6407,9 @@ DownloadListBuffer(void)
if (d-ok) {
Strcat(src, Sprintf(input type=submit name=ok%d value=OK,
d-pid));
- if (size d-size)
+ if (d-err)
+ Strcat_charp(src, Error while saving file);
+ else if (size d-size)
Strcat_charp(src, Download incompleted);
else
Strcat_charp(src, Download completed);
While you're changing this bit you might as well fix the grammar error:
Download incompleted is definitely wrong; Download in progress is
better (though I am making assumptions about when it's printed).
-- PMM
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#185006: w3m: doesn't complain if it tries to download file to full disk
Karsten Schoelzel wrote: I have rewritten the patch a bit and hopefully the error messages are a bit better now and the error number is properly propagated. Cool. Thanks for taking the effort to update the patch. -- PMM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#100629: x2x: patches
http://www.eax.com/patches/X2X/x2x-2-daemon.diff http://www.eax.com/patches/X2X/x2x-3-cleanup.diff These URLs are no longer valid, and I can't find the patches with Google; let's just close this bug. The wayback machine has them: http://web.archive.org/web/20031105032725/http://www.eax.com/patches/X2X/x2x-2-daemon.diff http://web.archive.org/web/20021230134207/http://www.eax.com/patches/X2X/x2x-3-cleanup.diff Perhaps you should reopen this bug? For what it's worth, I don't much like the cleanup patch: it turns if (foo = bar) into foo = bar; if (foo) rather than if ((foo = bar)) and introduces what I think are completely spurious 'volatile' qualifiers. -- PMM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364202: x2x: would like to be able to specify window title on command line [PATCH]
Package: x2x
Version: 1.27-8
Severity: wishlist
x2x currently has a '-label' option which lets you specify the text that
goes inside the x2x window. However, it doesn't allow you to specify the
window title (ie the text displayed by your window manager).
I had a need for this feature, so I added it. (if you care, I was running
x2x to display on a Cygwin X server on a windows machine with a voice
recognition application which used the title of the window to identify
an application...)
Anyway, it's a trivial patch and it might be useful in other situations
so here it is; feel free to forward it upstream if x2x still has an
upstream...
NB: this patch fixes in passing a missing blank line in the manpage.
-- PMM
===begin patch===
diff -ur x2x-1.27/x2x.1 x2x-1.27-patched/x2x.1
--- x2x-1.27/x2x.1 2006-04-21 22:04:22.552039110 +0100
+++ x2x-1.27-patched/x2x.1 2006-04-21 22:13:32.963034144 +0100
@@ -155,7 +155,14 @@
(remove the leading XK_).
.TP
.B \-label \fIlabel\fP
+.IP
+Override the label of the control window (useful when running over ssh).
+The label is the text displayed within the control window.
+.TP
+.B \-title \fItitle\fP
+.IP
Override the title of the control window (useful when running over ssh).
+The title is usually displayed by the window manager.
.IP
.SH AUTHOR
David Chaiken
diff -ur x2x-1.27/x2x.c x2x-1.27-patched/x2x.c
--- x2x-1.27/x2x.c 2006-04-21 22:04:22.557038301 +0100
+++ x2x-1.27-patched/x2x.c 2006-02-24 19:45:34.986143344 +
@@ -221,6 +221,7 @@
static char*defaultFN = -*-times-bold-r-*-*-*-180-*-*-*-*-*-*;
static char*fontName= -*-times-bold-r-*-*-*-180-*-*-*-*-*-*;
static char*label = NULL;
+static char*title = NULL;
static char*pingStr = PING; /* atom for ping request */
static char*geomStr = NULL;
static BoolwaitDpy = False;
@@ -370,6 +371,13 @@
#ifdef DEBUG
printf (label = %s\n, label);
#endif
+} else if (!strcasecmp(argv[arg], -title)) {
+ if (++arg = argc) Usage();
+ title = argv[arg];
+
+#ifdef DEBUG
+ printf (title = %s\n, title);
+#endif
} else if (!strcasecmp(argv[arg], -geometry)) {
if (++arg = argc) Usage();
geomStr = argv[arg];
@@ -524,6 +532,7 @@
printf( -shadow DISPLAY\n);
printf( -sticky sticky key\n);
printf( -label LABEL\n);
+ printf( -title TITLE\n);
printf( -buttonmap button# \keysym ...\\n);
exit(4);
@@ -760,10 +769,14 @@
xsh-flags = (PPosition|PBaseSize|PWinGravity);
XSetWMNormalHints(fromDpy, trigger, xsh);
- windowName = (char *)malloc(strlen(programStr) + strlen(toDpyName) + 2);
- strcpy(windowName, programStr);
- strcat(windowName, );
- strcat(windowName, toDpyName);
+ if (title) {
+windowName = title;
+ } else {
+windowName = (char *)malloc(strlen(programStr) + strlen(toDpyName) + 2);
+strcpy(windowName, programStr);
+strcat(windowName, );
+strcat(windowName, toDpyName);
+ }
XStoreName(fromDpy, trigger, windowName);
XSetIconName(fromDpy, trigger, windowName);
@@ -793,7 +806,8 @@
}
XFree((char *) xsh);
- free(windowName);
+ if (windowName != title)
+free(windowName);
/* conversion stuff */
pDpyInfo-toScreen = (doEdge == EDGE_WEST || doEdge == EDGE_NORTH)
===endit===
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#357520: pterm closes all open filedescriptors before running command
Package: pterm Version: 0.58-1 pterm closes all open filedescriptors before running the command, which means that you can't pass it (by arrangement) a filedescriptor. Demonstration: compare the expected results from xterm with what pterm does. zircon$ 4bug.outfile xterm -e /bin/sh -c 'exec 2bug.stderr;exec 4;echo some output' zircon$ cat bug.outfile some output zircon$ cat bug.stderr zircon$ 4bug.outfile pterm -e /bin/sh -c 'exec 2bug.stderr;exec 4;echo some output' zircon$ cat bug.outfile zircon$ cat bug.stderr /bin/sh: line 1: 4: Bad file descriptor The culprit is this loop in unix/uxpty.c (line 756): /* Close everything _else_, for tidiness. */ for (i = 3; i 1024; i++) close(i); Can this be taken out, please? It's just unhelpful. -- PMM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#357167: libgphoto2: FTBFS on stable
Package: libgphoto2 Version: 2.1.6-6 I'm trying to backport libgphoto2 to stable (because 2.1.6 is apparently a requirement if you want a USB camera to work with a 2.6.14 or similar kernel). However, it doesn't seem to build from source: your debian/rules uses dpkg-architecture -qDEB_HOST_ARCH_OS, which doesn't work on stable: DEB_HOST_ARCH_OS is not a supported variable name at /usr/bin/dpkg-architecture line 271. It then ignores this error, and proceeds happily through the building but trips up at the end because print-udev-rules and print-usb-usermap have been left in debian/tmp. This is because this part of debian/rules: ifeq ($(DEB_HOST_GNU_SYSTEM), linux-gnu) sed -e s/[EMAIL PROTECTED]@ //g \ debian/libgphoto2-2.files.in debian/libgphoto2-2.files else grep -v [EMAIL PROTECTED]@ \ debian/libgphoto2-2.files.in debian/libgphoto2-2.files endif has taken the 'else' clause and the generated filelist is wrong. (I can't see where DEB_HOST_GNU_SYSTEM is supposed to be being set...) hope this helps -- PMM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334303: pterm: fix to patch to support input methods
I discovered a bug in my patch to support input methods on pterm -- it
broke ctrl-space (which should send NUL) so it had no effect.
Here's the updated patch. The fix relates to this caveat I mentioned
in my initial patch:
* I chose to work around a bug in mb_to_wc() where it crashes if passed
\0; you might prefer to fix it instead.
The workaround was broken -- this time round I did what I should have
done in the first place and fixed mb_to_wc().
-- PMM
diff -ur putty-0.58/unix/gtkwin.c putty-0.58-patched/unix/gtkwin.c
--- putty-0.58/unix/gtkwin.c2005-04-05 20:37:47.0 +0100
+++ putty-0.58-patched/unix/gtkwin.c2006-03-04 22:43:30.0 +
@@ -37,6 +37,12 @@
#define NCFGCOLOURS (lenof(((Config *)0)-colours))
#define NEXTCOLOURS 240 /* 216 colour-cube plus 24 shades of grey */
#define NALLCOLOURS (NCFGCOLOURS + NEXTCOLOURS)
+/* Index of foreground/background colours in cols[] */
+#define FGCOLIDX 256
+#define BGCOLIDX 258
+
+/* Support X Input Methods ? */
+#define USE_XIM
GdkAtom compound_text_atom, utf8_string_atom;
@@ -96,6 +102,13 @@
int ngtkargs;
guint32 input_event_time; /* Timestamp of the most recent input event. */
int reconfiguring;
+#ifdef USE_XIM
+GdkICAttr *ic_attr;
+GdkIC *ic;
+GdkFont *ic_fontset;
+int cursor_x;
+int cursor_y;
+#endif
};
struct draw_ctx {
@@ -407,13 +420,138 @@
void draw_backing_rect(struct gui_data *inst)
{
GdkGC *gc = gdk_gc_new(inst-area-window);
-gdk_gc_set_foreground(gc, inst-cols[258]);/* default background */
+gdk_gc_set_foreground(gc, inst-cols[BGCOLIDX]);/* default background
*/
gdk_draw_rectangle(inst-pixmap, gc, 1, 0, 0,
inst-cfg.width * inst-font_width +
2*inst-cfg.window_border,
inst-cfg.height * inst-font_height +
2*inst-cfg.window_border);
gdk_gc_unref(gc);
}
+#ifdef USE_XIM
+
+/* These macros should evaluate true if A and B differ */
+#define COLORCMP(A,B) ((A).pixel != (B).pixel)
+#define FONTCMP(A,B) (!gdk_font_equal(A,B))
+#define SIMPLECMP(A,B) ((A) != (B))
+
+#define IC_SET_IF_CHANGED(FIELD,VALUE,MASKBIT)
IC_CMP_SET_IF_CHANGED(SIMPLECMP,FIELD,VALUE,MASKBIT)
+
+/* This macro assumes the following local variables: attr, inst, attrmask */
+#define FILL_IN_ATTRS() do { \
+if (attr-style GDK_IM_PREEDIT_POSITION) { \
+ int width = inst-cfg.width * inst-font_width; \
+ int height = inst-cfg.height * inst-font_height; \
+ int border = inst-cfg.window_border; \
+ IC_SET_IF_CHANGED(spot_location.x, border + inst-cursor_x *
inst-font_width, GDK_IC_SPOT_LOCATION); \
+ IC_SET_IF_CHANGED(spot_location.y, border + (inst-cursor_y+1) *
inst-font_height - 1, GDK_IC_SPOT_LOCATION); \
+ IC_SET_IF_CHANGED(preedit_area.x, border, GDK_IC_PREEDIT_AREA); \
+ IC_SET_IF_CHANGED(preedit_area.y, border, GDK_IC_PREEDIT_AREA); \
+ IC_SET_IF_CHANGED(preedit_area.width, width, GDK_IC_PREEDIT_AREA); \
+ IC_SET_IF_CHANGED(preedit_area.height, height, GDK_IC_PREEDIT_AREA); \
+ IC_CMP_SET_IF_CHANGED(FONTCMP,preedit_fontset, inst-ic_fontset,
GDK_IC_PREEDIT_FONTSET); \
+} \
+IC_SET_IF_CHANGED(preedit_colormap, inst-colmap,
GDK_IC_PREEDIT_COLORMAP); \
+/* These fields are GtkColors and can't be compared with a simple == */ \
+IC_CMP_SET_IF_CHANGED(COLORCMP,preedit_foreground, inst-cols[FGCOLIDX],
GDK_IC_PREEDIT_FOREGROUND); \
+IC_CMP_SET_IF_CHANGED(COLORCMP,preedit_background, inst-cols[BGCOLIDX],
GDK_IC_PREEDIT_BACKGROUND); \
+} while (0)
+
+/* We define IC_CMP_SET_IF_CHANGED suitably to give two functions:
+ * set_ic_attrs() sets all the fields in the attr struct: this
+ * is used only when initially creating the IC
+ * update_ic_attrs() updates only the fields which have changed,
+ * and then calls gdk_ic_set_attr() to tell GDK about them.
+ */
+
+static void update_ic_attrs(struct gui_data *inst)
+{
+GdkICAttributesType attrmask = 0;
+GdkICAttr *attr = inst-ic_attr;
+
+if (!inst-ic) {
+ return;
+}
+
+#define IC_CMP_SET_IF_CHANGED(CMPMACRO,FIELD,VALUE,MASKBIT) do { \
+if (CMPMACRO(attr-FIELD, VALUE)) { attr-FIELD = (VALUE); attrmask |=
MASKBIT; } \
+} while (0)
+FILL_IN_ATTRS();
+#undef IC_CMP_SET_IF_CHANGED
+
+if (attrmask)
+ gdk_ic_set_attr(inst-ic, inst-ic_attr, attrmask);
+}
+
+/* Fill in a GdkICAttr struct from the current
width/height/font/border/colours.
+ * Essentially we set all attributes which aren't set-once.
+ * Returns a GdkICAttributesType mask with bits set where we've set
+ * fields in attr. We assume attr-style is valid.
+ * This is called only when first creating the IC.
+ */
+static GdkICAttributesType set_ic_attrs(struct gui_data *inst, GdkICAttr *attr)
+{
+GdkICAttributesType attrmask = 0;
+
+#define IC_CMP_SET_IF_CHANGED(CMPMACRO,FIELD,VALUE,MASKBIT) do { \
+ attr-FIELD = (VALUE); attrmask |= MASKBIT; \
+} while (0)
+FILL_IN_ATTRS();
+#undef
Bug#276150: ntpd: with certain time servers crashes in sendpkt because inter==NULL
[EMAIL PROTECTED] wrote: [I'm putting this as a comment to bug 276150 because it seems to me to be the same symptoms: viz, crash on startup with certain time servers.] ntpd crashes on startup with a segmentation fault. This turns out to be a problem where the ntp server has an record; it's been reported and fixed upstream: https://ntp.isc.org/bugs/show_bug.cgi?id=353 The easy workaround is to edit your ntp.conf so that it says server -4 my.ntp.server instead of just server my.ntp.server. This forces use of IPv4. -- PMM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#276150: ntpd: with certain time servers crashes in sendpkt because inter==NULL
[I'm putting this as a comment to bug 276150 because it seems to
me to be the same symptoms: viz, crash on startup with certain time
servers.]
ntpd crashes on startup with a segmentation fault. This seems to be
reproducible for me. Here's a backtrace from gdb (I built ntpd from
the source package); it seems to reliably crash in the same place:
(gdb) run -n
Starting program: /usr/local/src/ntp-4.2.0a+stable/build-simple/ntpd/ntpd -n
Program received signal SIGSEGV, Segmentation fault.
sendpkt (dest=0x807b1c0, inter=0x0, ttl=0, pkt=0x807b1c0, len=134721984) at
../../ntpd/ntp_io.c:1413
1413switch (inter-sin.ss_family) {
(gdb) bt
#0 sendpkt (dest=0x807b1c0, inter=0x0, ttl=0, pkt=0x807b1c0, len=134721984) at
../../ntpd/ntp_io.c:1413
#1 0x08061d44 in peer_xmit (peer=0x807b1b8) at ../../ntpd/ntp_proto.c:2418
#2 0x0805e279 in transmit (peer=0x807b1b8) at ../../ntpd/ntp_proto.c:301
#3 0x080691c8 in timer () at ../../ntpd/ntp_timer.c:289
#4 0x08051777 in ntpdmain (argc=0, argv=0xbfefceb0) at ../../ntpd/ntpd.c:1079
#5 0x0805138b in main (argc=134721984, argv=0x807b1c0) at ../../ntpd/ntpd.c:239
Here's my ntp.conf:
===begin===
# NTP configuration file (ntp.conf)
server time.aaisp.net
# Miscellaneous stuff
logfile /var/log/xntpd
#precision -18 # clock reading precision (usec)
driftfile /etc/ntp.drift# path for drift file
statsdir /var/log/ntpstats/ # directory for statistics files
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
# Authentication stuff
#keys /usr/local/bin/ntp.keys # path for keys file
#trustedkey 1 2 3 4 14 15 # define trusted keys
#requestkey 15 # key (7) for accessing server variables
#controlkey 15 # key (6) for accessing server variables
#authdelay 0.72 # authentication delay (SPARC4c/65 SS1+ DES)
#authdelay 0.000159 # authentication delay (SPARC4c/65 SS1+ MD5)
===endit===
If I change the server to 'pool.ntp.org' then ntp works fine.
NB: I am not running exec-shield -- the remarks in this bug about that
are in my opinion a different problem (which should probably have its
own bug report).
-- PMM
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344165: pvftowav prints unnecessary waffle to stderr
Package: mgetty-pvftools Version: 1.1.33-2 Severity: wishlist The pvftowav utility prints a progress message to stdout; this is different to the other pvf utilities, which are silent during normal execution (which makes sense, since they're usable as filters): mnementh$ pvftoau /tmp/foo.pvf /tmp/foo.au mnementh$ pvftowav /tmp/foo.pvf /tmp/foo.wav Writing Wave file: Microsoft PCM format, 1 channel, 8000 samp/sec 8000 byte/sec, 1 block align, 8 bits/samp I think pvftowav shouldn't print this message by default. You could have a --verbose switch to enable it if you wanted (and you could make the other utilities accept --verbose too). -- PMM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341263: autoconf doesn't realise its cache is out of date when included files change
Ben Pfaff wrote: There are at least two different issues here. The first is simply that Autoconf renames sinclude to m4_sinclude via M4sugar. I don't know why bare sinclude works for you; it does not work for me. If I replace sinclude by m4_sinclude, I can reproduce your problem. Odd... When the first issue is cleared up, the second arises. This is what you are pointing out: m4_sinclude does not do dependency tracking. The way to fix this would be to make autom4te record which optional (m4_sinclude) dependencies were present or absent on the last run, so that it could update the target only if that state changed. My advice would be to use m4_include instead of m4_sinclude if possible. I'm using sinclude here to include configure.in fragments from plug-ins into the main configure.in. Some plugins are simple enough not to need any configure.in checks, so they don't have a fragment. I suppose I could force them all to have an empty file and use include, but. (In practice the workaround I've adopted is that we unconditionally blow away the autom4te.cache before running autoconf since we don't run autoconf unless configure.in or a fragment changed, making the cache pretty useless.) Otherwise, if you'd like to implement the above behavior and submit a patch to me, I'd be happy to review it, include it in the Debian Autoconf, and submit to upstream. I might have a look at this (although the internals of autoconf are largely a mystery to me). -- PMM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341263: autoconf doesn't realise its cache is out of date when included files change
Package: autoconf Version: 2.59a-3 Watch: ---begin--- zircon$ mkdir test zircon$ cd test zircon$ cat configure.in AC_PREREQ(2.50) AC_INIT(test,1) AC_CHECK_FUNCS(wombat) sinclude(conf2.in) AC_OUTPUT() zircon$ autoconf zircon$ grep wombat configure for ac_func in wombat zircon$ grep baboon configure zircon$ cat conf2.in AC_CHECK_FUNCS(baboon) zircon$ autoconf zircon$ grep baboon configure zircon$ rm -rf autom4te.cache/ zircon$ autoconf zircon$ grep baboon configure for ac_func in baboon ---endit--- Notice that the first autoconf creates a configure script which has a check for 'wombat' but not 'baboon' (correctly, because at this point conf2.in doesn't exist). We then create conf2.in, but rerunning autoconf has no effect -- this is a bug. Blowing away the autom4te.cache causes autoconf to do the right thing and update the configure script so it includes the new check. This seems to happen both for newly created included files (as in this test sequence) and where a preexisting include file is updated. -- PMM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339518: ncurses: doesn't retry on EINTR when setting tty to noecho in initscr()
Package: libncurses5
Version: 5.4-4
[source inspection suggests upstream's 5.5 still has this bug.]
This is obviously an upstream bug, but I report it to the Debian BTS
in the first instance, for you to forward upstream or fix locally,
as you choose.
The ncurses library, as part of the setup it does in initscr(), calls
tcsetattr() (or moral equivalent) to set the TTY into non-echoing mode.
(To be exact, initscr() calls newterm() calls _nc_initscr() calls
_nc_set_tty_mode() calls GET_TTY().) Unfortunately nothing is handling
the possibility that a signal interrupts tcsetattr and causes it to
return EINTR (the correct response is to retry the call). Moreover,
newterm() ignores the return value from _nc_initscr() so the application
has no chance to find out that initialisation didn't work.
I wouldn't be surprised to find that other parts of ncurses also
failed to handle EINTR correctly; but I haven't checked.
I'm going to append a test program which demonstrates the problem.
The idea of the test program is that because we've started curses
and disabled echoing no characters should be printed in response
to typing. But if we arrange for lots of signals to be received
while we're running initscr() then sometimes the echoing isn't disabled
because the tcsetattr() returned EINTR. You might have to try
running the program multiple times to get the bug to trigger.
(I ran into this whilst developing a genuine application, where it
manifested as a very annoyingly intermittent phenomenon.)
-- Peter Maydell
===begin cursesbug.c===
/* Demonstrate curses bug. Compile with:
* gcc -g -Wall -o cursesbug cursesbug.c -lcurses
*
* Run with: reset ; ./cursesbug [no]
* (the reset is to make sure you have a clean terminal before starting)
* If the optional argument is specified then we don't generate all the
* SIGALRMs.
* When the prompt says, try typing. Nothing should be echoed but if
* signals are flying around then there's a chance that keys will be
* echoed. It's a race condition so you might have to try running the
* program multiple times to trigger it.
*/
#include curses.h
#include stdio.h
#include unistd.h
#include stdlib.h
#include signal.h
#include sys/time.h
#include errno.h
sig_atomic_t quitnow = 0;
void handler(int signum)
{
if (signum == SIGTERM)
quitnow = 1;
}
void register_handler(int sig)
{
struct sigaction sa;
sigset_t ss;
int i;
sa.sa_flags = 0;
sa.sa_handler = handler;
sigfillset(sa.sa_mask);
do
{
i = sigaction(sig, sa, NULL);
} while (i == -1 errno == EINTR);
if (i == -1) {
perror(sigaction failed);
exit(1);
}
sigemptyset(ss);
sigaddset(ss, sig);
do
{
i = sigprocmask(SIG_UNBLOCK, ss, NULL);
} while (i == -1 errno == EINTR);
if (i == -1) {
perror(sigprocmask failed);
exit(1);
}
}
void start_signal_storm(void)
{
struct itimerval p;
int i;
register_handler(SIGALRM);
p.it_value.tv_sec = p.it_interval.tv_sec = 0;
p.it_value.tv_usec = p.it_interval.tv_usec = 1;
do
{
i = setitimer(ITIMER_REAL, p, NULL);
} while (i == -1 errno == EINTR);
if (i == -1) {
perror(setitimer failed);
exit(1);
}
}
void blockalarms(void)
{
sigset_t set;
int i;
sigemptyset(set);
sigaddset(set, SIGALRM);
do
{
i = sigprocmask(SIG_BLOCK, set, NULL);
} while (i == -1 errno == EINTR);
if (i == -1) {
perror(sigprocmask failed);
exit(1);
}
}
int main(int argc, char **argv)
{
register_handler(SIGTERM);
if (argc == 1) {
fprintf(stderr, Starting signal storm...\n);
start_signal_storm();
} else {
fprintf(stderr, Running without signal storm...\n);
}
if (!initscr()) {
fprintf(stderr, initscr failed\n);
return 1;
}
if (cbreak() == ERR) {
fprintf(stderr, cbreak failed\n);
return 1;
}
if (noecho() == ERR) {
fprintf(stderr, noecho failed\n);
return 1;
}
if (clear() == ERR) {
fprintf(stderr, noecho failed\n);
return 1;
}
if (addstr(Start typing now: any echoing is a bug...\n) == ERR)
{
fprintf(stderr, addstr failed\n);
return 1;
}
if (refresh() == ERR) {
fprintf(stderr, noecho failed\n);
return 1;
}
while (!quitnow) {
/* this will get woken up by the SIGALRMs, of course */
sleep(1);
}
/* get here on SIGTERM */
blockalarms();
if (endwin() == ERR) {
fprintf(stderr, endwin failed\n);
return 1;
}
fprintf(stderr, Done.\n);
return 0;
}
===endit===
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334303: pterm: patch to support input methods
Here's a patch to unix/gtkwin.c which adds input method support.
Notes:
* I've made it all conditional on USE_XIM, so you can compile without it.
If you don't care about being able to do that, some of the code at the
end of the keypress handling function could perhaps be improved.
* I chose to work around a bug in mb_to_wc() where it crashes if passed
\0; you might prefer to fix it instead.
* I've tested with Japanese input, in both a UTF-8 and a EUC-JP locale
(you do get 'current locale' strings in key events if using the IM),
and with the C locale (in which case the IM says nothing doing).
* However, I haven't tested on a system with no IM set up at all :-)
* For all this to work we have to run in the real locale, not the C locale
[at least at the point when we open the IM, or it will refuse to work]
I haven't audited the other putty code to see if this is safe!
* In particular, the mb_to_wc() etc code in uxucs.c put us back in the
C locale again...
* We should probably really call gdk_set_locale() on startup whether
compiled USE_XIM or not.
* I notice some remarks in the xterm source to the effect that the font
for the input method is supposed to be in the locale encoding, not
UTF8. Don't know whether this affects pterm. In any case it might be
nice to be able to specify the font for the IM separately from the
main text font (then you can have it a bit bigger if you like) --
xterm allows this.
-- PMM
===begin patch===
--- gtkwin.c.orig 2005-10-29 22:58:37.0 +0100
+++ gtkwin.c2005-10-30 22:07:36.0 +
@@ -37,6 +37,12 @@
#define NCFGCOLOURS (lenof(((Config *)0)-colours))
#define NEXTCOLOURS 240 /* 216 colour-cube plus 24 shades of grey */
#define NALLCOLOURS (NCFGCOLOURS + NEXTCOLOURS)
+/* Index of foreground/background colours in cols[] */
+#define FGCOLIDX 256
+#define BGCOLIDX 258
+
+/* Support X Input Methods ? */
+#define USE_XIM
GdkAtom compound_text_atom, utf8_string_atom;
@@ -96,6 +102,13 @@
int ngtkargs;
guint32 input_event_time; /* Timestamp of the most recent input event. */
int reconfiguring;
+#ifdef USE_XIM
+GdkICAttr *ic_attr;
+GdkIC *ic;
+GdkFont *ic_fontset;
+int cursor_x;
+int cursor_y;
+#endif
};
struct draw_ctx {
@@ -407,13 +420,138 @@
void draw_backing_rect(struct gui_data *inst)
{
GdkGC *gc = gdk_gc_new(inst-area-window);
-gdk_gc_set_foreground(gc, inst-cols[258]);/* default background */
+gdk_gc_set_foreground(gc, inst-cols[BGCOLIDX]);/* default background
*/
gdk_draw_rectangle(inst-pixmap, gc, 1, 0, 0,
inst-cfg.width * inst-font_width +
2*inst-cfg.window_border,
inst-cfg.height * inst-font_height +
2*inst-cfg.window_border);
gdk_gc_unref(gc);
}
+#ifdef USE_XIM
+
+/* These macros should evaluate true if A and B differ */
+#define COLORCMP(A,B) ((A).pixel != (B).pixel)
+#define FONTCMP(A,B) (!gdk_font_equal(A,B))
+#define SIMPLECMP(A,B) ((A) != (B))
+
+#define IC_SET_IF_CHANGED(FIELD,VALUE,MASKBIT)
IC_CMP_SET_IF_CHANGED(SIMPLECMP,FIELD,VALUE,MASKBIT)
+
+/* This macro assumes the following local variables: attr, inst, attrmask */
+#define FILL_IN_ATTRS() do { \
+if (attr-style GDK_IM_PREEDIT_POSITION) { \
+ int width = inst-cfg.width * inst-font_width; \
+ int height = inst-cfg.height * inst-font_height; \
+ int border = inst-cfg.window_border; \
+ IC_SET_IF_CHANGED(spot_location.x, border + inst-cursor_x *
inst-font_width, GDK_IC_SPOT_LOCATION); \
+ IC_SET_IF_CHANGED(spot_location.y, border + (inst-cursor_y+1) *
inst-font_height - 1, GDK_IC_SPOT_LOCATION); \
+ IC_SET_IF_CHANGED(preedit_area.x, border, GDK_IC_PREEDIT_AREA); \
+ IC_SET_IF_CHANGED(preedit_area.y, border, GDK_IC_PREEDIT_AREA); \
+ IC_SET_IF_CHANGED(preedit_area.width, width, GDK_IC_PREEDIT_AREA); \
+ IC_SET_IF_CHANGED(preedit_area.height, height, GDK_IC_PREEDIT_AREA); \
+ IC_CMP_SET_IF_CHANGED(FONTCMP,preedit_fontset, inst-ic_fontset,
GDK_IC_PREEDIT_FONTSET); \
+} \
+IC_SET_IF_CHANGED(preedit_colormap, inst-colmap,
GDK_IC_PREEDIT_COLORMAP); \
+/* These fields are GtkColors and can't be compared with a simple == */ \
+IC_CMP_SET_IF_CHANGED(COLORCMP,preedit_foreground, inst-cols[FGCOLIDX],
GDK_IC_PREEDIT_FOREGROUND); \
+IC_CMP_SET_IF_CHANGED(COLORCMP,preedit_background, inst-cols[BGCOLIDX],
GDK_IC_PREEDIT_BACKGROUND); \
+} while (0)
+
+/* We define IC_CMP_SET_IF_CHANGED suitably to give two functions:
+ * set_ic_attrs() sets all the fields in the attr struct: this
+ * is used only when initially creating the IC
+ * update_ic_attrs() updates only the fields which have changed,
+ * and then calls gdk_ic_set_attr() to tell GDK about them.
+ */
+
+static void update_ic_attrs(struct gui_data *inst)
+{
+GdkICAttributesType attrmask = 0;
+GdkICAttr *attr = inst-ic_attr;
+
+if (!inst-ic) {
+ return;
+}
+
Bug#336390: pterm: on 64 bit machines, on startup, doesn't display text until mouse event or focus loss
Package: pterm
Version: 0.58-1
Symptoms:
I start pterm. It brings up its window, which is cleared to black
with the cursor in the top left corner. After this, nothing happens: the
expected shell prompt isn't printed. Pressing keys has no visible effect.
When I click the mouse on the window or use the window manager to switch
away this causes pterm to suddenly update, printing the shell prompt plus
any characters corresponding to keys I had pressed earlier (and if say
I had pressed 'lsRET' I also get the ls output now).
Complications:
I only see this on Alpha. I'm using the ratpoison window manager, which
is prone to showing up bugs in applications because it tends to map them
and give them the first Expose event very early.
Interesting things:
If I put a sleep(5) just before the call to gtk_main() at the bottom of
gtkwin.c then the problem goes away: pterm sleeps for five seconds and
then displays the prompt fine.
If I put a call to term_invalidate(inst-term) just before gtk_main()
this also causes the problem to disappear.
---begin true but irrelevant stuff---
I thought that the the problem was that the gtkwin front end quietly
drops any drawing events that occur before we've managed to map the
window, but this doesn't seem to be what's actually happening when
I insert debugging printf()s. Still, maybe the code should be changed?
get_ctx() just returns NULL if inst-area-window is NULL, in which
case the code in terminal.c will do no redrawing (but will clear
its internal flag to say no update is required). This is decidedly
unfortunate because the gtkwin's Expose event handler does a blit
of its internal pixmap onto the window: and the pixmap is blank
because we never drew onto it. (Note the completely bogus comment
in expose_area(), incidentally.)
Probably the correct approach is to have get_ctx return NULL only
if inst-pixmap is NULL. The code in do_text and do_cursor which
copies from inst-pixmap to inst-window will have to be conditional
on inst-window not being NULL. Dropping drawing events before
inst-pixmap is created will be fine because in configure_area()
where we create the pixmap we subsequently do a term_invalidate().
I also notice that we call gdk_draw_pixmap() for what looks like
a whole screen blit after every call to do_text() or do_cursor().
Wouldn't it be better to just do that once in free_ctx()?
---endit---
Actual problem:
The gtkwin.c timer code implicitly assumes sizeof(int)==sizeof(long).
On alpha, long is 64 bit, so timer ticks as returned by GETTICKCOUNT()
are 64 bits (and at time of writing well overflowing into the high
word). However, we pass this through to the timer_trigger() routine
with GINT_TO_POINTER() and then retrieve it with GPOINTER_TO_INT().
Unfortunately on alpha GPOINTER_TO_INT(x) is defined as
((gint) (glong) (x)), which truncates the count to 32 bits.
The upshot is that the next timeout is scheduled for aeons in the
future, and we never actually draw anything.
Patch:
---begin---
--- gtkwin.c.orig 2005-10-29 22:58:37.0 +0100
+++ gtkwin.c2005-10-30 00:22:57.0 +0100
@@ -1187,14 +1187,14 @@
static gint timer_trigger(gpointer data)
{
-long now = GPOINTER_TO_INT(data);
+long now = (long)(data);
long next;
long ticks;
if (run_timers(now, next)) {
ticks = next - GETTICKCOUNT();
timer_id = gtk_timeout_add(ticks 0 ? ticks : 1, timer_trigger,
- GINT_TO_POINTER(next));
+ (gpointer)(next));
}
/*
@@ -1216,7 +1216,7 @@
ticks = 1; /* just in case */
timer_id = gtk_timeout_add(ticks, timer_trigger,
- GINT_TO_POINTER(next));
+ (gpointer)(next));
}
void fd_input_func(gpointer data, gint sourcefd, GdkInputCondition condition)
---endit---
Disclaimer: works for me on the Alpha, but totally untested on
32 bit machines. Almost certainly won't work on systems where
pointers are 32 bit but long is 64 bit.
I think that we only ever have one outstanding timer (since
timer_id is a single global, not an array), so we could just
keep 'next' in a global, rather than trying to stuff it into
a pointer and pull it back out again; maybe that'd be cleaner?
Or we could force timer ticks to be 32 bit integers on all
platforms...
-- PMM
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335614: nmh: please build with -g
Package: nmh Version: 1.1-release-4 Policy says that packages should build binaries with a set of CFLAGS like -O2 -g -Wall: http://www.debian.org/doc/debian-policy/ch-files.html#s10.1 However nmh's debian/rules sets CFLAGS to -O2 -Wall only. Please put -g into that, it makes it much easier to debug nmh :-) (The shipped binaries get stripped, of course, but you ought to be able to do a 'debian/rules build' and have debug-info-enabled binaries in the build tree.) thanks -- PMM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#245932: patch for mhshow segfault bug
A long time ago, I wrote:
If my inbox contains the two files appended to this bug report
(both spam) then mhshow segfaults if asked to show both of them
and later:
I think the call to get_content() in mhparse.c:256 is trashing the FILE*.
I got round to tracking this down properly this evening. It's still
present in upstream's 1.1RC4. This patch is against that but probably
will apply to whatever Debian's currently using, since it's pretty
straightforward. The problem was that in the error cases we were
calling fclose() on the FILE* twice -- once inside get_content()
(it's done implicitly by free_content()), and once in the caller.
The easiest thing seemed to be to change the callers not to fclose().
hope this helps,
--PMM
===begin===
--- /usr/local/src/nmh-1.1-RC4-debpatch.pmm/uip/mhparse.c 2003-09-30
17:58:43.0 +0100
+++ uip/mhparse.c 2005-10-25 01:25:40.0 +0100
@@ -259,7 +259,6 @@
if (!(ct = get_content (fp, file, 1))) {
if (is_stdin)
unlink (file);
- fclose (fp);
advise (NULL, unable to decode %s, file);
return NULL;
}
@@ -293,6 +292,7 @@
* toplevel = 0 # we are inside message type or multipart type
* # other than multipart/digest
* toplevel = -1 # we are inside multipart/digest
+ * NB: on failure we will fclose(in)!
*/
static CT
@@ -1056,7 +1056,6 @@
if (!(p = get_content (fp, ct-c_file,
ct-c_subtype == MULTI_DIGEST ? -1 : 0))) {
- fclose (ct-c_fp);
ct-c_fp = NULL;
return NOTOK;
}
@@ -1285,7 +1284,6 @@
fseek (fp = ct-c_fp, ct-c_begin, SEEK_SET);
if (!(p = get_content (fp, ct-c_file, 0))) {
- fclose (ct-c_fp);
ct-c_fp = NULL;
return NOTOK;
}
===endit===
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334298: skkinput: doesn't recognise mod2-mod5 in conversionStartKey X resource
Package: skkinput
Version: 1:2.06.4-1
I tend to hit shift-space by mistake rather too often, so I wanted to move
the start-conversion key combination to Windows-space instead. (I have the
Windows key mapped as X modifier 4, aka 'Hyper'.) So I put this in my
X resources:
Skkinput.xim.conversionStartKey: mod4Keyspace
However, skkinput doesn't recognise 'mod4', only 'shift', 'cntrl', 'lock'
and 'mod1'. The following patch fixes this.
--- skkinput-2.06.4/parseStr.c 2002-06-29 05:48:46.0 +0100
+++ skkinput-2.06.4-mod/parseStr.c 2005-10-16 23:03:49.0 +0100
@@ -96,6 +96,8 @@
static struct keyToMask key_masks[] = {
{ shift, ShiftMask }, { lock, LockMask },
{ cntrl, ControlMask }, { mod1, Mod1Mask },
+{ mod2, Mod2Mask }, { mod3, Mod3Mask },
+{ mod4, Mod4Mask }, { mod5, Mod5Mask },
{ NULL, 0L },
} ;
struct keyToMask *kptr ;
(If you want to test this and you don't have your keyboard set up with
a Mod4 key then
xmodmap -e 'keycode 115 = Hyper_L' -e 'clear Mod4' -e 'add Mod4 = Hyper_L'
will hopefully set up the left Windows key as one, assuming you have
a standard PC keyboard. Probably best to check that with xev.)
Hope this helps.
-- PMM
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334303: pterm doesn't seem to support input methods
Package: pterm Version: 0.58-1 pterm doesn't seem to support input methods, meaning that you can't enter Japanese text into it the same way you can with (say) xterm. A few minutes googling brought up http://developer.gnome.org/doc/API/gdk/gdk-input-methods.html which appears to be the API you need to use. -- PMM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333449: xmon: stray debug printf left in xmond
Package: xmon Version: 1.5.6-1.3 If xmond tries and fails to connect to the real X server, in addition to printing an error message about not being able to connect it prints the text perror clobbered errno. This seems to be a stray bit of test/debug code left in main.c from fixing bug 174792. -- PMM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#63652: xmon: Wishlist: unsupported opcodes
For what it's worth: opcodes 128+ are reserved for X extensions. I believe that these are allocated to extensions by the server at startup: this would mean that you have to (a) catch the reply to the QueryExtension request the application makes so you know the major opcode for the extension is, and (b) teach xmon about the particular extension: generally they have their own private sub-request opcode in the second byte. Events are probably similar. So it's impossible to say what opcode 129 meant to the original submitter. My guess for 'most popular extension not supported by xmon' is the SHM extension. I know enlightenment and other 21st century programs use it a lot for client side rendering. hope this helps -- PMM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322998: memaid-pyqt: does not work on 64 bit architectures
Package: memaid-pyqt
Version: 0.2.3-3
When I try to run memaid-pyqt on my Alpha, it starts up the GUI fine,
and I can bring up the 'add item' dialog from menu or toolbar, but
it doesn't appear to actually add any items. Whenever I click on
one of the numbered buttons (which I assume is supposed to actually
add an item) I see this on stderr:
Traceback (most recent call last):
File /usr/lib/python2.3/site-packages/pyqt_memaid/add_items_dlg.py, line
61, in new_item
add_new_item(grade, q, a, cat_name)
File /usr/lib/python2.3/site-packages/pyqt_memaid/memaid_core.py, line 754,
in add_new_item
e.new_id()
File /usr/lib/python2.3/site-packages/pyqt_memaid/memaid_core.py, line 153,
in new_id
self.id = struct.unpack('L', digest[0:4])[0]
struct.error: unpack str size does not match format
Changing the 'L' to 'L' (to force interpretation as little-endian
32 bits) seems to fix the problem, but I know very little Python
so somebody else should review this before applyng the change :-)
Peter Maydell
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318854: ttf-{bengali,devanagari,gujarati,punjabi,tamil}-fonts: defoma errors on install
Soumyadip Modak wrote: On Sun, 2005-07-17 at 20:57 +0100, [EMAIL PROTECTED] wrote: I suspect that this is because defoma doesn't like fonts with spaces in the name (but the defoma docs don't say explicitly that that's wrong, and I'm no defoma expert, I just looked at the source to see what causes that error message to be produced.) Well technically the name of the Lohit family of fonts don't have any space. E.G. for lohit_bn.ttf FontForge shows : Lohit-Bengali in the FontName field. I was looking at /etc/defoma/hints/ttf-bengali-fonts.hints, which has Lohit Bengali (with space) for both the Family and FontName fields. -- PMM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319951: ttf-farsiweb: defoma errors on install
Package: ttf-farsiweb Version: 0.4-1 Extract from apt-get log (edited to remove references to irrelevant packages; full log available if required): Setting up ttf-farsiweb (0.4-1) ... Debian::Defoma::Id::defoma_id_register at line 60 in /var/lib/defoma/scripts/vflib2.defoma: (Nazli Bold, /usr/share/fonts/truetype/ttf-farsiweb/nazlib.ttf, 20): Illegal argument. Regenerating /etc/vfontcap... done I suspect that this is because defoma doesn't like fonts with spaces in the name (but the defoma docs don't say explicitly that that's wrong, and I'm no defoma expert, I just looked at the source to see what causes that error message to be produced.) The system is a stock 'sarge' and this was a first-time install of the package. This is architecture: alpha, but I don't think that is likely to matter. -- PMM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318854: ttf-{bengali,devanagari,gujarati,punjabi,tamil}-fonts: defoma errors on install
Package: ttf-indic-fonts Version: 0.4.4 Extract from apt-get log (edited to remove references to irrelevant packages; full log available if required): Setting up ttf-bengali-fonts (0.4.4) ... Debian::Defoma::Id::defoma_id_register at line 60 in /var/lib/defoma/scripts/vflib2.defoma: (Lohit Bengali, /usr/share/fonts/truetype/ttf-bengali-fonts/lohit_bn.ttf, 30): Illegal argument. Regenerating /etc/vfontcap... done Regenerating fonts cache... done. Setting up ttf-devanagari-fonts (0.4.4) ... Debian::Defoma::Id::defoma_id_register at line 60 in /var/lib/defoma/scripts/vflib2.defoma: (Lohit Hindi, /usr/share/fonts/truetype/ttf-devanagari-fonts/lohit_hi.ttf, 30): Illegal argument. Regenerating /etc/vfontcap... done Regenerating fonts cache... done. Setting up ttf-gujarati-fonts (0.4.4) ... Debian::Defoma::Id::defoma_id_register at line 60 in /var/lib/defoma/scripts/vflib2.defoma: (aakar Medium, /usr/share/fonts/truetype/ttf-indic-fonts/aakar-medium.ttf, 30): Illegal argument. Debian::Defoma::Id::defoma_id_register at line 60 in /var/lib/defoma/scripts/vflib2.defoma: (Lohit Gujarati, /usr/share/fonts/truetype/ttf-indic-fonts/lohit_gu.ttf, 30): Illegal argument. Regenerating /etc/vfontcap... done Regenerating fonts cache... done. Setting up ttf-punjabi-fonts (0.4.4) ... Debian::Defoma::Id::defoma_id_register at line 60 in /var/lib/defoma/scripts/vflib2.defoma: (Lohit Punjabi, /usr/share/fonts/truetype/ttf-indic-fonts/lohit_pa.ttf, 30): Illegal argument. Regenerating /etc/vfontcap... done Regenerating fonts cache... done. Setting up ttf-tamil-fonts (0.4.4) ... Debian::Defoma::Id::defoma_id_register at line 60 in /var/lib/defoma/scripts/vflib2.defoma: (Lohit Tamil, /usr/share/fonts/truetype/ttf-tamil-fonts/lohit_ta.ttf, 30): Illegal argument. Regenerating /etc/vfontcap... done Regenerating fonts cache... done. I suspect that this is because defoma doesn't like fonts with spaces in the name (but the defoma docs don't say explicitly that that's wrong, and I'm no defoma expert, I just looked at the source to see what causes that error message to be produced.) The system is a stock 'sarge' and this was a first-time install of the package. This is architecture: alpha, but I don't think that is likely to matter. -- PMM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#267433: ttf-arabeyes: defoma errors on postinst: reason: space in FontName?
Since you wrote: I can't seem to reproduce the results you are getting. I thought it was worth my commenting to say that I also run into this error. Here's a section from an apt-get install run: (I was installing ttf-arabeyes for the first time.) ===begin=== Setting up libxdelta2 (1.1.3-6) ... Setting up ttf-alee (4.5) ... Regenerating /etc/vfontcap... done Regenerating fonts cache... /var/lib/dpkg/info/ttf-alee.postinst: line 17: 27249 Killed HOME=/root fc-cache -v /var/log/fontconfig.log 21 failed; see /var/log/fontconfig.log for more information. done. Setting up ttf-arabeyes (1.1-1) ... Debian::Defoma::Id::defoma_id_register at line 60 in /var/lib/defoma/scripts/vflib2.defoma: (Mashq Bold, /usr/share/fonts/truetype/ttf-arabeyes/ae_Mash_bold.ttf, 20): Illegal argument. Debian::Defoma::Id::defoma_id_register at line 60 in /var/lib/defoma/scripts/vflib2.defoma: (AlMothnna Bold, /usr/share/fonts/truetype/ttf-arabeyes/ae_AlMothnna_bold.ttf, 20): Illegal argument. Debian::Defoma::Id::defoma_id_register at line 60 in /var/lib/defoma/scripts/vflib2.defoma: (Rasheeq Bold, /usr/share/fonts/truetype/ttf-arabeyes/ae_Rasheeq_bold.ttf, 20): Illegal argument. Regenerating /etc/vfontcap... done Setting up ttf-arhangai (20030401-2) ... Regenerating /etc/vfontcap... done Setting up ttf-arphic-bkai00mp (2.10-6) ... Regenerating /etc/vfontcap... done Setting up ttf-arphic-bsmi00lp (2.10-6) ... Regenerating /etc/vfontcap... done Setting up ttf-arphic-gbsn00lp (2.11-6) ... Regenerating /etc/vfontcap... done Setting up ttf-arphic-gkai00mp (2.11-6) ... Regenerating /etc/vfontcap... done Setting up xdelta (1.1.3-6) ... Setting up ttf-arphic-ukai (0.0.20050328-2) ... Regenerating /etc/vfontcap... done Setting up ttf-arphic-uming (0.0.20050328-2) ... Regenerating /etc/vfontcap... done Setting up ttf-baekmuk (2.2-1) ... Regenerating /etc/vfontcap... done Setting up ttf-bengali-fonts (0.4.4) ... Debian::Defoma::Id::defoma_id_register at line 60 in /var/lib/defoma/scripts/vflib2.defoma: (Lohit Bengali, /usr/share/fonts/truetype/ttf-bengali-fonts/lohit_bn.ttf, 30): Illegal argument. Regenerating /etc/vfontcap... done Regenerating fonts cache... done. Setting up ttf-devanagari-fonts (0.4.4) ... Debian::Defoma::Id::defoma_id_register at line 60 in /var/lib/defoma/scripts/vflib2.defoma: (Lohit Hindi, /usr/share/fonts/truetype/ttf-devanagari-fonts/lohit_hi.ttf, 30): Illegal argument. Regenerating /etc/vfontcap... done Regenerating fonts cache... done. ===endit=== I note also that it's not just your font package that has this problem, but on the other hand it doesn't affect every font package. I strongly suspect that the problem is that your /etc/defoma/hints/ttf-arabeyes.hints file specifies a FontName for these files which contains a space. The documentation for defoma doesn't seem to say explicitly that it's banned, but it looks like that's the check that's failing and causing the 'Illegal argument' error. -- PMM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#266052: jack: utf8 support: still not displayed right, falls over trying to id3 tag
[I don't know whether you want to handle this by reopening the bug report or treating this as a fresh one.] I've just had a chance to upgrade to the new version of jack which is supposed to fix this bug and add UTF8 support. It correctly queries the server and gets a UTF8 freedb file back. However, the during-ripping display mangles the UTF8 track names rather, giving mojibake, and also doesn't cope with the fact that some characters are double-width. This is a screenshot of what jack looks like: http://www.chiark.greenend.org.uk/~pmaydell/misc/jack-screendump.png For comparison, here's a cat of the freedb file to show what the track names ought to look like: http://www.chiark.greenend.org.uk/~pmaydell/misc/cat-screendump.png Also, once ripping is complete it tries and fails to tag them: This is jack 3.1.1 (C)2004 Arne Zellentin [EMAIL PROTECTED] *info* querying... Tagging..Traceback (most recent call last): File /usr/bin/jack, line 260, in ? jack_tag.tag(freedb_rename) File /usr/lib/python2.3/site-packages/jack_tag.py, line 141, in tag tag.update() File /usr/lib/python2.3/site-packages/eyeD3/tag.py, line 502, in update self.__saveV1Tag(version); File /usr/lib/python2.3/site-packages/eyeD3/tag.py, line 941, in __saveV1Tag tag += self._fixToWidth(self.getTitle().encode(latin_1), 30); UnicodeEncodeError: 'latin-1' codec can't encode characters in position 0-6: ordinal not in range(256) It should ideally tag them properly in UTF8 (if such a thing is possible); failing that, it should catch and report the error in a more user friendly way than a python backtrace. I'm using a UTF8 locale. Filenames are written to disk correctly, so (assuming you're happy to live without id3 tags) it's just a cosmetic issue. Peter Maydell -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#313042: upgrade to sarge hits bug 278417 : release notes should recommend PERL_DL_NONLAZY=1 workaround
Package: upgrade-reports (I'm guessing this is the right place to report this; apologies if I'm wrong.) When upgrading my woody system to sarge (following the procedure recommended by the release notes) it fell over like this: [...] Selecting previously deselected package libxft2. Unpacking libxft2 (from .../libxft2_2.1.7-1_i386.deb) ... Selecting previously deselected package libxi6. Unpacking libxi6 (from .../libxi6_4.3.0.dfsg.1-14_i386.deb) ... Selecting previously deselected package libxt6. Unpacking libxt6 (from .../libxt6_4.3.0.dfsg.1-14_i386.deb) ... /usr/bin/perl: relocation error: /usr/lib/perl5/auto/Text/Iconv/Iconv.so: undefined symbol: Perl_Gthr_key_ptr dpkg: error processing /var/cache/apt/archives/libxt6_4.3.0.dfsg.1-14_i386.deb (--unpack): subprocess pre-installation script returned error exit status 127 [...] and then of course everything else in that dpkg run that was depending on libxt6 failed to configure either. Judging from the archives this is bug 278417. It doesn't seem to be easy to just install the fixed version of debconf early because it has all sorts of dependencies, so I think the easiest thing is probably to use the workaround suggested in that bug of setting PERL_DL_NONLAZY=1 when running aptitude. It worked for me, anyway. Since that bug has been closed and archived I'm filing this bug to say that you need to update the release notes. This isn't a 'pure' woody system (bunch of stuff from backports and 2.6 kernel compatibility packages) but I don't think that's relevant. I have a (nearly) full transcript of the upgrade session if you want it. -- PMM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#313061: looking at /etc/fonts/fonts.conf makes pterm die with a BadName error
Package: pterm Version: 0.58-1 keranth$ pterm [In the pterm session cat the offending file] Gdk-ERROR **: BadName (named color or font does not exist) serial 14733 error_code 15 request_code 75 minor_code 0 The default sarge /etc/fonts/fonts.conf seems to cause this, but I've narrowed it down to a smaller file. begin 664 killpterm.txt A0D\9F%M:6QY/N^\K^\LR#FF([FG)T\+V9A;6EL3X* ` end This is probably a libgtk bug, but let's start here. -- PMM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#313061: looking at /etc/fonts/fonts.conf makes pterm die with a BadName error
Forgot to say, I have this in my .Xdefaults: ! Resources for pterm: use a font which gives us kanji, and don't display scrollbar pterm.Font: -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1 pterm.ScrollBar: 0 ! don't query for confirmation when window manager closes pterm windows: pterm.WarnOnClose: 0keranth$ of which at least the first is probably relevant. -- PMM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#266052: jack: doesn't support UTF8 freedb entries
Martin Michlmayr wrote: * tbm [EMAIL PROTECTED] [2005-04-15 03:43]: There's a lot that needs to be done here to make this proper production quality. Do you know what else is needed? Well, I guess one problem is that the curses library shipped with jack doesn't seem to handle UTF-8 100%, but otoh the curses library that comes with Python seems not to handle UTF-8 at all... As I said in an earlier remark, the layout code for displaying stuff probably need fixes to work with double-width characters -- I don't know how much of that would be a library problem and how much a problem with jack itself. It needs testing to make sure that it behaves sensibly if the charset isn't utf8 (probably filenames should be converted to the user's charset). More significantly, there are several other differences between protocol levels 3 and 6, which need to be accounted for. I only put in a bodge for the most obvious of these, the rest need more consideration. -- PMM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#266052: jack: doesn't support UTF8 freedb entries
Michael Banck wrote: On Mon, Aug 16, 2004 at 03:15:52PM +0100, [EMAIL PROTECTED] wrote: jack doesn't cope properly with CDs whose track titles have non ISO-8859-1 characters in them. I made a quick hack change to my copy of jack so it used protocol level 6, and it seems to work OK sorry I forgot to reply. I talked to upstream about this, and he said he'd address this once he got time (which is pretty rare) Could you send me the patch for this, please? I append it here, but it is of course not suitable to apply as-is (it's against the older version of jack, for a start!) Apart from some debugging print statements, it does the bare minimum: requesting protocol 6 in queries, and handling the new 210 response. There's a lot that needs to be done here to make this proper production quality. -- PMM ===begin=== --- /usr/bin/jack.orig Sun Nov 21 17:19:54 2004 +++ /usr/bin/jack.pmm Sun Nov 21 17:19:39 2004 @@ -1393,12 +1393,13 @@ qs = qs + `i[START] + MSF_OFFSET` + qs = qs + `(MSF_OFFSET + tracks[-1][START] + tracks[-1][LEN]) / CDDA_BLOCKS_PER_SECOND` hello = hello= + username + + hostname + + freedb_servers[freedb_server]['id'] -qs = quote_plus(qs + + hello + proto=3, =) +qs = quote_plus(qs + + hello + proto=6, =) url = http://; + freedb_servers[freedb_server]['host'] + /~cddb/cddb.cgi? + qs +print opening url + url # PMM f = urlopen(url) buf = f.readline() if buf and buf[0:1] == 2: -if buf[0:3] == 211: # Found inexact matches, list follows +if buf[0:3] == 211 or buf[0:3] == 210 : # Found inexact matches or multiple exact matches, list follows print Found inexact matches choose one: num = 1 matches = [] @@ -1443,7 +1444,8 @@ exit() cmd = cmd=cddb read + freedb_cat + + cd_id -url = http://; + freedb_servers[freedb_server]['host'] + /~cddb/cddb.cgi? + quote_plus(cmd + + hello + proto=3, =) +url = http://; + freedb_servers[freedb_server]['host'] + /~cddb/cddb.cgi? + quote_plus(cmd + + hello + proto=6, =) +print 2 opening url + url # PMM f = urlopen(url) buf = f.readline() if buf and buf[0:3] == 210: # entry follows @@ -1452,6 +1454,7 @@ of = open(file, w) buf = f.readline() while buf: +print raw data + buf buf = rstrip(buf) if buf != .: of.write(buf + \n) ===endit=== -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
