Bug#342592: can't GET a previously-POSTed URL

[Zefram]

Package: lynx-ssl
Version: 2.8.4.1b-3
Severity: normal

If the document served by a POST action contains a normal link to the
same URL that was POSTed to, then on following the link Lynx will repeat
the POST instead of doing the GET that it should.  I encountered this
bug while attempting to report a bug in Mutt's Gnats database, so here's
the recipe to reproduce it and demonstrate the envelope:

0. lynx http://bugs.mutt.org
1. In the login form, fill in username "guest" and password "guest".
2. Submit login form, thus POSTing to
   <http://bugs.mutt.org/cgi-bin/Gnatsweb.pl?database=mutt>.
3. Accept two cookies.
4. Observe that the new page contains an ordinary link to
   <http://bugs.mutt.org/cgi-bin/Gnatsweb.pl?database=mutt>, the very
   same URL, and invites you to follow it.
5. Follow the link.  At this point you're supposed to get the Gnats main
   page, but instead you get the same page again.
6. Edit the URL of the current page, adding "&a=b" on the end.
   This yields the Gnats page as it's supposed to.
7. Edit the URL again, removing the "&a=b" to bring it back to what it
   was before.  This now works, yielding the Gnats page again.

-zefram


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#290136: RFP: libtime-unix-perl -- cross-platform time() for Perl

[Zefram]

Package: wnpp
Severity: wishlist

URL: 
License: Perl standard (dual licensed, GPL and Artistic)

Time::Unix provides a time() function that uses the Unix epoch regardless
of OS platform.  This is both an aid to cross-platform coding and a
proof-of-concept for behaviour that should become standard in Perl 6.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#723573: xterm occasionally forgets BackSpace translation

[Zefram]

retitle 723573 usual translations not applied when focus is on scrollbar
thanks

I've managed to reliably reproduce the problem.  When the mouse pointer
is located on the xterm's scrollbar, showing the up-and-down-arrow mouse
cursor, none of the translations in the "XTerm.vt100.translations"
resource get applied.  This doesn't only affect backspace, it also
affects some scrolling keys that I've set up in the same resource.
The translations are applied normally when the mouse pointer is in the
text part of the xterm, showing the I-beam mouse cursor, and when the
mouse pointer is on the window frame or titlebar, showing a mouse cursor
determined by the window manager.  Toggling the backspace option fixed
the problem merely by virtue of moving the mouse off the scrollbar.

The man page contains an oblique note about applying different
translations in the scrollbar context.  (It talks about changing mouse
button behaviour, not keys.)  It shows a resource name pattern of
"*VT100.scrollbar.translations".  Based on that, I've tried setting
a resource under the name "XTerm.vt100.scrollbar.translations", and
it turns out that the scrollbar context obeys translations that are
placed there.  As a permanent change, I've changed my resource settings
to specify the translations under a key of "XTerm.vt100*translations"
instead of "XTerm.vt100.translations".  Empirically this fixes the issue:
the translations now apply when focus is on the scrollbar as well as in
the other focus states.

So it may possibly be a bug that, in the absence of an overriding
XTerm.vt100.scrollbar.translations, XTerm.vt100.translations isn't applied
when focus is on the scrollbar.  Don't know whether that's intentional.
But it is certainly a bug that the names by which translation resources
are looked up 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 UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734009: auto-compile noise can't be avoided by script

[Zefram]

Package: guile-2.0
Version: 2.0.9+1-1
Severity: important

Guile 2.0 has a facility to automatically cache a compiled version of any
Scheme source file that it loads, and it wants the world to know about it!
If auto-compilation is enabled, which it is by default, then when guile
loads a file (that was not already compiled) it emits a banner describing
the auto-compilation.  This interferes with the proper functionality
of any program written as a guile script, by producing output that the
program did not intend.  I have tried to work around this, and although
a command-line switch can turn off the auto-compilation, it's a switch
that isn't recognised by earlier versions of guile, so there's no way for
a script to avoid the noise while being portable between guile versions
1.8 and 2.0.  There's also no way to avoid the noise and actually get
the auto-compilation behaviour.

I am mainly concerned about being portable between versions while
avoiding the noise.  In my particular case, my script uses the
read-eval (#.) feature, which means that the compilation process
actually can't work.  (I have good reason for this, and for related
reasons the auto-compilation is also of essentially no value for
this script.)  This means that *every* time the script is run, not
just the first time, guile emits the banner about auto-compilation,
followed by a rather misleading warning/error about compilation failure.
It's misleading because it then goes on to execute the script just fine.
I can demonstrate this with a minimal test case:

