Upstream:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=69436
-zefram
Upstream:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=69436
-zefram
hat a
single upstream fix would resolve both bugs.
A near-identical customisation can also be applied to the guile-2.2
package, to ameliorate the same problems there, which I reported as
Bug#1064444 and Bug#1064445.
-zefram
ModuleLoader.nqp:130
(/usr/share/nqp/lib/ModuleLoader.moarvm:load_setting)
from :1
(/usr/lib/perl6/runtime/perl6.moarvm:)
$
raku(1) should not be failing because of an environment variable that
isn't controlling anything and isn't being referenced.
-zefram
uot;; while(1) { rename("a", "b"); rename("b", "a"); }' &
[1] 390457
$ guile-2.2 --no-auto-compile ok.scm
ok
$ guile-2.2 --no-auto-compile ok.scm
Backtrace:
0 (primitive-load "/home/zefram/tmp/g0/b/ok.scm")
ERROR: In procedure primitiv
e_DE.iso88591 guile-2.2 --no-auto-compile
$'foo\xf4\x90\x80\x80bar.scm' 2>&1 | cat -v
perplexity
$ LC_ALL=de_DE.utf8 guile-2.2 --no-auto-compile $'foo\xf4\x90\x80\x80bar.scm'
2>&1 | cat -v
;;; Stat of /home/zefram/tmp/g0/fooM-tM-^PM-^@M-^@bar.scm failed:
;;; Throw to key
of the filename for any purpose. Furthermore,
this limitation must be documented.
-zefram
uot;; while(1) { rename("a", "b"); rename("b", "a"); }' &
[1] 389562
$ guile-3.0 --no-auto-compile ok.scm
ok
$ guile-3.0 --no-auto-compile ok.scm
Backtrace:
0 (primitive-load "/home/zefram/tmp/g0/b/ok.scm")
ERROR: In procedure prim
e_DE.iso88591 guile-3.0 --no-auto-compile
$'foo\xf4\x90\x80\x80bar.scm' 2>&1 | cat -v
perplexity
$ LC_ALL=de_DE.utf8 guile-3.0 --no-auto-compile $'foo\xf4\x90\x80\x80bar.scm'
2>&1 | cat -v
;;; Stat of /home/zefram/tmp/g0/fooM-tM-^PM-^@M-^@bar.scm failed:
;;; Throw to key
of the filename for any purpose. Furthermore,
this limitation must be documented.
-zefram
the environmentally-selected
locale. For ASCII and Latin-1 locales this implies that it can't use
that en dash, and must substitute an ASCII "-". I have no strong opinion
about whether it should use the en dash in a UTF-8 locale.
-zefram
specifically seeing that result with a Latin-1 terminal emulator
and the C locale.
-zefram
would then always be empty by the
time that loop is reached. But it would still be good style to change <>
to , to better indicate the program's intended behaviour.
>If it is, I would like to include your reasoning into a patch for
>upstream, ok?
Sure. You may use that text freely.
-zefram
'|echo wibble'
wibble
#
These arise from its use of the <> Perl operator, which is not suitable
for the implementation of a read-from-list-of-files kind of command.
Because the range of misbehaviour includes writing to arbitrary files
and running arbitrary commands, this is a more severe bug than normal.
-zefram
Package: xindy
Version: 2.5.1.20160104-10
Severity: important
xindy(1) does various funny things if a filename contains characters
that are not usually used in filenames:
$ touch '>t0'
$ ls -l
total 0
-rw-rw-r-- 1 zefram zefram 0 Jul 17 01:21 '>t0'
$ xindy '>t0' 2>/dev/null
$ ls -l
Package: psutils
Version: 1.17.dfsg-4
Severity: minor
If the extractres(1) program attempts to display a usage message, it
gets its own name wrong:
$ extractres -q
Usage: 1 [-merge] [file]
$
-zefram
ers that are not
usually used in filenames:
$ ls -l
total 4
-rw-rw-r-- 1 zefram zefram 2 Jul 17 00:45 t0
$ ts %F '>t1'
$ ls -l
total 4
-rw-rw-r-- 1 zefram zefram 2 Jul 17 00:45 t0
-rw-rw-r-- 1 zefram zefram 0 Jul 17 00:49 t1
$ echo c > 't2 '
$ ts %F 't2 '
Can't open t2 : No such file or
Package: psutils
Version: 1.17.dfsg-4
Severity: important
extractres(1) does various funny things if a filename contains characters
that are not usually used in filenames:
$ touch '>t0.ps'
$ ls -l
total 0
-rw-rw-r-- 1 zefram zefram 0 Jul 17 00:25 '>t0.ps'
$ extractres '>t0.ps'
$ ls -
even an attempt to open the additional files:
$ echo a >t0
$ echo b >t1
$ markdown t0 t1
a
$ markdown t1 t0
b
$ markdown t2doesnotexist
Can't open t2doesnotexist: No such file or directory at /usr/bin/markdown line
221.
$ markdown t0 t2doesnotexist
a
$
-zefram
Package: markdown
Version: 1.0.1-10.1
Severity: important
markdown(1) does various funny things if a filename contains characters
that are not usually used in filenames:
$ echo a > '>t0'
$ ls -l
total 4
-rw-rw-r-- 1 zefram zefram 2 Jul 16 23:20 '>t0'
$ markdown '>t0'
$ ls -l
total 4
3mhint: \tgit branch -m "..., 36) = 36
And a configuration extract:
$ sed -n 6,7p ~/.gitconfig
[color]
ui = never
-zefram
king
step and non-checking conversion recombine into an ordinary checking
conversion of the kind you already have.
-zefram
. Apparently it's
being optimised incorrectly, to a pure identity transformation without
the checking.
-zefram
condition.
-zefram
for efficient job control. I use the commands "fg" (foregrounding the
current job) and "%-" (foregrounding the previous job) all the time,
and I'm thus heavily affected by this bug.
-zefram
syntax.
If it cannot be made to handle arbitrary filenames correctly, then
clojure(1) must at least detect that it can't handle the specified
filename. It must signal an error on any filename it can't handle, and
not use any mangled form of the filename for any purpose. Furthermore,
this limitation must be documented.
-zefram
attached patch therefore fixes this bug in a very simple way, by
deleting the logic that switches focus to the subjob. With this patch
in place, the above test case produces this pleasing output:
% t0 () { sleep 1000; }
% t0
^Zzsh: suspended t0
% echo foo
foo
% :
% jobs
[1] + suspended (signal)
orrectly, then
node(1) must at least detect that it can't handle the specified filename.
It must signal an error on any filename it can't handle, and not use
any mangled form of the filename for any purpose. Furthermore, this
limitation must be documented.
-zefram
to the invoking user, for the duration of its
use by the X server.
-zefram
ly-yellow
text is now rendered in white, until you get up to the first post-list
text "foo", at which point all the text rendered on the screen, plus
the help text, turns yellow.
-zefram
ion should instead use the IEC prefixes "kibi-",
"mebi-", and "gibi-".
-zefram
deal.)
libquvi ought to work around the age gate. It should not impose this
censorship on its users.
I found a discussion of the same issue being addressed in some other
code at <https://github.com/fent/node-ytdl-core/issues/19>. Maybe the
fix they used can be adopted.
-zefram
the rendered x0.html file, and then rewrites
the status line back to its normal state. It then rewrites the rendered
display again with different colouration, and finally waits for input.
-zefram
displayed page, as if ey had never selected the link to the other
page, or as if loading had failed due to a network problem (though no
error message is displayed). This is not long-standing behaviour in my
experience: it is new and problematic.
-zefram
between attempts, doesn't
make it succeed. After a successful repeated page load, further attempts
to load the same page again go back to failing.
-zefram
ecify size
or position should continue to not set those bits, and should accept
whatever geometry the window manager imposes as a result. mplayer should
never be moving or replacing the window after it has been mapped.
-zefram
te(1, "\33[33mcommit 613abc6d16e99bd9834fe6afd79beb61a3a4734d\33[m\n",
56) = 56
Given the configulation, that line should be free of escape sequences.
-zefram
ompletely unchanged,
and add a new command-line option that provides the same information in
the new format.
-zefram
er
is still whitespace-delimited and the first thing following the colon,
so it's still easy to parse out in a backward-compatible way. What do
you think?
-zefram
Michael Kerrisk (man-pages) wrote:
>fixed in upstream quite a long time back (2014).
Ah, cool. The version at
<http://man7.org/linux/man-pages/man2/adjtimex.2.html> is fine.
-zefram
in either microseconds or nanoseconds, depending on the STA_NANO status
flag, just like timex.time.tv_usec.
-zefram
ts (like
"-o +200us", whose meaning would be unaffected by STA_NANO).
-zefram
diff -ur adjtimex-1.29.orig/adjtimex.8 adjtimex-1.29/adjtimex.8
--- adjtimex-1.29.orig/adjtimex.8 2009-03-12 00:31:07.0 +
+++ adjtimex-1.29/adjtimex.82017-04-18 17:00:46.129859207 +0100
anoseconds*. The true raw time
is different from both of the values shown, and for the call made above
should have been shown as
raw time: 1490397277s 23837440ns = 1490397277.023837440
-zefram
so did not configure the package during installation.
The default configuration shouldn't be mucking about with the running
system in uninvited ways.
-zefram
Control: tags -1 -moreinfo
thanks
1a24855e760e71ee9a20a1a90 is the first bad
commit\n", 65) = 65
20408 open("/home/zefram/.gitconfig", O_RDONLY) = 3
20408 read(3, "[user]\n\tname = Zefram\n\temail = zef...@fysh.org\n\tsigningkey
= 0x8E1E1EC1\n\n[color]\n\tui = never\n", 4096) = 93
20408 r
unhighlighted
instance). Obviously this is quite an inconvenience when one wants to
c some text including the search string.
-zefram
guring out which part of the perl build makes the difference.
Something I haven't yet tried varying is the C compiler. I'm using Debian
gcc 4.7.2-5, which doesn't understand the -fstack-protector-strong option
that the failing perls are built with.
-zefram
level of
which I was not previously aware. I can probably track it down from here.
-zefram
to depend on the variable more than it used to.
Fixed in Data-Alias-1.20, now on CPAN.
-zefram
);
if(ret) exit(1);
}
exit(0);
}
$ gcc -std=c99 try_dl.c -ldl -o try_dl
$ ./try_dl /usr/lib/x86_64-linux-gnu/libperl.so.5.20
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
/home/zefram/tmp/try_dl
/lib/x86_64-linux-gnu/ld-2.19.so
/lib/x86_64-linux-gnu/libc-2.19.so
/lib/x86_64
with the clock.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
is not documented seriously
damages the usability of this program to people who don't already know
how to use it.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
confidence in it.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
:
$ ls -l /proc/self/fd
total 0
lrwx-- 1 zefram zefram 64 Apr 3 16:45 0 - /dev/pts/13
lrwx-- 1 zefram zefram 64 Apr 3 16:45 1 - /dev/pts/13
lrwx-- 1 zefram zefram 64 Apr 3 16:45 2 - /dev/pts/13
lr-x-- 1 zefram zefram 64 Apr 3 16:45 3 - /proc/5271/fd
so the man page is not correct
file, little-endian
8 lequad 0x100
8 byte 2 \b, line size 2^%d byte
9 byte 2 \b, page size 2^%d byte
10 byte 1
10 byte 1 \b, max fanout %d
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
the source as shown. If you have difficulty reproducing it,
obviously I can supply these files on request.
I see this on i386 but not on an amd64 machine that has otherwise the
same versions of things installed.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
,
but the space remains.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
::SizeLimit) that makes that mistake.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
to unconditionally and unconfigurably
use /usr/bin/guile-2.0.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
'
$
Subcommands mentioned in the guile documentation are actually available,
despite not being listed.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
]
155: 2 [show-help #directory (scripts frisk) 26d1900 #output: file
/dev/pts/14]
In ice-9/boot-9.scm:
788: 1 [call-with-input-file #f ...]
In unknown file:
?: 0 [open-file #f r #:encoding #f #:guess-encoding #f]
ERROR: In procedure open-file:
ERROR: Wrong type (expecting string): #f
$
-zefram
of guile-1.8, which classifies
+inf.0 and -inf.0 as integers, and +nan.0 as rational but not integer.
guile-2.0 follows R6RS in treating all three of these values as real
but not rational. (Mathematically, infinities are not real, and NaN is,
as the acronym says, not a number.)
-zefram
Upstream:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16364
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Upstream:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16363
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Upstream:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16358
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Upstream:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16357
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Upstream:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16362
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Upstream:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16356
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Upstream:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16361
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Upstream:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16359
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Upstream:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16360
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
script in this sequence:
$ echo '(display hello world\n)' t10
$ guile-2.0 t10
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;; or pass the --no-auto-compile argument to disable.
;;; compiling /home/zefram/usr/guile/t10
;;; compiled
/home/zefram/.cache/guile/ccache/2.0-LE-8-2.0
the --no-auto-compile argument to disable.
;;; compiling /home/zefram/usr/guile/t9
;;; compiled
/home/zefram/.cache/guile/ccache/2.0-LE-8-2.0/home/zefram/usr/guile/t9.go
(5 . 2)
(5 . 2)
$ guile-2.0 t9
(5 . 2)
(5 . 2)
In the test case, the explicitly-constructed pair aaa is conflated with
the pair
--no-auto-compile t8
5
$ guile-2.0 t8
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;; or pass the --no-auto-compile argument to disable.
;;; compiling /home/zefram/usr/guile/t8
;;; WARNING: compilation of /home/zefram/usr/guile/t8 failed:
;;; ERROR: build
is enabled, set GUILE_AUTO_COMPILE=0
;;; or pass the --no-auto-compile argument to disable.
;;; compiling /home/zefram/usr/guile/t11
;;; /home/zefram/usr/guile/t11:7:6: warning: possibly unbound variable
`arg-hack'
;;; compiled
/home/zefram/.cache/guile/ccache/2.0-LE-8-2.0/home/zefram/usr/guile/t11
. Test case:
$ echo '(display aaa\n)' t13
$ echo '(display bbb\n)' t14
$ guile-2.0 t13
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;; or pass the --no-auto-compile argument to disable.
;;; compiling /home/zefram/usr/guile/t13
;;; compiled
/home/zefram/.cache/guile/ccache
On Thu, Jan 02, 2014 at 11:44:09AM +, Zefram wrote:
Thomas Dickey wrote:
which translation was performing the backspace?
I'm not sure what you mean by this question. The relevant item in the
translations resource is
KeyBackSpace: string(0x08)
I have other translation items
))
(newline)
$ guile-1.8 t2
5
$ guile-2.0 --no-auto-compile t2
5
$ guile-2.0 t2
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;; or pass the --no-auto-compile argument to disable.
;;; compiling /home/zefram/usr/guile/t2
;;; WARNING: compilation of /home/zefram/usr/guile/t2
to it
when compilation fails (as the file auto-compilation does).
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
) .
48) . 47) . 46) . 45) . 44) . 43) . 42) . 41) . 40) . 39) . 38) . 37) . 36) .
35) . 34) . 33) . 32) . 31) . 30) . 29) . 28) . 27) . 26) . 25) . 24) . 23) .
22) . 21) . 20) . 19) . 18) . 17) . 16) . 15) . 14) . 13) . 12) . 11) . 10) .
9) . 8) . 7) . 6) . 5) . 4) . 3) . 2) . 1)
-zefram
-9/boot-9.scm:3961:3
()]
3968: 6 [#procedure e9bcc0 at ice-9/boot-9.scm:3961:3 ()]
1645: 5 [%start-stack load-stack #procedure e9c980 at ice-9/boot-9.scm:3957:10
()]
1650: 4 [#procedure e9a060 ()]
In unknown file:
?: 3 [primitive-load /home/zefram/usr/guile/t6]
In ice-9/eval.scm:
387: 2 ^Z
zsh
are inadequately documented. The man page describes
translations only as a resource for the vt100 widget, not for the
scrollbar widget (except for the implication of the example in a
different section of the doc), and has no mention of translations being
applied differently depending on focus.
-zefram
to disable.
;;; compiling /home/zefram/usr/lucifex/on_guile/t0
;;; WARNING: compilation of /home/zefram/usr/lucifex/on_guile/t0 failed:
;;; ERROR: #. read expansion found and read-eval? is #f.
hello world
$
I can turn off the auto-compilation from within the script by using the
--no-auto-compile
affect xterm translations. But I wouldn't be too
surprised if the bug turns out not to be in the xterm source at all but
in one of the X libraries.
(nor do I see a way to reproduce the bug)
Yes. It only happens apparently at random.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ
Package: nvi
Version: 1.81.6-8.2
Severity: minor
The escapetime settable option in nvi is not documented in its man page,
unlike the majority of options.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas
with that relationship.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
-multilib4.7.2-5
gcc-multilib4:4.7.2-1
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
bytecode 106.0, 8 byte words, little-endian, x86 12 byte long
double floats, Parrot 0.0.0
It's producing pbc output regardless of the output filename.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas
= 1234567890123456789
$P1 = $P0 * $P0
say $P1
.end
$ parrot t6.pir
no bigint lib loaded
current instr.: 'main' pc 6 (t6.pir:4)
$ ./from_github/parrot t6.pir
1524157875323883675019051998750190521
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject
between
Debian stable and current github, but still claim that -o foo.pasm
will produce pasm output.
(I'm using the github checkout because that gets me a Parrot with the
bigint library built in. Think I'm going to submit a wishlist ticket
about having that in the Debian Parrot.)
Zefram
elsewhere in the Parrot source
tree (src/ops/*.ops) whereas most of the documentation is stored directly
in the source tree.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
as more text is entered before it.
It disappears at the end of text entry (following Esc). There's no
permanent effect on the file content.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
the video. This bug report is concerned
with mplayer2's failure to ultimately show the video full-screen.
-zefram
$ mplayer -fs t0.mp4
MPlayer2 UNKNOWN (C) 2000-2012 MPlayer Team
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able
. The result is that a window manager that applies
its own positioning logic in preference to program-supplied positions,
but honours user-supplied positions, will override the user-supplied
position with mplayer. The same goes for the USSize hint.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs
but distinct Bug#617361 that was deemed not-a-bug. See also Bug#187138
concerning nearly-identical behaviour of Galeon, and Bug#668850 concerning
related behaviour of Libreoffice.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble
.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
to use it. Applications that turn the
mode on, such as w3m, effectively break normal xterm usage. It would
be nice to have an option that prevents mouse tracking being engaged,
along the lines of the existing allowTitleOps option that can prevent
unwanted changes of window title.
-zefram
will be to later break compilation. The option should be
rejected up front if its implementation is not available.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
1 - 100 of 136 matches
Mail list logo