y the
same condition.
-zefram
console's ownership set to the invoking user, for the duration of its
use by the X server.
-zefram
es its input while checking the encoding. Apparently it's
being optimised incorrectly, to a pure identity transformation without
the checking.
-zefram
tion, maybe the checking
step and non-checking conversion recombine into an ordinary checking
conversion of the kind you already have.
-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 '
x27;t 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: 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'
$ extractre
certain characters 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 '
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
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 '>t
s
line 114.
# echo > '|echo wibble'
# debconf-set-selections '|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
parts of the output.
I'm specifically seeing that result with a Latin-1 terminal emulator
and the C locale.
-zefram
in any of these locales,
and the help text ought to always conform to 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
lockmore has no installation candidate
#
Where did it go?
-zefram
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
tly says
under no circumstances are currently installed packages removed,
or packages not already installed retrieved and installed.
-zefram
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
reopen 440242
thanks
Eugene V. Lyubimkin wrote:
>Zefram wrote:
>> There's no indication here that it might remove requested packages.
>Requested? 'dist-upgrade' command takes no additional arguments, see synopsis.
I meant "requested" in the sense that I ha
tpd, which presumably used to
involve the ntp-server package, but now appears to be supplied by the
ntp package.
-zefram
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Package: iceweasel
Version: 3.5.16-4
Severity: normal
If I have an iceweasel session open, and then close it by means of an X
"delete window" request, sometimes (not always) a process is left running:
USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND
zefram
ceweasel process,
or restart your system.
and an "OK" button. Clicking on that button terminates the new process
without ever bringing up a real browser window.
See also Bug#187138, concerning nearly-identical behaviour of Galeon.
-zefram
--
To UNSUBSCRIBE, ema
Mike Hommey wrote:
>Are you using KDE styles for GNOME/Gtk applications ?
Not knowingly. I use X resources for a handful of programs, not including
Iceweasel or anything related to it. My window manager is twm. I have
no packages installed with "kde" in the name.
-zefram
--
T
er way.
Curiously, dpkg denies knowledge of
/usr/lib/iceweasel/plugins/libflashplayer.so.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
sometimes, and the
system has to cope with it. I can get similarly-wrong, but not identical,
behaviour by SIGSTOPing a perfectly-working preexisting Iceweasel process.
(In this case the new process hangs, and does not produce the error
window, until the preexisting process is continued, th
Mike Hommey wrote:
>You filed another bug for that
The other bug was for a different problematic behaviour pattern, though
obviously related in underlying mechanism. I don't want to just close
this bug report, because I can well imagine one of the bugs being fixed
without the other.
Please don't
close either as a duplicate, but merge them if you think they're best
handled as a single ticket.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
The submitter suggests that the new effect of "##" et al is the same as
that of "D". It is not: the deleted text doesn't go into the deletion
buffer (which remains unchanged).
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with
Package: nvi
Version: 1.81.6-4
Severity: important
Tags: l10n
nvi used to (in version 1.79) handle all possible octet values in files
being edited. In the present version it has lost this capability: any
octet with the top bit set results in a "conversion error" message, an
unaddressable line whi
Package: toilet
Version: 0.1-2
Severity: important
The package description for toilet says
TOIlet can open FIGlet fonts and is mostly commandline-compatible with it.
This turns out not to be the case. figlet defaults to supplying
plain printable ASCII output. toilet's default output consis
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
ause @ARGV 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
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
0bar.scm'
$ LC_ALL=de_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-
;chdir ".."; 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")
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
0bar.scm'
$ LC_ALL=de_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-
x27;chdir ".."; 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")
ERR
ModuleLoader.moarvm:)
from src/vm/moar/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
me design issue, it's likely that 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#106 and Bug#1064445.
-zefram
nts,
such as "9.53", but the gs that I have installed actually reports version
number "9.53.3". Fixing that code in pdfxup doesn't resolve the rest
of the errors.
-zefram
101 - 138 of 138 matches
Mail list logo