$ cat t0
#!/usr/bin/guile -s
!#
(fluid-set! read-eval? #t)
(display #."hello world")
(newline)
$ guile-1.8 -s t0
hello world
$ guile-2.0 -s t0
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;   or pass the --no-auto-compile argument 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 option, but that breaks compatibility to 1.8:

$ cat t1
#!/usr/bin/guile \
--no-auto-compile -s
!#
(fluid-set! read-eval? #t)
(display #."hello world")
(newline)
$ guile-2.0 '\' t1
hello world
$ guile-1.8 '\' t1
guile-1.8: Unrecognized switch `--no-auto-compile'
Usage: guile-1.8 OPTION ...
Evaluate Scheme code, interactively or from a script.
...

guile should not be emitting this banner by default.  It's really not
acceptable to damage the visible behaviour of a program that worked
fine on older guile versions.  It also, for this auto-compilation to
serve as the invisible optimising cache as which it's intended, ought to
keep quiet about compilation failure: the fallback to interpreting the
script should be silent.  But if such sensible behaviour is somehow not
possible, it absolutely needs to be possible for a script to turn off the
auto-compilation in a way that's compatible with guile-1.8 and earlier.
I have rated this bug "important" because of this lack of workaround.

-zefram


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#723573: xterm occasionally forgets BackSpace translation

[Zefram]

>On Thu, Jan 02, 2014 at 11:44:09AM +0000, 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

BackSpace: string(0x08)

I have other translation items in the same resource, such as

Alt b: scroll-back(1,page)

which are equally affected by this problem.

I've stored the resource under different keys at different times, as
described in my previous message.  In one experiment I had separate
XTerm.vt100.translations and XTerm.vt100.scrollbar.translations,
and for the experiment I put different content in the two resources.
XTerm.vt100.translations applied when focus was on the text, frame,
or titlebar, and XTerm.vt100.scrollbar.translations applied when focus
was on the scrollbar.  My permanent setup has only a single translations
resource, under the key "XTerm.vt100*translations".

>As long as the translations merge rather than override, that's a good solution.

I'm not sure what you're imagining merging.  As I have only one
translations resource, there's no merging to perform among my resources.
My resource does merge with the default key and mouse bindings, of which
the mouse bindings differ between scrollbar context and other contexts.

-zefram


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734108: interactive use subject to compiler limitations

[Zefram]

Package: guile-2.0
Version: 2.0.9+1-1
Severity: important

guile-2.0's compiler has some inconvenient restrictions, relative to its
interpreter.  Where the compiler is automatically applied to scripts, the
restrictions aren't a serious problem, because if compilation fails then
guile falls back to interpreting the script.  But in an interactive REPL
session, it appears that each form entered by the user is passed through
the compiler, and if compilation fails then the error is signalled,
with no fallback to interpretation.

As a test case, consider a form in which a procedure object appears.
The compiler can't handle forms that directly reference a wide variety of
object types, including procedures (both primitive and user-defined) and
GOOPS objects.  In the interpreter these objects simply self-evaluate,
and it can be useful to reference them without the usual indirection
through a named variable.  Here I'll show what happens to such a form
in a script and interactively, in guile 1.8 and 2.0:

$ cat t2
(cond-expand
  (guile-2
(eval-when (compile load eval)
  (fluid-set! read-eval? #t)))
  (else
(fluid-set! read-eval? #t)))
(define (p x y) (#.+ x y))
(write (p 2 3))
(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 failed:
;;; ERROR: build-constant-store: unrecognized object #
5
$ guile-1.8
guile> (fluid-set! read-eval? #t)
guile> (define (p x y) (#.+ x y))
guile> (p 2 3)
5
guile> ^D
$ guile-2.0
GNU Guile 2.0.9-deb+1-1
Copyright (C) 1995-2013 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> (fluid-set! read-eval? #t)
scheme@(guile-user)> (define (p x y) (#.+ x y))
While compiling expression:
ERROR: build-constant-store: unrecognized object #
scheme@(guile-user)> (p 2 3)
:3:0: In procedure #:3:0 ()>:
:3:0: In procedure #:3:0 
()>: Unbound variable: p

-zefram


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734108: interactive use subject to compiler limitations

[Zefram]

severity 734108 normal
thanks

I have discovered that there is a workaround for this problem: there is
an option in the REPL to control whether forms go through the compiler
or the interpreter.  Hence:

scheme@(guile-user)> (fluid-set! read-eval? #t)
scheme@(guile-user)> (#.+ 2 3)
While compiling expression:
ERROR: build-constant-store: unrecognized object #
scheme@(guile-user)> ,o interp #t
scheme@(guile-user)> (#.+ 2 3)
$1 = 5

So the problem is merely that the REPL is broken *by default*.
It should either default to the working mechanism, or fall back 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

Bug#734128: insufficient print abbreviation in error messages

[Zefram]

Package: guile-2.0
Version: 2.0.9+1-1
Severity: normal

When guile is constructing error messages that display offending objects,
in version 2.0 it never abbreviates long or deep structures.  This can
easily lead to pathologically-long messages that take stupid amounts of
time and memory to construct and to display.  By contrast, guile-1.8
applies abbreviation at a reasonable level, and objects appearing in
stack traces have reasonable abbreviation on both versions.  Two very
mild examples:

$ guile-1.8 --debug -c "(read (let aaa ((n 100) (v '())) (if (= n 0) v (aaa (- 
n 1) (cons n v)"
Backtrace:
In current input:
   1: 0* [read {(1 2 3 4 5 6 7 8 9 ...)}]

:1:1: In procedure read in expression (read (# 100 #)):
:1:1: Wrong type argument in position 1 (expecting open input 
port): (1 2 3 4 5 6 7 8 9 10 ...)
$ guile-2.0 --debug -c "(read (let aaa ((n 100) (v '())) (if (= n 0) v (aaa (- 
n 1) (cons n v)"
Backtrace:
In ice-9/boot-9.scm:
 157: 7 [catch #t # ...]
In unknown file:
   ?: 6 [apply-smob/1 #]
In ice-9/boot-9.scm:
  63: 5 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 4 [eval # #]
In unknown file:
   ?: 3 [call-with-input-string "(read (let aaa ((n 100) (v '())) (if (= n 0) v 
(aaa (- n 1) (cons n v)" ...]
In ice-9/command-line.scm:
 180: 2 [# #]
In unknown file:
   ?: 1 [eval (read (let aaa (# #) (if # v #))) #]
   ?: 0 [read (1 2 3 4 5 6 7 8 9 ...)]

ERROR: In procedure read:
ERROR: In procedure read: Wrong type argument in position 1 (expecting open 
input port): (1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 
26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 
52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 
78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100)
$ guile-1.8 --debug -c "(read (let aaa ((n 100) (v '())) (if (= n 0) v (aaa (- 
n 1) (cons v n)"
Backtrace:
In current input:
   1: 0* [read {(((# . 3) . 2) . 1)}]

:1:1: In procedure read in expression (read (# 100 #)):
:1:1: Wrong type argument in position 1 (expecting open input 
port): (((# . 7) . 6) . 5) . 4) . 3) . 2) . 1)
$ guile-2.0 --debug -c "(read (let aaa ((n 100) (v '())) (if (= n 0) v (aaa (- 
n 1) (cons v n)"
Backtrace:
In ice-9/boot-9.scm:
 157: 7 [catch #t # ...]
In unknown file:
   ?: 6 [apply-smob/1 #]
In ice-9/boot-9.scm:
  63: 5 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 4 [eval # #]
In unknown file:
   ?: 3 [call-with-input-string "(read (let aaa ((n 100) (v '())) (if (= n 0) v 
(aaa (- n 1) (cons v n)" ...]
In ice-9/command-line.scm:
 180: 2 [# #]
In unknown file:
   ?: 1 [eval (read (let aaa (# #) (if # v #))) #]
   ?: 0 [read (((# . 3) . 2) . 1)]

ERROR: In procedure read:
ERROR: In procedure read: Wrong type argument in position 1 (expecting open 
input port): 
()
 . 100) . 99) . 98) . 97) . 96) . 95) . 94) . 93) . 92) . 91) . 90) . 89) . 88) 
. 87) . 86) . 85) . 84) . 83) . 82) . 81) . 80) . 79) . 78) . 77) . 76) . 75) . 
74) . 73) . 72) . 71) . 70) . 69) . 68) . 67) . 66) . 65) . 64) . 63) . 62) . 
61) . 60) . 59) . 58) . 57) . 56) . 55) . 54) . 53) . 52) . 51) . 50) . 49) . 
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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734132: combinatorial explosion in elided stack trace

[Zefram]

Package: guile-2.0
Version: 2.0.9+1-1
Severity: normal

If an error is signalled in the interpreter, and the stack contains in
a certain position an object whose unabbreviated print representation
is very large, then the process of displaying the stack trace will take
a huge amount of time and memory, pausing in the middle of output, even
though the displayed stack trace doesn't actually show the object at all.
Test case:

$ cat t6
(define bs (let aaa ((n 100) (v '())) (if (= n 0) v (aaa (- n 1) (cons v v)
(write (list bs (error "wibble")))
$ guile-2.0 --no-auto-compile t6
Backtrace:
In ice-9/boot-9.scm:
 157: 11 [catch #t # ...]
In unknown file:
   ?: 10 [apply-smob/1 #]
In ice-9/boot-9.scm:
  63: 9 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 8 [eval # #]
In ice-9/boot-9.scm:
2320: 7 [save-module-excursion #]
3968: 6 [#]
1645: 5 [%start-stack load-stack #]
1650: 4 [#]
In unknown file:
   ?: 3 [primitive-load "/home/zefram/usr/guile/t6"]
In ice-9/eval.scm:
 387: 2 ^Z
zsh: suspended  guile-2.0 --no-auto-compile t6
$ jobs -l
[1]  + 32574 suspended  guile-2.0 --no-auto-compile t6
$ ps vw 32574
  PID TTY  STAT   TIME  MAJFL   TRS   DRS   RSS %MEM COMMAND
32574 pts/5T  0:36  0 3 2266300 1634556  9.9 guile-2.0 
--no-auto-compile t6

With the test's size parameter at 100 as above, there is no realistic
prospect of actually completing generation of the stack trace.  For some
range of values (about 25 on my machine) there will be a noticeable pause,
after which the stack trace completes:

...
 387: 2 [eval # ()]
 387: 1 [eval # ()]
In unknown file:
   ?: 0 [scm-error misc-error #f "~A" ("wibble") #f]

It appears that it's generating the entire print representation of
the object behind the scenes, though it then obviously throws it away.
Experimentation with customising print methods for SRFI-9 record types
shows that the delay and memory usage depend on the print representation
per se, rather than on the amount of structure beneath the object.
(A record-based cons-like type produces similar behaviour to the
cons test when using the default print method that shows the content.
Replacing it with a print method that emits a fixed string and doesn't
recurse eliminates the delay entirely.)

If my test program is run in compiled form (via auto-compilation) then
it doesn't exhibit the pause.  Actually it gets optimised such that the
problem object isn't anywhere near what the stack trace displays, so for
a fair test the program needs to be tweaked.  It can be arranged for the
problem object to be directly mentioned in the stack trace, and there is
still no pause: the object appears in a highly abbreviated form, such as

   2: 1 [vv ((# # # # ...) (# # # # ...) (# # # # ...) (# # # # ...) ...)]

For comparison, guile-1.8 never exhibits this problem.  By default
it doesn't emit a stack trace for a script, but it can be asked to do
so via --debug.  It then behaves like the compiled form of guile-2.0:
there is no delay, and the object is shown in very abbreviated form.

-zefram


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734009: auto-compile noise can't be avoided by script

[Zefram]

I wrote:
>a command-line switch can turn off the auto-compilation,

On closer examination, it turns out that aside from the portability
concern that I described, turning off auto-compilation doesn't actually
fix the problem.  If a compiled version has previously been cached for
the filename of a script being run, guile will consider using the cached
version even if --no-auto-compile was supplied: the switch only controls
the attempt to compile for the cache.  If the cached compilation is up
to date then it is used silently, which is OK.  But if it's out of date,
because the cache was for a different script that previously existed
under the same name, then guile emits a banner saying that it's out of
date (implying that the cached compilation is therefore not being used).
So the script's visible behaviour is defiled even if it applies the
option.

Observe what happens to the second 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/home/zefram/usr/guile/t10.go
hello world
$ echo '(display "goodbye world\n")' >t10
$ guile-2.0 --no-auto-compile t10
;;; note: source file /home/zefram/usr/guile/t10
;;;   newer than compiled 
/home/zefram/.cache/guile/ccache/2.0-LE-8-2.0/home/zefram/usr/guile/t10.go
goodbye world

-zefram


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734157: compiler disrespects referential integrity

[Zefram]

Package: guile-2.0
Version: 2.0.9+1-1
Severity: important

The guile-2.0 compiler doesn't preserve the distinctness of mutable
objects that are referenced in code via the read-eval (#.) facility.
(I'm not mutating the code itself, only quoted objects.)  The interpreter,
and for comparison guile-1.8, do preserve object identity, allowing
read-eval to be used to incorporate direct object references into code.
Test case:

$ cat t9
(cond-expand
  (guile-2 (defmacro compile-time f `(eval-when (compile eval) ,@f)))
  (else (defmacro compile-time f `(begin ,@f
(compile-time (fluid-set! read-eval? #t))
(compile-time (define aaa (cons 1 2)))
(set-car! '#.aaa 5)
(write '#.aaa)
(newline)
(write '(1 . 2))
(newline)
$ guile-1.8 t9
(5 . 2)
(1 . 2)
$ guile-2.0 --no-auto-compile t9
(5 . 2)
(1 . 2)
$ guile-2.0 t9
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;   or pass 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 literal (1 . 2), and so the runtime modification of aaa (which
is correctly mutable) affects the literal.

I've rated this bug "important" because it *silently* damages program
behaviour.  This issue seems closely related to the problem described
at <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11198>, wherein the
compiler is entirely unable to handle code incorporating references to
some kinds of object.  In that case the failure mode is a compile-time
error, so the problem can be worked around.  The failure mode with pairs,
silent misbehaviour, is a more serious problem.

-zefram


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734158: compiler can't handle object references in code

[Zefram]

Package: guile-2.0
Version: 2.0.9+1-1
Severity: normal

guile-2.0's compiler can't handle code that directly references
procedures, GOOPS objects, or various other object types.  The
interpreter, and for comparison guile-1.8, accept such references
just fine, allowing read-eval to be used to incorporate direct object
references into code.  Test case:

$ cat t8
(cond-expand
  (guile-2 (defmacro compile-time f `(eval-when (compile eval) ,@f)))
  (else (defmacro compile-time f `(begin ,@f
(compile-time (fluid-set! read-eval? #t))
(write (#.+ 2 3))
(newline)
$ guile-1.8 t8
5
$ guile-2.0 --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-constant-store: unrecognized object #
5

This breaks most of the interesting uses for read-eval, albeit only when
attempting to compile the code.  That it produces an actual error, and can
fall back to interpretation, limits the seriousness.  However, there are
several related problems that exacerbate it, which I've recently reported:
auto-compilation is difficult to portably disable and the failure is
noisy (Bug#734009), silent failure when the object is a mutable pair
rather than a procedure (Bug#734157), and the limitation applies in the
REPL which doesn't fall back to the interpreter (Bug#734108).

This problem is described upstream at
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11198>.  I'm reporting it
in the Debian system so that it is properly tracked from a Debian point
of view.

-zefram


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734009: auto-compile noise can't be avoided by script

[Zefram]

I wrote:
>I have rated this bug "important" because of this lack of workaround.

I have come up with a truly ugly workaround.  The meta option system
can be used to introduce a -c option that explicitly loads the script
file via primitive-eval, which does not attempt compilation.  (Nor does
it look at the compilation cache, so this even avoids the problem that
--no-auto-compile runs into.)  Running the script this way yields a
different command line (visible through (program-arguments)) from that
which arrives when the script is run via -s, so if the script is to
process its command line, for robustness it must pay attention to which
way it was invoked.  All together, this looks like:

$ cat t11
#!/usr/bin/guile \
-c (begin\
\ \ \ (define\ arg-hack\ #t)\
\ \ \ (primitive-load\ (cadr\ (program-arguments
!#
(define argv
  (if (false-if-exception arg-hack)
(cdr (program-arguments))
(program-arguments)))
(write argv)
(newline)
$ guile-1.6 '\' t11 a b c
("t11" "a" "b" "c")
$ guile-1.6 -s t11 a b c 
("t11" "a" "b" "c")
$ guile-1.8 '\' t11 a b c
("t11" "a" "b" "c")
$ guile-1.8 -s t11 a b c 
("t11" "a" "b" "c")
$ guile-2.0 '\' t11 a b c
("t11" "a" "b" "c")
$ guile-2.0 -s t11 a b c 
;;; note: auto-compilation 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.go
("t11" "a" "b" "c")
$ guile-2.0 -s t11 a b c
("t11" "a" "b" "c")

I'm not comfortable with this as a workaround.  It smells fragile.
So for the time being I'm leaving the "important" severity tag, but I'm
open to being convinced that it's better than I think.

Note that though this does avoid the banner appearing for #!-based
executions, it's not muffling the banner per se but actually preventing
compilation.  While for some programs it's desirable to prevent
compilation per se (because of the compiler's limitations), there are
plenty of programs that would like to be compiled and only want to muffle
the banner.  Losing the efficiency of compilation is potentially a high
price to pay for clean output.

-zefram


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734178: compile cache confused about file identity

[Zefram]

Package: guile-2.0
Version: 2.0.9+1-1
Severity: normal

The automatic cache of compiled versions of scripts in guile-2.0
identifies scripts mainly by name, and partially by mtime.  This is not
actually sufficient: it is easily misled by a pathname that refers to
different files at different times.  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/2.0-LE-8-2.0/home/zefram/usr/guile/t13.go
aaa
$ mv t14 t13
$ guile-2.0 t13
aaa

You can see that the mtime is not fully used here: the cache is misapplied
even if there is a delay of seconds between the creations of the two
script files.  The cache's mtime check will only notice a mismatch if
the script currently seen under the supplied name was modified later
than when the previous script was *compiled*.

Obviously, in this test case the cache could trivially distinguish the
two script files by looking at the inode numbers.  On its own the inode
number isn't sufficient, but exact match on device, inode number, and
mtime would be far superior to the current behaviour, only going wrong
in the presence of deliberate timestamp manipulation.  As a bonus, if
the cache were actually *keyed* by inode number and device, rather than
by pathname, it would retain the caching of compilation across renamings
of the script.

Or, even better, the cache could be keyed by a cryptographic hash of the
file contents.  This would be immune even to timestamp manipulation, and
would preserve the cached compilation even across the script being copied
to a fresh file or being edited and reverted.  This would be a cache
worthy of the name.  The only downside is the expense of computing the
hash, but I expect this is small compared to the expense of compilation.

-zefram


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727841: powl() inaccurate but only at runtime

[Zefram]

Package: libc6
Version: 2.13-38
Severity: normal

On amd64, powl() is generating inaccurate results when called at runtime,
but if a call to it gets constant-folded at compile time (by gcc 4.7)
then the constant-folded result is much more accurate.

$ cat t0.c
#include 
#include 
int main(void) {
int c = getchar();
printf("%.16La\n", powl((long double)c, -298.0L));
printf("%.16La\n", powl(10.0L, -298.0L));
return 0;
}
$ gcc t0.c -lm
$ echo | ./a.out
0x8.5f0468293f0ebc30p-993
0x8.5f0468293f0eb4e0p-993

The second of the two values emitted, the one resulting from constant
folding in gcc, is actually the closest long double value available
to the unrepresentable 10**-298.  The first value emitted, resulting
from a runtime call to powl(), is far less accurate.  The difference,
117 ulp, cannot be accounted for by the use of different rounding modes:
there must be actual different algorithms in use.

So (a) libc's powl() is inaccurate; and (b) gcc's constant folding on
powl() doesn't accurately simulate its runtime behaviour.  I think these
are both bugs, but fixing the first will presumably fix the second too,
so for now I'm only reporting this against libc.

Relevant package versions:

libc6:amd64 2.13-38
libc6-dbg:amd64 2.13-38
libc6-dev:amd64 2.13-38
libc6-dev-i386  2.13-38
libc6-i386  2.13-38
libc6-pic:amd64 2.13-38
gcc 4:4.7.2-1
gcc-4.7 4.7.2-5
gcc-4.7-base:amd64  4.7.2-5
gcc-4.7-doc 4.7.2-2
gcc-4.7-locales 4.7.2-5
gcc-4.7-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

Bug#734311: guild assumes too much about guile config

[Zefram]

Package: guile-2.0-libs
Version: 2.0.9+1-1
Severity: minor

/usr/bin/guild from guile-2.0-libs begins with some shell code that by
default passes the main Scheme program to /usr/bin/guile.  The main
program then relies on a bunch of libraries that are part of the
guile-2.0-libs package and which are installed under /usr/share/guile/2.0,
hence made available specifically to guile-2.0.  If /usr/bin/guile, which
is controlled by the alternatives system, doesn't refer to guile-2.0,
guild is liable to fail:

$ namei /usr/bin/guile
f: /usr/bin/guile
 d /
 d usr
 d bin
 l guile -> /etc/alternatives/guile
   d /
   d etc
   d alternatives
   l guile -> /usr/bin/guile-1.8
 d /
 d usr
 d bin
 - guile-1.8
$ /usr/bin/guild list
ERROR: no code for module (ice-9 command-line)

guild should (by default, at least) invoke /usr/bin/guile-2.0, rather
than /usr/bin/guile.  This implies that the package containing guild
ought to declare a dependency on the guile-2.0 package, but that poses
a bit of a problem, as the guile-2.0 package declares a dependency on
guile-2.0-libs, which is what contains guild.  Perhaps guild ought to
be in a separate package from the libraries.

The immediate workaround for this problem is to run guild with
GUILE=/usr/bin/guile-2.0 in the environment.  While this configurability
is handy right now in working around the bug, it doesn't seem a good
idea for guild to accept such advice from the environment.  Presumably
$GUILE, if set, would normally point to the user's preferred guile,
which, like /usr/bin/guile, is not necessarily the one that guild needs.
As guild specifically needs guile-2.0, and it knows that if guile-2.0 is
available then it'll specifically be available as /usr/bin/guile-2.0, it
would seem more sensible for guild 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

Bug#734313: "guild list" lists nothing

[Zefram]

Package: guile-2.0-libs
Version: 2.0.9+1-1
Severity: minor

"guild list" is meant to list the available subcommands within guild.
It actually shows an empty list:

$ GUILE=/usr/bin/guile-2.0 guild list
Usage: guild COMMAND [ARGS]
Run command-line scripts provided by GNU Guile and related programs.

Commands:

For help on a specific command, try "guild help COMMAND".

Report guild bugs to bug-gu...@gnu.org
GNU Guile home page: <http://www.gnu.org/software/guile/>
General help using GNU software: <http://www.gnu.org/gethelp/>
For complete documentation, run: info guile 'Using Guile Tools'
$

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

Bug#734314: "guild help COMMAND" crashes

[Zefram]

Package: guile-2.0-libs
Version: 2.0.9+1-1
Severity: minor

"guild help COMMAND" crashes for most existing guild subcommands.
For example:

$ GUILE=/usr/bin/guile-2.0 guild help frisk 
Usage: guild frisk OPTION...
Show dependency information for a module.
Backtrace:
In ice-9/boot-9.scm:
 157: 8 [catch #t # ...]
In unknown file:
   ?: 7 [apply-smob/1 #]
In ice-9/boot-9.scm:
  63: 6 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 5 [eval # #]
In /usr/bin/guild:
  74: 4 [main ("/usr/bin/guild" "help" "frisk")]
In scripts/help.scm:
 181: 3 [main "frisk"]
 155: 2 [show-help # #]
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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734323: doc out of date about (integer? +inf.0)

[Zefram]

Package: guile-2.0-doc
Version: 2.0.9+1-1
Severity: minor

Section 6.6.2.2 "Integers" of the guile-2.0 info document contains
this gem:

  (integer? +inf.0)
  => #t

Actual guile-2.0 behaviour:

scheme@(guile-user)> (integer? +inf.0)
$16 = #f

The doc example matches the behaviour 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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734009: auto-compile noise can't be avoided by script

[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

Bug#734108: interactive use subject to compiler limitations

[Zefram]

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

Bug#734132: combinatorial explosion in elided stack trace

[Zefram]

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

Bug#734128: insufficient print abbreviation in error messages

[Zefram]

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

Bug#734157: compiler disrespects referential integrity

[Zefram]

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

Bug#734323: doc out of date about (integer? +inf.0)

[Zefram]

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

Bug#734178: compile cache confused about file identity

[Zefram]

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

Bug#734313: "guild list" lists nothing

[Zefram]

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

Bug#734314: "guild help COMMAND" crashes

[Zefram]

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

Bug#728775: apt-get unwarrantedly consumes input

[Zefram]

Package: apt
Version: 0.9.7.9
Severity: minor

When apt-get is invoked in a way that involves actually installing a
package, it reads any available data from standard input, regardless of
actual need.  This breaks the usual ability, at an interactive shell,
to type the next command while the current one is running: apt-get
consumes input that was intended for the shell.  strace shows that the
input is read by the top-level apt-get process, by read(2) from fd 0,
in response to pselect(2).

Presumably apt-get is reading this input in order to pass it on to
interactive aspects of package installation, but it's doing it regardless
of whether the installation process seeks input and, where it does want
input, regardless of how much input it wants to read.  This behaviour
is not documented.  It's not immediately obvious why apt-get has to act
as an intermediary for this input at all.

-zefram


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#728775: apt-get unwarrantedly consumes input

[Zefram]

Steve Cotton wrote:
>It's to avoid someone typing their next command while packages are
>downloading, but then that input being used as the answer to a
>prompt during installation.

That can be used as an argument for all sorts of programs to clear stdin.
The Unix convention is that one does not.  For the purposes of this bug
report, I'm confident that the installation will not get interactive.
(I have debconf configured to non-interactive mode, which doesn't cover
all cases in which installation can get interactive, but does cover most.)

>There is an undocumented control flag DPkg::FlushSTDIN.

Setting that to "false" in /etc/apt/apt.conf.d doesn't make any practical
difference.

Looking at the source, I do see flushing cod controlled by that
flag, but it doesn't match the behaviour that I saw through strace.
It's in pkgDPkgPM::Go() in apt-pkg/deb/dpkgpm.cc.  Further down the
same function, there's a pselect loop which does match what I saw
with strace.  It reads from stdin conditional only upon (master >= 0 &&
!d->stdin_is_dev_null), not looking at configuration at all.  I expect
that both of these instances of stdin consumption need to be modified
for things to actually work as I want.

>But for your use-case of an interactive shell, wouldn't it be
>safer to just open another terminal?

Maybe; it depends on the circumstances.  (Again, it's an argument that
applies to all sorts of commands; apt-get is not a beautiful and unique
snowflake.)  Opening a fresh shell would avoid typeahead problems,
but would mean that the shells could differ in state such as current
directory, environment variables, and shell functions that I've just
written for the job at hand.  There's a risk of doing the wrong thing
simply due to failing to correctly keep two sets of shell state in my
head.  On the whole, running a command as root in the wrong directory
seems more dangerous than interpreting a command as a reply to a "keep
old config file?" question.

What's really optimal will depend on the individual.  It's a matter
between the human and eir shell; it is not apt-get's place to interfere
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

Bug#729334: nvi escapetime option undocumented

[Zefram]

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...@lists.debian.org

Bug#723573: xterm occasionally forgets BackSpace translation

[Zefram]

Thomas Dickey wrote:
>If you are using translations, xterm won't see anything except for the
>given string.  None of xterm's configurability will have any effect.

Indeed, that's the intent of that setting.

>That last part is where I don't see a possible relationship to xterm.

It seems to only 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...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#741360: statm "share" badly described

[Zefram]

Package: manpages
Version: 3.44-1
Severity: minor

proc(5) says:

   /proc/[pid]/statm
  Provides information about memory usage, measured in pages.  The
  columns are:

  size   total program size
 (same as VmSize in /proc/[pid]/status)
  resident   resident set size
 (same as VmRSS in /proc/[pid]/status)
  share  shared pages (from shared mappings)

Actually the "share" value doesn't count all shared pages mapped by the
process: it only counts *resident* shared pages.  It should be documented
as such.  The current documentation makes it look as though one can
subtract share from size to find out how much unshared memory the process
uses, but actually doing so gives a bogus figure.  I'm currently debugging
some code (the Perl module Apache::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

Bug#742700: spill fail with -fschedule-insns

[Zefram]

Package: gcc-4.7
Version: 4.7.2-5
Severity: normal

I have encountered a gcc failure when attempting to compile code for
the Perl module DBD-SQLite on i386.  Steps to reproduce:

$ wget -q 
http://cpan.metacpan.org/authors/id/I/IS/ISHIGAKI/DBD-SQLite-1.42.tar.gz
$ tar xzf DBD-SQLite-1.42.tar.gz 
$ cc -c -O1 -fschedule-insns -fno-schedule-insns2 DBD-SQLite-1.42/sqlite3.c
DBD-SQLite-1.42/sqlite3.c: In function 'unixLock':
DBD-SQLite-1.42/sqlite3.c:25374:1: error: unable to find a register to spill in 
class 'AD_REGS'
DBD-SQLite-1.42/sqlite3.c:25374:1: error: this is the insn:
(insn 87 348 93 14 (parallel [
(set (mem/j/c:DI (plus:SI (reg/f:SI 20 frame)
(const_int -20 [0xffec])) [0 lock.l_start+0 
S8 A32])
(sign_extend:DI (reg:SI 118 [ sqlite3PendingByte ])))
(clobber (reg:CC 17 flags))
(clobber (scratch:SI))
]) DBD-SQLite-1.42/sqlite3.c:25294 125 {extendsidi2_1}
 (expr_list:REG_DEAD (reg:SI 118 [ sqlite3PendingByte ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
DBD-SQLite-1.42/sqlite3.c:25374: confused by earlier errors, bailing out
Preprocessed source stored into /tmp/ccmHvZ0y.out file, please attach this to 
your bugreport.

I'm not attaching the source file itself or the preprocessed version that
the error message said to attach, on the basis that they're enormous
and it should be easy for you to reproduce the problem starting by
downloading 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
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#742949: new magic: Hash::SharedMem

[Zefram]

Package: file
Version: 5.11-2+deb7u3
Severity: wishlist

The Perl module Hash::SharedMem
<https://metacpan.org/release/Hash-SharedMem> defines a file format
for a key/value store.  Details of the file format are in the "DESIGN"
file in the module distribution.  Magic:

0 bequad =0xa58afd185cbf5af7 Hash::SharedMem master file, big-endian
>8 bequad <0x100
>>15 byte >2 \b, line size 2^%d byte
>>14 byte >2 \b, page size 2^%d byte
>>13 byte &1
>>>13 byte >1 \b, max fanout %d
0 lequad =0xa58afd185cbf5af7 Hash::SharedMem master 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
0 bequad =0xc693dac5ed5e47c2 Hash::SharedMem data file, big-endian
>8 bequad <0x100
>>15 byte >2 \b, line size 2^%d byte
>>14 byte >2 \b, page size 2^%d byte
>>13 byte &1
>>>13 byte >1 \b, max fanout %d
0 lequad =0xc693dac5ed5e47c2 Hash::SharedMem data 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

Bug#743525: symlink permissions misdescribed

[Zefram]

Package: manpages
Version: 3.44-1
Severity: minor

symlink(7) says:

   On Linux, the permissions of a symbolic link are not used in any opera-
   tions; the permissions are always 0777 (read, write,  and  execute  for
   all user categories), and can't be changed.

but in reality:

$ 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 that "the permissions are always 0777".
It is correct that they can't be changed.

-zefram


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#742949: new magic: Hash::SharedMem

[Zefram]

Christoph Biedl wrote:
>/tmp/libhash-sharedmem-perl-0.002/blib/arch/auto/Hash/SharedMem/SharedMem.so:
>undefined symbol: __sync_bool_compare_and_swap_8 at
>/usr/lib/perl/5.14/DynaLoader.pm line 184.
>
>Could you shed any light on this?

That looks like the machine doesn't support atomic 64-bit
compare-and-swap, or at least the compiler thinks it doesn't.  The module
is fundamentally reliant on having access to such a CPU instruction,
and won't be portable to pure 32-bit architectures.  This is actually
the first such failure I've seen, though.  Note that the nominally 32-bit
x86 acquired the requisite 64-bit instruction (cmpxchg8b) many years ago,
and so there are plenty of machines that support that without being fully
64-bit.  I've also seen a successful test on 32-bit ARM (little-endian).

For a big-endian test, the first platform I'd look for is SPARC 64-bit.
I don't have ready access to one myself.  Regrettably, the CPAN Testers
results are almost all for amd64, with a smattering of x86 and the
aforementioned ARM.  I'm not aware of anyone having actually run it on
a big-endian machine so far.  The big-endian magic is thus theoretical
and untested, but I have considerable 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

Bug#742271: c% mangles insertion point

[Zefram]

Package: nvi
Version: 1.81.6-8.2
Severity: normal

The command "c%" (replace text to matching bracket) inserts new text in
the wrong place if the matching bracket is at the end of a different line.

To reproduce: start nvi with no .exrc.  Insert text "foo{", newline,
"}".  Position cursor on the "{".  Type "c%bar", ESC.  End result
is that the line contains "fobar " instead of the expected "foobar".
During the input of the "bar" text, the display reflects the loss of the
"o", and may also show some phantom character (whose identity varies)
following the spurious space.  The phantom character vanishes upon ESC,
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

Bug#698156: authentication form redirect loop

[Zefram]

Package: googlecl
Version: 0.9.9-1
Severity: important

I'm attempting to use googlecl to download a document from Google Docs,
and I'm failing at the authentication stage, getting into a fruitless
loop on the Google Account website.  I start with the command line

$ google --user zefram@$employerdomain docs get -n $localname $docurl

googlecl fires up lynx (via the www-browser alias), starting at a URL
of the form "https://www.google.com/accounts/OAuthAuthorizeToken?
oauth_token=$base64&hd=$employerdomain".  This yields an
accounts.google.com cookie named "G" (which I accept), and a
redirect to "https://www.google.com/a/$employerdomain/ServiceLogin2?
continue=$oauth_url&passive=true&service=apps&btmpl=authsub".  This yields
a www.google.com cookie named "GALX" (accept) and a login form.  The form
has $employerdomain embedded next to the "Username" input box, and below
has a message "A third party service is requesting permission ...".

I enter the local part of my username and the correct password.  (If I
enter the wrong password I get back to the login form, with username
still filled in and a message "The username or password you entered is
incorrect.".)  This yields a redirect to "https://accounts.google.com/
AcceptGAPlusTermsOfService?HBSID=$base64&service=apps&continue=$oauth_url&
hl=en".  That delivers two accounts.google.com cookies named
"GoogleAccountsLocale_s" and "" (both accept), and a page that says
"Welcome to your new account" and invites me to complete a captcha and
signal acceptance of terms of service.  (My account is not new, but the
terms may well be.)  Filling in the captcha and selecting "I accept"
yields a redirect to "https://accounts.google.com/ManageAccount";,
which in turn redirects to to "https://accounts.google.com/
ServiceLogin?passive=$number&continue=$manage_url&followup=$manage_url".
This yields an accounts.google.com cookie named "GALX", and a login form
that is not domain-specific and says nothing about a third-party service.

Attempting to sign in via the generic login form yields a somewhat
similar sequence, except that the "AcceptGAPlusTermsOfService" URL
redirects straight to ManageAccount rather than showing the page with
the captcha form.  I thus get straight back to the generic login form.

Having read previous bug reports about authenticating with non-gmail
domains, I tried removing the "hl" parameter from the OAuth URL.
This yields more cookies and redirects, ultimately going to a version
of the non-specific login form with the "third party service" message.
Attempting to login here goes through the redirect sequence of
AcceptGAPlusTermsOfService to ManageAccount to ServiceLogin, ending up
back at the generic login form with no "third party service" message.
(I wasn't seeing the same failure mode that was previously reported with
non-gmail domains; this is clearly a different problem.)

Whichever kinds of attempts I've made on the website, returning to
googlecl yields the error message "Token upgrade failed! Could not get
OAuth access token.".

So, the bug is one or more of:

* googlecl relies upon a web-based process that is inoperative

* Google's sign-in process is broken

* lynx does something wonky with Google's sign-in process that it doesn't
  do with other websites

* googlecl misses the point of itself by invoking an interactive web-based
  process in the middle of a command-line operation

With respect to the latter, even if the authentication were to work,
googlecl is failing at the purpose for which I installed it, namely
to avoid the pain of trying to do everything through a web browser.
OK, it needs authentication, and so the invocation that I started with
does require some degree of interaction, but this could take the form of
prompting for the account's password to be entered at the tty.  googlecl
could do the HTTP stuff itself, as it does for other parts of the process,
and thus (a) avoid relying on the vagaries of a random web browser and
(b) provide an actual command-line-style interface as advertised.

There also really needs to be some way to authenticate with *no*
interaction, which currently seems to be lacking.  Provided that googlecl
can handle a password itself, this could be as simple as reading the
password from the config file.

-zefram


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#676754: libapache2-mod-perl2: FTBFS: tests failed

[Zefram]

The failure is a deadlock between LWP::Protocol::http and Apache (under
the influence of the mod_perl server-side test modules).  It turns on
an ambiguity in RFC 2616, so it is not clear which side is at fault.
I'm blaming both.  (Plus the RFC authors.)  Upstream bug reports, with
patches, at

https://rt.cpan.org/Public/Bug/Display.html?id=82408
https://rt.cpan.org/Public/Bug/Display.html?id=82409

-zefram


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#702821: perl/hash_attack.t fails with 5.10.1 + CVE-2013-1667 fix

[Zefram]

The patch in svn.apache.org r1455340 is not correct for Perl 5.10 due
to a slight difference in hash splitting logic.  Full explanation and
revised patch now available on the RT ticket.

-zefram


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#709084: fim SEGVs immediately

[Zefram]

Package: fim
Version: 0.3-beta-prerelease-1.3+b1
Severity: grave

When invoked to view any file ("fim foo.png"), fim puts something on
the screen and then immediately SEGVs, cleans up the screen, and exits.
strace shows the activity immediately preceding the SEGV to consist of
sending textual commands to itself over a pipe.

-zefram


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#709085: dvifb suffers total font failure

[Zefram]

Package: dvifb
Version: 1:01.03-14.1+b1
Severity: grave

I'm not getting any actual characters displayed by dvifb, just some rules
where some of the content should be.  (Doesn't look like it corresponds
to all character positions.)  Behaviour sounds somewhat similar to
Bug#245399 from Martin Pitt, but it's not the same cause: strace shows
that dvifb isn't attempting to use /var/cache/fonts, and empirically
changing permissions on it doesn't help.  I haven't determined the cause
of the failure.  I have texlive-full installed, so all the fonts should
be available.  I do get a ~/.texmf-var directory, containing some PK
files that have believable sizes.  This is a fresh wheezy installation.

-zefram


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#714997: ntpdate gets invoked by default

[Zefram]

Package: ntpdate
Version: 1:4.2.6.p5+dfsg-2
Severity: normal

If I install the ntpdate package, in order to have the useful diagnostic
tool of the ntpdate(8) program, an if-up script also gets installed, which
uses ntpdate in order to adjust the system clock every time a network
interface comes up.  Sure that's a vaguely sensible way to use ntpdate,
but wanting to do that is not inherent in installing the ntpdate program.

I think there should be two distinct packages here: one providing the
ntpdate program (and ntpdate-debian), and a second one implementing
the specific use of ntpdate to repeatedly adjust the system clock.
The package descriptions must reflect these distinct purposes.  If for
some reason you're not willing to split the packages, then the secondary
purpose of the single package needs to be stated in its description.
(The present description of the ntpdate package describes the ntpdate
program, but makes no mention of running it automatically.)

-zefram


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#712040: libreoffice dot dir lacks dot

[Zefram]

Package: libreoffice
Version: 1:3.5.4+dfsg-4
Severity: minor

libreoffice by default creates some files in a directory ~/libreoffice.
Conventionally this should by ~/.libreoffice, keeping out of the namespace
of the user's normal (visible) files.

-zefram


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#668850: libreoffice: opens windows in wrong session

[Zefram]

Additional commentary, as I've just run into this issue.  In my case,
I tried to open multiple libreoffice instances in a single login session
on a single X display, but it's a multi-screen display.  Attempting to
bring up libreoffice instances on different screens doesn't work: the
later invocations just bring up more windows on the screen that contains
the original instance.  This seriously impacts usability.

That's really just the icing on the cake.  libreoffice suffers much of the
annoying behaviour that I previously noted for Iceweasel in Bug#617362.
The second libreoffice invocation terminates immediately instead of
waiting for editing of the second file to be finished.  Selecting "Exit"
or performing X client termination on one window closes both.  (At least
some settings are per-window, though.)

Unlike Iceweasel, libreoffice doesn't seem to even offer an option to
control this behaviour.

-zefram


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#712040: libreoffice dot dir lacks dot

[Zefram]

Rene Engelhard wrote:
>On Wed, Jun 12, 2013 at 01:20:05PM +0100, Zefram wrote:
>> libreoffice by default creates some files in a directory ~/libreoffice.
>
>No.

Well, that's what it empirically did for me.  Installed via apt-get,
no manual intervention or configuration, no environment variables set
specially for libreoffice.

>UserInstallation=$SYSUSERCONFIG/libreoffice/4

/usr/lib/libreoffice/program/bootstraprc contains the line

UserInstallation=$SYSUSERCONFIG/libreoffice/3

>where SYSUSERCONFIG *is* /home/rene/.config here.

I do not have an environment variable by that name.  Trying out setting
it, using just a pathname (of an existing dir) yields failure at startup:

$ SYSUSERCONFIG=/home/zefram/t1 libreoffice test-document.doc
Xlib:  extension "XINERAMA" missing on display ":0.2".
[Java framework] Error in function createSettingsDocument (elements.cxx).
javaldx failed! 
Warning: failed to read path from javaldx
I18N: Operating system doesn't support locale "en_US"
terminate called after throwing an instance of 
'com::sun::star::uno::RuntimeException'

If that sort of setting works for you, maybe that's a v3 vs v4 difference.

Some parts of the source suggest that it's meant to be a URL, and
that works:

$ SYSUSERCONFIG=file:///home/zefram/t1 libreoffice test-document.doc
Xlib:  extension "XINERAMA" missing on display ":0.2".
I18N: Operating system doesn't support locale "en_US"

Files appear under /home/zefram/t1/libreoffice/3.

Chasing down that "Error in function createSettingsDocument", to see where
SYSUSERCONFIG gets defaulted, leads eventually to osl_psz_getConfigDir()
in sal/osl/unx/security.c.  This has some logic to use XDG_CONFIG_HOME
if it's set, otherwise:

// a default equal to $HOME/.config should be used.
if (!osl_psz_getHomeDir(Security, pszDirectory, nMax))
return sal_False;
n = strlen(pszDirectory);
if (n + sizeof(DOT_CONFIG) < nMax)
{
strncpy(pszDirectory+n, DOT_CONFIG, sizeof(DOT_CONFIG));
if (access(pszDirectory, 0) != 0)
{
// resort to HOME
pszDirectory[n] = '\0';
}
}

That is, it uses ~/.config *if it already exists*, and otherwise just
uses ~.  So its ultimate default is, as I found, to create files under
~/libreoffice.  Creating ~/.config for test purposes, empirically it does
then get used: ~/.config/libreoffice is created rather than ~/libreoffice.

Aside from putting configuration files in the wrong place by default,
this logic will also lose configuration if ~/.config gets created
(perhaps by a different program) after configuration has already been
saved in ~/libreoffice.

-zefram


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#712040: libreoffice dot dir lacks dot

[Zefram]

Rene Engelhard wrote:
>OK, that explains why it's so rerely seen. both KDE and GNOME create stuff 
>under
>.config

Aha.  I can't abide such desktop environments.  I'm old-school: I
use twm, with a minimalist configuration.  Not entirely unrelated to
the fact that I hardly ever run GUI applications such as libreoffice.
(Currently have sixteen windows open, all xterms.)  Needed libreoffice
on this isolated occasion to fill in a form for my employer that was
distributed as a .ods spreadsheet file.

>I guess we should patch this to *always* use .config.

Yeah.  Must create it on demand.

>Not something we can or should do for wheezy, though.

Indeed, stability would seem to preclude any move of the config directory
within the wheezy maintenance track.

-zefram


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#712887: username parameter ignored

[Zefram]

Package: tinyirc
Version: 1:1.1.dfsg.1-2
Severity: normal

tinyirc documents that it accepts an IRC nick as a command line parameter.
Actually it ignores any such parameter.  It uses either $IRCNICK from
the environment or, failing that, the user's username.

-zefram


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#712888: documentation lacking

[Zefram]

Package: tinyirc
Version: 1:1.1.dfsg.1-2
Severity: normal

The curses-based input editing facility is entirely undocumented.

-zefram


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#644876: initramfs-tools: Boot failure from software RAID1 + LVM2 by timing

[Zefram]

The wait_for_udev patch cannot possibly fix the original problem, of
md devices not starting because their components are slow to come up,
because the wait_for_udev only happens *after* the attempt to assemble
md devices.  If you change nothing else, there's still only a single
attempt at assembly, liable to happen before slow components come online.

I have run into exactly the same problem as the original reporter.  I am
now using the patch below.  It adds a crude delay/retry loop to the md
assembly process, for the case where INITRDSTART lists devices explicitly.
(The "all" case would be considerably more complicated, unless one
were to translate it into an explicit list by reading mdadm.conf.)
Note that most assembly attempts are made with --no-degraded; this is
in case some components become available before others.  Only when the
retry limit is reached will a degraded assembly be accepted.

The delay/retry arrangement could be made much more sophisticated.
My version uses a fixed number of retries with relatively large delays.
A nicer arrangement would be to retry more rapidly until a configurable
amount of time has passed.  Also, assembly of all the desired md devices
could be attempted in parallel, so that if everything is coming up
degraded the retry delay is only incurred once.

PATCH
--- /usr/share/initramfs-tools/scripts/local-top/mdadm  2013-01-24 
13:26:51.0 +
+++ /etc/initramfs-tools/scripts/local-top/mdadm2013-07-22 
21:31:57.038274846 +
@@ -87,7 +87,20 @@
   for dev in $MD_DEVS; do
 
 verbose && log_begin_msg "Assembling MD array $dev"
-if $MDADM --assemble --scan --run --auto=yes $dev; then
+devok=false
+for try in 0 1 2 3 4; do
+  if $MDADM --assemble --scan --no-degraded --auto=yes $dev; then
+devok=true
+break
+  fi
+  sleep 2
+done
+if ! $devok; then
+  if $MDADM --assemble --scan --run --auto=yes $dev; then
+devok=true
+  fi
+fi
+if $devok; then
   verbose && log_success_msg "started $dev"
 else
   log_failure_msg "failed to start $dev"
PATCH

-zefram


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#721720: -floop-parallelize-all misleadingly accepted

[Zefram]

Package: gcc-4.7
Version: 4.7.2-5
Severity: normal

There's a funny arrangement for gcc's -floop-parallelize-all option
(and it looks like some related options too) where it's always accepted,
but the optimisation mechanism that it controls depends on an optional
library package being installed.  This turns out to make it difficult
to detect whether the optimisation is really available.

I've run into this with building libmemcached from source.  I'm doing
this independent of the Debian libmemcached package, actually as part of
the Perl module Memcached::libmemcached, which I'm building from CPAN on
a non-system Perl.  The gcc in question is targeting x86_64-linux-gnu.
The library has an autoconf configure script.  I can simulate the relevant
test this way:

$ cat t.c
int main()
{
  return 0;
}
$ gcc-4.7 -O2 -floop-parallelize-all -c t.c && echo OK   
OK

As the option is accepted, it's used in compilation of the library code.
Compilation of a couple of the modules then fails.  I can demonstrate
this with an eviscerated version of the library's CRC32 code:

$ cat c.c
static const int crc32tab[256] = {};
int c(const char *key, int key_length)
{
  int x;
  int crc= ~0;
  for (x= 0; x < key_length; x++)
 crc= (crc >> 8) ^ crc32tab[(crc ^ key[x]) & 0xff];
  return ((~crc) >> 16) & 0x7fff;
}
$ gcc-4.7 -O2 -floop-parallelize-all -c c.c && echo OK
c.c: In function 'c':
c.c:2:5: sorry, unimplemented: Graphite loop optimizations can only be used if 
the libcloog-ppl0 package is installed

I've advised the Perl module maintainer that the configure
test ought to include some complex loop code in order to
properly trigger failure.  Bug report for that module is at
<https://rt.cpan.org/Ticket/Display.html?id=88378>.

But I think that this problem should be addressed in the Debian gcc.
The simple configure test *should* work.  There's a practical problem in
determining what complexity of code is required for the test; this is
liable to vary between gcc versions and between target architectures.
In principle, I think it's wrong for gcc to accept an option when its
only effect 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

Bug#723560: iceweasel can't run two sessions simultaneously

[Zefram]

Package: iceweasel
Version: 17.0.8esr-1~deb7u1
Severity: normal

Suppose one already has Iceweasel running.  Now run it again by typing
"firefox" in a terminal window on the same X screen.  A new Iceweasel
window pops up, but the second firefox process terminates immediately
instead of waiting for the end of the session with the new window.
In fact, the two Iceweasel windows are not only being managed by the
same instance of the program, they're actually treated as part of the
same session, and things done with one window will affect the other:
changes to preferences (such as preferred background colour) in one
window affect the other, and selecting the "Quit" menu option in one
window will close both.  Finally, closing the original Iceweasel window
(by an X "delete window" request) won't terminate the original firefox
process -- the process stays around to manage the second window.

I realise that managing both windows with the same process is intentional,
and done for performance reasons, but merging state of the two sessions
and losing the usual correspondence between processes and sessions
is an undesirable side effect.  I don't mind waiting the extra second
it takes to start a fresh session rather than add a new window to the
existing session.

If it's desired to have a way to open a new window in an existing session
from the command line, which I can see being useful to some people,
then that should be an option, not mandatory.  In fact, the iceweasel(1)
man page already advertises such an option ("-new-window"); it appears
that it's being treated as always on.

It gets worse.  With one Iceweasel running, if you try to run another
one on a *different* X screen then the second "firefox" invocation fails
to bring up a browser window at all.  It instead produces a small window
titled "Close Iceweasel", containing a road-sign-like icon and the text

Iceweasel is already running, but is not responding. To open a
new window, you must first close the existing Iceweasel 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.

The iceweasel(1) man page also advertises an option "-no-remote"
that looks as though it should decouple Iceweasel sessions, fixing the
above problems.  Empirically, if the option is used for either or both
invocations of Iceweasel, the effect is actually to yield the "Close
Iceweasel" window for the second invocation, regardless of whether it's
on the same or different X screen.

This bug report is essentially a revival of Bug#617362.  That ticket got
closed without actually being resolved, due to confusion with the related
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? Contact listmas...@lists.debian.org

Bug#723573: xterm occasionally forgets BackSpace translation

[Zefram]

Package: xterm
Version: 278-4
Severity: normal

I configure xterm with X resources that include

XTerm.vt100.translations: #override \n\
BackSpace: string(0x08)

so normally the backspace key in xterm sends ^H.  However, from time to
time the behaviour mysteriously changes: the backspace key starts sending
^? instead.  I have not been able to determine what class of event causes
this; I see no reliable correlation with any particular activity, and have
no recipe to reproduce the problem.  It seems to change for all xterms
simultaneously.

I have found a way to change it back: empirically, toggling the
"Backarrow Key (BS/DEL)" item in any xterm's ctrl-left menu fixes it,
for *all* xterms.  Note, the final state of the BS/DEL menu item makes
no difference; toggling it normally has no effect, as the translation
takes precedence.  (I originally tried toggling BS/DEL in case there
was some interaction with the state of that option, but apparently the
state of the option is irrelevant, the fix just comes from something
triggered by the process of toggling it.)  The fix is only temporary:
it'll later change to ^? again, as mysteriously as the first time.

-zefram


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#723578: option to disable mouse tracking mode

[Zefram]

Package: xterm
Version: 278-4
Severity: wishlist

Sending an escape sequence to xterm can cause it to disable mouse-based
c&p in favour of reporting mouse events as escape sequences.  This is a
deliberate feature, the "mouse tracking" mode, but awfully annoying when
one does not specifically want 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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#723657: -geometry not fully honoured

[Zefram]

Package: mplayer2
Version: 2.0-554-gf63dbad-1+b1
Severity: minor

When mplayer is started up with a -geometry option that specifies a
position for the window (e.g., "-geometry +0+0"), it fails to set the
USPosition hint bit that tells the window manager that the position was
supplied by the user.  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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#723877: -fs mode fails entirely

[Zefram]

Package: mplayer2
Version: 2.0-554-gf63dbad-1+b1
Severity: important

When invoked in full-screen (-fs) mode, mplayer2 entirely fails
for me.  It initially brings up a window in the video's native size,
but then unmaps that, brings up what appears to be a zero-size window,
unmaps that too, and generates some error messages while it's doing it.
It then apparently hangs: in addition to no video it produces no sound,
and doesn't advance the time in the stdout display.  Full trace attached.

Version-1 mplayer (the "mplayer" package) works fine for this sort
of invocation on the same video file.

Note, initially mapping a window of the video's native size is
itself a bug, but not the bug with which this report is concerned.
Version-1 mplayer has the same bug: it briefly maps a window of the
video's native size and then replaces it with a full-screen window,
in which it successfully shows 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 to use your remote control.

Playing t0.mp4.
Cache fill:  0.00% (0 bytes)   

Detected file format: QuickTime/MPEG-4/Motion JPEG 2000 format (libavformat)
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x2aeb8efa6860]multiple edit list entries, a/v 
desync might occur, patch welcome
[lavf] stream 0: video (h264), -vid 0
[lavf] stream 1: audio (aac), -aid 0, -alang und
VIDEO:  [H264]  640x360  24bpp  25.000 fps  704.0 kbps (85.9 kbyte/s)
Clip info:
 major_brand: isom
 minor_version: 512
 compatible_brands: isomiso2avc1mp41
 encoder: Lavf53.21.1
Load subtitles in .
Failed to open VDPAU backend libvdpau_r600.so: cannot open shared object file: 
No such file or directory
[vdpau] Error when calling vdp_device_create_x11: 1
[ass] auto-open
==
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Asking decoder to use 6 threads if supported.
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==
==
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 48000 Hz, 2 ch, s16le, 93.5 kbit/6.08% (ratio: 11683->192000)
Selected audio codec: [ffaac] afm: ffmpeg (FFmpeg AAC (MPEG-2/MPEG-4 Audio))
==
AO: [pulse] Init failed: Connection refused
Failed to initialize audio driver 'pulse'
AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample)
Starting playback...
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [xv] 640x360 => 640x360 Planar YV12  [fs]
X11 error: BadDrawable (invalid Pixmap or Window parameter)
X11 error: BadWindow (invalid Window parameter)
Our window was destroyed, exiting
X11 error: BadWindow (invalid Window parameter)
X11 error: BadDrawable (invalid Pixmap or Window parameter)
A:   0.1 V:   0.1 A-V:  0.000 ct:  0.000   0/  0 ??% ??% ??,?% 0 0 99% 
X11 error: BadDrawable (invalid Pixmap or Window parameter)
X11 error: BadWindow (invalid Window parameter)
X11 error: BadWindow (invalid Window parameter)
X11 error: BadWindow (invalid Window parameter)
X11 error: BadWindow (invalid Window parameter)
X11 error: BadWindow (invalid Window parameter)

Bug#723989: intermittent spurious NUL

[Zefram]

Package: nvi
Version: 1.81.6-8.2
Severity: minor

Occasionally, while entering text for an insert-like command, "^@" will
appear on the screen immediately following the insertion point, as if
there were a NUL character there in the file.  It remains there during
text entry, the "^@" moving along 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

Bug#724074: ops doc missing

[Zefram]

Package: parrot-doc
Version: 4.0.0-3
Severity: normal

The /usr/share/doc/parrot/4.0.0/pod/ops directory is empty.  It's meant
to contain POD describing the opcodes of the Parrot VM.

Presumably this bug is related to the fact that the missing files are
generated by extracting POD from C files 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

Bug#724339: parrot won't generate pasm output

[Zefram]

Package: parrot-minimal
Version: 4.0.0-3
Severity: normal

The parrot(1) man page says that using the -o option with an output
filename that ends in ".pasm" should produce pasm output.  This doesn't
actually work:

$ cat t2.pir
.sub main
.end
$ parrot -o t2.pasm t2.pir
$ file t2.pasm
t2.pasm: Parrot 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...@lists.debian.org

Bug#724450: bigint library in parrot

[Zefram]

Package: parrot-minimal
Version: 4.0.0-3
Severity: wishlist

Parrot can be compiled with a built-in bigint facility.  The Debian Parrot
build has not.  It would be convenient if it did have bigint support.

Test case:

$ cat t6.pir
.sub main :main
$P0 = new "Integer"
$P0 = 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 of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#724339: [Pkg-parrot-devel] Bug#724339: parrot won't generate pasm output

[Zefram]

Jonathan "Duke" Leto wrote:
>I can confirm that it also happens with the latest Parrot.

Yeah, I see that too.  I'm actually using a Parrot checkout from github
in addition to the Debian Parrot, and I'm seeing the same behaviour with
both.  The relevant parts of parrot(1) have been reorganised 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, is there a test that is failing because of this?

No formal preexisting test that I know of.  I just ran into it myself
because I wanted to actually use the facility, to see exactly what ops
my PIR was compiling to.

-zefram


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#672887: arrow keys interfere with escape

[Zefram]

Package: nvi
Version: 1.81.6-8.1
Severity: normal

By default, nvi sets up some key mappings for cursor keys and some
other editing keys.  The key strings appear to be taken from terminfo,
and they're mapped to sequences that roughly implement the keys' nominal
editing actions.  There needs to be some way to suppress these default
mappings, preferably by a command in ~/.exrc, in order to prevent them
damaging the interactive experience.

The remainder of this bug report details how the default mappings are
a problem and that there currently isn't any way to suppress them.
You can skip this if you're already clear on these matters.

The default mappings are mostly OK (as in, don't interfere with anything)
for the command map.  In the input map, however, they tends to screw up
the use of Esc to terminate input.  For example, I get this by default
in an xterm:

:map!
^[OA  ^[ka  cursor up
^[OB  ^[ja  cursor down
^[OC  ^[la  cursor right
^[OD  ^[ha  cursor left

I'll leave aside the issue of these target sequences being very poor
implementations of arrow actions, and the fundamental problem that arrow
actions make no sense in the middle of a text parameter to an editing
command.  These mappings cause a practical problem by making the ^[ byte
ambiguous, when seen in the input while reading text.  When I press Esc,
rather than immediately end the text input, nvi waits for half a second
or so to see whether there are more bytes following that would indicate
that I'd pressed an arrow key.  This pause damages the interactivity of
vi, by denying immediate feedback.

Furthermore, starting from text input, the actual key sequence
Esc-O-anything *is valid*.  It ends input, then opens a new line above
the current one, and begins text entry on the new line.  The mappings make
these sequences as a whole ambiguous: whether Esc-O-A (for example) gets
its proper behaviour or the fake-up-arrow behaviour depends on the timing
with which it is typed.  I don't often run into this, but it has happened.

So I'd like to not have these confounding entries in the input map.
Obviously, in a running nvi instance I can manually remove them one
by one, by entering unmap commands.  That's very cumbersome.  I should
be able to automate this by putting the unmap commands in my ~/.exrc,
but that strangely doesn't work.  If I have this in my ~/.exrc:

unmap! ^[OA 
unmap! ^[OB
unmap! ^[OC
unmap! ^[OD

(real escape characters, not hat-bracket), then on startup vi complains:

    "^[OA" isn't currently mapped
/home/zefram/.exrc, 10: Ex command failed: pending commands discarded

and yet the default mappings are in full effect.  Strangely, I *can*
replace the default mappings with other mappings in ~/.exrc, by using
the map command.  In that case there's no error and the .exrc mappings
are in effect in place of the default mappings.  (They take precedence
key-by-key; any key not explicitly mapped in .exrc gets its default
mapping.)  I tried mapping the escape sequences to themselves: that
fixes the rare Esc-O-A problem, but doesn't avoid the pause.

If unmap commands in ~/.exrc took effect in suppressing the default
mappings, as map commands do, that would be a big step forward.  But it's
actually not a satisfactory solution, as alluded to by the error messages
shown above.  Once the first unmap command on a not-mapped key sequence
is seen, the rest of the .exrc is ignored.  This is a problem because the
sequences that get default mappings aren't fixed, but depend on terminfo.
For example, in rxvt the arrow keys send ^[[A et al instead of ^[OA et
al, and terminfo knows it.  If I use both terminal types, it would be
an obvious strategy to put unmap commands into ~/.exrc for both sets
of default-mapped sequences.  But that won't work, because the unmap
commands for the sequences that the present terminal doesn't use will
be treated as an error, and if the error is caused by the first set of
unmap commands then the correct set won't get to run.

Even apart from the error issue, having to tell .exrc about the escape
sequences for every terminal I ever use is a messy way to go about this.
In practice it'd be kinda workable, because most terminals send either
the ^[[A or ^[OA set, but it'll always fall down on the occasional use
of an unconventional terminal not previously used.

So it would be much better to have a command in .exrc that doesn't need
to vary according to terminal.  Also preferably a single command to
affect all the keys.  I'd like to have a command that says "don't apply
default mappings".  Either one command for each map (command and input),
or one for both.

-zefram



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#673021: negative fraction in kb geometry emitted badly

[Zefram]

Package: x11-xkb-utils
Version: 7.5+5
Severity: normal

When generating .xkb source-style output, xkbcomp incorrectly serialises
negative fractional dimensions in the keyboard geometry.  Negative
integer dimensions (as seen in the "kinesis" geometry file) are fine.
For example:

$ cat t0.xkb
xkb_keymap {
xkb_keycodes "evdev" { include "evdev" };
xkb_types "complete" { include "complete" };
xkb_compatibility "complete" { include "complete" };
xkb_symbols "us" { include "us" };
xkb_geometry "test" {
width = 100;
height = 100;
shape "K" { { [  20,  20 ] } };
section "a" {
top = 50;
left = 50;
row {
top = -3.6;
left = -3;
keys { { , "K" } };
};
};
};
};
$ xkbcomp -w0 t0.xkb t0.xkm
$ xkbcomp t0.xkm t1.xkb
$ sed -n '1,/geometry/d;/= *-/p' t1.xkb
top=  -3.-5;
left= -3;

-zefram



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#673023: kb geometry aliases can't refer to aliases

[Zefram]

Package: x11-xkb-utils
Version: 7.5+5
Severity: important

XKB key aliases can be defined in the geometry section, as well as in
the keycodes section, to effect a separation of concerns.  However, this
separation fails because xkbcomp doesn't allow key aliases in the geometry
section to freely use the key names supplied by the keycodes section.
Specifically, the geometry section can't use names that the keycodes
section defined as aliases.  This contrasts with the symbols section,
which can use key names defined directly or as aliases interchangeably.
Test case:

$ cat t0.xkb
xkb_keymap {
xkb_keycodes "test_keycodes" {
minimum = 8;
maximum = 255;
 = 10;
 = 11;
alias  = ;
 = 12;
 = 13;
alias  = ;
};
xkb_types "complete" { include "complete" };
xkb_compatibility "complete" { include "complete" };
xkb_symbols "test_symbols" {
key  { [ a, A ] };
key  { [ b, B ] };
key  { [ c, C ] };
key  { [ d, D ] };
};
xkb_geometry "test_geometry" {
alias  = ;
alias  = ;
};
};
$ xkbcomp t0.xkb t0.xkm
Warning:  Attempt to alias  to non-existent key 
  Ignored
Warning:  Key  not found in test_keycodes keycodes
  Symbols ignored
Warning:  No symbols defined for  (keycode 13)

Observe that the symbols section uses the directly-defined  and
the alias  equivalently without trouble, but when the geometry
section tries to use the directly-defined  and the alias 
equivalently the latter fails.  The alias  is then not usable by
the symbols section.

This problem occurs for real around the "menu" key of 104/105-key PC
keyboards.  It is known as both  and , the latter apparently
referring to a "compose" function.  Its keycode varies according to how
the keyboard is accessed: 117 in the "standard" xfree86 keycode set,
and 135 in the evdev driver.  Both the xfree86 and evdev keycode files
define both names, one directly and one as an alias, but they differ
on which one is done which way.  It shouldn't matter that they differ,
but the result is that a geometry file can't reliably refer to this key
at all.  The only workaround is to have two versions of the geometry file,
the choice between them having to be made to match the keycodes file.
This is obviously a failure of the separation of concerns that the
multi-section mechanism was intended to achieve.

(The geometry section *can* use alias key names for its picture-drawing
part, just not for creating aliases.  I've run into this problem
specifically when attempting to have the geometry section provide
systematic layout-based key names, so that the symbols section can assign
keysyms based on keys' locations rather than on their nominal functions.)

-zefram



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#673027: xkbcomp bad parsing of -w option

[Zefram]

Package: x11-xkb-utils
Version: 7.5+5
Severity: minor

xkbcomp's warning-level option only works if the numeric argument comes
in a separate command-line argument from the "-w".  E.g., "xkbcomp -w 3
t0.xkb" and "xkbcomp -w 4 t0.xkb" work, and produce different degrees
of verbosity.  But "xkbcomp -w3 t0.xkb" and "xkbcomp -w4 t0.xkb" both
produce no warnings, as far as I can see.

There is no explicit indication that the option was badly formed.
The numeric argument is not being treated as an option, nor is the
filename argument being consumed as the argument to "-w".  It just
silently goes wrong.

-zefram



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#673028: xkbcomp doesn't install key repeat state

[Zefram]

Package: x11-xkb-utils
Version: 7.5+5
Severity: important

Whether a key is eligible to auto-repeat can be specified in XKB source,
using the key.repeat property.  xkbcomp processes this, preserving it in
a compiled .xkm file and regurgitating it when decompiling a .xkm back to
.xkb source.  However, when it's asked to install a keymap, by giving it
a display as a target, it doesn't install the per-key repeat property.
Instead, the keys retain the repeat state that they previously had.
Working around this requires use of "xset r" and "xset -r" to separately
set the repeat flag for each keycode.

When xkbcomp is asked to read the keymap state back from a display,
it correctly reflects the effective per-key repeat state.  So "xkbcomp
t0.xkb $DISPLAY; xkbcomp $DISPLAY t1.xkb" yields t1.xkb showing repeat
states unrelated to those in t0.xkb, while in other respects showing
equivalent settings.

-zefram



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#673031: bad handling of overlong key name

[Zefram]

Package: x11-xkb-utils
Version: 7.5+5
Severity: minor

XKB key names are limited to four octets.  Initially I didn't know that,
and tried to use longer names, like this:

$ cat t0.xkb
xkb_keymap {
xkb_keycodes "test_keycodes" {
minimum = 8;
maximum = 255;
 = 10;
};
xkb_types "complete" { include "complete" };
xkb_compatibility "complete" { include "complete" };
xkb_symbols "us" { include "us" };
xkb_geometry "kinesis" { include "kinesis" };
};
$ xkbcomp t0.xkb t0.xkm
syntax error: line 5 of t0.xkb
last scanned symbol is: FOOBARm
Errors encountered in t0.xkb; not compiled.

There's obviously a nul-termination problem in that error message.
Possibly overrunning a fixed-size buffer too?

-zefram



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#673035: useless "No symbols defined for" warnings

[Zefram]

Package: x11-xkb-utils
Version: 7.5+5
Severity: minor

xkbcomp warns whenever a keycode has been given a name but does not have
symbols explicitly defined.  This happens a lot, because keycodes files
tend to name every keycode defined for their protocol, including many
obscure keys that most keyboards don't have.  For example, the evdev
set results in a lot of

Warning:  No symbols defined for  (keycode 99)
Warning:  No symbols defined for  (keycode 100)
Warning:  No symbols defined for  (keycode 101)
...
Warning:  No symbols defined for  (keycode 146)
Warning:  No symbols defined for  (keycode 147)
Warning:  No symbols defined for  (keycode 148)
Warning:  No symbols defined for  (keycode 149)

It's OK to warn about this, but since it's a very normal situation
and doesn't usually represent an actual problem it should be a very
low-priority warning, that can be turned off without losing any of the
more useful warnings.

In fact it's implemented as quite a high-priority warning.  It takes
"-w 3" to turn it off; "-w 4" or higher generates this warning.
By comparison, the warning for the reverse situation, where an attempt
is made to assign symbols to a key name that hasn't been defined, which
*does* generally indicate a real problem, is turned off at "-w 4" or
below, appearing only with "-w 5" or higher.  So at "-w 4" you get the
useless warnings but not the useful ones.

Having this warning on means that any successful run of xkbcomp generates
screenfuls of useless warnings, thus hiding real warnings.  Having this
warning off means that real warnings will be suppressed.  Neither is
a good way to operate.  The "No symbols defined for" warning needs to
be lower priority than other warnings, or independently selectable,
or just abolished entirely.

-zefram



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#668224: inaccurate arcs

[Zefram]

Package: inkscape
Version: 0.47.0-2+b1
Severity: important

When rendering SVG  items that contain Arc commands, inkscape
screws up the geometry.  Simple test case:

http://www.w3.org/2000/svg";>






This attempts to render a unit circle twice.  First, in red, as a
.  Secondly, in green, in four equal arc-segment pieces in
a .  The correct result is that the two versions of the circle
coincide.  There should be no visible difference between their locations.

For testing, I've invoked inkscape to render it via "inkscape -bblack
-e t1.png t1.svg".  Actual result is that the red version is properly
circular but the green one deviates from it significantly.  They coincide
at the four cardinal points, but between them the green one is located
well inside the red circle.  I crudely measured its diagonal diameter
to be about 1.7% less than the circle's diameter.

In my real application, where I first noticed the fault, the deviations
are much more significant than the 1.7% that you see with the simple
test case.  It seems to depend on the angular extent of the arc, in a
non-obvious manner.  The bug is utterly devastating.

Googling reveals some talk about Inkscape internally approximating arcs
with Bezier curves.  That could account for this, if it's done ineptly.
If Inkscape is to use such approximations then it must use more control
points, adaptively, to get a result that's close enough given the output
resolution.  But it would be much better, of course, for Inkscape to
actually handle arcs as arcs, rendering them natively.

-zefram



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#863008: failing to load previously-loaded pages of some websites

[Zefram]

Package: lynx-cur
Version: 2.8.9dev1-2+deb8u1
Severity: important

Lynx has developed a habit of finding it difficult to load the same web
page twice in one session, for pages in some websites but not others.
The envelope of this bug is a bit tricky.

As far as I can see, within any particular Lynx session this bug affects
a fixed set of websites: a site that is affected is affected for the
whole session, and a site that does not exhibit the problem won't come
to exhibit it later in the session.  A "website" for this purpose is
the combination of scheme prefix and authority part of a URL.  All paths
within a website are affected together.  I have not been able to determine
whether different scheme/authority combinations that involve the same
hostname can be affected distinct from each other, but ones involving
different hostnames are definitely distinct.  The websites that I have
found affected so far are only HTTPS ones.

Which websites are affected is mostly consistent between Lynx sessions.
For the past few weeks I have found that <https://en.wikipedia.org> is
affected in all my Lynx sessions.  Recently <https://www.theguardian.com>
has come to be affected in most sessions, but not entirely consistently.
Most websites remain unaffected.  I have no idea what distinguishes the
affected websites from unaffected ones.

Where the bug is in effect, the first loading of any page from an affected
website works normally, but then any second or subsequent attempt to
load the same page shortly thereafter fails.  This happens for almost
any means of invoking a page load: following a link from another page,
typing in the URL manually, or following a link from the browser's
"visited links" page.  But page loading succeeds if invoked by following
a link from the browser's "history" page, by using the "u" command to pop
the history stack, or by using the ^R command to reload the current page.
Where page loading fails due to this bug, there is activity in the status
line that seems to reflect a network request, but then the activity ends
and the status line returns to normal without changing page, as if the
request to load the affected page had never been made.

The inability to load a page twice applies separately to each page in the
affected website.  Loading a different page (with different URL) works.
Many pages from the same website may be loaded in sequence.  But then
attempting to load the same pages again fails: each previously-loaded
page cannot be loaded again.  Such failing page loads can be arbitrarily
interleaved with successful first-time page loads.

However, an attempted repeated page load may succeed if enough activity
has taken place since the first (successful) load of that page.  "Enough
activity" seems to be constituted by successful loads of sufficiently
many other pages.  (Perhaps a caching issue?)  Repeatedly attempting to
load a failing page, with no other activity 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

Bug#863008: failing to load previously-loaded pages of some websites

[Zefram]

Thomas Dickey wrote:
>This report doesn't indicate a version where Lynx behaves as you expect.

Strangely, this misbehaviour doesn't seem to have arrived with a specific
Lynx version, but developed over time.  I'm sure that the present version
worked fine on these websites when it was first installed here a year and
a half ago.  It was definitely working for <https://www.theguardian.com>
two weeks ago, for which it's not working now.  Presumably this version
always had the bug, but it's being triggered by some unusual environmental
condition that has changed over time.  So I never noticed this bug with
the previously-installed Lynx version, whatever that was, but I don't
see any reason to think that that version actually lacked the bug.

If you can't reproduce the problem, I could have a go at compiling a
bunch of Lynx versions from source to see which ones do this.

>This sounds like the longstanding Lynx behavior: it doesn't automatically
>reload a page which has been read and is cached locally.

I'm not sure quite what behaviour you mean there.  Maybe I've failed
to explain the bug clearly enough.  The bug I'm reporting is not mere
caching behaviour: it's not a cache operating correctly, nor is it merely
a matter of a cache serving up stale information.

In the past I have observed that, when invoking loading of a
recently-loaded page (as is the situation in the bug report), Lynx
will show the requested page from cache.  That is, it shows the page
instantly rather than making a network request for it, and if the page
is volatile then the version that it shows may be the previously-loaded
version rather than current.  This behaviour is totally fine, and is not
what the bug report is about.  (Incidentally, trying it now, I'm seeing
this caching behaviour from "u" commands popping the history stack,
but not from repeated selection of ordinary links.  Don't know whether
this is normal or not.)

In the situation of the bug report, other than it being specific to some
websites, the condition for the bug to manifest does look a lot like the
condition for Lynx to serve a page from the cache.  But the behaviour is
not to serve the page from cache: the requested page does not get shown
at all.  No history entry gets pushed, and Lynx continues to display the
page from which the link was selected.  The user can continue navigating
in the 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

Bug#863008: failing to load previously-loaded pages of some websites

[Zefram]

Thomas Dickey wrote:
>Also, steps to reproduce the problem.

OK, can provide that straight away.  For this recipe, there should be
no ~/.lynxrc in place.  First, at the command line:

$ echo 'https://en.wikipedia.org/wiki/Main_Page";>Wikipedia' 
>x0.html
$ lynx -cookies x0.html

Lynx fires up, displaying the rendered x0.html page, containing only
the single "Wikipedia" hyperlink.  Press .  In response Lynx
displays the Wikipedia front page.  Press "u".  In response Lynx returns
to displaying the rendered x0.html page.  Press .  At this point,
correct behaviour would be to display the Wikipedia front page.  Observed
incorrect behaviour is that there is some brief status line activity
but when it's over the rendered x0.html page continues to be displayed.

The state of the -cookies option doesn't affect the bug; using the
option in the above recipe just simplifies the interaction.  Likewise,
~/.lynxrc configuration is irrelevant as far as I've explored; having
no such config file is just a conveniently-reproducible reference point.

Varying the link target shows correct behaviour for some websites and
incorrect for others.  For example, correct behaviour is observed if
the link is to <https://encrypted.google.com>.

strace can show some of what's going on.  The first time the link is
selected, Lynx forks off a short-lived process that apparently handles the
DNS lookup, then opens an IPv6/TCP connection to en.wikipedia.org:443
and performs some network I/O, with commentary in the status line.
After commenting "HTTP/1.1 200 OK" it opens a temporary .html.gz file, and
from there on while continuing to read from the network it writes to the
temporary file.  It closes the network connection and the temporary file.
It then reopens the file read-only, reads part of it, and closes it again.
It then reopens the file read-only again, reads all of it while rendering
to the screen, and then closes the file again.

Upon "u", Lynx changes the display back to the rendered x0.html page
without any network or file action.

The second time the link is selected, Lynx initially proceeds as it
did the first time: short-lived DNS process, open IPv6/TCP connection,
network I/O with status-line commentary up to "HTTP/1.1 200 OK".
But it does not open any temporary file.  It reads the bulk of the
network response without strace showing any evidence of where the
data is going.  It comments "Data transfer complete" (as it did at
this point the first time), but then immediately comments "Getting
file://localhost/[...]/x0.html".  Without actually referring to any file,
it rewrites the display of 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

Bug#858668: STA_NANO confuses adjtimex(8)

[Zefram]

Package: adjtimex
Version: 1.29-3
Severity: minor

$ /sbin/adjtimex -p
 mode: 0
   offset: 766894
frequency: 5735179
 maxerror: 649789
 esterror: 2161
   status: 8193
time_constant: 10
precision: 1
tolerance: 32768000
 tick: 
 raw time:  1490397277s 23837440us = 1490397277.23837440

Observe that the "raw time" line shows in its two-part form a time over
23 million microseconds, i.e., over 23 seconds, into the present second.
Also, in its one-part form it shows a value that seems to treat these
microseconds as each being 1e-8 seconds long.  These displays are
inconsistent with each other, and inconsistent with the meaning of
microseconds.

What's really going on is that the STA_NANO flag is set (8192 in the
status), so the tv_usec field of the struct timeval doesn't actully
represent microseconds.  It represents *nanoseconds*.  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

Bug#858668: STA_NANO confuses adjtimex(8)

[Zefram]

Roger Shimizu wrote:
>I meant we may have:
>   status: 8193
>  status flag: STA_PLL | STA_NANO

That might be OK for the status flags, but I don't fancy duplicating
*every* line just to add the unit:

offset: 5221897
offset qty: 5221897 ns
  maxerror: 616511
  maxerror qty: 616511 us
  esterror: 9673
  esterror qty: 9673 us

Applying that approach to every line doesn't seem sensible.  But if
you're OK with adding the unit to the existing line, then there's a
similar approach available to keep the status on one line:

   status: 8193 (STA_PLL | STA_NANO)

It's worth avoiding duplicating the lines, if reasonably possible,
because duplication gives the impression that two different pieces of
information are being presented.

If you reckon it's not acceptable to modify the existing lines at all,
then it would seem better to leave the -p output completely unchanged,
and add a new command-line option that provides the same information in
the new format.

-zefram

Bug#861019: git bisect colour output contrary to configuration

[Zefram]

Package: git
Version: 1:2.1.4-2.1+deb8u2
Severity: minor

My ~/.gitconfig contains

[color]
ui = never

which should prevent attempts at colouring output from all git commands.
I do not have any git configuration enabling colour in any situation
(such as for specific commands).  But when a git bisect completes,
the output identifying the first bad commit includes escape sequences
to colour the "commit 631..." line yellow.  Excerpt of strace output:

11015 write(1, "613abc6d16e99bd9834fe6afd79beb61a3a4734d is the first bad 
commit\n", 65) = 65
11015 write(1, "\33[33mcommit 613abc6d16e99bd9834fe6afd79beb61a3a4734d\33[m\n", 
56) = 56

Given the configulation, that line should be free of escape sequences.

-zefram

Bug#861583: -geometry and -fs not fully honoured

[Zefram]

Package: mplayer
Version: 2:1.0~rc4.dfsg1+svn34540-1+deb7u1
Severity: minor

When mplayer is started up with a -geometry option that specifies a
position for the window (e.g., "-geometry +0+0"), it fails to set the
USPosition hint bit that tells the window manager that the position was
supplied by the user.  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 initially override the user-supplied
position with mplayer.  The same goes for the USSize hint.  However,
immediately after the window has been placed by the window manager,
mplayer then moves the window itself, not quite to the position requested.

Something similar happens with the -fs (full-screen) option.  mplayer
initially puts up a window in the video's native size, with no USPosition
or USSize hints.  It then replaces that with a window that actually
functions as the requested full-screen arrangement.

In both cases, the user-specified geometry ought to be applied
immediately, with the hint bits set to let the window manager know that
it is user-specified.  Invocations where the user does not specify 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

Bug#785208: adjtimex postinst adjusts clock

[Zefram]

Control: tags -1 -moreinfo
thanks

Bug#785208: adjtimex postinst adjusts clock

[Zefram]

Roger Shimizu wrote:
>Adjtimex loads the param on every starting up because you choose to
>when you installed adjtimex package,

I did not choose to have it do anything on startup.  My choice was
merely to install a useful debugging tool.  I have debconf set to
non-interactive, so did not configure the package during installation.
The default configuration shouldn't be mucking about with the running
system in uninvited ways.

-zefram

Bug#756505: undocumented how to show a buffer

[Zefram]

Package: mcabber
Version: 0.10.1-3
Severity: important

The mcabber documentation doesn't say how to display a desired chat
buffer.  Joining a room (/room join) creates a chat buffer, the existence
of the buffer can be seen (/buffer list), and some buffer can be shown
by entering chat mode (), but the documentation doesn't indicate
any way to select *which* buffer is shown in chat mode.  In fact the
"[status]" buffer is initially shown, so there's no documented way to
display an actual room buffer.  I presume there is some way, obviously
undocumented.  That such a critical function 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

Bug#785208: adjtimex postinst adjusts clock

[Zefram]

Package: adjtimex
Version: 1.29-3
Severity: normal

The postinst script for the adjtimex package insists on running
adjtimex to perform some clock adjustment.  This is silly.  At the time
the package is installed or upgraded, the system is already running,
quite likely with the clock already well regulated (especially if this
was an upgrade).  In my case, I'm regulating the clock with ntpd, so
adjtimex should never be automatically run outside the boot sequence.
The postinst script should not be performing any clock adjustment.

It seems that, as with ntpdate in Bug#714997, the package is conflating
the desire to install a tool with the desire to use it in a particular
way.  adjtimex is useful for much more than just the automatic adjustment
that the postinst script contemplates.  I use it mainly in read-only
mode to watch what in fine detail what ntpd and the kernel are doing
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

Bug#787734: libstdc++ breaks dynamic unloading

[Zefram]

Package: libstdc++6
Version: 4.9.2-10
Severity: normal

Where libstdc++ is dynamically loaded, in some cases it prevents an
unrelated dynamic library that was loaded earlier from being unloaded.
It also, incidentally, can't itself be unloaded, but that's much less
of a problem.  When I say that a library can't be unloaded, I mean that
dlclose() indicates success, but the library actually remains mapped.
I've been probing this with a test program, which just dlopens a sequence
of libraries and then dlcloses them in reverse sequence, looking at
what's actually mapped at each point:

$ cat try_dl.c
#include 
#include 
#include 
#include 
int main(int argc, char **argv)
{
setbuf(stdout, NULL);
if(argc <= 1) exit(2);
argv++; argc--;
void **handles = malloc(sizeof(void*) * argc);
if(!handles) exit(1);
char maps_cmd[100];
sprintf(maps_cmd, "sed -n 's:.* /:/:p' /proc/%ld/maps | sort -u", 
(long)getpid());
system(maps_cmd);
for(int i = 0; i != argc; i++) {
handles[i] = dlopen(argv[i], RTLD_LAZY);
printf("dlopen(\"%s\", RTLD_LAZY) = %p\n", argv[i], handles[i]);
system(maps_cmd);
if(!handles[i]) exit(1);
}
for(int i = argc; i--; ) {
int ret = dlclose(handles[i]);
printf("dlclose(%p /*\"%s\"*/) = %d\n", handles[i], argv[i], 
ret);
system(maps_cmd);
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-linux-gnu/libdl-2.19.so
dlopen("/usr/lib/x86_64-linux-gnu/libperl.so.5.20", RTLD_LAZY) = 0x1761070
/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-linux-gnu/libcrypt-2.19.so
/lib/x86_64-linux-gnu/libdl-2.19.so
/lib/x86_64-linux-gnu/libm-2.19.so
/lib/x86_64-linux-gnu/libpthread-2.19.so
/usr/lib/x86_64-linux-gnu/libperl.so.5.20.2
dlopen("/usr/lib/x86_64-linux-gnu/libstdc++.so.6", RTLD_LAZY) = 0x1762ae0
/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-linux-gnu/libcrypt-2.19.so
/lib/x86_64-linux-gnu/libdl-2.19.so
/lib/x86_64-linux-gnu/libgcc_s.so.1
/lib/x86_64-linux-gnu/libm-2.19.so
/lib/x86_64-linux-gnu/libpthread-2.19.so
/usr/lib/x86_64-linux-gnu/libperl.so.5.20.2
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.20
dlclose(0x1762ae0 /*"/usr/lib/x86_64-linux-gnu/libstdc++.so.6"*/) = 0
/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-linux-gnu/libcrypt-2.19.so
/lib/x86_64-linux-gnu/libdl-2.19.so
/lib/x86_64-linux-gnu/libgcc_s.so.1
/lib/x86_64-linux-gnu/libm-2.19.so
/lib/x86_64-linux-gnu/libpthread-2.19.so
/usr/lib/x86_64-linux-gnu/libperl.so.5.20.2
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.20
dlclose(0x1761070 /*"/usr/lib/x86_64-linux-gnu/libperl.so.5.20"*/) = 0
/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-linux-gnu/libcrypt-2.19.so
/lib/x86_64-linux-gnu/libdl-2.19.so
/lib/x86_64-linux-gnu/libgcc_s.so.1
/lib/x86_64-linux-gnu/libm-2.19.so
/lib/x86_64-linux-gnu/libpthread-2.19.so
/usr/lib/x86_64-linux-gnu/libperl.so.5.20.2
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.20

Observe that both libperl and libstdc++ remain loaded after the dlcloses,
along with all their dependencies.  But if libperl is loaded without
libstdc++, it unloads as one would expect:

$ ./try_dl /usr/lib/x86_64-linux-gnu/libperl.so.5.20
/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-linux-gnu/libdl-2.19.so
dlopen("/usr/lib/x86_64-linux-gnu/libperl.so.5.20", RTLD_LAZY) = 0xd48070
/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-linux-gnu/libcrypt-2.19.so
/lib/x86_64-linux-gnu/libdl-2.19.so
/lib/x86_64-linux-gnu/libm-2.19.so
/lib/x86_64-linux-gnu/libpthread-2.19.so
/usr/lib/x86_64-linux-gnu/libperl.so.5.20.2
dlclose(0xd48070 /*"/usr/lib/x86_64-linux-gnu/libperl.so.5.20"*/) = 0
/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-linux-gnu/libdl-2.19.so
/lib/x86_64-linux-gnu/libpthread-2.19.so

In this case libpthread, loaded as one of libperl's dependencies, won't
unload, but this doesn't seem to be a problem.

I'll spare you the full try_dl

Bug#806460: search highlight glitch

[Zefram]

Package: lynx-cur
Version: 2.8.9dev1-2+deb8u1
Severity: normal

Under some circumstances, whose envelope I have not fully determined,
there is a visual glitch when highlighting instances of text searched
for in a displayed web page.

When searching for a given search string in a given page, and looking
at a particular instance of the string, whether the glitch occurs is
totally deterministic.  When searching in page source for a string that
begins with a dot character, the glitch almost always manifests, but not
absolutely always.  I have also seen the glitch, but less frequently,
when performing other searches in page source.  I have never seen the
glitch when searching a rendered page.

The nature of the glitch is that the highlighted instance of the string
is offset one column to the left of its proper position.  The surrounding
unhighlighted text remains in its proper position.  As a result, the
character immediately preceding the search string is absent from the
display (overwritten by the out-of-place first highlighted character), and
the last character of the search string is duplicated (one out-of-place
highlighted instance followed immediately by one in-place unhighlighted
instance).  Obviously this is quite an inconvenience when one wants to
c&p some text including the search string.

-zefram

Bug#806461: spurious colour output from bisect

[Zefram]

Package: git
Version: 1:2.1.4-2.1
Severity: minor

I'm getting some coloured output from git despite having set
color.ui=never in my ~/.gitconfig.  When completing a git bisect
process, when git gives the "is the first bad commit" report, the "commit
22ff..." line is being output with escape sequences intended to colour it
yellow, if stdout is a terminal.  The color.ui setting has successfully
disabled most of the coloured-by-default output from git, just not this
particular bit.  Caught by strace (with many irrelevant lines omitted):

20408 write(1, "22ff313068aa37b1a24855e760e71ee9a20a1a90 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 read(3, "", 4096) = 0
20408 close(3)  = 0
20408 write(1, "\33[33mcommit 22ff313068aa37b1a24855e760e71ee9a20a1a90\33[m\n", 
56) = 56

-zefram

Bug#787453: libdata-alias-perl: FTBFS with perl 5.22

[Zefram]

Hi, I'm the Data-Alias maintainer.  Data-Alias has been updated for Perl
5.22, in Data-Alias-1.19, now on CPAN.  However, I've had reports from two
separate users describing test failures of D-A-1.19 on vendor versions
of Perl 5.22, one Debian and one Fedora.  These new test failures are
recognisable by a bunch of syntax-related error messages from the test
suite, starting with a "Useless use of anonymous hash" warning from
t/03_copy.t, following build success.

I have not been able to reproduce this new failure myself.  It doesn't
happen with my usual configurations of stock Perl 5.22.  It doesn't
happen if I apply as much of the Fedora configuration settings as I can
to stock 5.22.  It even doesn't happen if I use my usual configuration
after applying the patches from the Debian perl 5.22.0-4 package.

It would be really helpful if someone with a failing setup would
try figuring 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

Bug#787453: libdata-alias-perl: FTBFS with perl 5.22

[Zefram]

Niko Tyni wrote:
>However, building Data-Alias-1.19 with clang works even on our packaged
>perl 5.22.0-4. So the perl build doesn't seem to matter that much.

Thanks, that's a very useful set of results.  Compiler used to build
D-A matters.  It must be doing something hacky at the C language level of
which I was not previously aware.  I can probably track it down from here.

-zefram

Bug#787453: libdata-alias-perl: FTBFS with perl 5.22

[Zefram]

The compiler-dependent problem turned out to be some C-level undefined
behaviour in the module, with insufficient sequence points around a
variable mutation.  The compilers differed in whether they performed
the write before or after a call to a Perl core function (yylex())
that in 5.22 has come to depend on the variable more than it used to.

Fixed in Data-Alias-1.20, now on CPAN.

-zefram

Bug#865027: stumbles on Youtube age gate

[Zefram]

Package: libquvi7
Version: 0.4.1-3
Severity: normal

libquvi fails to download videos from Youtube that are subject to age
restriction.  For example, using the cclive(1) frontend:

$ cclive "https://www.youtube.com/watch?v=W6JhcjbWEwg";
Checking ... .. ... libquvi: error: 
/usr/share/libquvi-scripts/lua/website/youtube.lua:112: Sign in to confirm your 
age (code=150)

(This video is of an interview of one journalist by another.  Not being
able to see it, I don't know what aspect it has that would cause Youtube
to age-restrict it.  My guess is that it's a reality-is-NSFW 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

Bug#865736: doc misuses metric prefixes

[Zefram]

Package: findutils
Version: 4.4.2-9+b1
Severity: minor

find(1) documents the following suffixes that can be applied to the
argument of a -size criterion:

  `k'for Kilobytes (units of 1024 bytes)
  `M'for Megabytes (units of 1048576 bytes)
  `G'for Gigabytes (units of 1073741824 bytes)

These are not the correct names for these units.  The prefixes "kilo-",
"mega-" and "giga-" properly refer to the decimal multipliers 10^3,
10^6, and 10^9.  To refer to the binary multipliers 2^10, 2^20, and
2^30 the documentation should instead use the IEC prefixes "kibi-",
"mebi-", and "gibi-".

-zefram

Bug#858668: STA_NANO confuses adjtimex(8)

[Zefram]

Roger Shimizu wrote:
>You tagged as minor, so I think it's just a display issue of raw time,
>and it doesn't affect adjtimex's time calculation, right?

I didn't look at the calculating parts of adjtimex, which I never use.
I use adjtimex mainly for display, and just occasionally to poke
status flags.  I tagged this bug as minor because I was only reporting
a display problem.

I've now audited adjtimex fully for nanosecond issues.  In addition to
the display problem, STA_NANO affects the interpretation of offsets input
with the -o and -s options; this is a documentation issue rather than a
functionality issue.  The parts of adjtimex that perform computations are
not affected, because they don't use the adjtimex syscall to retrieve
the time: they use gettimeofday, which yields microseconds regardless
of STA_NANO.

>And it'd be appreciated if you can kindly provide a patch.

Attached.

Would you also be interested in patches to make the interface a bit nicer?
I'm thinking of things like showing units on the values displayed with -p
(the unit for "offset" depends on STA_NANO), using symbolic names for
the status flags, and permitting input option values to use units (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
@@ -158,6 +158,7 @@
1024   PPS signal wander exceeded
2048   PPS signal calibration error
4096   clock hardware fault
+   8192   raw time denominated in nanoseconds
 .fi
 .IP "\fB\-t\fP \fIval\fP, \fB\-\-tick\fP \fIval\fP"
 Set the number of microseconds that should be added to the system time
@@ -185,16 +186,18 @@
 To see the acceptable range for \fInewfreq\fP, use \-\-print and look at
 "tolerance", or try an illegal value (e.g. \-\-tick 0).
 .IP "\fB\-s\fP \fIadj\fP, \fB\-\-singleshot\fP \fIadj\fP"
-Slew the system clock by \fIadj\fP usec.  
+Slew the system clock by \fIadj\fP usec or nsec
+(using whichever unit the clock is presently denominated in).
 (Its rate is changed temporarily by about 1 part in 2000.)
 .IP "\fB\-o\fP \fIadj\fP, \fB\-\-offset\fP \fIadj\fP" 
-Add a time offset of \fIadj\fP usec.
+Add a time offset of \fIadj\fP usec or nsec
+(using whichever unit the clock is presently denominated in).
 The kernel code adjusts the time gradually by \fIadj\fP, 
 notes how long it has been since the last time offset, 
 and then adjusts the frequency offset to correct for the apparent drift.  
 .\"The short range of this parameter makes it almost 
 .\"totally useless except for use with ntpd:
-\fIadj\fP must be in the range -512000...512000.
+The adjustment cannot be of more than 500 ms in either direction.
 .IP "\fB\-S\fP \fIstatus\fP, \fB\-\-status\fP \fIstatus\fP"
 Set kernel system clock status register to value \fIstatus\fP. Look here
 above at the \fB\-\-print\fP switch section for the meaning of
diff -ur adjtimex-1.29.orig/adjtimex.c adjtimex-1.29/adjtimex.c
--- adjtimex-1.29.orig/adjtimex.c   2010-04-17 01:06:34.0 +0100
+++ adjtimex-1.29/adjtimex.c2017-04-18 17:02:04.705080554 +0100
@@ -57,6 +57,12 @@
 #define RTC_RD_TIME  _IOR('p', 0x09, struct rtc_time) /* Read RTC time  */
 #endif /* HAVE_LINUX_RTC_H */
 
+#ifdef STA_NANO
+#define HAS_STA_NANO(f) (f & STA_NANO)
+#else
+#define HAS_STA_NANO(f) 0
+#endif
+
 int F_print = 0;
 
 #ifndef LOG_PATH
@@ -217,11 +223,11 @@
 "   -p, --print   print values of kernel time variables\n"
 "   -t, --tick valset the kernel tick interval in usec\n"
 "   -f, --frequency newfreq   set system clock frequency offset\n"
-"   -s, --singleshot adj  slew the system clock by adj usec\n"
+"   -s, --singleshot adj  slew the system clock by adj usec or nsec\n"
 "   -S, --status val  set kernel clock status\n"
 "   -R, --reset   reset status after setting parameters\n"
 " (needed for early kernels)\n"
-"   -o, --offset adj  add a time offset of adj usec\n"
+"   -o, --offset adj  add a time offset of adj usec or nsec\n"
 "   -m, --maxerror valset maximum error (usec)\n"
 "   -e, --esterror valset estimated error (usec)\n"
 "   -T, --timeconstant valset phase locked loop time constant\n"
@@ -494,7 +500,7 @@
   "precision: %ld\n"
   "tolerance: %ld\n"
   " tick: %ld\n"
-  " raw time:  %ds %dus = %d.%06d\n",
+  " raw time:  %ds %d%cs = %d.%0*d\n&q

Bug#860559: timex.offset unit ambiguity

[Zefram]

Package: manpages-dev
Version: 3.74-1
Severity: minor

adjtimex(2) says:

#  struct timex {
#  int modes;   /* mode selector */
#  long offset; /* time offset (usec) */

In fact the "offset" field is not necessarily in microseconds.  It is
in either microseconds or nanoseconds, depending on the STA_NANO status
flag, just like timex.time.tv_usec.

-zefram

Bug#860559: timex.offset unit ambiguity

[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

Bug#858668: STA_NANO confuses adjtimex(8)

[Zefram]

Roger Shimizu wrote:
>See: 
>https://github.com/rogers0/adjtimex/blob/master/debian/patches/07-update-manpage-adjtimex.8.patch

That only has a small overlap with my patch.  Most of my patch is still
applicable.

>I guess "usec or nsec" is still confusing to end-user.

That's why I added the parenthetical "using whichever unit the clock is
presently denominated in".  If any more explanation is required than
that and the description of the status flag, it should be brought out
as a separate paragraph, not squeezed into the option descriptions.

>But please add new lines for new stuff.

That doesn't sit well with what I want to achieve.  I'm thinking that
I'd like to make the -p output look something like

   offset: 5221897 ns
frequency: 5733637 /65536 us/s
 maxerror: 616511 us
 esterror: 9673 us
   status: STA_PLL | STA_NANO
time_constant: 10 Sh
precision: 1 us
tolerance: 32768000 /65536 us/s
 tick:  us
 raw time: 1492784129.037972432
 return value: TIME_OK

Most of the new stuff is units, and I don't see a reasonable layout
that puts that all on new lines.  But in most cases the existing number
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

Bug#1064443: Acknowledgement (confused by changing absolute pathname)

[Zefram]

Upstream:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=69436

-zefram

Bug#1064446: Acknowledgement (confused by changing absolute pathname)

[Zefram]

Upstream:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=69436

-zefram

Bug#1033233: spurious colour output from git init

[Zefram]

Package: git
Version: 1:2.30.2-1+deb11u2
Severity: minor

"git init" outputs a bunch of lines marked "hint:".  For me it's emitting
those lines with a bunch of ANSI colour escape sequences, despite me
having configured color.ui=never in my ~/.gitconfig.  Some strace output:

write(2, "\33[33mhint: Using 'master' as the"..., 90) = 90
write(2, "\33[33mhint: is subject to change."..., 87) = 87
write(2, "\33[33mhint: of your new repositor"..., 80) = 80
write(2, "\33[33mhint: \33[m\n", 15)= 15
write(2, "\33[33mhint: \tgit config --global "..., 61) = 61
write(2, "\33[33mhint: \33[m\n", 15)= 15
write(2, "\33[33mhint: Names commonly chosen"..., 80) = 80
write(2, "\33[33mhint: 'development'. The ju"..., 86) = 86
write(2, "\33[33mhint: \33[m\n", 15)= 15
write(2, "\33[33mhint: \tgit branch -m "..., 36) = 36

And a configuration extract:

$ sed -n 6,7p ~/.gitconfig
[color]
ui = never

-zefram

Bug#1030344: filename on command line gets mangled

[Zefram]

Package: nodejs
Version: 12.22.12~dfsg-1~deb11u3
Severity: normal

The node(1) command-line interface is documented to take the filename
of a script to execute.  Here's how well it understands filenames:

$ echo 'process.stdout.write("sadness\n");' > $'L\xef\xbf\xbdon.js'
$ echo 'process.stdout.write("joy\n");' > $'L\xe9on.js'
$ node $'L\xe9on.js'
sadness
$

In this example I've created two different script files, with different
but related names, I've told node(1) to run one of them, and it's run
the wrong one.  One can see via strace(1) that node(1) doesn't use the
correct filename for any file operations at all; it completely substitutes
the erroneous filename.  The use of the wrong filename doesn't depend on
the file of that wrong name existing: if there is no file of that name
then node(1) will fail to find any script to execute, and will generate
an error message that shows the erroneous filename.

This bug occurs whenever the supplied filename doesn't have the syntax of
UTF-8 encoding of text, containing only Unicode codepoints of which node
approves.  The nature of the manglement is that each octet that doesn't
look like valid UTF-8 gets replaced with the three octets $'\xef\xbf\xbd',
which is the UTF-8 encoding of U+fffd "replacement character".  It appears
that the supplied filename is being UTF-8 decoded, with decoding
errors muffled and the replacement character silently substituted in,
and then the lossily-decoded filename is re-encoded in correct UTF-8,
and the result of that process is the filename that gets actually used.
As far as I can see the manglement comes only from UTF-8 decoding:
there isn't also any Unicode normalisation.

This could cause a security problem in some circumstances that are only
slightly strange.  Suppose a privileged program is using node(1) to run
scripts that partly derive from untrusted user input.  Suppose the program
has created an innocuous script to run, has permitted an untrusted user
to determine part of the filename for that script, and has ensured that
the supplied filename is innocuous from a Unix point of view but isn't
preventing the use of filenames with high-half octets.  Suppose further
that an untrusted user can cause the same program to create another file,
of content that the program doesn't intend to execute, under the mangled
name, which is equally innocuous from a Unix point of view.  Then it
could execute code determined by a malicious user, due entirely to node(1)
misinterpreting a filename.  I'm not aware of any specific program that
can be exploited in this way, and I haven't based the declared severity
of this bug report on this security issue.

Preferably, node(1) should use the script file of the name that was
supplied on the command line.  It must pass to the file syscalls the
same octet string that was supplied as a command line argument, without
assuming anything about its syntax.

If it cannot be made to handle arbitrary filenames correctly, 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

Bug#1030606: bad job control on suspended shell function

[Zefram]

Package: zsh
Version: 5.8-6+deb11u1
Severity: normal
Tags: patch

zsh screws up the way it displays job status if a job consists of a
shell function that got suspended after it was started:

% t0 () { sleep 1000; }
% t0
^Zzsh: suspended
[1]  + suspended
% echo foo
foo
[1]  + suspended
% :
[1]  + suspended
% jobs
[1]  + suspended
[1]  + suspended
[1]  + suspended
%

Observe that the job's status is redundantly reported before each
prompt is issued, and an extra time when executing the "jobs" builtin.
(The triple output around "jobs" consists of a redundant output before
doing the real work of "jobs", the requested job listing, and then another
redundant output before the next prompt.)  Also observe that the command
being run in the job is never reported.  By contrast, here's what correct
job control looks like:

% sleep 1000
^Z
zsh: suspended  sleep 1000
% echo foo
foo
% :
% jobs
[1]  + suspended  sleep 1000

This bug arises in situations where the job's command was originally
run as part of the shell process (as is the case with a shell function),
that command spawned an external process, and the job then got suspended,
forcing the shell to fork off a subprocess to embody the job.  The parent
shell manages the complicated process relationships that result by means
of a hidden subjob.  When called upon to display the state of the original
job, it shows the original job's number, but then substitutes in the
subjob for everything else that it does.  The command text isn't displayed
because the subjob doesn't have that data.  The frequent redundant
display happens because the original job is marked as needing reporting,
so reporting is triggered, but after reporting it is the subjob that
gets that flag cleared, so it is reported again at the next opportunity.

There are complicated things that could be done to fix these problems
while reporting the subjob status.  But, having examined various
combinations of job statuses that can occur, I think that actually it
was a mistake to report on the subjob in place of the original job.
The 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)  t0
%

-zefram
--- zsh-5.8.orig/Src/jobs.c 2020-01-05 17:59:57.0 +
+++ zsh-5.8/Src/jobs.c  2023-02-05 14:36:37.640874940 +
@@ -1077,22 +1077,6 @@
lng = !!isset(LONGLISTJOBS);
 }
 
-if (jn->stat & STAT_SUPERJOB &&
-   jn->other)
-{
-   Job sjn = &jobtab[jn->other];
-   if (sjn->procs || sjn->auxprocs)
-   {
-   /*
-* A subjob still has process, which must finish before
-* further execution of the superjob, which the user wants to
-* know about.  So report the status of the subjob as if it
-* were the user-visible superjob.
-*/
-   jn = sjn;
-   }
-}
-
 /* find length of longest signame, check to see */
 /* if we really need to print this job  */
 

Bug#1031240: filename on command line gets mangled

[Zefram]

Package: clojure
Version: 1.10.2-1
Severity: normal

The clojure(1) command-line interface is documented to take the filename
of a script to execute.  Here's how well it understands filenames:

$ echo '(println "sadness")' > 'L?on.clj'
$ echo '(println "ennui")' > $'L\xef\xbf\xbdon.clj'
$ echo '(println "joy")' > $'L\xe9on.clj'
$ LC_ALL=C clojure $'L\xe9on.clj'
sadness
$ LC_ALL=de_DE.utf8 clojure $'L\xe9on.clj' 
ennui
$ LC_ALL=de_DE.iso88591 clojure $'L\xe9on.clj'
joy
$

In this example I've created three different script files, with different
but related names, I've told clojure(1) three times to run one of them,
and it's run a different file on each invocation.  In the invocations that
ran the wrong files, one can see via strace(1) that clojure(1) doesn't
use the correct filename for any file operations at all; it completely
substitutes the erroneous filename.  The use of the wrong filename
doesn't depend on the file of that wrong name existing: if there is no
file of that name then clojure(1) will fail to find any script to execute,
and will generate an error message that shows the erroneous filename.

How clojure(1) mangles the script filename on each invocation depends
on the locale implied by the environment, and more specifically on the
character encoding nominated by the LC_CTYPE component of the locale.
Nominating a locale that's not installed behaves the same as nominating
the C locale.  Part of my example above depends on having the de_DE.utf8
and de_DE.iso88591 locales installed.  If you don't have the specific
locales that I used then you can get the same results as me by
substituting an installed locale that nominates the same encoding.

This bug occurs whenever the supplied filename doesn't have the syntax
of locale-nominated encoding of text, containing only Unicode codepoints
of which clojure approves.  The nature of the manglement is that each
subsequence of octets that doesn't look like valid encoded text gets
replaced with one or more instances of a substitute sequence that is
valid encoded text.  Where the locale-nominated encoding is ASCII,
the substitute is '?'.  Where the locale-nominated encoding is UTF-8,
the substitute is the three octets $'\xef\xbf\xbd', which is the UTF-8
encoding of U+fffd "replacement character".

It appears that the supplied filename is being decoded, according
to the locale-nominated encoding, with decoding errors muffled and
a replacement character (U+fffd or "?") silently substituted in,
and then the lossily-decoded filename is re-encoded according to the
locale-nominated encoding, and the result of that process is the filename
that gets actually used.  As far as I can see the manglement comes only
from character decoding: there isn't also any Unicode normalisation.

This could cause a security problem in some circumstances that are only
slightly strange.  Suppose a privileged program is using clojure(1) to
run scripts that partly derive from untrusted user input.  Suppose it
runs with environment settings in which the implied locale nominates an
encoding that isn't an 8-bit single-byte encoding.  Suppose the program
has created an innocuous script to run, has permitted an untrusted user
to determine part of the filename for that script, and has ensured that
the supplied filename is innocuous from a Unix point of view but isn't
preventing the use of filenames with high-half octets.  Suppose further
that an untrusted user can cause the same program to create another file,
of content that the program doesn't intend to execute, under the mangled
name, which is equally innocuous from a Unix point of view.  Then it could
execute code determined by a malicious user, due entirely to clojure(1)
misinterpreting a filename.  I'm not aware of any specific program that
can be exploited in this way, and I haven't based the declared severity
of this bug report on this security issue.

Preferably, clojure(1) should use the script file of the name that was
supplied on the command line.  It must pass to the file syscalls the
same octet string that was supplied as a command line argument, without
assuming anything about its 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

Bug#1031245: wonky current job with suspended shell function

[Zefram]

Package: zsh
Version: 5.8-6+deb11u1
Severity: normal

zsh doesn't correctly set its idea of the current job if a job consists
of a shell function that got suspended after it was started.  This is
the same condition that gives rise to Bug#1030606.  In the example
below I'm using a zsh with the patch that I supplied for that bug.
In a zsh without that patch the bug still occurs in the same way, but
the job status reporting is messed up, making it more difficult to see
what's happening.  Here's what the bug looks like:

% t0 () { sleep 1000; }
% t0
^Zzsh: suspended  t0
% sleep 2000
^Z
zsh: suspended  sleep 2000
% jobs
[1]  - suspended (signal)  t0
[3]  + suspended  sleep 2000
% fg %1
[1]  - continued  t0
^Zzsh: runningt0
% jobs
[1]  - runningt0
[3]  + suspended  sleep 2000
%

Observe that in the final "jobs" listing the current job, marked with "+",
is the "sleep 2000" job, even though the job most recently active was the
"t0" job.  By contrast, here's what correct job control looks like:

% sleep 1000
^Z
zsh: suspended  sleep 1000
% sleep 2000
^Z
zsh: suspended  sleep 2000
% jobs
[1]  - suspended  sleep 1000
[2]  + suspended  sleep 2000
% fg %1
[1]  - continued  sleep 1000
^Z
zsh: suspended  sleep 1000
% jobs
[1]  + suspended  sleep 1000
[2]  - suspended  sleep 2000
%

Getting the current job wrong leads to the previous job (marked with "-")
also going wrong, and it generally impedes the use of these concepts
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