Bug#415292: libgl1-mesa-glx: assertion failure in libGL.so.1
At 2023-01-02T18:54:02+0100, Fabio Pedretti wrote: > upstream bug report was closed with: > "This code has been rewritten since and almost certainly fixed, > closing." Jesus. I'd never trust a claim like that without output from a formal verification suite to confirm it. I think we may have a brogrammer at play. Regards, Branden signature.asc Description: PGP signature
[PATCH] escape hyphens in xterm.man
Hi Thomas,
Congratulations on another xterm release!
There are some instances of hyphens used in a literal context in the
xterm man page that should be escaped for reliable copy and paste. Most
of these are in the names of actions that can be bound to translation
resources.
There are a few others, like the first hyphen in a URL to the new
"bad-utf8" web page of yours being escaped, but not the second one.
Please find attached (1) a diff and (2) the ed script I used to produce
the changes. The ed script was in turn generated by simply running
"grep -n" over the xterm.man source for unescaped hyphens, manually
rejecting cases where an escaped hyphen was unwarranted (e.g., many,
many instances of "UTF-8" and various noun phrases), then replacing the
leading colon and text portion of the matched lines with an ed "s"
command using ex mode in vi. Crude, but the evaluation part took much
longer than the rest.
Let me know if you have any problems with or objections to this
suggestion.
Regards,
Branden
--- xterm-359/xterm.man~ 2020-08-20 21:15:02.521317339 +1000
+++ xterm-359/xterm.man 2020-08-20 22:09:29.134637802 +1000
@@ -848,7 +848,7 @@
Unless overridden by the \fB\-lf\fP option or the \fBlogFile\fP resource:
.RS
.bP
-If the filename is \*(``-\*('', then logging is sent to the standard output.
+If the filename is \*(``\-\*('', then logging is sent to the standard output.
.bP
Otherwise a filename is generated, and
the log file is written to the directory from which \fI\*n\fP is invoked.
@@ -899,7 +899,7 @@
.BI \-lf " filename"
Specify the log filename.
This sets the \fBlogFile\fP resource.
-If set to \*(``-\*('',
+If set to \*(``\-\*('',
\fI\*n\fP writes its log to the standard output.
See the \fB\-l\fP option.
.TP 8
@@ -1233,7 +1233,7 @@
We recommend using
the \fB\-lc\fR option or the \*(``\fBlocale:\ true\fR\*('' resource
in UTF-8 locales when your operating system supports locale,
-or \fB\-en\ UTF-8\fP option or the \*(``\fBlocale:\ UTF-8\fR\*('' resource
+or \fB\-en\ UTF\-8\fP option or the \*(``\fBlocale:\ UTF\-8\fR\*('' resource
when your operating system does not support locale.
.TP 8
.B +u8
@@ -1671,17 +1671,17 @@
mini.\*n_32x32,
mini.\*n_48x48
.bP
-filled-\*n_16x16,
-filled-\*n_32x32,
-filled-\*n_48x48
+filled\-\*n_16x16,
+filled\-\*n_32x32,
+filled\-\*n_48x48
.bP
\*n_16x16,
\*n_32x32,
\*n_48x48
.bP
-\*n-color_16x16,
-\*n-color_32x32,
-\*n-color_48x48
+\*n\-color_16x16,
+\*n\-color_32x32,
+\*n\-color_48x48
.RE
.IP
In either case, \fI\*n\fP allows for adding a \*(``_48x48\*('' to specify the
@@ -1795,37 +1795,37 @@
.TP
keypress
assigns keypresses by default to the
-\fBinsert-seven-bit()\fP and
-\fBinsert-eight-bit()\fP actions.
+\fBinsert\-seven\-bit()\fP and
+\fBinsert\-eight\-bit()\fP actions.
.TP
paging
assigns key bindings to the
-\fBscroll-back()\fP and
-\fBscroll-forw()\fP actions.
+\fBscroll\-back()\fP and
+\fBscroll\-forw()\fP actions.
.TP
popup-menu
assigns mouse-buttons with the \fIcontrol\fP modifier to the popup-menus.
.TP
reset
assigns mouse-button 2
-with the \fImeta\fP modifier to the \fBclear-saved-lines\fP action.
+with the \fImeta\fP modifier to the \fBclear\-saved\-lines\fP action.
.TP
-scroll-lock
-assigns a key-binding to the \fBscroll-lock()\fP action.
+scroll\-lock
+assigns a key\-binding to the \fBscroll\-lock()\fP action.
.TP
select
assigns mouse- and keypress-combinations
to actions which manipulate the selection.
.TP
-shift-fonts
+shift\-fonts
assigns key-bindings to
-\fBlarger-vt-font()\fP and
-\fBsmaller-vt-font()\fP actions.
+\fBlarger\-vt\-font()\fP and
+\fBsmaller\-vt\-font()\fP actions.
.TP
-wheel-mouse
+wheel\-mouse
assigns buttons 4 and 5 with different modifiers to the
-\fBscroll-back()\fP and
-\fBscroll-forw()\fP actions.
+\fBscroll\-back()\fP and
+\fBscroll\-forw()\fP actions.
.RE
.TP 8
.B ptyHandshake\fP (class\fB PtyHandshake\fP)
@@ -2298,7 +2298,7 @@
.TP 8
.B "alternateScroll\fP (class\fB ScrollCond\fP)"
If \*(``true\*('',
-the \fBscroll-back\fP and \fBscroll-forw\fP actions
+the \fBscroll\-back\fP and \fBscroll\-forw\fP actions
send cursor\-up and \-down keys
when \fI\*n\fP is displaying the alternate screen.
The default is \*(``false\*(''.
@@ -2621,7 +2621,7 @@
.IP
With the default value (0),
\fI\*n\fP matches the behavior of DEC's terminals.
-To use all extensions, set all bits, \*(``-1\*('' for example.
+To use all extensions, set all bits, \*(``\-1\*('' for example.
.TP 8
.B "cjkWidth\fP (class\fB CjkWidth\fP)"
Specifies whether \fI\*n\fP should follow
@@ -3452,8 +3452,8 @@
If all of the \fBfaceSize\fP resources are set, then \fI\*n\fP
will use this information to determine the next smaller/larger
TrueType font for the
-\fBlarger-vt-font()\fP and
-\fBsmaller-vt-font()\fP actions.
+\fBlarger\-vt\-font()\fP and
+\fBsmaller\-vt\-font()\fP actions.
If any are not set, \fI\*n\fP will use only the areas of the bitmap fonts.
.TP 8
.B "faceSize1\fP (class\fB FaceSize1\fP)"
@@ -3808,7
Bug#913815: xterm: does not correctly document saveLines default
Package: xterm
Version: 337-1
Severity: normal
Tags: upstream
The man page says *saveLines defaults to 64. But it really defaults to
1024.
Patch attached. It also synchronizes xterm.dat, whatever that is, with
the application defaults file.
-- System Information:
Debian Release: buster/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages xterm depends on:
ii libc6 2.27-8
ii libfontconfig1 2.13.1-2
ii libfreetype62.8.1-2
ii libice6 2:1.0.9-2
ii libtinfo6 6.1+20181013-1
ii libutempter01.1.6-3
ii libx11-62:1.6.7-1
ii libxaw7 2:1.0.13-1+b2
ii libxft2 2.3.2-2
ii libxinerama12:1.1.4-1
ii libxmu6 2:1.1.2-2
ii libxpm4 1:3.5.12-1
ii libxt6 1:1.1.5-1
ii xbitmaps1.1.1-2
Versions of packages xterm recommends:
ii x11-utils 7.7+4
Versions of packages xterm suggests:
pn xfonts-cyrillic
-- no debconf information
Index: xterm-337-quilt/xterm.dat
===
--- xterm-337-quilt.orig/xterm.dat
+++ xterm-337-quilt/xterm.dat
@@ -4,7 +4,7 @@
*iconName: Xterm
*c132: TRUE
*scrollBar: on
-*saveLines:1000
+*saveLines:1024
! This is nonsense: if the xterm has no session management capabilities,
! it is useless, and if it does, it is harmful.
Index: xterm-337-quilt/xterm.man
===
--- xterm-337-quilt.orig/xterm.man
+++ xterm-337-quilt/xterm.man
@@ -1130,7 +1130,7 @@ should not cause the window to be reposi
This option specifies the number of lines to save that have been scrolled
off the top of the screen.
This corresponds to the \fBsaveLines\fP resource.
-The default is \*(``64\*(''.
+The default is \*(``1024\*(''.
.TP 8
.B \-sm
This option, corresponding to the \fBsessionMgt\fR resource,
@@ -4540,7 +4540,7 @@ The default is \*(``false\*(''.
.B "saveLines\fP (class\fB SaveLines\fP)"
Specifies the number of lines to save beyond the top of the screen when a
scrollbar is turned on.
-The default is \*(``64\*(''.
+The default is \*(``1024\*(''.
.TP 8
.B "scrollBar\fP (class\fB ScrollBar\fP)"
Specifies whether or not the scrollbar should be displayed.
Bug#913413: [PATCH] Map Shift+Win to Menu
At 2018-11-13T10:37:20+0100, Łukasz Stelmach wrote: > +// Pressing the Shift+Win (left or right, respectively) acts as Menu > +// while Shift+Win acts as Menu. I don't understand this comment; it seems tautologous. Shouldn't it be more like: // Pressing left or right Win acts as Win, while Shift+Win acts as Menu. ? -- Regards, Branden signature.asc Description: PGP signature
Bug#902555: radeon.4: Some fixes in the manual
At 2018-06-28T11:31:30+0200, Michel Dänzer wrote: > > Please send this kind of change directly upstream to the > amd-...@lists.freedesktop.org list for review, split up into one patch > per logical change. Well, a lot of these changes aren't "logical", they're stylistic. > On 2018-06-27 09:07 PM, Bjarni Ingi Gislason wrote: > > > > Don't begin a sentence with a digit. > > Why not? What's the problem with that? It's considered substandard English style. See, e.g., [1] https://www.editage.com/insights/scientific-writing-avoid-starting-sentences-with-a-number-or-abbreviation The Chicago Manual of Style, which is the preferred style guide of Michael Kerrisk of the Linux Man-Pages Project, is paywalled[2], but my copy of the 14th edition says: §8.9 "At the beginning of a sentence any number that would ordinarily be set in numerals is spelled out, regardless of any inconsistency this may create [...]". Other style guides broadly agree, though they might not be quite as militant about it as Chicago is. > > Add a comma after "e.g.". > > That looks odd to me. It's standard to have the comma. Chicago, 14th ed. again: §5.62 "A comma is usually used after such expressions as _that is_, _namely_, _i.e._, and _e.g._ The punctuation preceding such expressions should be determined by the magnitude of the break in continuity. If the break is minor, a comma should be used. If the break is greater than that signaled by a comma, a semicolon or an em dash may be used, or the expression and the element it introduces may be enclosed in parentheses". [italics replaced by underscore delimeters] I've run into Bjarni in the groff and man-pages projects. He's a detail-oriented style maven after my own heart and I can vouch that his proposed corrections are usually sound ones. [1] ;-) [2] >:( http://www.chicagomanualofstyle.org/16/ch06/ch06_toc.html redirects me to a login screen. -- Regards, Branden signature.asc Description: PGP signature
Bug#880551: xterm: corrections to man page
At 2017-11-07T08:10:40-0500, G. Branden Robinson wrote:
> Here's an updated version of the patch, reverting the de-boldfacing of
> action names (and some token names) in resource translations.
Of course, by sending that I guaranteed I'd find a problem with it.
Here's my next try. The problem with the previous was stuff like this:
\\fP(ti
in many of the resource translation lines.
Third try attached.
--
Regards,
Branden
--- xterm-330/xterm.man 2017-06-18 14:07:02.0 -0400
+++ xterm-330-branden/xterm.man 2017-11-07 08:15:09.462564868 -0500
@@ -61,16 +61,16 @@
.\"
.\" Bulleted paragraph
.de bP
-.ie \n(.IP \(bu 4
-.el.IP \(bu 2
+.ie n .IP \(bu 4
+.el .IP \(bu 2
..
.\" these would be fallbacks for DS/DE,
.\" but groff changed the meaning of the macros.
.de NS
-.ie \n(.sp
-.el.sp .5
-.ie \n(.in +4
-.el.in +2
+.ie n .sp
+.el .sp .5
+.ie n .in +4
+.el .in +2
.nf
.ft C \" Courier
..
@@ -912,7 +912,7 @@
Also, \fI\*n\ \-e\fP is supposed to provide a consistent
functionality for other applications that need to start text-mode
programs in a window, and if \fBloginShell\fP were not ignored, the
-result of ~/.profile might interfere with that.
+result of \(ti/.profile might interfere with that.
.IP
If you do want the effect of \fB\-ls\fP and \fB\-e\fP simultaneously, you
may get away with something like
@@ -1325,9 +1325,9 @@
(the first two are equivalent
since the descriptor follows the last \*(``/\*(''):
.NS 15
--S/dev/pts/123/45
--S123/45
--Sab34
+\-S/dev/pts/123/45
+\-S123/45
+\-Sab34
.NE
.IP
Note that \fI\*n\fP does not close any file descriptor
@@ -1488,13 +1488,13 @@
.bP
.B ptyInitialErase\fP (PIE), along with the
.bP
-\fIstty\fP erase character (^H for backspace, ^? for delete)
+\fIstty\fP erase character (\(haH for backspace, \(ha? for delete)
.RE
.IP
will affect DECBKM. First, \fI\*n\fP obtains the initial \fIerase\fP character:
.RS
.bP
-\fI\*n\fP's internal value is ^H
+\fI\*n\fP's internal value is \(haH
.bP
\fI\*n\fP asks the operating system for the value which \fBstty\fP shows
.bP
@@ -1509,14 +1509,14 @@
_ _ _ _
l c c c.
\fBPIE\fR \fBstty\fR \fBtermcap\fR \fIerase\fP
-false ^H ^H ^H
-false ^H ^? ^?
-false ^? ^H ^H
-false ^? ^? ^?
-true ^H ^H ^H
-true ^H ^? ^H
-true ^? ^H ^?
-true ^? ^? ^?
+false \(haH \(haH \(haH
+false \(haH \(ha? \(ha?
+false \(ha? \(haH \(haH
+false \(ha? \(ha? \(ha?
+true \(haH \(haH \(haH
+true \(haH \(ha? \(haH
+true \(ha? \(haH \(ha?
+true \(ha? \(ha? \(ha?
.TE
.IP
Using that \fIerase\fP character, \fI\*n\fP allows further choices:
@@ -1526,8 +1526,9 @@
character for the initial state of \fBDECBKM\fP
.bP
if \fBbackarrowKeyIsErase\fP is false, \fI\*n\fP sets \fBDECBKM\fP
-to 2 (internal). This ties together \fBbackarrowKey\fP
-and the control sequence for \fBDECBKM\fP
+to 2 (internal).
+This ties together \fBbackarrowKey\fP and the control sequence for
+\fBDECBKM\fP.
.bP
applications can send a control sequence to set/reset \fBDECBKM\fP control set
.bP
@@ -1540,14 +1541,14 @@
_ _ _ _ _
c l l c c.
\fIerase\fR \fBBKIE\fR \fBBK\fR \fBDECBKM\fP \fIresult\fP
-^? false false 2 ^H
-^? false true 2 ^?
-^? true false 0 ^?
-^? true true 1 ^?
-^H false false 2 ^H
-^H false true 2 ^?
-^H true false 0 ^H
-^H true true 1 ^H
+\(ha? false false 2 \(haH
+\(ha? false true 2 \(ha?
+\(ha? true false 0 \(ha?
+\(ha? true true 1 \(ha?
+\(haH false false 2 \(haH
+\(haH false true 2 \(ha?
+\(haH true false 0 \(haH
+\(haH true true 1 \(haH
.TE
.TP 8
.B "fullscreen\fP (class\fB Fullscreen\fP)"
@@ -1911,17 +1912,18 @@
susp,
swtch and
weras.
-Control characters may be specified as ^char (e.g., ^c or ^u)
-and \fB^?\fP may be used to indicate delete (127).
-Use \fB^\-\fP to denote \fIundef\fP.
-Use \fB\\034\fP to represent \fB^\\\fP, since a literal backslash in
+Control characters may be specified as \fB\(ha\fPchar
+(e.g., \fB\(hac\fP or \fB\(hau\fP)
+and \fB\(ha?\fP may be used to indicate delete (127).
+Use \fB\(ha\-\fP to denote \fIundef\fP.
+Use \fB\e034\fP to represent \fB\(ha\e\fP, since a literal backslash in
an X resource escapes the next character.
.IP
This is very useful for overriding
the default terminal settings without having to do an \fIstty\fP every time
an \fI\*n\fP is started.
Note, however, that the \fIstty\fP program on a given host may use different
-keywords; \fI\*n\fR's table is built-in.
+keywords; \fI\*n\fR's table is built in.
.IP
If the \fBttyModes\fP resource specifies a value for \fBerase\fP,
that overrides the \fBptyInitialErase\fP resource setting,
@@ -2443,7 +2445,7 @@
.B "charClass\fP (class\fB CharClass\fP)"
Specifies comma-separated lists of character class bindings of the form
.NS
-\fIlow\fP[-\fIhigh]\fP[:\fIvalue\fP].
+\fIlow\fP[\-\fIhigh]\fP[:\fIvalue\fP].
.NE
.IP
These are used in determining which
@@ -3064,9 +3066,9 @@
.IP
It is possible to select suitable bitmap fonts using a script such as this:
.NS
-\
<
Bug#880551: xterm: corrections to man page
Here's an updated version of the patch, reverting the de-boldfacing of
action names (and some token names) in resource translations.
My additional fixes are described at the end, numbered 21-25.
Please find two attachments:
1. The actual diff.
2. A diff of the nroffed output of the two pages prepared like this:
nroff -ww -man $DIR/xterm.man | colcrt -
This makes it _much_ easier to see what all my patches were up to, and
also serves as a bit of a sanity check.
Note that (a) I'm using a UTF-8 environment, so the nroff output and
diffs reflect that (it also helps expose the hyphen-minus fix) and (b) I
cheated out the whitespace changes resulting from the fixed conditionals
in the page local macros bP and NS.
--
Regards,
Branden
01. The local macro definitions for bP and NS were testing the values of
registers which were likely to be undefined; e.g.
"./xterm-330/xterm.man:64: warning: number register `.I' not defined"
Make them test instead simply for "n" (nroff mode, as opposed to
troff mode), since that appears to be the intention.
02. Use the \(ha, \(ga, and \(ti character escapes instead of ^`~
literals, since these produce full-sized spacing glyphs instead of
small ones intended as combining characters on troff output devices.
03. Use \- character escape in examples, URLs, and other literal
contexts when an ASCII "hyphen-minus" is intended; ensures that
the correct glyph can be cut and pasted from the man page both from
TTY and PDF output devices.
04. Apply font markup to "Control characters may be specified as ^char
(e.g., ^c or ^u)", consistently with the ensuing discussion.
05. Minor style fix: "the feature is built in" vs. "the program's
built-in features".
06. Remove no-op zero-width space character escapes from the xfontsel
example.
07. Add linebreaks after sentences that had only one space between them
and the succeeding sentence, so the roff system recognizes them as
separate sentences and pads ("adjusts") the line appropriately.
(ca. lines 3389, 5382, ...)
08. Remove trailing whitespace from the ends of input lines.
09. Convert several uses of bare `` and '' to use the page's local
string defines, for consistency with the rest of the page.
[item 10 reverted]
11. Remove trailing "\n\" from the BtnUp select-end example; it didn't
seem necessary and the \ was syntactically meaningful to
roff so it didn't get rendered as expected and caused a warning:
"./xterm-330/xterm.man:5033: warning: number register `.' not defined"
It also turned off fill mode outside of the examples for a few
paragraphs, making the output ugly.
12. "etc" is an abbreviation that gets a period.
13. Join two really short input lines ca. line 5029 (about
triple-clicking).
14. Use the local AQ string definition instead of bare 's in printf
examples, for correct appearance and more successful cut and
pasting.
15. In the big default charClass table, use a dingbat asterisk at the
end of the C comment for symmetry with the beginning, which already
uses one.
16. Rewrite the upper half of the charClass table so it depicts the
actual (printable) glyphs in \x80-\xff. What was there was largely
incomprehensible to me.
17. Use character escape '\e' instead of '\\' in resource translation
examples. '\\' does not render as desired and makes the examples
wrong. (\(rs would be more strictly correct than \e, but is a
groffism; \e is not an invariant glyph reference but instead means
"whatever the current roff escape character is"; fortunately, most
man pages do not change the escape character. Traditional roff
does not have a character escape for the "reverse solidus".)
18. The translation examples also don't need zero-width spaces (\&) at
the ends of the input lines; this is a no-op. Remove them.
19. Unindent the examples for the VT100 and Tektronix default
translations by one space since some of the lines are very wide.
One space was all the room available given the existing alignment.
If desired, I can prepare a patch to step the font size down by
a point or two, though this will not help TTY-like devices.
20. Fix missing word: "you could add a binding [to] shifted keys".
21. Add missing period to end of sentence ca. line 1526.
22. Break a really, really long input line ca. line 5162.
23. Set names of selection tokens in bold, not italics, ca. line
6362, for consistency with the rest of the page.
24. Set names of CUT_BUFFER selection token in bold as well, in
resource translation examples, ca. lines 6898, 6979, and 7023.
25. Grammar: Change a "not" to a "nor" ca. line 7150.
--- xterm-330/xterm.man 2017-06-18 14:07:02.0 -0400
+++ xterm-330-branden/xterm.man 2017-11-07 07:23:38.195647033 -0500
@@ -61,16 +61,16 @@
.\"
.\" Bulleted paragraph
.de bP
-.ie \n(.IP
Bug#880551: xterm: corrections to man page
At 2017-11-06T18:51:32-0500, Thomas Dickey wrote: > > > > 10. Remove boldfacing from portions of code examples; these escapes > > > > changed the font family back to Times from Courier. If this change > > > > is unacceptable, I can come up with one that will stay within the > > > > Courier family, but it will only work for groff. I don't know of > > > > a portable way to do what I think is desired here. > > > > > > This is a problem, since I'm using the boldface to guide > > > a script which generates the hyperlinks here: > > > > > > https://invisible-island.net/xterm/manpage/xterm.html > > > > > > The \fP's should have done what was needed to restore the font-family... > > > > Ah. I'll revert that part for my next patch submission, than. > > thanks :-) I note that PRIMARY, SELECT, and CLIPBOARD all get the boldface treatment, but CUT_BUFFER[01] do not. Would you like me to bold these as well for consistency and potential future documentation, or leave them alone? > fwiw, I wrote a script yesterday which compares the copies of the > macros with a reference version (thinking of ncurses). Of course! Once you've done it right once, automate it! :D -- Regards, Branden signature.asc Description: PGP signature
Bug#880551: xterm: corrections to man page
At 2017-11-05T15:11:13-0500, Thomas Dickey wrote: > On Thu, Nov 02, 2017 at 02:20:54AM -0400, G. Branden Robinson wrote: > > 10. Remove boldfacing from portions of code examples; these escapes > > changed the font family back to Times from Courier. If this change > > is unacceptable, I can come up with one that will stay within the > > Courier family, but it will only work for groff. I don't know of > > a portable way to do what I think is desired here. > > This is a problem, since I'm using the boldface to guide > a script which generates the hyperlinks here: > > https://invisible-island.net/xterm/manpage/xterm.html > > The \fP's should have done what was needed to restore the font-family... Ah. I'll revert that part for my next patch submission, than. I think the problem comes down to restoring font style versus restoring for family _and_ style. A distinction without a difference on the Graphic Systems CAT with only 4 positions and that was it... -- Regards, Branden signature.asc Description: PGP signature
Bug#880551: xterm: corrections to man page
Hi Thomas, At 2017-11-02T04:55:25-0400, Thomas Dickey wrote: > thanks - someone reported a problem with the same macro in ncurses. > (I'll have to make a script to check for other instances, since I've > used bullets in a lot of places - I've a to-do item for that anyway). Thanks to a bug in gropdf, I discovered a problem with the patch in this part: 17. Use character escape '\e' instead of '\\' in resource translation examples. '\\' does not render as desired and makes the examples wrong. The \\ problem is indeed a problem but my fix was wrong thanks to: https://savannah.gnu.org/bugs/index.php?51568 Once I have it ready, would you prefer a whole new diff against xterm-330, or something else? -- Regards, Branden signature.asc Description: PGP signature
Bug#880551: xterm: corrections to man page
At 2017-11-02T04:55:25-0400, Thomas Dickey wrote: > thanks - someone reported a problem with the same macro in ncurses. > (I'll have to make a script to check for other instances, since I've > used bullets in a lot of places - I've a to-do item for that anyway). Yeah, I've noticed those. When I read over the ncurses man pages I get all kinds of ideas... ;-) > For the rest, I'll pick through in case there's something I find > that's an unnecessary groffism (but likely will just apply most/all of the > change). I tried not to introduce any; I know you're concerned with broad portability, especially to legacy systems. > > Make them test instead simply for "n" (nroff mode, as opposed to > > troff mode), since that appears to be the intention. > > > > 02. Use the \(ha, \(ga, and \(ti character escapes instead of ^`~ > > literals, since these produce full-sized spacing glyphs instead of > > small ones intended as combining characters on troff output devices. > > > > 03. Use \- character escape in (especially in examples) when an ASCII > > "hyphen-minus" is intended; ensures that the correct glyph can be > > cut and pasted from the man page both from TTY and PDF output > > devices. > > :-) > > It would have been nice if groff hadn't reversed common usage here. I didn't realize that was the case. My battered old copy of _Unix Text Processing_ (Dougherty, O'Reilly) doesn't really cover these matters. (Its explanation of \- is simply "the minus sign in the _current_ font", emphasis in original.) There simply isn't much discussion of spacing vs. combining glyphs. Also, I noted that your definition of NS and NE complains about groff not offering DS and DE (display start and end). As far as my limited awareness goes, displays were never part of anyone's man macros; they were part of both ms and mm, though. GNU roff's man has EX and EE, but notes that not all legacy systems' man macros had them. However, the GNU folks seemed to believe they did not originate these macros themselves. Let me know if I can be of any help. -- Regards, Branden signature.asc Description: PGP signature
Bug#880551: xterm: corrections to man page
Package: xterm
Version: 327-2 (but I prepared the diff against xterm-330)
Severity: normal
Tags: upstream
Hi Thomas,
Here's a patch for various markup bugs and inconsistencies in the xterm
man page.
01. The local macro definitions for bP and NS were testing the values of
registers which were likely to be undefined; e.g.
"./xterm-330/xterm.man:64: warning: number register `.I' not defined"
Make them test instead simply for "n" (nroff mode, as opposed to
troff mode), since that appears to be the intention.
02. Use the \(ha, \(ga, and \(ti character escapes instead of ^`~
literals, since these produce full-sized spacing glyphs instead of
small ones intended as combining characters on troff output devices.
03. Use \- character escape in (especially in examples) when an ASCII
"hyphen-minus" is intended; ensures that the correct glyph can be
cut and pasted from the man page both from TTY and PDF output
devices.
04. Apply font markup to "Control characters may be specified as ^char
(e.g., ^c or ^u)", consistently with the ensuing discussion.
05. Minor style fix: "the feature is built in" vs. "the program's
built-in features".
06. Remove no-op zero-width space character escapes from the xfontsel
example.
07. Add linebreaks after sentences that had only one space between them
and the succeeding sentence, so the roff system recognizes them as
separate sentences and pads ("adjusts") the line appropriately.
08. Remove trailing whitespace from the ends of input lines.
09. Convert several uses of bare `` and '' to use the page's local
string defines, for consistency with the rest of the page.
10. Remove boldfacing from portions of code examples; these escapes
changed the font family back to Times from Courier. If this change
is unacceptable, I can come up with one that will stay within the
Courier family, but it will only work for groff. I don't know of
a portable way to do what I think is desired here.
11. Remove trailing "\n\" from the BtnUp select-end example; it didn't
seem necessary and the \ was syntactically meaningful to
roff so it didn't get rendered as expected and caused a warning:
"./xterm-330/xterm.man:5033: warning: number register `.' not defined"
It also turned off fill mode outside of the examples for a few
paragraphs, making the output ugly.
12. "etc" is an abbreviation that gets a period.
13. Join two really short input lines about triple-clicking.
14. Use the local AQ string definition instead of bare 's in printf
examples, for correct appearance and more successful cut and
pasting.
15. In the big default charClass table, use a dingbat asterisk at the
end of the C comment for symmetry with the beginning, which already
uses one.
16. Rewrite the upper half of the charClass table so it depicts the
actual (printable) glyphs in \x80-\xff. What was there was largely
incomprehensible to me.
17. Use character escape '\e' instead of '\\' in resource translation
examples. '\\' does not render as desired and makes the examples
wrong. (\(rs would be more strictly correct than \e, but is a
groffism; \e is not an invariant glyph reference but instead means
"whatever the current roff escape character is"; fortunately, most
man pages do not change the escape character. Traditional roff does
not have a character escape for the "reverse solidus".)
18. The translation examples also don't need zero-width spaces (\&) at
the ends of the input lines; this is a no-op. Remove them.
19. Unindent the examples for the VT100 and Tektronix default
translations by one space since some of the lines are very wide.
One space was all the room available given the existing alignment.
If desired, I can prepare a patch to step the font size down by
a point or two, though this will not help TTY-like devices.
20. Fix missing word: "you could add a binding [to] shifted keys".
-- System Information:
Debian Release: 9.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages xterm depends on:
ii libc6 2.24-11+deb9u1
ii libfontconfig1 2.11.0-6.7+b1
ii libice6 2:1.0.9-2
ii libtinfo5 6.0+20161126-1+deb9u1
ii libutempter01.1.6-3
ii libx11-62:1.6.4-3
ii libxaw7 2:1.0.13-1+b2
ii libxft2 2.3.2-1+b2
ii libxinerama12:1.1.3-1+b3
ii libxmu6 2:1.1.2-2
ii libxpm4 1:3.5.12-1
ii libxt6 1:1.1.5-1
ii xbitmaps1.1.1-2
Versions of packages xterm recommends:
ii x11-utils 7.7+3+b1
Versions of packages xterm suggests:
pn xfonts-cyrillic
-- no debconf information
--
Regards,
Branden
Bug#869773: xdm logs failed logins that may be sensitive
At 2017-07-26T11:51:10+0200, Nicolas George wrote:
> Package: xdm
> Version: 1:1.1.11-3
> Severity: normal
>
> Dear Maintainer,
>
> When somebody tries to log in and fails, xdm writes the given user name in
> the system logs. Unfortunately, typing the password in the login field is a
> common mistake. When that happens, xdm logs it too. That leaves the
> password of an user in clear in the system logs. It is not very
> important, but still a little security concern since normally passwords
> are stored permanently on the system only in hashed form.
>
> The corresponding log line looks like this:
>
> Jul 26 11:32:31 hellroy xdm[1004]: LOGIN FAILURE ON :0, XXX
>
> (I have redacted the login that was actually a password.)
>
> It may be better to not log it at all, or maybe only log it when it matches
> an actual login name.
Hmm, yes, that's bad.
Here's a quick-and-dirty, untested patch. I didn't even compile-test it
because I can't get stock xdm to build on my Debian Stretch system. The
xdm codebase is choked with bad style (unused results, discarded
qualifiers) that causes the compile to bomb long before it gets to
greet.c.
"Somebody should do something about that," he said, peering around a
corner into a mirror.
Regards,
Branden
--- xdm-1.1.11/greeter/greet.c.orig 2017-07-28 14:20:44.649055209 -0400
+++ xdm-1.1.11/greeter/greet.c 2017-07-28 14:21:09.812798680 -0400
@@ -405,12 +405,9 @@
FailedLogin (struct display *d, const char *username)
{
#ifdef USE_SYSLOG
-if (username == NULL)
- username = "username unavailable";
-
syslog(LOG_AUTHPRIV|LOG_NOTICE,
- "LOGIN FAILURE ON %s, %s",
- d->name, username);
+ "LOGIN FAILURE ON %s",
+ d->name);
#endif
DrawFail (login);
}
signature.asc
Description: PGP signature
Re: ANN: xterm-329
At 2017-06-12T19:34:17+0200, Sven Joachim wrote:
> Debian unstable i386, but I get the same error on amd64.
>
> > XTerm 329 builds fine for me on Debian 9 amd64.
>
> Maybe you have configured with --enable-regis-graphics? This makes the
> problem go away.
Only if it's the default. I configured only with --prefix=$HOME.
> I have attached a full build log for reference.
Me too.
Regards,
Branden
Script started on Mon Jun 12 13:35:34 2017
$ ./configure --prefix=$HOME && make
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
Configuring for linux-gnu
checking for gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for executable suffix...
checking for object suffix... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking version of gcc... 6.3.0
checking for gcc option to accept ANSI C... none needed
checking $CC variable... ok
checking how to run the C preprocessor... gcc -E
checking for mawk... mawk
checking for a BSD compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking for lint... no
checking for cppcheck... no
checking for splint... no
checking if we must define _GNU_SOURCE... yes
checking if we should also define _DEFAULT_SOURCE... yes
checking if _XOPEN_SOURCE really is set... yes
checking if SIGWINCH is defined... yes
checking for ncurses/curses.h... no
checking for ncurses/term.h... no
checking for stdlib.h... yes
checking for sys/ptem.h... no
checking for sys/ttydefaults.h... yes
checking for term.h... yes
checking for termios.h... yes
checking for unistd.h... yes
checking for wchar.h... yes
checking whether time.h and sys/time.h may both be included... yes
checking for nl_langinfo and CODESET... yes
checking for signal global datatype... volatile sig_atomic_t
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... (cached) yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... (cached) yes
checking for time_t... yes
checking for cc_t in or ... yes
checking for mode_t... yes
checking for pid_t... yes
checking for uid_t in sys/types.h... yes
checking for off_t... yes
checking for gethostname... yes
checking for getlogin... yes
checking for initgroups... yes
checking for mkdtemp... yes
checking for putenv... yes
checking for unsetenv... yes
checking for sched_yield... yes
checking for setpgid... yes
checking for strftime... yes
checking for tcgetattr... yes
checking for waitpid... yes
checking for wcswidth... yes
checking for wcwidth... yes
checking for lastlog.h... yes
checking for paths.h... yes
checking for lastlog path... _PATH_LASTLOG
checking for utmp implementation... utmp
checking if utmp.ut_host is declared... yes
checking if utmp.ut_syslen is declared... no
checking if utmp.ut_name is declared... ut_name
checking for exit-status in utmp... ut_exit.e_exit
checking if utmp.ut_xtime is declared... yes
checking if utmp.ut_session is declared... yes
checking if utmp is SYSV flavor... yes
checking for lastlog.h... (cached) yes
checking for struct lastlog... no
checking for sys/param.h... yes
checking if POSIX saved-ids are supported... yes
checking if we want full tgetent function... yes
checking for full tgetent function... no
checking for partial tgetent function... -ltermcap
checking for termcap.h... yes
checking for X applications class... XTerm
checking for directory to install resource files...
${exec_prefix}/lib/X11/app-defaults
checking for the icon name... xterm-color
checking for icon symlink to use... NONE
checking for directory to install pixmaps... ${datadir}/pixmaps
checking for directory to install icons... no
checking if icon theme should be used... no
checking for icon(s) to install... icons/xterm-color_48x48.xpm
checking for icon name... xterm-color
checking if you want to install desktop files... yes
checking for desktop-file-install... yes
checking for requested desktop-category... auto
checking for install-permissions reference... xterm
checking for PATH separator... :
checking for xterm... /usr/bin/xterm
checking for symbolic link to create to xterm... xterm
checking if you want to disable openpty... no
checking if you want to disable setuid... no
checking if you want to disable setgid... no
checking if you want to run xterm setuid to a given user... no
checking if you want to run xterm setgid to match utmp/utmpx file... no
checking if you want to link with utempter... no
checking if external errno is declared... yes
checking if external errno exists... no
checking for explicit tty group name... auto...
checking for tty group name... tty
checking if we may use the tty group... yes
checking for sys/wait.h that is POSIX.1 compatible... yes
Re: ANN: xterm-329
At 2017-06-12T18:48:37+0200, Sven Joachim wrote:
> This does not build for me:
>
> ,
> | gcc -I. -I.. -DHAVE_CONFIG_H -Wdate-time -D_FORTIFY_SOURCE=2
> -DDEF_ALLOW_FONT=False -DDEF_ALLOW_TCAP=False
> -DDEF_DISALLOWED_WINDOW=\"1,2,3,4,5,6,7,8,9,11,13,14,18,19,20,21,GetSelection,SetSelection,SetWinLines,SetXprop\"
> -D_GNU_SOURCE -D_DEFAULT_SOURCE -DNARROWPROTO=1 -DFUNCPROTO=15
> -DOSMAJORVERSION=4 -DOSMINORVERSION=11 -I/usr/include/freetype2
> -DDEFCLASS=\"XTerm\" -g -O2
> -fdebug-prefix-map=/usr/local/src/deb-src/xterm/xterm=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wall -c ../misc.c
> | ../charproc.c: In function 'doparsing':
> | ../charproc.c:3703:23: error: 'TScreen {aka struct }' has no
> member named 'graphics_regis_def_wide'; did you mean 'graphics_max_wide'?
> | result = screen->graphics_regis_def_wide;
> |^~
> | ../charproc.c:3704:24: error: 'TScreen {aka struct }' has no
> member named 'graphics_regis_def_high'; did you mean 'graphics_max_high'?
> | result2 = screen->graphics_regis_def_high;
> | ^~
> | Makefile:131: recipe for target 'charproc.o' failed
> | make[2]: *** [charproc.o] Error 1
You might want to share some info about your environment.
XTerm 329 builds fine for me on Debian 9 amd64.
Regards,
Branden
signature.asc
Description: PGP signature
Bug#859929: x11-common: unowned files after upgrade from jessie to stretch and purge: /etc/X11/Xwrapper.config
At 2017-04-23T11:45:03+0200, Julien Cristau wrote: > The wrapper was moved to the xserver-xorg-legacy package, and I'm a bit > worried removing the configuration file in the x11-common maintainer > scripts would break that transition. Ahhh. Did we never get solid support in dpkg for migrating conffiles? That was painful enough back in the XFree86 days that I remember it still. Regards, Branden
Bug#859929: x11-common: unowned files after upgrade from jessie to stretch and purge: /etc/X11/Xwrapper.config
At 2017-04-09T13:34:44+0200, Andreas Beckmann wrote: > 1m37.2s INFO: Warning: Package purging left files on system: > /etc/X11/Xwrapper.config not owned It appears the old Xwrapper was killed off at some point. The patch should be trivial enough that I can do it. This would also serve as an exercise of branden-guest's permissions on alioth. Any objection? Regards, Branden signature.asc Description: PGP signature
Bug#858304: vim-runtime: markdown syntax highlighting (and possibly others) goes crazy and drives the terminal crazy
At 2017-04-07T12:08:58-0400, James McCoy wrote: > On Fri, Apr 07, 2017 at 07:23:39AM -0400, G. Branden Robinson wrote: > > However, my xterms are somewhat customized. I'm attaching my > > .Xresources file. > > Perfect! That seems to be the difference. I, and presumably Francesco, aren't > using TTF fonts. If I change your Xresources to use > > XTerm.*.VT100.Font: > -misc-fixed-medium-r-normal--18-120-100-100-c-90-iso10646-1 > > instead of the FaceName/FaceSize resources, then playing the recording > reproduces the problem. I agree that we're narrowing it down. I commented out my *.face* resources, xrdb -merged .Xresources, ran xterms from other xterms, and got some intriguing stuff on stderr. $ xterm xterm: cannot load font '-Misc-Fixed-Bold-o-*-*-13-120-75-75-C-60-ISO10646-1' $ xterm -fn '-misc-fixed-medium-r-normal--18-120-100-100-c-90-iso10646-1' xterm: cannot load font '-Misc-Fixed-Medium-o-*-*-18-120-100-100-C-90-ISO10646-1' xterm: cannot load font '-Misc-Fixed-Bold-o-*-*-18-120-100-100-C-90-ISO10646-1' xterm: cannot load font '-Misc-Fixed-Medium-o-*-*-18-120-100-100-C-180-ISO10646-1' xterm: cannot load font '-Misc-Fixed-Medium-o-*-*-18-120-100-100-C-180-ISO10646-1' To me, this implicates something at or near the bold font emulation stuff that xterm does. This may be enough for Thomas Dickey to locate the bug. There's some pretty complicated logic involved; from xterm(1): alwaysBoldMode (class AlwaysBoldMode) Specifies whether xterm should check if the normal and bold fonts are distinct before deciding whether to use overstriking to simulate bold fonts. If this resource is true, xterm does not make the check for distinct fonts when deciding how to handle the boldMode resource. The default is "false". boldMode alwaysBoldMode Comparison Action false falseignored use font false true ignored use font true falsesame overstrike true falsedifferentuse font true true ignored overstrike This resource is used only for bitmap fonts: · When using bitmap fonts, it is possible that the font server will approximate the bold font by rescaling it from a different font size than expected. The alwaysBoldMode resource allows the user to override the (sometimes poor) resulting bold font with overstriking (which is at least consistent). · The problem does not occur with TrueType fonts (though there can be other unnecessary issues such as different coverage of the normal and bold fonts). As an alternative, setting the allowBoldFonts resource to false overrides both the alwaysBoldMode and the boldMode resources. Regards, Branden signature.asc Description: PGP signature
Bug#858304: vim-runtime: markdown syntax highlighting (and possibly others) goes crazy and drives the terminal crazy
At 2017-04-06T21:56:13-0400, James McCoy wrote:
> On Fri, Apr 07, 2017 at 12:54:19AM +0200, Francesco Poli wrote:
> > On Thu, 6 Apr 2017 15:06:17 -0400 G. Branden Robinson wrote:
> >
> > > At 2017-04-06T13:33:58-0400, James McCoy wrote:
> > > > On Thu, Apr 06, 2017 at 01:17:55PM -0400, G. Branden Robinson wrote:
> > > > > The below is not a sufficient reproduction receipe for me.
> > > > >
> > > > > I'm running Debian Stretch (testing).
> > > > >
> > > > > Things do not go wrong at step #5, nor afterward.
> > > >
> > > > Make sure the terminal is sized small enough (80x24). That causes the
> > > > syntax highlighting in Vim to get a little confused and enable some bold
> > > > highlighting, which then causes the visual bell to turn everything bold.
> > >
> > > It was.
> >
> > Hello Branden!
> > Thanks for trying to reproduce the bug.
> >
> > Does it help to know that I have:
> >
> > xset b off
> >
> > in my ~/.xsession script?
>
> I don't think that's relevant. My bell is on. I was also able to
> reproduce it without causing the bell.
>
> I've attached an asciinema recording of me reproducing the problem.
> When I replay the recording, it causes the same problem to the xterm in
> which it is running, so hopefully this helps debug the problem.
That's really interesing. I _still_ can't repro this, even playing back
James's demo with asciinema--a tool of which I wasn't aware, thanks!
I'm launching xterm in GNOME with the GNOME command runner, whatever
that's called--the Alt+F2 thing.
However, my xterms are somewhat customized. I'm attaching my
.Xresources file.
Regards,
Branden
XTerm.PtyInitialErase: true
XTerm.TermName: xterm-256color
XTerm.ToolBar: false
! From xterm(1):
!
! If your xterm is configured to support the “toolbar”, then those patterns need
! an extra level for the form-widget which holds the toolbar and vt100 widget.
! A wildcard between the top-level “XTerm” and the “vt100” widget makes the
! resource settings work for either, e.g., “XTerm*vt100.NAME”.
XTerm.*.VT100.Background: gray10
XTerm.*.VT100.FaceName: FreeMono
! Set FaceSize big, but small enough for 165x50 text on a 1898x1143 root window.
! 14 would work, but underscores (_) do not render at all in FreeMono on Debian
! Stretch. (See < http://bugs.debian.org/858142 >).
! XXX: You can''t have unpaired apostrophes in X resource comment lines? When
! did that happen?
XTerm.*.VT100.FaceSize: 13
XTerm.*.VT100.Foreground: gray90
XTerm.*.VT100.VisualBell: true
! Keep left Alt working as a Meta key, while letting right Alt work as an
! AltGr key under the following X configuration:
! xkb_keymap {
! xkb_keycodes { include "evdev+aliases(qwerty)" };
! xkb_types { include "complete" };
! xkb_compat{ include "complete" };
! xkb_symbols { include
"pc+us(altgr-intl)+us:2+us:3+inet(evdev)+level3(ralt_switch)+compose(caps)+terminate(ctrl_alt_bksp)"
};
! xkb_geometry { include "hhk(basic)"};
! };
XTerm.*.VT100.MetaSendsEscape: true
! vim:set ai et sw=4 ts=4 tw=80:
signature.asc
Description: PGP signature
Bug#858304: vim-runtime: markdown syntax highlighting (and possibly others) goes crazy and drives the terminal crazy
At 2017-04-06T13:33:58-0400, James McCoy wrote: > On Thu, Apr 06, 2017 at 01:17:55PM -0400, G. Branden Robinson wrote: > > The below is not a sufficient reproduction receipe for me. > > > > I'm running Debian Stretch (testing). > > > > Things do not go wrong at step #5, nor afterward. > > Make sure the terminal is sized small enough (80x24). That causes the > syntax highlighting in Vim to get a little confused and enable some bold > highlighting, which then causes the visual bell to turn everything bold. It was. Would it help for me to record a short video and add it to the bug? Regards, Branden signature.asc Description: PGP signature
Re: Bug#858304: vim-runtime: markdown syntax highlighting (and possibly others) goes crazy and drives the terminal crazy
The below is not a sufficient reproduction receipe for me. I'm running Debian Stretch (testing). Things do not go wrong at step #5, nor afterward. At 2017-04-05T22:03:50-0400, James McCoy wrote: > On Mon, Mar 20, 2017 at 10:29:20PM +0100, Francesco Poli (wintermute) wrote: > > I finally found a reliable way to reproduce it. > > > > Steps to reproduce: > > > > 0) open the attached test.md file: > > > > $ vim -u NONE test.md > > > > 1) enable syntax highlighting: > > > > :set bg=dark > > :syn on > > > > 2) go to the end of the file: > > > > [Shift+G] > > > > 3) go back to the beginning of the file (line by line): > > > > [k].[k] ← hold the key pressed until you reach the first line > > > > 4) visualize file info on the status line: > > > > [Ctrl+G] > > > > 5) the syntax highlighting has gone crazy (even the status line is > > in boldface!): see the attached screenshot > > wrong_vim_syntaxmarkdown.png > > > > 6) exit from vim: > > > > :q > > > > 7) the terminal (xterm), or rather the shell (bash), has also gone > > crazy (it now prints everything in boldface by default): see > > the attached screenshot > > wrong_vim_syntaxmarkdown2.png > > > > 8) the terminal won't come back to normal behavior until I quit it; > > another trick to regain the normal behavior of the terminal is > > opening test.md again, enable syntax highlighting, and exit vim > > (steps 0, 1, and 6 above) Regards, Branden signature.asc Description: PGP signature
Bug#706114: xfonts-utils: insufficient zlib1g dependency
This bug has been marked as needing help for a while.
Guillem Jover wrote:
> On Thu, 2013-04-25 at 14:51:29 +0200, Andreas Beckmann wrote:
> On 2013-04-25 10:39, Guillem Jover wrote:
> > > I guess the correct solution though, is to change update-fonts-*
> > > and any other script in xfonts-utils calling mkfont* from other
> > > maintainer scripts, to only run if xfonts-utils itself is
> > > configured or being configured, and calling these through
> > > xfonts-utils maintainer scripts too, so that if xfonts-utils and
> > > something else using it like gsfonts-x11 are both unpacked on the
> > > same run, the actual update-fonts-* executions will be delayed
> > > until xfonts-utils is itself configured, at which point the
> > > scripts should be able to run. I don't think this would be much
> > > more difficult to prepare.
> >
> > Sounds like a job for triggers (but there is currently a dpkg bug
> > that causes it to run triggers for packages that are not configured
> > (or their dependencies are not)
>
> Right, sorry, I didn't mention triggers exactly for that reason.
> Although this one should be easier to switch during jessie, as these
> packages do not need to await processing from xfonts-utils, which
> should avoid the cycles that enable that bug.
Well, it's been four years and the Stretch release is coming up. Sounds
like it's a good time to get this fixed.
update-fonts-{scale,alias} only manipulate text files so the only issue
here is update-fonts-dir (which calls mkfontdir, a simple script which
execs-with-flags mkfontscale, which links against libfontenc.so.1, which
links against zlib1g (whew!), which might not be configred when
update-fonts-dir is called.
I've never had to write dpkg triggers before but I'm happy to learn (and
I've glanced over the lengthy design doc).
If I understand the discussion, then I propose:
1) To convert xfonts-utils postinst and postrm update-fonts-dir calls
to dpkg triggers;
2) To add a note in update-fonts-dir's manpage pointing out the issue;
3) Submit a patch to dh_installxfonts in debhelper once part (1) above
is shown to be robust.
Comments?
--
Regards,
Branden
Re: How to set up a supplementary xorg.conf Device section
On Tue, Mar 21, 2017 at 11:59:09AM +0900, Michel Dänzer wrote: > Just modify or create /etc/X11/xorg.conf directly. The xorg.conf.d > mechanism is for snippets shipped in packages. [...] > The identifier doesn't matter, it would only be used for referring to > the Section "Device" from other sections in the configuration. [...] > Looks like that should just work. Thanks, Michel. Testing was successful and I followed up to the bug. Regards, Branden
How to set up a supplementary xorg.conf Device section (was: Bug#858142: xterm: ASCII underscore does not render when using -fa FreeMono -fs 14)
[redirecting side topic to mailing list] On Mon, Mar 20, 2017 at 08:56:58PM +0100, Sven Joachim wrote: > On 2017-03-20 15:18 -0400, G. Branden Robinson wrote: > > > I'm at a loss, then. As you originally suspected, maybe it is a > > graphics driver issue. Attaching Xorg.log[2]. > > Apparently you have an Intel GPU and use the modesetting(4) driver (the > default). You could try to disable acceleration > (Option "AccelMethod" "none" in xorg.conf) or use the intel driver > (cp /usr/share/doc/xserver-xorg-video-intel/xorg.conf /etc/X11), and see > if that makes a difference. I beg your indulgence. If you don't have it to spare, just tell me to JFGI and I will, but I see some humor and irony in my situation. Plus I like reconnecting with old Debian colleagues. I don't precisely know how to do this. I've never had to actually fight with a modularized xorg.conf file before. I have, however, consulted xorg.conf(5) and modesetting(4). Here's what I think I need to do: 1) Create /etc/X11/xorg.conf.d. (done) 2) Write a file to put in there. (in progress) 3) Restart the X server. I enabled zapping[1] so this is easy. The problem is that an Identifier is mandatory for the Device Section I am writing, and I cannot tell from my Xorg.0.log file what identifier is "autodetected". How do I figure this out? I am attaching my untested conf file. > Disabling the PageFlip option in xorg.conf might help to avoid those. I did see that; thanks. That's the next problem I'm going to tackle after my precious missing underscore. (My work habits involve maximized xterms and vertically-split vim windows; those, combined with the monitor I'm using and my aging eyes, mandate the 14-point font size.) But in the meantime I did want to report that problem because frankly it's insane to be dumping that much redundant crap into the log file. syslog has had message rate limiting for decades, and the Linux kernel for several years at least. Someone was not thinking. Regards, Branden [1] It's very nice to have this configurable via XKB and the keyboard-configuration package these days! Section "Device" Identifier "mystery" Driver "modesetting" Option "AccelMethod" "none" # Option "PageFlip" "off" EndSection
Bug#858142: xterm: ASCII underscore does not render when using -fa FreeMono -fs 14
On Mon, Mar 20, 2017 at 08:02:29PM +0100, Sven Joachim wrote: > On 2017-03-20 14:42 -0400, G. Branden Robinson wrote: > > I think you may be getting FreeMono.ttf instead of DejaVuSansMono.ttf. > > I don't think so, the screenshot I included in > <8760j3hklk@turtle.gmx.de> very much looks like DejaVuSansMono to > me. At least it's notably different from the screenshot in my first > reply <87wpbjholo@turtle.gmx.de>. Agreed. I installed fonts-freefont-ttf and that (FreeMono.ttf) is definitely a Courier/typewriter-like font[1]. It also doesn't make the underscore invisible at a size of 14 points. > Tried it, but saw no difference. I'm at a loss, then. As you originally suspected, maybe it is a graphics driver issue. Attaching Xorg.log[2]. Regards, Branden [1] "xfd -fa FreeMono" turns over a new rock with fonts-freefont-ttf installed, though. Obviously something is corrupted or being misinterpreted. Attaching a screenshot of that, too. [2] ...a truncated form of it since it's choked with 104 megabytes and counting of: (WW) modeset(0): flip queue failed: Device or resource busy (WW) modeset(0): Page flip failed: Device or resource busy (EE) modeset(0): present flip failed Sigh. [34.367] (--) Log file renamed from "/home/branden/.local/share/xorg/Xorg.pid-1478.log" to "/home/branden/.local/share/xorg/Xorg.0.log" [34.368] X.Org X Server 1.19.2 Release Date: 2017-03-02 [34.368] X Protocol Version 11, Revision 0 [34.368] Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian [34.368] Current Operating System: Linux crack 4.9.0-2-amd64 #1 SMP Debian 4.9.13-1 (2017-02-27) x86_64 [34.368] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-2-amd64 root=UUID=47df0675-2105-4b80-896a-a62d1d2e1f05 ro quiet [34.368] Build Date: 03 March 2017 03:14:41PM [34.368] xorg-server 2:1.19.2-1 (https://www.debian.org/support) [34.368] Current version of pixman: 0.34.0 [34.368]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [34.368] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [34.368] (==) Log file: "/home/branden/.local/share/xorg/Xorg.0.log", Time: Sat Mar 18 20:30:17 2017 [34.368] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [34.369] (==) No Layout section. Using the first Screen section. [34.369] (==) No screen section available. Using defaults. [34.369] (**) |-->Screen "Default Screen Section" (0) [34.369] (**) | |-->Monitor "" [34.370] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [34.370] (==) Automatically adding devices [34.370] (==) Automatically enabling devices [34.370] (==) Automatically adding GPU devices [34.370] (==) Max clients allowed: 256, resource mask: 0x1f [34.370] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [34.370]Entry deleted from font path. [34.370] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [34.370] (==) ModulePath set to "/usr/lib/xorg/modules" [34.370] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [34.370] (II) Loader magic: 0x559daf45ae00 [34.370] (II) Module ABI versions: [34.370]X.Org ANSI C Emulation: 0.4 [34.370]X.Org Video Driver: 23.0 [34.370]X.Org XInput driver : 24.1 [34.370]X.Org Server Extension : 10.0 [34.370] (++) using VT number 2 [34.372] (II) systemd-logind: took control of session /org/freedesktop/login1/session/_32 [34.372] (II) xfree86: Adding drm device (/dev/dri/card0) [34.373] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 12 paused 0 [34.374] (--) PCI:*(0:0:2:0) 8086:0a16:17aa:3978 rev 11, Mem @ 0xb000/4194304, 0xa000/268435456, I/O @ 0x3000/64, BIOS @ 0x/131072 [34.374] (II) LoadModule: "glx" [34.376] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [34.378] (II) Module glx: vendor="X.Org Foundation" [34.378]compiled for 1.19.2, module version = 1.0.0 [34.378]ABI class: X.Org Server Extension, version 10.0 [34.378] (==) Matched modesetting as autoconfigured driver 0 [34.378] (==) Matched fbdev as autoconfigured driver 1 [34.378] (==) Matched vesa as autoconfigured drive
Bug#858142: xterm: ASCII underscore does not render when using -fa FreeMono -fs 14
On Mon, Mar 20, 2017 at 07:24:55PM +0100, Sven Joachim wrote: > No, attached is a screenshot of "xterm -fa DejaVuSansMono -fs 14". I think you may be getting FreeMono.ttf instead of DejaVuSansMono.ttf. > > [1] On my Debian Stretch system installed freshly as of Friday, 17 March, > > "matching" is a generous term. "xfd -fa X-14" also brings up DejaVu > > Sans Mono-14. Frustratingly, "fc-list $pattern" as documented in the > > fc-list(1) manpage seems to be useless, returning no matches no matter > > what $pattern is. But that's a bug for a different package... > > Apparently fc-match gives better results than fc-list. On my system it > revealed that FreeMono is best matched by FreeMono.ttf coming from the > fonts-freefont-ttf package, followed by DejaVuSansMono.ttf. This could be the key. I _don't_ have fonts-freefont-ttf installed, and fc-match tells me: $ fc-match FreeMono DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book" Can you repro the problem if you temporarily uninstall fonts-freefont-ttf? (Or override fontconfig/Xft's resolution order to force DejaVuSansMono.ttf to be found first, but I don't know how to do that?) Regards, Branden
Bug#858142: xterm: ASCII underscore does not render when using -fa FreeMono -fs 14
On Mon, Mar 20, 2017 at 06:17:42PM +0100, Sven Joachim wrote: > On 2017-03-20 13:05 -0400, G. Branden Robinson wrote: > > On Mon, Mar 20, 2017 at 05:58:27PM +0100, Sven Joachim wrote: > >> On 2017-03-18 16:37 -0400, Branden Robinson wrote: > >> > but "xfd -fa FreeMono-14" works fine, so I figured > >> > I would start with xterm. > >> > >> …I cannot reproduce your problem. See the attached screenshot, where > >> the underscore is rendered just fine. > > > > Your screenshot does not depict the FreeMono font; your screenshot has > > serifs all over the glyphs; FreeMono (or at least the font resolved by > > the name "FreeMono" on my system) is a sans-serif font. > > Which font would that be, and which package do I need to install to get > it? I am a total noob when it comes to fonts. I apologize; the name FreeMono is a bit of a red herring. I carried the name over via a dotfile from a different machine. If you run the xfd command shown above, it identifies the "matching" font[1] as DejaVu Sans Mono-14 ...which I'm betting comes from the following file: /usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf in the following package: fonts-dejavu-core Does this help you repro the problem? I'll retitle the bug separately. I haven't talked to the control bot in years and half-expect to suffer an impedance mismatch. I fear I may even be forced to use "kthxbye". :-| Thanks for the prompt follow-up! [1] On my Debian Stretch system installed freshly as of Friday, 17 March, "matching" is a generous term. "xfd -fa X-14" also brings up DejaVu Sans Mono-14. Frustratingly, "fc-list $pattern" as documented in the fc-list(1) manpage seems to be useless, returning no matches no matter what $pattern is. But that's a bug for a different package... Regards, Branden
Bug#858142: xterm: ASCII underscore does not render when using -fa FreeMono -fs 14
On Mon, Mar 20, 2017 at 05:58:27PM +0100, Sven Joachim wrote: > On 2017-03-18 16:37 -0400, Branden Robinson wrote: > > > Package: xterm > > Version: 327-2 > > Severity: normal > > Tags: upstream > > > > Observe screenshot. Wouldn't surprise me in the least if the problem is > > really with libxft2, > > Probably it's something else (Xresources? video driver?), because… > > > but "xfd -fa FreeMono-14" works fine, so I figured > > I would start with xterm. > > …I cannot reproduce your problem. See the attached screenshot, where > the underscore is rendered just fine. Your screenshot does not depict the FreeMono font; your screenshot has serifs all over the glyphs; FreeMono (or at least the font resolved by the name "FreeMono" on my system) is a sans-serif font. -- Regards, Branden
