Bug#415292: libgl1-mesa-glx: assertion failure in libGL.so.1

[G. Branden Robinson]

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

[G. Branden Robinson]

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

[G. Branden Robinson]

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

[G. Branden Robinson]

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

[G. Branden Robinson]

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

[G. Branden Robinson]

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

[G. Branden Robinson]

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

[G. Branden Robinson]

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

[G. Branden Robinson]

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

[G. Branden Robinson]

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

[G. Branden Robinson]

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

[G. Branden Robinson]

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

[G. Branden Robinson]

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

[G. Branden Robinson]

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

[G. Branden Robinson]

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

[G. Branden Robinson]

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

[G. Branden Robinson]

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

[G. Branden Robinson]

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

[G. Branden Robinson]

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

[G. Branden Robinson]

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

[G. Branden Robinson]

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

[G. Branden Robinson]

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

[G. Branden Robinson]

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)

[G. Branden Robinson]

[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#858295: /usr/bin/xfd: renders some fonts' combining characters outside their bounding boxes

[Branden Robinson]

Package: x11-utils
Version: 7.7+3+b1
Severity: normal
File: /usr/bin/xfd
Tags: upstream

To reproduce:
1. apt-get install fonts-freefont-ttf
2. xfd -fa FreeMono
3. Press the "Next" button until you reach the page with codepoint 0x300 in it.

Observe screenshot.  This is ugly and confusing; perhaps something in the TTF
file is being mis-parsed.

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages x11-utils depends on:
ii  libc6 2.24-9
ii  libfontconfig12.11.0-6.7+b1
ii  libfontenc1   1:1.1.3-1+b2
ii  libfreetype6  2.6.3-3+b2
ii  libgl1-mesa-glx [libgl1]  13.0.5-1
ii  libx11-6  2:1.6.4-3
ii  libx11-xcb1   2:1.6.4-3
ii  libxaw7   2:1.0.13-1+b2
ii  libxcb-shape0 1.12-1
ii  libxcb1   1.12-1
ii  libxcomposite11:0.4.4-2
ii  libxext6  2:1.3.3-1+b2
ii  libxft2   2.3.2-1+b2
ii  libxi62:1.7.9-1
ii  libxinerama1  2:1.1.3-1+b3
ii  libxmu6   2:1.1.2-2
ii  libxmuu1  2:1.1.2-2
ii  libxrandr22:1.5.1-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  libxtst6  2:1.2.3-1
ii  libxv12:1.0.11-1
ii  libxxf86dga1  2:1.1.4-1+b3
ii  libxxf86vm1   1:1.1.4-1+b2

x11-utils recommends no packages.

Versions of packages x11-utils suggests:
pn  mesa-utils  

-- no debconf information

Bug#858293: /usr/bin/xfd: displays garbage style information about FreeMono font

[Branden Robinson]

Package: x11-utils
Version: 7.7+3+b1
Severity: normal
File: /usr/bin/xfd
Tags: upstream

To reproduce:
1. apt-get install fonts-freefont-ttf
2. xfd -fa FreeMono

Observe screenshot.  Even if FreeMono.ttf is malformed, it looks to me like xfd
isn't validating its input.  We know what sort of problems that can lead to.

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages x11-utils depends on:
ii  libc6 2.24-9
ii  libfontconfig12.11.0-6.7+b1
ii  libfontenc1   1:1.1.3-1+b2
ii  libfreetype6  2.6.3-3+b2
ii  libgl1-mesa-glx [libgl1]  13.0.5-1
ii  libx11-6  2:1.6.4-3
ii  libx11-xcb1   2:1.6.4-3
ii  libxaw7   2:1.0.13-1+b2
ii  libxcb-shape0 1.12-1
ii  libxcb1   1.12-1
ii  libxcomposite11:0.4.4-2
ii  libxext6  2:1.3.3-1+b2
ii  libxft2   2.3.2-1+b2
ii  libxi62:1.7.9-1
ii  libxinerama1  2:1.1.3-1+b3
ii  libxmu6   2:1.1.2-2
ii  libxmuu1  2:1.1.2-2
ii  libxrandr22:1.5.1-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  libxtst6  2:1.2.3-1
ii  libxv12:1.0.11-1
ii  libxxf86dga1  2:1.1.4-1+b3
ii  libxxf86vm1   1:1.1.4-1+b2

x11-utils recommends no packages.

Versions of packages x11-utils suggests:
pn  mesa-utils  

-- no debconf information

Bug#858142: xterm: ASCII underscore does not render when using -fa FreeMono -fs 14

[G. Branden Robinson]

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

[G. Branden Robinson]

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

[G. Branden Robinson]

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

[G. Branden Robinson]

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

Bug#858142: xterm: Screenshot of "xfd -fa FreeMono-14" on my system

[Branden Robinson]

Package: xterm
Version: 327-2
Followup-For: Bug #858142

I mentioned running the command in the subject in my initial report, but
did not provide a screenshot.

Here it is, in the event it's of interest or use.

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (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-9
ii  libfontconfig1  2.11.0-6.7+b1
ii  libice6 2:1.0.9-2
ii  libtinfo5   6.0+20161126-1
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

Re: nonfree(?) fonts in xfonts-100dpi

[Branden Robinson]

Hi dine,

I considered this issue back in the day as package maintainer.

In the United States and some other jurisdictions, possibly not
including Japan[1], bitmap typefaces are not regarded as
copyrightable. In fact, typefaces generally aren't--but the "font"
that creates them in the form of instructions in a sort of programming
language, often are.

As I understand it, in the West the reasoning is based on analogy to
and the precedent of hot-metal typography, whereby you could purchase
a "font" from some foundry and rack it in your Linotype, for example.
By contrast, if a person studied a font in a newspaper or book closely
and cast his own hot-metal font to simulate it, that person enjoyed
independent commercial rights.

Donald Knuth, for example, famously designed the Computer Modern fonts
based on reference to typefaces traditionally used in mathematical
typesetting.

Let me know if you have further questions or if this fails to
illuminate the issue.

Regards,
Branden

[1] I did some limited research on this potential exception. It seemed
to involve only glyphs used in Japanese typography (hirigana,
katakana, and kanji) and explicitly _not_ Western scripts (romaji). At
the time, the Lucida fonts didn't have renderings for any of these
codepoints, and my guess would be that they still don't, as my
recollection is that those fonts have been close to moribund ever
since they landed in the X Window System distribution. Maybe the Euro
sign got added, and I wouldn't count on much more than that. Scalable
fonts have been where the action is for over 25 years. The bottom line
is that we had no bitmap fonts with "Japanese characters" with a
non-free license, and no bitmap fonts without them that had a license
that was binding.

On Thu, Mar 16, 2017 at 2:08 PM, dine <2500418...@qq.com> wrote:
> Hi. I just spot an issue in xfonts-100dpi, xfonts-75dpi, and related
> packages: some of the fonts are free, but the Lucida bitmaps do not allow
> modification, the same reason the Luxi fonts got marked nonfree 15 years
> ago. Does Lucida need similar treatment?

Bug#852448: x11-common: ssh-agent socket removed from /tmp for long-running sessions

[Branden Robinson]

Hi Sam,

On Tue, Jan 24, 2017 at 2:51 PM, Sam Hartman  wrote:
> I think sticking the agent socket in XDG_RUNTIME_DIR is a better place in the 
> modern world order.
> Here's a patch.
>
> --- 90x11-common_ssh-agent~ 2010-10-13 09:29:00.0 -0400
> +++ 90x11-common_ssh-agent  2017-01-24 09:36:32.717942114 -0500
> @@ -17,6 +17,11 @@
>fi
>  fi
>
> +if [ -n "$XDG_RUNTIME_DIR" ]; then
> +mkdir $XDG_RUNTIME_DIR/ssh-agent
> +SSHAGENTARGS="-a $XDG_RUNTIME_DIR/ssh-agent/sock $SSHAGENTARGS"
> +fi
> +
>  if [ -n "$STARTSSH" ]; then
>STARTUP="$SSHAGENT $SSHAGENTARGS ${TMPDIR:+env TMPDIR=$TMPDIR} $STARTUP"
>  fi

Your patch looks good, except that I would quote the expansion of
$XDG_RUNTIME_DIR when invoking mkdir. If $XDG_RUNTIME_DIR contains
whitespace, the shell will tokenize it in a surprising way and create
different directory names than are expected.

$ FOO="foo bar"; test -d "$FOO" || echo "$FOO does not exist"; if [ -n
"$FOO" ]; then mkdir $FOO; cd "$FOO"; fi; ls -dl "$FOO" $FOO
foo bar does not exist
-bash: cd: foo bar: No such file or directory
ls: cannot access 'foo bar': No such file or directory
drwxr-xr-x 1 branden None 0 Jan 24 15:28  bar
drwxr-xr-x 1 branden None 0 Jan 24 15:28  foo

Regards,
Branden

Bug#848818: xterm: ctlseqs.txt is not rebuilt from ctlseq.ms

[Branden Robinson]

On Tue, Dec 20, 2016 at 9:26 AM, Thomas Dickey  wrote:
> severity 848818 wishlist
> close 848818
>
> I'm not going to discuss this further -
>
> https://www.debian.org/Bugs/Developer#severities
> http://invisible-island.net/personal/changelogs.html#problem_hostile

It's been a while since I've had one of these arguments, but reviewing
Policy 2.1 I agree.

Failure to generate ctlseqs.* from ctlseqs.ms would be a GPL violation
and thus a "serious" bug if:
1. The document were under the GPL; and
2. Debian didn't make the ctlseqs.ms and the requisite tools for
generating its dervative forms available.

...but neither of those prerequisites is the case.

That said, I think it would be _nice_ if a package produced all its
generated forms of documentation from their source forms as part of
the build process, and declared Build-Depends appropriately. This acts
as a form of QA on documentation generation tool chains, which in my
experience (in the case of XML/XSL) is as robust as a football pitch
of egg shells.

Thank God you've stuck with *roff. James Clark did such good work on
GNU Roff. Something terrible happened to him.

Regards,
Branden

Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T

[Branden Robinson]

On Thu, May 22, 2008 at 12:15:04PM -0400, Alex Deucher wrote:
  In short, I'm now back to the original #348082 status quo, with the added
  benefit of not having to use the ConnectorTable option as part of the
  workaround.  Also, my monitor now detects as DVI-0, and is not located at
  DVI-1 as before.
 
 Does switching to the other DVI port help?

Unfortunately, I cannot find out.  The other DVI port is an ADC port, and I
don't have compatible hardware:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=348082#152

-- 
G. Branden Robinson| I don't care if it has a GUI, or
Debian GNU/Linux   | command line, or is carved in mud
[EMAIL PROTECTED] | with a sharp spoon.
http://people.debian.org/~branden/ | -- Barry Smith


signature.asc
Description: Digital signature

Bug#348082: closed by Brice Goglin [EMAIL PROTECTED] (Re: Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung S

[Branden Robinson]

On Sat, Dec 22, 2007 at 11:39:08AM +, Debian Bug Tracking System wrote:
 On Sun, Nov 18, 2007 at 05:05:33PM +0100, Brice Goglin wrote:
  On Thu, Sep 13, 2007 at 09:16:39PM -0400, Alex Deucher wrote:
Given these setbacks, is there something more I can do to help with this
bug?
   
   Once I merge the external tmds stuff, things might improve.  stay tuned.
  
  Unless I am mistaken, this has been merged now. Branden, is it better
  with 6.7.196-1 currently in experimental?
 
 Marking as fixed now. Feel free to reopen if I am wrong.

I'll give this a try (I'm running 192 at present since I'm tracking lenny).

Lately I've developed fresh problems with the X server--I'm not sure about
the exact cause but the symptom is that the Xorg process goes crazy and
chews up 100% CPU (or even just over that according to top on my SMP
system, which was a new experience for me) and is totally unresponsive to
everything including all signals.  The hardware-accelerated cursor is still
drivable but that's about it.

Next time this happens I'll see if I can attach GDB to the X server and see
where it's spinning.

-- 
G. Branden Robinson|Kissing girls is a goodness.  It is
Debian GNU/Linux   |a growing closer.  It beats the
[EMAIL PROTECTED] |hell out of card games.
http://people.debian.org/~branden/ |-- Robert Heinlein


signature.asc
Description: Digital signature

Bug#446275: xfs: add descriptive comment to top of init script

[Branden Robinson]

Package: xfs
Version: 1:1.0.1-5
Severity: wishlist

On Thu, Oct 11, 2007 at 12:34:40PM -0400, Piotr F Mitros wrote:
 Hello,
 
 I noticed you were listed as the maintainer at the top of
 /etc/init.d/xfs. I had a minor suggestion. Add a comment to
 the top of the file explaining what it is and what it does,
 and possibly, where to find more documentation.
 
 The file currently begins with:
 
 #!/bin/sh
 
 # $Id: xfs.init 2186 2005-02-11 07:11:05Z branden $
 
 # Copyright 1998-2004 Branden Robinson [EMAIL PROTECTED].
 ...
 
 
 I would suggest beginning it with something to the effect of:
 
 #!/bin/sh
 # Initialization script for the X Font Server.
 # For more information, see /usr/share/doc/xfs/README.Debian
 # or run: man xfs
 
 # $Id: xfs.init 2186 2005-02-11 07:11:05Z branden $
 
 # Copyright 1998-2004 Branden Robinson [EMAIL PROTECTED].
 
 Little touches like this can make the system significantly
 more newbie-friendly.

For configuration files in general, I agree.  For init scripts in
particular, I am less certain, as the function of each file in /etc/init.d
is mandated by the Linux Standard Base.

I am not the package maintainer of xfs anymore, though, so I am opening a
Debian bug report to accommodate your request.

(Note to self/package maintainers: please change the submitter of this bug
to Mr. Mitros once the BTS has allocated a bug number.)

-- 
G. Branden Robinson|  Experience is simply the name we
Debian GNU/Linux   |  give our mistakes.
[EMAIL PROTECTED] |  -- Oscar Wilde
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

Attn: David Nusinow, re: glint PCI table and the shell

[Branden Robinson]

Hi David,

Saw this on #debian-x:

23:26  gravity Oh my god... the glint pci id table is insane
23:26  gravity Manageable I guess, but irritatingly complicated
23:29  * KiBi patpats gravity
23:38  gravity Ok, yeah. This one's going to be a static file. I really
  don't feel like figuring out how to warp shell in to making something right
  out of this:
23:38  gravity #define PCI_VENDOR_TI_CHIP_PERMEDIA2\ ((PCI_VENDOR_TI
 16) | PCI_CHIP_TI_PERMEDIA2)
23:38  gravity ^ more pain than it's worth for a temporary hack
23:39  gravity Internally though, that's actually a pretty good way to do
  things. It'll work well for pci-rework

You have access to bitwise operations in standard POSIX shell arithmetic.

$ echo $(( 1  5 ))
32
$ echo $(( 1  5 | 4 ))
36

-- 
G. Branden Robinson|  Never underestimate the power of
Debian GNU/Linux   |  human stupidity.
[EMAIL PROTECTED] |  -- Robert Heinlein
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T

[Branden Robinson]

On Sat, Sep 01, 2007 at 11:21:18AM -0400, Alex Deucher wrote:
 On 9/1/07, Branden Robinson [EMAIL PROTECTED] wrote:
  That's three more experiments:
 
  1) xrandr --output DVI-0 --off

This appears to be a no-op.  The interference is left in place, and it is
the same as if I do not use xrandr or xvidmode at all.

  2) Option ConnectorTable 3,1,1,3,2,0,0,3

This also has no apparent effect.  The same interference is present on
server startup.

  3) Switch the ConnectorTable back to what I have now*, and plug the monitor
  into the other DVI port.
 
 4) 3) with the new connectortable.

I'm afraid I cannot perform these experiments.  Upon trying it, I see that my
other video output is an ADC connector, not a DVI connector.

http://redwald.deadbeast.net/tmp/debian_bug_348082_damn_ati_connectors.jpeg

 Also, if you have an analog monitor (VGA connector). it'd be nice to
 test that to make sure we actually have the dac mapping correct.

Another disappointment -- I got rid of my last CRT monitors earlier this
year.

Given these setbacks, is there something more I can do to help with this
bug?

-- 
G. Branden Robinson|People are equally horrified at
Debian GNU/Linux   |hearing the Christian religion
[EMAIL PROTECTED] |doubted, and at seeing it
http://people.debian.org/~branden/ |practiced. -- Samuel Butler


signature.asc
Description: Digital signature

Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T

[Branden Robinson]

On Fri, Aug 31, 2007 at 11:13:59PM -0400, Alex Deucher wrote:
  For some reason, when kdm asks for the pixmaps that comprise its
  background, the X server draws from someplace else in video memory.  The
  following has me pretty convinced given that it comprises a bunch of images
  from recently-viewed webpages and windows that were unmapped when the
  previous X session was terminated.
 
 Very strange.  Can you open an new bug (https://bugs.freedesktop.org)
 for that?

Filed as fd.o #12274.

-- 
G. Branden Robinson| If you're handsome, it's flirting.
Debian GNU/Linux   | If you're a troll, it's sexual
[EMAIL PROTECTED] | harassment.
http://people.debian.org/~branden/ | -- George Carlin


signature.asc
Description: Digital signature

Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T

[Branden Robinson]

:  -772800836
Subpixel:   horizontal rgb
Clones:
CRTC:   1
CRTCs:  0 1
dvi_monitor_type: auto
scaler: fill
  1280x800 (0x60)   83.5MHz
h: width  1280 start 1344 end 1480 total 1680 skew0 clock   49.7KHz
v: height  800 start  801 end  804 total  828   clock   60.0Hz
  1280x768 (0x61)   80.1MHz
h: width  1280 start 1344 end 1480 total 1680 skew0 clock   47.7KHz
v: height  768 start  769 end  772 total  795   clock   60.0Hz
  1024x768 (0x55)   65.0MHz -HSync -VSync
h: width  1024 start 1048 end 1184 total 1344 skew0 clock   48.4KHz
v: height  768 start  771 end  777 total  806   clock   60.0Hz
  800x600 (0x59)   40.0MHz +HSync +VSync
h: width   800 start  840 end  968 total 1056 skew0 clock   37.9KHz
v: height  600 start  601 end  605 total  628   clock   60.3Hz
  640x480 (0x62)   25.2MHz -HSync -VSync
h: width   640 start  656 end  752 total  800 skew0 clock   31.5KHz
v: height  480 start  490 end  492 total  525   clock   59.9Hz

-- 
G. Branden Robinson| What influenced me to atheism was
Debian GNU/Linux   | reading the Bible cover to cover.
[EMAIL PROTECTED] | Twice.
http://people.debian.org/~branden/ | -- J. Michael Straczynski


signature.asc
Description: Digital signature

Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T

[Branden Robinson]

A bit more info:

On Thu, Aug 30, 2007 at 08:16:04PM -0400, Alex Deucher wrote:
  http://redwald.deadbeast.net/tmp/branden_grief_4.jpeg
  http://redwald.deadbeast.net/tmp/branden_grief_5.jpeg
 
  I'll call that new problem #1: this looks like actual framebuffer
  corruption on top of the video signal interference (sic?) I've been
  experiencing since I filed this bug.

My opinion now is that it has something to do with pixmap cache management.

For some reason, when kdm asks for the pixmaps that comprise its
background, the X server draws from someplace else in video memory.  The
following has me pretty convinced given that it comprises a bunch of images
from recently-viewed webpages and windows that were unmapped when the
previous X session was terminated.

http://redwald.deadbeast.net/tmp/branden_grief_6.jpeg

(Sigh.  I reckon hardcore porn would be less embarrassing than some of
that.)

  xvidtune no longer works to fix the pinkness and striping effect.  But I
  reckon this is expected thanks to some X extension jiggery-pokery -- RandR
  1.2 superseding XVidMode.  At least that's my vague understanding.
  Corrections welcome.  :)
 
  Based on that conjecture, I poked around with xrandr (the utility), and
  came up with the following recipe:
 
  xrandr --output DVI-1 --mode 0x4f
  xrandr --output DVI-1 --mode 0x4e

More for the benefit of debian-x folks or general users, I'll note that
sticking the above as the first thing in my $HOME/.xsession works
beautifully.

  New problem #2: The X cursor is corrupted.  It looks like the cursor has
  been sectionally barrel-shifted about the vertical axis.  This doesn't
  visibly affect the insertion point cursor that xterm uses, but the normal
  right-pointing arrow that KDE uses barely is, and the white hand cursor KDE
  uses when you hover over the task bar is dramatically affected.
 
 known server issue see bug:
 https://bugs.freedesktop.org/show_bug.cgi?id=11796

I've applied Michel's fix from that bug and it works great.

-- 
G. Branden Robinson|   The well-bred contradict other
Debian GNU/Linux   |   people. The wise contradict
[EMAIL PROTECTED] |   themselves.
http://people.debian.org/~branden/ |   -- Oscar Wilde


signature.asc
Description: Digital signature

Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T

[Branden Robinson]

On Fri, Aug 31, 2007 at 11:22:29PM -0400, Alex Deucher wrote:
 It appears the driver thinks have two monitors connected.  do you?

Nope.  Just the one, the Samsung SyncMaster 213T.

I haven't switched DVI ports yet.  Apparently I'm on DVI-1.

 If not, I think perhaps I got the dac mapping backwards when I suggested
 the connectortable.  does it help if you force off DVI-0 (xrandr --output
 DVI-0 --off)

If I understand you correctly, I'll try this instead of the two xrandr mode
switches in my .xsession.

 Can you also try this connectortable (reverses the dac mapping)?
 Option ConnectorTable 3,1,1,3,2,0,0,3

That's three more experiments:

1) xrandr --output DVI-0 --off
2) Option ConnectorTable 3,1,1,3,2,0,0,3
3) Switch the ConnectorTable back to what I have now*, and plug the monitor
into the other DVI port.

Please let me know if I'm leaving one out.

* OptionConnectorTable3,0,1,3,2,1,0,3

-- 
G. Branden Robinson|
Debian GNU/Linux   | Music is the brandy of the damned.
[EMAIL PROTECTED] | -- George Bernard Shaw
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T

[Branden Robinson]

On Thu, Aug 30, 2007 at 10:25:49AM -0400, Alex Deucher wrote:
 On 8/30/07, Michel Dänzer [EMAIL PROTECTED] wrote:
  On Thu, 2007-08-30 at 09:54 -0400, Alex Deucher wrote:
 
   Branden,  remind me again what card this is and what connectors your
   card has.  Actually, the full log would be useful.  It's it a mac,
   we'll need to add a quirk for it.  If it's a powerbook, I may have
   already fixed it.
 
  Alex, the full history of this bug report is available at
 
  http://bugs.debian.org/348082
 
 ok, I scanned over the bug.  It looks like the ddc lines are reversed.
  What connectors does the card actually have?

2 DVI ports.

  What model mac is this?

Power Mac G4, dual 1.25GHz, mirrored drive door

 I'm assuming that it has a DVI port and a VGA port.  Does it have a
 TV port as well?

2 DVI ports, no TV port.

 try:
 Option ReverseDDC true
 
 If that doesn't work we can try some connector tables.

Will do.

-- 
G. Branden Robinson| Mediocrity knows nothing higher
Debian GNU/Linux   | than itself, but talent instantly
[EMAIL PROTECTED] | recognizes genius.
http://people.debian.org/~branden/ | -- Sir Arthur Conan Doyle


signature.asc
Description: Digital signature

Bug#439952: xterm: corruption when using screen, mutt, and fullwidth characters

[Branden Robinson]

Package: xterm
Version: 229-1
Severity: normal
File: /usr/bin/xterm

Please see the attached typescript and timings file.

Some garbage characters in a spam subject are causing an extraneous
linefeed at the bottom of the screen.  When I redraw with ^L, the extra
linefeed goes away (though, interestingly, scriptreplay doesn't show this
quite correctly) but the space before 13 in mutt's index view gets eaten.
Cursoring over the line corrects it.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: powerpc (ppc)

Kernel: Linux 2.6.18-4-powerpc-smp (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages xterm depends on:
ii  libc6 2.6.1-1GNU C Library: Shared libraries
ii  libfontconfig12.4.2-1.2  generic font configuration library
ii  libice6   2:1.0.3-3  X11 Inter-Client Exchange library
ii  libncurses5   5.6+20070812-1 Shared libraries for terminal hand
ii  libsm62:1.0.3-1+b1   X11 Session Management library
ii  libx11-6  2:1.0.3-7  X11 client-side library
ii  libxaw7   1:1.0.3-3  X11 Athena Widget library
ii  libxext6  1:1.0.3-2  X11 miscellaneous extension librar
ii  libxft2   2.1.12-2   FreeType-based font drawing librar
ii  libxmu6   1:1.0.3-1  X11 miscellaneous utility library
ii  libxt61:1.0.5-3  X11 toolkit intrinsics library
ii  xbitmaps  1.0.1-2Base X bitmaps

Versions of packages xterm recommends:
ii  xutils  1:7.1.ds.3-1 X Window System utility programs

-- no debconf information
Script started on Tue Aug 28 13:53:58 2007
$TERM is xterm.
Using UTF-8 environment.
findagent: attached to agent at /tmp/ssh-laPsQr4806/agent.4806
findsm: attached to session manager at local/sisyphus:/tmp/.ICE-unix/5001
]0;[EMAIL PROTECTED]: /home/branden501 {0} [EMAIL PROTECTED]:~$ screen -dr
[?1049h[?7h[?1;4;6l[?1h=(B657 
{0} [EMAIL PROTECTED]:~$ q:Quit  d:Del  u:Undel  s:Save  
m:Mail  r:Reply  g:Group  ?:Help   

   1 N   Aug 28 Otavio Salvador (  18) Re: [RFC] Remove massbuild 
bashisms   
  
   2 N   Aug 28 Otavio Salvador (  23) Re: Kernels at 2.6.21 rather than 
2.6.22?
   
   3 N + Aug 29 美樹本  (  16) スポンサー様からの強い要望により


   4 N   Aug 28 Tim Olsen   (  15) Re: creation of 
lock-empty resource MUST return 201
 
   5 N + Aug 29 wr  (  59) 成为／优秀的部门／主管经理／专题　
5013437
   
   6 N   Aug 28 Debian Bug Trac ( 111) Processed: tagging 315589, tagging 
354713, tagging 336220, tagging 271599, tagging 389255, tagging 376188 ... ... 
... ... ... ..
   7 N   Aug 28 Debian Bug Trac (  23) Processed: Bug#318004: 
xserver-xorg: numlock led not working after vt switch  
  
   8 N   Aug 28 Stefan Richter  (  56) Re: Firewire lockup on 2.6.22.3 in 
SMP but not UP, old drivers
  
   9 N + Aug 29 1104.海外订∴单  ( 250) 有效获取、留住≈订单技巧训练 [EMAIL PROTECTED]

  10 N   Aug 28 rhys Sherrow(   6) 1722ni 

 
  11 N + Aug 28 Printing Offer  ( 148) 250 Free Business Cards !! Don't 
Miss Out!  

  12 N + Aug 29 张海滨  (  29) 顺达贸易有限公司《业务合作》！ 

   
  13 N   Aug 28 Reva Bartlett   (  28) Increase you image

  
  14 N   Aug 28 Reva Bartlett   (  28) Increase you image

  
  15 N + Aug 28 Willie M. Peter (  19) Don't be left out, join masses of 
men in 

Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T

[Branden Robinson]

On Mon, Aug 27, 2007 at 11:35:33AM +0200, Brice Goglin wrote:
 Hi Branden,
 
 The randr-1.2 ati driver is now in experimental (6.7.192 uploaded
 today), it contains a major rework of the driver. Could you test whether
 your problem still occurs?

Hi Brice,

I'll check into this as soon as I can (I'll shoot for some time this week,
tonight UTC-0400 if I'm really lucky).

What's the current state of autobuilding experimental?  Only i386 packages
are up right now.  If not, I still know how to build from source, of
course, but I don't run anything newer than lenny, so some warning would be
appreciated as to whether I'll need to set up a chroot for some
bleeding-edge build-deps.

Once again, you have my appreciation for the big rubber mallet and pruning
shears you've been wielding so ferociously against the X bug list.

-- 
G. Branden Robinson| The last time the Republican Party
Debian GNU/Linux   | was on the right side of a social
[EMAIL PROTECTED] | issue, Abe Lincoln was president.
http://people.debian.org/~branden/ | -- Kirk Tofte


signature.asc
Description: Digital signature

Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T

[Branden Robinson]

On Tue, Jul 24, 2007 at 12:10:48AM +0200, Brice Goglin wrote:
  I took two pictures of my monitor.  The images are way too large to attach,
  so I have put them up on one of my web servers.
 
  http://redwald.deadbeast.net/tmp/branden_grief_1.jpeg
  http://redwald.deadbeast.net/tmp/branden_grief_2.jpeg
 
 Hi Branden,
 
 What's the status of this bug with ati driver 6.6.3 (or 6.6.192 in
 experimental) and xserver-xorg-core 1.3?

Hi Brice!

ii  xserver-xorg-core   2:1.3.0.0.dfsg-11
ii  xserver-xorg-video-ati  1:6.6.3-2

Still exactly the same, as far as I can tell.  I just restarted X within
the past day or two.

The pinkness still comes back in exactly the same way on any X server
reset, and I can still get rid of it exactly the same way -- run xvidtune,
and then adjust the screen right or left.  I haven't tried up/down or
resizing, but I suspect that any vidmode tweak will just fix the problem.

My hardware is still exactly the same as when I filed this report.

Thanks very much for your scrupulous attention to old X bugs.

-- 
G. Branden Robinson|It's extremely difficult to govern
Debian GNU/Linux   |when you control all three branches
[EMAIL PROTECTED] |of government.
http://people.debian.org/~branden/ |-- John Feehery


signature.asc
Description: Digital signature

Bug#421854: libx11-6: opera: xcb_xlib.c:52 xcb_xlib_unlock: Assertion 'c-xlib.lock' failed.Aborted

[Branden Robinson]

Package: libx11-6
Version: 2:1.1-2
Severity: normal

Hi Mr. Kroeger,

I am no longer intensely involved in X Window System packaging for Debian.
In the future, you can use the reportbug command from the Debian package
of the same name to file bugs.  It's interactive and very user-friendly,
and will help you file a high-quality bug report.

As I understand it, the XCB-linked Xlib has not yet propagated into
unstable, so you must be running experimental libx11-6 packages.

[Note to XSF: If I don't get to it first, please change the submitter on
this report to Charlie Kroeger [EMAIL PROTECTED] as soon as
it is convenient.]

On Tue, May 01, 2007 at 11:43:09PM -0500, Charlie Kroeger wrote:
 Dear Mr. Robinson,
 
 This message I get when trying to start Opera from the command line:
 
 opera: xcb_xlib.c:52 xcb_xlib_unlock: Assertion
  'c-xlib.lock' failed.Aborted
 
 I wrote the Opera Linux newsgroup and their man: Eirik Byrkjeflot Anonsen 
 said:
 
 Ouch!  This is a bug in xlib.  Some people have been adding a new
 interface to X with some improvements over the old xlib stuff.  The
 error message above says that the sequence of calls into xcb (the new
 interface) is wrong.  Opera doesn't use xcb directly, so this is
 almost certainly a bug in xlib.
 
 I didn't know exactly where to file this report so I send it to you,
 
 Thanks for all your work on Debian.

-- 
G. Branden Robinson|The errors of great men are
Debian GNU/Linux   |venerable because they are more
[EMAIL PROTECTED] |fruitful than the truths of little
http://people.debian.org/~branden/ |men. -- Friedrich Nietzsche


signature.asc
Description: Digital signature

xfonts-base: Changes to 'debian-unstable'

[Branden Robinson]

 debian/rules |   57 +-
 debian/xfonts-base.postinst.in   |6 
 debian/xfonts-base.postrm.in |   15 
 debian/xfonts-base.preinst.in|   20 
 debian/xsfbs/xsfbs-autoreconf.mk |  150 ++
 debian/xsfbs/xsfbs.mk|  379 
 debian/xsfbs/xsfbs.sh|  907 +++
 7 files changed, 1493 insertions(+), 41 deletions(-)

New commits:
commit d7a4b2a880f0332bb4dac0609f146f9388a51a36
Author: Branden Robinson [EMAIL PROTECTED](none)
Date:   Wed Apr 18 02:40:50 2007 -0400

Perform janitorial work.

* Add licensing information to package preinst script.
* Use more convential Make idiom for creating a target.
* Add #DEBHELPER# expando to preinst script.
* Update comments in Debian rules file.
* Wrap lines at 80 columns.
* Update Vim modelines.
* Remove Subversion Id keywords.
* Update copyright notices where applicable.

diff --git a/debian/rules b/debian/rules
index 03787cd..bbcd9bb 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,20 +1,34 @@
 #!/usr/bin/make -f
-# debian/rules for the Debian xfonts-base package.
+# Debian xfonts-base package building rules
 # Copyright © 2004 Scott James Remnant [EMAIL PROTECTED]
 # Copyright © 2005 Daniel Stone [EMAIL PROTECTED]
 # Copyright © 2005 David Nusinow [EMAIL PROTECTED]
+# Copyright © 2007 Branden Robinson [EMAIL PROTECTED]
 
 # Uncomment this to turn on verbose mode.
-#export DH_VERBOSE=1
+#export DH_VERBOSE = 1
 
-# set this to the name of the main shlib's binary package
+# If this is a library package, set this to name of the package containing the
+# shared library.
 PACKAGE = xfonts-base
 
 include debian/xsfbs/xsfbs.mk
 
-# This package contains multiple modules as shipped by upstream. Each module 
is # contained in a subdirectory in the root dir of the package. You must list 
each
-# subdirectory explicitly so that the build system knows what to build
-SUBDIRS=font-arabic-misc-X11R7.0-1.0.0 font-cursor-misc-X11R7.0-1.0.0 
font-daewoo-misc-X11R7.0-1.0.0 font-dec-misc-X11R7.0-1.0.0 
font-isas-misc-X11R7.0-1.0.0 font-jis-misc-X11R7.0-1.0.0 
font-micro-misc-X11R7.0-1.0.0 font-misc-misc-X11R7.0-1.0.0 
font-mutt-misc-X11R7.0-1.0.0 font-schumacher-misc-X11R7.0-1.0.0 
font-sony-misc-X11R7.0-1.0.0 font-sun-misc-X11R7.0-1.0.0
+# This package contains multiple modules as shipped by upstream.  Each module 
is
+# contained in a subdirectory in the root dir of the package.  You must list
+# each subdirectory explicitly so that the build system knows what to build.
+SUBDIRS=font-arabic-misc-X11R7.0-1.0.0 \
+   font-cursor-misc-X11R7.0-1.0.0 \
+   font-daewoo-misc-X11R7.0-1.0.0 \
+   font-dec-misc-X11R7.0-1.0.0 \
+   font-isas-misc-X11R7.0-1.0.0 \
+   font-jis-misc-X11R7.0-1.0.0 \
+   font-micro-misc-X11R7.0-1.0.0 \
+   font-misc-misc-X11R7.0-1.0.0 \
+   font-mutt-misc-X11R7.0-1.0.0 \
+   font-schumacher-misc-X11R7.0-1.0.0 \
+   font-sony-misc-X11R7.0-1.0.0 \
+   font-sun-misc-X11R7.0-1.0.0
 
 CFLAGS = -Wall -g
 ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
@@ -40,23 +54,22 @@ build: prepare build-stamp
 build-stamp:
dh_testdir
for FILE in $(SUBDIRS); do \
-   echo $$FILE ; \
+   echo $$FILE; \
mkdir $$FILE-obj-$(DEB_BUILD_GNU_TYPE); \
-   (cd $$FILE-obj-$(DEB_BUILD_GNU_TYPE)  \
-   ../$$FILE/configure --prefix=/usr 
--mandir=\$${prefix}/share/man \
---infodir=\$${prefix}/share/info $(confflags) \
---with-fontdir=\$${prefix}/share/fonts/X11/misc \
-CFLAGS=$(CFLAGS)  \
-   $(MAKE)) || exit 1; \
+   (cd $$FILE-obj-$(DEB_BUILD_GNU_TYPE) \
+../$$FILE/configure --prefix=/usr \
+   --mandir=\$${prefix}/share/man \
+   --infodir=\$${prefix}/share/info $(confflags) \
+   --with-fontdir=\$${prefix}/share/fonts/X11/misc \
+   CFLAGS=$(CFLAGS) \
+$(MAKE)) || exit 1; \
done
-
-   touch build-stamp
+   $@
 
 clean: xsfclean
dh_testdir
dh_testroot
rm -f build-stamp
-
rm -f config.cache config.log config.status
rm -f */config.cache */config.log */config.status
rm -f conftest* */conftest*
@@ -70,9 +83,9 @@ install: build
dh_testroot
dh_clean -k
dh_installdirs
-
for FILE in $(SUBDIRS); do \
-   cd $$FILE-obj-$(DEB_BUILD_GNU_TYPE)  $(MAKE) 
DESTDIR=$(CURDIR)/debian/tmp install ; \
+   cd $$FILE-obj-$(DEB_BUILD_GNU_TYPE) \
+$(MAKE) DESTDIR=$(CURDIR)/debian/tmp install; \
cd ..; \
done
install -D -m644 debian/fonts.alias \
@@ -80,15 +93,15 @@ install: build
 
 # Build architecture-dependent files here.
 binary-arch: build install

Bug#418818: xterm: strange creeping background problem on redraw when using mutt and screen

[Branden Robinson]

Package: xterm
Version: 225-1
Severity: normal
Tags: upstream

I'm not sure exactly where the bug lies here -- it could be in screen,
mutt, ncurses, or xterm.  I'm going with xterm for now because rxvt, while
it also exhibits a bug, doesn't exhibit exactly the same bug.

It appears that xterm sometimes forgets what color to paint certain
character cells.

How to reproduce:
1) Be running screen.
2) Have mutt running with a folder (index) view in 2 different screen
   windows.
3) Go to the one of the mutt windows in screen.
   (You may already notice that the top-line menu bar's background color is
   not drawn all the way across the xterm window.)
4) Switch to the other mutt window in screen.
   (You should notice that the top-line menu bar's background color is not
   present all the way across the window.  For me, it stops with the last
   character that has a foreground glyph.)
5) Press enter to tell mutt to view a message in the folder.
   (Again, the background color of the top line stops with the last real
   character drawn.)
6) Press 'i' to tell mutt to return to the folder view.
   (Notice how some correct background color has crept in from the right
   side, leaving a gap in the middle of the top line with the default
   terminal background color.)
7) Repeat steps 5) and 6), pressing no other keys, and watch how each time
   you return to the folder view, the gap with the wrong background color
   gets progressively smaller.
8) Eventually, the folder index is rendered correctly.  The gap persists in
   message view as well, but doesn't get larger.  Some of the gap is
   clobbered from the left because mutt writes more text to the menu bar in
   that view than in folder view, though.
9) CTRL-L at any time (with the affected screen window active) cleans all
   of this up.

rxvt-unicode-ml seems to be broken slightly differently.  Instead, as you
repeat steps 5) and 6), it forgets the correct background color for more
and more character cells, not fewer.

I took a ton of screenshots to document this.  Please find a compressed tar
archive at the following URL:

http://necrotic.deadbeast.net/tmp/creeping_mutt.tar.gz

It contains the following files:
xterm01.png
xterm02.png
xterm03.png
xterm04.png
xterm05.png
xterm06.png
xterm07.png
xterm08.png
xterm09.png
xterm10.png
xterm11.png
xterm12.png
xterm13.png
xterm14.png
xterm15.png
xterm16.png
xterm17.png
xterm18.png
xterm19.png
rxvt01.png
rxvt02.png
rxvt03.png

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: powerpc (ppc)

Kernel: Linux 2.6.15-1-powerpc-smp (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages xterm depends on:
ii  libc6   2.3.6.ds1-13 GNU C Library: Shared libraries
ii  libfontconfig1  2.4.2-1.2generic font configuration library
ii  libice6 1:1.0.1-2X11 Inter-Client Exchange library
ii  libncurses5 5.5-5Shared libraries for terminal hand
ii  libsm6  1:1.0.1-3X11 Session Management library
ii  libx11-62:1.0.3-7X11 client-side library
ii  libxaw7 1:1.0.2-4X11 Athena Widget library
ii  libxext61:1.0.1-2X11 miscellaneous extension librar
ii  libxft2 2.1.8.2-8FreeType-based font drawing librar
ii  libxmu6 1:1.0.2-2X11 miscellaneous utility library
ii  libxt6  1:1.0.2-2X11 toolkit intrinsics library
ii  xbitmaps1.0.1-2  Base X bitmaps

Versions of packages xterm recommends:
ii  xutils  1:7.1.ds.3-1 X Window System utility programs

-- no debconf information


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

Bug#418324: xterm: baffling weirdness with 9x15 font and some Unicode glyphs

[Branden Robinson]

On Mon, Apr 09, 2007 at 08:21:25PM -0400, Thomas Dickey wrote:
 On Mon, Apr 09, 2007 at 01:14:17AM -0400, Branden Robinson wrote:
  On Sun, Apr 08, 2007 at 08:27:18PM -0400, Thomas Dickey wrote:
   grep'ing the code, I see some special case in wcwidth.c (the built-in 
   flavor)
   which may be related - makes xterm treat those codes as double-width.  I 
   expect
   they're being scaled.
  
  xterm does treat them as double-width in all the default bitmap fonts in
  the resources; but it's only in 9x15 that the glyph doesn't render, which
  suggests to me another layer to the problem.
 
 Perhaps not 9x15 - in the default font, which is actually 6x13, I see the
 angle brackets looking more like parentheses - and not scaled.

You're right.  The glyphs look okay in 6x13, don't get rendered at all in
9x15, and look like they've been scaled in an ugly way in the other fonts.

(nil2 excepted, as I don't know what I'm looking at there.)

-- 
G. Branden Robinson|The basic test of freedom is
Debian GNU/Linux   |perhaps less in what we are free to
[EMAIL PROTECTED] |do than in what we are free not to
http://people.debian.org/~branden/ |do.  -- Eric Hoffer


signature.asc
Description: Digital signature

xfonts-base: Changes to 'debian-unstable'

[Branden Robinson]

 debian/changelog |   12 ++
 debian/copyright |  235 ++-
 2 files changed, 228 insertions(+), 19 deletions(-)

New commits:
commit 781fe1fc9dd8667fc3f5135e7595f6bd190485ba
Author: Branden Robinson [EMAIL PROTECTED](none)
Date:   Sun Apr 8 15:07:40 2007 -0400

Update Debian copyright file.
+ Remove Adobe copyright notices; nothing in the upstream sources
  case-insensitive matches adobe, let alone bears a copyright notice of
  theirs.
+ Add many copyright notices, licenses, and other notations of status
  (such as public domain') from upstream sources.
+ Add other information required by Debian Policy §12.5.

diff --git a/debian/changelog b/debian/changelog
index 75dc4d0..0e2bc8d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+xfonts-base (1:1.0.0-5) UNRELEASED; urgency=low
+
+  * Update Debian copyright file.
++ Remove Adobe copyright notices; nothing in the upstream sources
+  case-insensitive matches adobe, let alone bears a copyright notice of
+  theirs.
++ Add many copyright notices, licenses, and other notations of status
+  (such as public domain') from upstream sources.
++ Add other information required by Debian Policy §12.5.
+
+ -- Branden Robinson [EMAIL PROTECTED]  Sun,  8 Apr 2007 14:59:14 -0400
+
 xfonts-base (1:1.0.0-4) unstable; urgency=low
 
   [ Eugene Konev ]
diff --git a/debian/copyright b/debian/copyright
index 850cf94..2e65b3d 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -1,19 +1,216 @@
-Copyright 1984-1989, 1994 Adobe Systems Incorporated.
-Copyright 1988, 1994 Digital Equipment Corporation.
-
-Adobe is a trademark of Adobe Systems Incorporated which may be
-registered in certain jurisdictions.
-Permission to use these trademarks is hereby granted only in
-association with the images described in this file.
-
-Permission to use, copy, modify, distribute and sell this software
-and its documentation for any purpose and without fee is hereby
-granted, provided that the above copyright notices appear in all
-copies and that both those copyright notices and this permission
-notice appear in supporting documentation, and that the names of
-Adobe Systems and Digital Equipment Corporation not be used in
-advertising or publicity pertaining to distribution of the software
-without specific, written prior permission.  Adobe Systems and
-Digital Equipment Corporation make no representations about the
-suitability of this software for any purpose.  It is provided as
-is without express or implied warranty.
+Source package: xfonts-base
+Obtained from:
+XXX: upstream GIT URLs for:
+font-arabic-misc-X11R7.0-1.0.0
+font-cursor-misc-X11R7.0-1.0.0
+font-daewoo-misc-X11R7.0-1.0.0
+font-dec-misc-X11R7.0-1.0.0
+font-isas-misc-X11R7.0-1.0.0
+font-jis-misc-X11R7.0-1.0.0
+font-micro-misc-X11R7.0-1.0.0
+font-misc-misc-X11R7.0-1.0.0
+font-mutt-misc-X11R7.0-1.0.0
+font-schumacher-misc-X11R7.0-1.0.0
+font-sony-misc-X11R7.0-1.0.0
+font-sun-misc-X11R7.0-1.0.0
+Upstream author(s):
+various; see copyright notices below
+Debian package author(s):
+Stephen Early
+Mark Eichin
+Branden Robinson
+ISHIKAWA Mutsumi
+Scott James Remnant
+Daniel Stone
+David Nusinow
+
+Debian copyright(s)/licence(s):
+
+Unless otherwise noted, all modifications and additions to the upstream soruces
+found in this Debian package bear the following copyright and license terms:
+
+Copyright 1996-2004 Branden Robinson
+
+Permission is hereby granted, free of charge, to any person obtaining a 
copy
+of this software and associated documentation files (the Software), to
+deal in the Software without restriction, including without limitation the
+rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+sell copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL 
THE
+AUTHOR(S) AND COPYRIGHT HOLDER(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
DEALINGS
+IN THE SOFTWARE.
+
+Upstream copyright(s)/licence(s):
+
+font-arabic-misc-X11R7.0-1.0.0/COPYING:
+Copyright 1996, 1997, 1998, 1999 Computing Research Labs, New Mexico State
+University
+
+Permission is hereby granted, free of charge, to any person obtaining a 
copy

xfonts-base: Changes to 'debian-unstable'

[Branden Robinson]

 debian/changelog |2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

New commits:
commit d166d905ea79da85caced2105c2973ab688babab
Author: Branden Robinson [EMAIL PROTECTED](none)
Date:   Sun Apr 8 15:16:29 2007 -0400

Fix typo.

diff --git a/debian/changelog b/debian/changelog
index 0e2bc8d..412d1bd 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -5,7 +5,7 @@ xfonts-base (1:1.0.0-5) UNRELEASED; urgency=low
   case-insensitive matches adobe, let alone bears a copyright notice of
   theirs.
 + Add many copyright notices, licenses, and other notations of status
-  (such as public domain') from upstream sources.
+  (such as public domain) from upstream sources.
 + Add other information required by Debian Policy §12.5.
 
  -- Branden Robinson [EMAIL PROTECTED]  Sun,  8 Apr 2007 14:59:14 -0400


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

Bug#418324: xterm: baffling weirdness with 9x15 font and some Unicode glyphs

[Branden Robinson]

Package: xterm
Version: 222-3
Severity: normal
Tags: upstream

This is an upstream issue, I'll wager.

The root of my complaint is that the Unicode glyphs LEFT-POINTING ANGLE
BRACKET (U+2329) and RIGHT-POINTING ANGLE BRACKET (U+232A) don't render
when I size my xterms up to the Large font.  This was brought to my
attention because GNU roff renders URLs between these glyphs in UTF-8
environments.  (On a Debian system, an example of a manpage that uses the
.URL macro is update-fonts-alias, but there are many others.)

At first I thought this was just an oversight in the 9x15 font, as those
glyphs render fine.  So fired up gbdfed to have a look, intending to draw
my own glyphs and submit a patch.

Imagine my surprise when I found that the font does define glyphs there.
Next I thought, well, maybe the bounding box is wrong, or it's declared as
a normal-width character but is really double-width.  Those guesses appear
to be wrong, too:

STARTCHAR angleleft
ENCODING 9001
SWIDTH 576 0
DWIDTH 9 0
BBX 9 15 0 -3
BITMAP


0400
0400
0800
0800
1000
1000
0800
0800
0400
0400



ENDCHAR
STARTCHAR angleright
ENCODING 9002
SWIDTH 576 0
DWIDTH 9 0
BBX 9 15 0 -3
BITMAP


1000
1000
0800
0800
0400
0400
0800
0800
1000
1000



ENDCHAR

I'm not really clear on what SWIDTH and DWIDTH are, but they (and the
bounding box BBOX) are the same as glyph 9000 (U+2328 KEYBOARD), which
renders fine.

So then I thought maybe it's a bug in xterm.  After floundering a bit,
because konsole doesn't want to play with bitmap fonts and fails to
install them when its convoluted dialogs offer to, and gnome-terminal
wanted to install a few dozen megs of dependencies, including Epiphrany and
dvd+rw-tools (?!), I settled on rxvt-unicode-ml.

I was in for another surprise.  urxvt displays the glyphs correctly -- but
then so does xterm, when I launch it manually!  (Usually I just let the
session manager start all the xterms I use.)  What's more, both urxvt and
xterm suddenly forget how to render U+2328 and U+232B (ERASE TO THE
LEFT), which my usual xterms that can't render angle brackets handle just
fine!

There is one difference between urxvt and xterm -- the angle bracket glyphs
I *do* get look right on urxvt, but xterm is showing me some ugly stuff
that reminds me of the semigraphics characters on the TRS-80 Model I.

I've worked with X for a long time but this has me stumped.

What on earth is going on?

Here's my $HOME/.Xresources; as you can see, I don't change XTerm's fonts:

! Personal Xresources file

XClipboard*Form*Text*font:  fixed

XConsole.verbose:   true
XConsole*iconic:false
XConsole*geometry:  1272x89+0-58
XConsole*saveLines: 1000
XConsole*font:  6x10

XTerm*autoWrap: true
XTerm*curses:   true
XTerm*loginShell:   true
XTerm*reverseWrap:  true
XTerm*scrollBar:true
XTerm*saveLines:5000
XTerm*scrollTtyOutput:  false
XTerm*trimSelection:true
XTerm*visualBell:   true
XTerm*activeIcon:   true
XTerm.VT100.background: gray30
XTerm.VT100.foreground: gray90
XTerm.VT100.geometry:   200x67-0+0
XTerm.VT100.color4: DodgerBlue1
XTerm.VT100.color8: gray50
XTerm.VT100.color12:SteelBlue1
XTerm.VT100.scrollbar.background:   white
XTerm.VT100.scrollbar.foreground:   blue

UXTerm*autoWrap:true
UXTerm*curses:  true
UXTerm*loginShell:  true
UXTerm*reverseWrap: true
UXTerm*scrollBar:   true
UXTerm*saveLines:   5000
UXTerm*scrollTtyOutput: false
UXTerm*trimSelection:   true
UXTerm*visualBell:  true
UXTerm*activeIcon:  true
UXTerm.VT100.background:gray30
UXTerm.VT100.foreground:gray90
UXTerm.VT100.geometry:  200x67-0+0
UXTerm.VT100.color4:DodgerBlue1
UXTerm.VT100.color8:gray50
UXTerm.VT100.color12:   SteelBlue1
UXTerm.VT100.scrollbar.background:   white
UXTerm.VT100.scrollbar.foreground:  blue

XCalc*IconName: xcalc

XLock.star.delay: 2
XLock.star.batchcount: 100
XLock.star.saturation: 1.0
XLock.star.rock: on
XLock.star.trek: 0

! vim:ai:noet:sts=8:sw=8:tw=0:

-- System Information:
Debian Release: 4.0
  APT prefers oldstable
  APT policy: (500, 'oldstable'), (500, 'testing'), (500, 'stable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1-powerpc-smp
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages xterm depends on:
ii  libc6   2.3.6.ds1-13 GNU C Library: Shared libraries
ii  libfontconfig1  2.4.2-1.2generic font configuration library
ii  libice6 1:1.0.1-2X11 Inter-Client Exchange library
ii  libncurses5 5.5-5Shared libraries for terminal hand
ii  libsm6  1:1.0.1-3X11 Session Management library
ii  libx11-62:1.0.3-7X11 client-side 

Bug#418324: URL to screenshot

[Branden Robinson]

I forgot to add a screen shot as documentary evidence.

http://necrotic.deadbeast.net/tmp/glyph_weirdness.png

-- 
G. Branden Robinson|Those who fail to remember the laws
Debian GNU/Linux   |of science are condemned to
[EMAIL PROTECTED] |rediscover some of the worst ones.
http://people.debian.org/~branden/ |-- Harold Gordon


signature.asc
Description: Digital signature

Bug#418324: URL to screenshot

[Branden Robinson]

Missing qualification in my bug description:

 At first I thought this was just an oversight in the 9x15 font, as those
 glyphs render fine.

That is, they render fine in all the other default xterm fonts, except
possibly for Unreadable (nil2).

-- 
G. Branden Robinson|   I am not young enough to know
Debian GNU/Linux   |   everything.
[EMAIL PROTECTED] |   -- Oscar Wilde
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

xfonts-base: Changes to 'debian-unstable'

[Branden Robinson]

 debian/changelog |   13 +++--
 debian/control   |7 ---
 2 files changed, 11 insertions(+), 9 deletions(-)

New commits:
commit 474af23b1cf341c6e7dd0fefa00646bb1b12cb0e
Author: Branden Robinson [EMAIL PROTECTED](none)
Date:   Sun Apr 8 20:57:55 2007 -0400

Update package description.

+ Stop claiming that the package also provides font file manipulation
  utilities.  It no longer does; those moved to xfonts-utils.  (To aid
  transitions, xfonts-base should have grown a dependency on xfonts-utils,
  but etch is out now and it's too late to help people upgrading from
  sarge.)
+ Stop documenting the dependency on xutils; debhelper now worries about
  this for us via dh_installxfonts and ${misc:Depends}, so the dependency
  is no longer directly our responsibility.

diff --git a/debian/changelog b/debian/changelog
index 412d1bd..4e314f2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -7,8 +7,17 @@ xfonts-base (1:1.0.0-5) UNRELEASED; urgency=low
 + Add many copyright notices, licenses, and other notations of status
   (such as public domain) from upstream sources.
 + Add other information required by Debian Policy §12.5.
-
- -- Branden Robinson [EMAIL PROTECTED]  Sun,  8 Apr 2007 14:59:14 -0400
+  * Update package description.
++ Stop claiming that the package also provides font file manipulation
+  utilities.  It no longer does; those moved to xfonts-utils.  (To aid
+  transitions, xfonts-base should have grown a dependency on xfonts-utils,
+  but etch is out now and it's too late to help people upgrading from
+  sarge.)
++ Stop documenting the dependency on xutils; debhelper now worries about
+  this for us via dh_installxfonts and ${misc:Depends}, so the dependency
+  is no longer directly our responsibility.
+
+ -- Branden Robinson [EMAIL PROTECTED]  Sun,  8 Apr 2007 20:54:40 -0400
 
 xfonts-base (1:1.0.0-4) unstable; urgency=low
 
diff --git a/debian/control b/debian/control
index 6b499be..f908caa 100644
--- a/debian/control
+++ b/debian/control
@@ -24,10 +24,3 @@ Description: standard fonts for X
  If you are not using a remote font server, you must install this package
  if you are installing an X server.  It contains fonts, including the
  'fixed' font, without which X servers will not work.
- .
- This package also provides a set of files that can be used by the X or
- fonts server to transcode fonts from one encoding to another (e.g., KOI8-R
- to ISO-8859-5).
- .
- This package requires the xutils package to prepare the font directories
- for use by an X server or X font server.


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

xterm: Changes to 'debian-unstable'

[Branden Robinson]

 debian/NEWS  |   18 --
 debian/changelog |7 +++
 2 files changed, 7 insertions(+), 18 deletions(-)

New commits:
commit c06d72edee7c099d5ee45853c8b5a24264c6373b
Author: Branden Robinson [EMAIL PROTECTED](none)
Date:   Sun Apr 8 22:39:29 2007 -0400

Remove debian/NEWS.

The events it attested to (like the upcoming 7.0 modularization are no
longer news, and are in the past.

diff --git a/debian/NEWS b/debian/NEWS
deleted file mode 100644
index 7769a1c..000
--- a/debian/NEWS
+++ /dev/null
@@ -1,18 +0,0 @@
-xterm (204-0pre1) experimental; urgency=low
-
-  * The xterm package has been splitted from the upstream X.Org tree, in
-advance of the upcoming modularization in X.Org 7.0.
-  * This first release will go to experimental distribution, in order to test
-if the transition has been successful.
-  * Several things have changed, probably the most obvious is that xterm and
-companions are now installed under /usr/bin instead of /usr/X11R6/bin, now
-that we got rid of imake and use autoconf tools.
-  * Also, wide fonts and 256-colour support have been added to xterm. It was a
-long awaited feature, I think. Please test if the new xterm fulfill all
-your wishes.
-
- -- David Martínez Moreno [EMAIL PROTECTED]  Fri, 23 Sep 2005 12:24:29 +0200
-
-  $Id$
-
-# vim:set ai et sw=2 ts=2 tw=78:
diff --git a/debian/changelog b/debian/changelog
index 3452e02..612a6a6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+xterm (225-2) unstable; urgency=low
+
+  * Remove debian/NEWS; the events it attested to (like the upcoming 7.0
+modularization are no longer news, and are in the past.
+
+ -- Branden Robinson [EMAIL PROTECTED]  Sun,  8 Apr 2007 22:37:50 -0400
+
 xterm (225-1) unstable; urgency=low
 
   * New upstream release.


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

Bug#418324: xterm: baffling weirdness with 9x15 font and some Unicode glyphs

[Branden Robinson]

On Sun, Apr 08, 2007 at 08:27:18PM -0400, Thomas Dickey wrote:
 grep'ing the code, I see some special case in wcwidth.c (the built-in flavor)
 which may be related - makes xterm treat those codes as double-width.  I 
 expect
 they're being scaled.

xterm does treat them as double-width in all the default bitmap fonts in
the resources; but it's only in 9x15 that the glyph doesn't render, which
suggests to me another layer to the problem.

 I have a to-do item to make it configurable whether the built-in or system
 wcwidth() is used; looks like this case would be interesting to compare.

I did not know that character width was determined by codepoint rather than
by font-specific information, but if this is something Unicode is
standardizing, I think that's a good thing.

The code chart for this block of Unicode (Miscellaneous Technical)[1] seems
to suggest that these glyphs should be fullwidth, or at least wide enough
to have the angle brackets hug the other symbols they enclose, but I find
it difficult to argue for the normativity of that observation without more
background.

[1] http://www.unicode.org/charts/PDF/U2300.pdf

-- 
G. Branden Robinson| If you have the slightest bit of
Debian GNU/Linux   | intellectual integrity you cannot
[EMAIL PROTECTED] | support the government.
http://people.debian.org/~branden/ | -- anonymous


signature.asc
Description: Digital signature

Bug#418324: another screenshot

[Branden Robinson]

Here's another screen shot, showing the same glyphs at every one of the
stock font sizes.

http://necrotic.deadbeast.net/tmp/more_glyph_weirdness.png

-- 
G. Branden Robinson|Patriotism is your conviction that
Debian GNU/Linux   |this country is superior to all
[EMAIL PROTECTED] |others because you were born in it.
http://people.debian.org/~branden/ |-- George Bernard Shaw


signature.asc
Description: Digital signature

Bug#202096: xfs: plan for running as non-root user and better FPE handling

[Branden Robinson]

On Tue, Feb 20, 2007 at 03:34:38AM +0200, Guillem Jover wrote:
 Hi,
 
 On Mon, 2007-02-19 at 23:20:22 +0100, Brice Goglin wrote:
  While cleaning the XSF BTS, I found this old wishlist about your plan to
  run XFs as non-root user. The thread ended in november 2003 but I didn't
  see anything happening accordingly. Did the idea get abandoned? Should I
  keep the wishlist open?
 
 Yes, I think we should definitely fix this for lenny.

I agree -- only laziness is responsible for its remaining unfixed, not
inapplicability.  :)

-- 
G. Branden Robinson|Damnit, we're all going to die;
Debian GNU/Linux   |let's die doing something *useful*!
[EMAIL PROTECTED] |-- Hal Clement, on comments that
http://people.debian.org/~branden/ |   space exploration is dangerous


signature.asc
Description: Digital signature

more tutorial info on wiki.debian.org

[Branden Robinson]

Hi folks,

I've added a couple of HOWTO sections to the XStrikeForce/svn-usage page:

* Use Environment Variables to Save Yourself Some Typing
* Merging New Upstream Releases to a Vendor Branch

-- 
G. Branden Robinson|The basic test of freedom is
Debian GNU/Linux   |perhaps less in what we are free to
[EMAIL PROTECTED] |do than in what we are free not to
http://people.debian.org/~branden/ |do.  -- Eric Hoffer


signature.asc
Description: Digital signature

minor web content updates on necrotic

[Branden Robinson]

Hi folks,

I've shut down two things that have long outlived their usefulness on
necrotic:

* The SVN repository snapshotting cron job.  Many of you may not remember
  this; it was only operative on the XFree86 repository, and is beyond
  irrelevant now.
* The XSF web page itself.  I've set up a seeother redirect for /xsf.* to
  URL: http://wiki.debian.org/XStrikeForce .

A new service I hope to deploy as soon as David Martínez Moreno has some
packages ready is ViewVC (the renamed and much-improved ViewCVS).  When I
set this up I will do so for all the XSF SVN repos.  My snapshotting cron
job was just a kludge to work around the fact that ViewCVS has been broken
for SVN repos for over a year.

-- 
G. Branden Robinson|One man's theology is another man's
Debian GNU/Linux   |belly laugh.
[EMAIL PROTECTED] |-- Robert Heinlein
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

Re: X Strike Force X.Org X11 SVN commit: r2573 - in trunk/app/xbase-clients: debian xprop-X11R7.0-1.0.1

[Branden Robinson]

On Thu, Jul 27, 2006 at 06:57:56AM +0300, Daniel Stone wrote:
 This is not what was committed.

My comment block was wrong, as I noted in
URL: https://bugs.freedesktop.org/show_bug.cgi?id=7647#c3 , which I
made about 11 minutes after your git commit, and prior to committing r2573.

My apologies if I misused Bugzilla somehow.

-- 
G. Branden Robinson|If I recall correctly, devfs went
Debian GNU/Linux   |straight from being marked as
[EMAIL PROTECTED] |EXPERIMENTAL to OBSOLETE in the
http://people.debian.org/~branden/ |kernel config. -- Tore Anderson


signature.asc
Description: Digital signature

Re: svn structure: branch vs trunk

[Branden Robinson]

On Sat, Jul 22, 2006 at 09:05:25PM +1000, Drew Parsons wrote:
 I am planning to bring some Xprint packages into the svn repository. Is
 there any documentation for the structure of the repository?  For
 instance I notice there is the trunk directory
 (http://necrotic.deadbeast.net/svn/xorg-x11/trunk/), but it seems to be
 out of date relative to xorg-x11/branches/7.1.  Should I be commiting my
 new packages to branches/7.1 or where?

After discussion on IRC, it appears branches/7.1 is the right place.

I'm not sure why; historically I used for managine different *Debian*
release suites, not different upstream ones.

If someone could shed some light on the reasons why branches/7.1 was
created, it might help us develop a strategy for managing the repo
structure going forward.

 Likewise from time to time we'll want to upload more recent versions of
 individual modules than the versions matching the latest X11R7
 amalgamated release.  For instance at the moment we'll want to upload
 libxfont 1.2, even though v1.1 matches X11R7.1.  Would libxfont 1.2 go
 into branches/7.1 regardless, or into trunk?

Again, I think a branch structure based on a Debian target might be
indicated:

branches/etch (for testing security, and RC issues close to release
   when auto-propagation from sid is switched off)
branches/sarge (for stable security)
branches/experimental

Historically, the trunk would map to branches/sid.

Also, I'm not sure we should branch the whole shebang, ever, now that
upstream has everything in neat modules.  We should probably only branch
individual modules on an as-needed basis.

 I've used cvs routinely before but I'm new to svn, so I'm not certain
 yet if branching means the same in svn as in cvs.

Kind of.  The main difference is that it's much cheaper to branch in SVN
than CVS.  A branch, like a tag, is just a pointer until changes are made,
and those changes are represented as deltas.

http://svnbook.red-bean.com/nightly/en/svn.branchmerge.html

The biggest hurdle I had to get over as a CVS refugee was that repository
layout is arbitrary.  There's nothing special about trunk, branches, or
tags.  They're just names.

 p.s. just to throw a spanner in the works, is anyone agitating to move
 the repository to git to follow X.org upstream?

I've been having to learn a little bit of git thanks to my job, but I'm not
a frequent committer anymore, either.  I'd say this decision should be
driven by consensus of those who do most of the committing.

I'm happy to host git on necrotic, and run gitweb there as well as any
other reasonable ancillary tools.

-- 
G. Branden Robinson| If God had intended for man to go
Debian GNU/Linux   | about naked, we would have been
[EMAIL PROTECTED] | born that way.
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

Re: svn structure: branch vs trunk

[Branden Robinson]

On Mon, Jul 24, 2006 at 07:38:30PM +1000, Drew Parsons wrote:
 Another question: how the hell do I commit changes to the repository?
 
 I can checkout from http: or svn:, but when I try to commit, it says the
 repository is read-only.  
 
 If I try to checkout or copy with svn+ssh:, then it says No repository
 found
 
   ;(

I know from IRC that you already got an answer, but the difference is that
the svn+ssh schema uses filesystem paths instead of SVN-specific ones.  So
everything is the same except you have to tack /var/lib/svn onto the
front of the path.

I apologize for leaving this information out of my greeting message; I have
updated the document so that future committers will see it.

-- 
G. Branden Robinson|To Republicans, limited government
Debian GNU/Linux   |means not assisting people they
[EMAIL PROTECTED] |would sooner see shoveled into mass
http://people.debian.org/~branden/ |graves.  -- Kenneth R. Kahn


signature.asc
Description: Digital signature

Bug#235144: let's try that again

[Branden Robinson]

merge 197526 235144
thanks

On Wed, Jul 26, 2006 at 10:12:41PM -0400, Branden Robinson wrote:
 merge 197526 253144
 forwarded 197526 https://bugs.freedesktop.org/show_bug.cgi?id=7647
 tag 197526 + patch
 thanks
 
 Patch attached.
 
 -- 
 G. Branden Robinson| You don't just decide to break
 Debian GNU/Linux   | Kubrick's code of silence and then
 [EMAIL PROTECTED] | get drawn away from it to a
 http://people.debian.org/~branden/ | discussion about cough medicine.

-- 
G. Branden Robinson|
Debian GNU/Linux   | Ab abusu ad usum non valet
[EMAIL PROTECTED] | consequentia.
http://people.debian.org/~branden/ |
Index: xprop.c
===
--- xprop.c (revision 2474)
+++ xprop.c (working copy)
@@ -1199,6 +1199,12 @@
nbytes = sizeof(short);
 else if (actual_format == 8)
nbytes = 1;
+else if (actual_format == 0)
+   /*
+* Some broken implementations can return zero, despite what the
+* XGetWindowProperty manual page says.
+*/
+   nbytes = 0;
 else
abort();
 *length = min(nitems * nbytes, max_len);


signature.asc
Description: Digital signature

Bug#197526: merge the only 2 xprop bugs in the BTS

[Branden Robinson]

merge 197526 253144
forwarded 197526 https://bugs.freedesktop.org/show_bug.cgi?id=7647
tag 197526 + patch
thanks

Patch attached.

-- 
G. Branden Robinson| You don't just decide to break
Debian GNU/Linux   | Kubrick's code of silence and then
[EMAIL PROTECTED] | get drawn away from it to a
http://people.debian.org/~branden/ | discussion about cough medicine.
Index: xprop.c
===
--- xprop.c (revision 2474)
+++ xprop.c (working copy)
@@ -1199,6 +1199,12 @@
nbytes = sizeof(short);
 else if (actual_format == 8)
nbytes = 1;
+else if (actual_format == 0)
+   /*
+* Some broken implementations can return zero, despite what the
+* XGetWindowProperty manual page says.
+*/
+   nbytes = 0;
 else
abort();
 *length = min(nitems * nbytes, max_len);


signature.asc
Description: Digital signature

Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T

[Branden Robinson]

On Fri, Jan 20, 2006 at 12:51:36PM -0500, Branden Robinson wrote:
 On Mon, Jan 16, 2006 at 12:23:50PM +0100, Michel Dänzer wrote:
  
  Hi Branden,
  
  On Sat, 2006-01-14 at 11:42 -0500, Branden Robinson wrote:
   
   Section Device
 Identifier  ATI Radeon 9000
 Driver  ati
 Option  UseFBDev  true
 Option  MonitorLayout TMDS,CRT
   EndSection
  
  Does commenting out one or both of these options make a difference?
 
 I'll give that a try this weekend.  Earlier this week I was away from the
 machine.
 
 Thanks for the suggestion!

Er, I completely zoned on this.  FWIW, I am now running:

ii  xserver-xorg  7.0.18the X.Org X server
ii  xserver-xorg-core 1.0.2-8   X.Org X server -- core 
server
ii  xserver-xorg-input-all7.0.18the X.Org X server -- input 
driver metapackage
ii  xserver-xorg-input-evdev  1.0.0.5-2 X.Org X server -- evdev 
input driver
ii  xserver-xorg-input-kbd1.0.1.3-2 X.Org X server -- keyboard 
input driver
ii  xserver-xorg-input-mouse  1.0.4-3   X.Org X server -- mouse 
input driver
ii  xserver-xorg-input-synaptics  0.14.4-5  Synaptics TouchPad driver 
for X.Org/XFree86 server
ii  xserver-xorg-input-wacom  0.7.4.1-2 X.Org X server -- wacom 
input driver
ii  xserver-xorg-video-all7.0.18the X.Org X server -- 
output driver metapackage
ii  xserver-xorg-video-ati6.5.8.0-1 X.Org X server -- ATI 
display driver
ii  xserver-xorg-video-chips  1.0.1.3-3 X.Org X server -- Chips 
display driver
ii  xserver-xorg-video-fbdev  0.1.0.5-2 X.Org X server -- fbdev 
display driver
ii  xserver-xorg-video-glint  1.0.1.3-3 X.Org X server -- Glint 
display driver
ii  xserver-xorg-video-imstt  1.0.0.5-2 X.Org X server -- IMSTT 
display driver
ii  xserver-xorg-video-mga1.2.1.3.dfsg.1-2  X.Org X server -- MGA 
display driver
ii  xserver-xorg-video-nv 1.0.1.5-2 X.Org X server -- NV 
display driver
ii  xserver-xorg-video-s3 0.3.5.4-3 X.Org X server -- legacy S3 
display driver
ii  xserver-xorg-video-s3virge1.8.6.5-2 X.Org X server -- S3 ViRGE 
display driver
ii  xserver-xorg-video-savage 2.0.2.3-4 X.Org X server -- Savage 
display driver
ii  xserver-xorg-video-sis0.8.1.3-2 X.Org X server -- SiS 
display driver
ii  xserver-xorg-video-sisusb 0.7.1.3-2 X.Org X server -- SiS USB 
display driver
ii  xserver-xorg-video-tdfx   1.1.1.3-3 X.Org X server -- tdfx 
display driver
ii  xserver-xorg-video-trident1.0.1.2-2 X.Org X server -- Trident 
display driver
ii  xserver-xorg-video-v4l0.0.1.5-1 X.Org X server -- Video 4 
Linux display driver
ii  xserver-xorg-video-vga4.0.0.5-2 X.Org X server -- VGA 
display driver

But there has been no evident change.

A few data points:

Commenting out both no difference
Commenting out only MonitorLayout no difference
Commenting out only UseFBDev  even worse!

Even worse consists of vertical red stripes on the screen.  Please see
the digital camera photo at:

  http://redwald.deadbeast.net/tmp/branden_grief_3.jpeg

It's a little dark but using flash was worse, and you should still be able
to get the gist of the interference.

I do have one further data point which renders the X.Org X server usable
again.

At least as far back as 6.8.2, the X server has had a problem in which the
display gets shifted several pixels to the right.  This usually happened
after power-cycle events on the monitor, but with 7.0 I note that it
happens across server resets too.  On my Samsung SyncMaster 213T I cannot
perform manual adjustments to the positioning on a digital input, so at
first this is really awful.

However, if I use xvidtune to adjust the screen *either* left *or* right
(you'd think only left would work), the screen image is centered perfectly.

This worked back in 6.8.2, and I never filed a bug about it.  7.0 still
exhibits this problem (and the fix still works) *but*, doing this
adjustment also makes the pink interference go away.  I haven't tested in
the commening out only UseFBDev case yet.

So this pink suffusion problem and the off-centered image problem seem to
be correlated somehow.

Please let me know if I can provide any further information.

-- 
G. Branden Robinson|  If you wish to strive for peace of
Free Software Developer|  soul, then believe; if you wish to
[EMAIL PROTECTED]  |  be a devotee of truth, then
http://deadbeast.net/~branden/ |  inquire. -- Friedrich Nietzsche


signature.asc
Description: Digital signature

Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T

[Branden Robinson]

On Mon, Jan 16, 2006 at 12:23:50PM +0100, Michel Dänzer wrote:
 
 Hi Branden,
 
 On Sat, 2006-01-14 at 11:42 -0500, Branden Robinson wrote:
  
  Section Device
  Identifier  ATI Radeon 9000
  Driver  ati
  Option  UseFBDev  true
  Option  MonitorLayout TMDS,CRT
  EndSection
 
 Does commenting out one or both of these options make a difference?

I'll give that a try this weekend.  Earlier this week I was away from the
machine.

Thanks for the suggestion!

-- 
G. Branden Robinson| When I die I want to go peacefully
Debian GNU/Linux   | in my sleep like my ol' Grand
[EMAIL PROTECTED] | Dad...not screaming in terror like
http://people.debian.org/~branden/ | his passengers.


signature.asc
Description: Digital signature

Bug#348082: xserver-xorg: [ati/radeon] pinkness and interference pattern on Radeon RV250 If [Radeon 9000] rev 1 and TMDS-connected Samsung SyncMaster 213T

[Branden Robinson]

Package: xserver-xorg
Version: 6.9.0.dfsg.1-2
Severity: normal
Tags: upstream

This is a regression from 6.8.2.dfsg.1-11.

I don't even know how to begin to describe the problem I'm having beyond
what's in the bug subject.

The amount of pinkness and intereference seems to vary with how saturated
the rest of the screen is.

I took two pictures of my monitor.  The images are way too large to attach,
so I have put them up on one of my web servers.

http://redwald.deadbeast.net/tmp/branden_grief_1.jpeg
http://redwald.deadbeast.net/tmp/branden_grief_2.jpeg

Sadly, this is so distracting I'll have to downgrade to 6.8.2.dfsg.1-11.

Congratulations on getting 6.9.0 into unstable nonetheless.  :)

-- Package-specific info:
Contents of /var/lib/xfree86/X.roster:
xserver-xfree86
xserver-xfree86-dbg
xserver-xorg

/etc/X11/X target unchanged from checksum in /var/lib/xfree86/X.md5sum.

X server symlink status:
lrwxrwxrwx 1 root root 17 Sep 27 10:24 /etc/X11/X - /usr/bin/X11/Xorg
-rwxr-xr-x 1 root root 2188224 Jan  6 14:37 /usr/bin/X11/Xorg

Contents of /var/lib/xfree86/xorg.conf.roster:
xserver-xorg

VGA-compatible devices on PCI bus:
:00:10.0 VGA compatible controller: ATI Technologies Inc Radeon RV250 If 
[Radeon 9000] (rev 01)
0001:10:13.0 VGA compatible controller: XGI - Xabre Graphics Inc Volari Z7

/etc/X11/xorg.conf does not match checksum in /var/lib/xfree86/xorg.conf.md5sum.

Xorg X server configuration file status:
-rw-r--r-- 1 root root 3096 Jan 14 10:07 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
#  (Xorg X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the  manual page.
# (Type man  at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following commands as root:
#
#   cp  .custom
#   md5sum  /var/lib/xfree86/.md5sum
#   dpkg-reconfigure xserver-xorg

Section Files
FontPathunix/:7100# local font server
# if the local font server has problems, we can fall back on these
FontPath/usr/lib/X11/fonts/misc
FontPath/usr/lib/X11/fonts/cyrillic
FontPath/usr/lib/X11/fonts/100dpi/:unscaled
FontPath/usr/lib/X11/fonts/75dpi/:unscaled
FontPath/usr/lib/X11/fonts/Type1
FontPath/usr/lib/X11/fonts/CID
FontPath/usr/lib/X11/fonts/100dpi
FontPath/usr/lib/X11/fonts/75dpi
EndSection

Section Module
LoadGLcore
Loadbitmap
Loaddbe
Loadddc
Loadextmod
Loadfreetype
Loadglx
Loadint10
Loadrecord
Loadspeedo
Loadtype1
Loadvbe
EndSection

Section InputDevice
Identifier  Generic Keyboard
Driver  keyboard
Option  CoreKeyboard
Option  XkbRules  xorg
Option  XkbModel  pc104
Option  XkbLayout us
Option  XkbOptionsctrl:nocaps,compose:ralt
EndSection

Section InputDevice
Identifier  Configured Mouse
Driver  mouse
Option  CorePointer
Option  Device/dev/input/mice
Option  Protocol  ImPS/2
Option  Emulate3Buttons   false
Option  ZAxisMapping  4 5
EndSection

Section Device
Identifier  ATI Radeon 9000
Driver  ati
Option  UseFBDev  true
Option  MonitorLayout TMDS,CRT
EndSection

Section Monitor
Identifier  Samsung SyncMaster 213T
Option  DPMS
HorizSync   30-75
VertRefresh 50-85
EndSection

Section Screen
Identifier  Default Screen
Device  ATI Radeon 9000
Monitor Samsung SyncMaster 213T
DefaultDepth24
SubSection Display
Depth   1
Modes   1600x1200 1280x960 1152x864 1024x768 
800x600 640x480
EndSubSection
SubSection Display
Depth   4
Modes   1600x1200 1280x960 1152x864 1024x768 
800x600 640x480
EndSubSection
SubSection Display
Depth   8
Modes   1600x1200 1280x960 1152x864 1024x768 
800x600 640x480
EndSubSection
SubSection Display
Depth   15
Modes   1600x1200 1280x960 1152x864 1024x768 
800x600 640x480
EndSubSection
SubSection Display

necrotic.deadbeast.net SVN services back up

[Branden Robinson]

On Fri, Aug 26, 2005 at 01:11:33AM -0500, Branden Robinson wrote:
 I'm taking svnserve access down on necrotic now to dump/load the following
 XSF repositories:
 
 xcursor
 xft
 xorg-old
 xrender
 xsftoolbox
 
 These are all Berkeley DB repos, and as David Nusinow noted earlier today,
 this is yet again causing us grief.  Thanks for the heads-up, David.
 
 I'll load them as FSFS repositories, which since I'm running SVN 1.2.0 on
 necrotic now, will have the added benefit of xdeltifying them[1].
 
 Also, I'm going to rename the xsftoolbox repository to just xsf.  This
 is because the Debian X FAQ should move there at some point (and be hauled
 in by any packages that need it via svn:externals), and it should have a
 name that more obviously identifies it as a central, common location for
 XSF-related resources.
 
 You can use svn switch --relocate to migrate any existing checkouts of
 the xsftoolbox repository.  Use svn help switch for assistance.

This work is done.  Everything seems to be working fine.

FYI, the other things that should move to the newly-named xsf repository
are the files in the root of the xfree86 repository.

-- 
G. Branden Robinson|
Debian GNU/Linux   |   Bother, said Pooh, as he was
[EMAIL PROTECTED] |   assimilated by the Borg.
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

brief downtime on necrotic.deadbeast.net starting

[Branden Robinson]

I'm taking Subversion services down on necrotic for a few minutes to
upgrade to my patched version of Subversion 1.2.0-1[1].

I'm not doing the dump/restore of the repositories yet to get the big
xdeltification.  I'll send out another mail when I disrupt services to do
that.

[1] http://necrotic.deadbeast.net/tmp/subversion/

-- 
G. Branden Robinson|If I recall correctly, devfs went
Debian GNU/Linux   |straight from being marked as
[EMAIL PROTECTED] |EXPERIMENTAL to OBSOLETE in the
http://people.debian.org/~branden/ |kernel config. -- Tore Anderson


signature.asc
Description: Digital signature

necrotic.deadbeast.net back up

[Branden Robinson]

Upgrade successful, and services re-enabled.  HTTP and SVN+SSH access both
appear to work fine.

Let me know if you experience any problems.

-- 
G. Branden Robinson|  The more you do, the more people
Debian GNU/Linux   |  will dislike what you do.
[EMAIL PROTECTED] |  -- Gerfried Fuchs
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

downtime expected on necrotic.deadbeast.net (SVN repo host)

[Branden Robinson]

Hi folks,

I'm expecting to bring Subversion services down on necrotic at some point
soon, possibly this evening.

Now that there's a known fix for bug #314381[1], I have successfully built
and used a patched Subversion 1.2.0-1 package for client-side operations
against the XSF repositories.

I now plan to build, install, and test patched 1.2.0-1 packages on
necrotic, and if I find no problems, dump and restore the xfree86 and
xorg-x11 repositories to get them using xdelta compression exclusively (see
the Subversion 1.2 release notes[2] for why).

Please watch this list for mails announcing the actual beginning of
downtime, and notice of service restoration (or problems, but
hopefully there won't be any of those).  I'm hoping the outage won't last
more than an hour.

#314381 was a showstopper for me and was the only thing keeping me from
upgrading to Subversion 1.2 on necrotic.  Those who have already upgraded
their clients should see performance improvements[3] due to various
optimizations in 1.2 as well as the new xdelta compression method.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=314381
[2] http://subversion.tigris.org/svn_1.2_releasenotes.html
[3] But don't expect the world, poor necrotic is only a 300 MHz UltraSPARC
II with 256MB of RAM.  Starting to live up to its name, I think... :)

-- 
G. Branden Robinson|It is the responsibility of
Debian GNU/Linux   |intellectuals to tell the truth and
[EMAIL PROTECTED] |expose lies.
http://people.debian.org/~branden/ |-- Noam Chomsky


signature.asc
Description: Digital signature

Bug#320059: xvfb: SEGV in XCopyPlane() triggered by VSW4 test suite (part of LSB 3.0 certification suite)

[Branden Robinson]

Package: xvfb
Version: 4.3.0.dfsg.1-14
Severity: important
Tags: upstream fixed-upstream

Xvfb has a bug in it that is tickled by the VSW4 test suite.  One of the
tests in that suite (/tset/CH06/cpypln/cpypln 3), now enabled as part of
the LSB 3.0 conformance checks, causes xvfb to SEGV in XCopyPlane().

Jeff Licquia tells me that the Xvfb from X.Org X11 6.8.1 fixed this
problem; it should therefore be possible to borrow a patch from
freedesktop.org CVS or the X.Org X11 6.8.2 packages to fix this.

We may want to try to push this fix into a stable-update release for sarge;
while not in itself an LSB test failure, it does make using Debian Sarge
itself as a platform for testing LSB conformance significantly more painful
than it should be.  Jeff says this is actually vital for demonstrating
the LSB conformance of Sarge, assuming our other (relatively few)
LSB-related problems are resolved.

(This is not a problem for LSB 2.0, because that version's conformance test
suite switches this test off.)

CCing Matt Taggart so that he knows to flag this as a Sarge LSB issue.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.9-powerpc-smp
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

Bug#312953: render: new upstream version (0.9) released 2005-06-10

[Branden Robinson]

Package: render
Severity: wishlist

As of a few minutes ago, Keith Packard released Render 0.9.

URL: http://xlibs.freedesktop.org/release/renderext-0.9.tar.gz

Since this is needed to build xorg-x11 from Subversion without a nasty
kludge, I plan to handle this within the next few days (maybe even
tonight).

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.9-powerpc-smp
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

Bug#312954: xrender: new upstream version (0.9.0) released 2005-06-10

[Branden Robinson]

Package: xrender
Severity: wishlist

As of a few minutes ago, Keith Packard released libXrender 0.9.0.

URL: http://xlibs.freedesktop.org/release/libXrender-0.9.0.tar.gz

Since this is needed to build xorg-x11 from Subversion without a nasty
kludge, I plan to handle this within the next few days (maybe even
tonight).

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.9-powerpc-smp
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

-- 
G. Branden Robinson| I suspect Linus wrote that in a
Debian GNU/Linux   | complicated way only to be able to
[EMAIL PROTECTED] | have that comment in there.
http://people.debian.org/~branden/ | -- Lars Wirzenius


signature.asc
Description: Digital signature

[decision] new patch management system in xorg-x11

[Branden Robinson]

On Sun, Mar 20, 2005 at 03:13:16PM -0500, Branden Robinson wrote:
 As some of you may have noticed, I've dropped the build-dependency on
 dbs[1] in the fledgling xorg-x11 SVN repository[2].

...but now it's coming back.

My focus has been on DPL stuff and the sarge release for the past couple of
months, but the general consensus (with David Nusinow's finger heavily on
the scale since he's the only one besides me who's committing to the
xorg-x11 SVN repo) appears to be:

* Stick with dbs for now so that changing build systems doesn't slow the
  progress of xorg-x11 into experimental;

* Migrate to quilt and traditional .orig.tar.gz/.diff.gz afterwards.  This
  includes having all patches applied to trunk/xc in SVN.  For the reasons
  why this is good, see my previous message[2].

Denis made a very strong case for quilt, and no one appears to have been
willing to rebut it.  I had been leaning against quilt because it confused
the hell out of me when I first encountered it in a Debian package, but
Denis's tutorial[1] was quite helpful.

Since I'm the one who seems to care the most about this, I propose to do
the build/patch system retooling on a branch after we've uploaded xorg-x11
-0pre1v1 to experimental.

Anyone wanna help?  :)

[1] Message-ID: [EMAIL PROTECTED]
[2] Message-ID: [EMAIL PROTECTED]

-- 
G. Branden Robinson|
Debian GNU/Linux   |  Ignorantia judicis est calamitas
[EMAIL PROTECTED] |  innocentis.
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

Bug#308783: xfree86 SVN trunk ready for branch merge and release

[Branden Robinson]

I've tested all the xfree86 packages built from the current SVN trunk in my
chroots.

Upgrade/downgrade and install/purge tests pass.

Fabio, build at will and upload unless the RM team says not to.  Remember
to ask the RMs to force -14 into sarge.

Now I've got to pack for Brazil.  :)

-- 
G. Branden Robinson|  When dogma enters the brain, all
Debian GNU/Linux   |  intellectual activity ceases.
[EMAIL PROTECTED] |  -- Robert Anton Wilson
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

Bug#309811: xfree86-common: FAQ should say X.Org, not freedesktop.org, is the vendor of the X.Org modular tree

[Branden Robinson]

Package: xfree86-common
Version: 4.3.0.dfsg.1-13
Severity: minor

Note to XSF: set submitter to Daniel Stone [EMAIL PROTECTED] after BTS
acks bug.

Also note that per the release policy[1], this bug is not fixable for
sarge.  We may need to fix it in x11-common (xorg-x11) for etch.

- Forwarded message from Daniel Stone [EMAIL PROTECTED] -

From: Daniel Stone [EMAIL PROTECTED]
To: X Strike Force SVN Repository Admin [EMAIL PROTECTED]
Cc: debian-x@lists.debian.org
Subject: Re: X Strike Force X.Org X11 SVN commit: r114 - in trunk/debian: . 
local
Date: Tue, 17 May 2005 13:56:55 +1000
Message-ID: [EMAIL PROTECTED]
Mail-Followup-To: X Strike Force SVN Repository Admin [EMAIL PROTECTED],
debian-x@lists.debian.org
User-Agent: Mutt/1.5.6+20040907i

On Mon, May 16, 2005 at 10:39:00PM -0500, X Strike Force SVN Repository Admin 
wrote:
 +pFuthermore, there was near-consensus that Debian should switch to the 
 X.Org
 +source tree, with the goal of migrating to the modularized tree over time.  
 We
 +expect that the monolithic X.Org distribution will be modularized in a 
 piecewise
 +fashion; as that happens, we will switch off the building of packages from 
 the
 +X.Org monolithic tree in favor of the modularized components that become
 +available from code class=otherfreedesktop.org/code./p

X.Org is the upstream vendor of the modular tree, not fd.o.



- End forwarded message -

[1] http://lists.debian.org/debian-devel-announce/2005/05/msg00011.html

-- 
G. Branden Robinson|I must despise the world which does
Debian GNU/Linux   |not know that music is a higher
[EMAIL PROTECTED] |revelation than all wisdom and
http://people.debian.org/~branden/ |philosophy. -- Ludwig van Beethoven


signature.asc
Description: Digital signature

Bug#308783: RFC: Bug#308783: libxpm4: problems with s_popen (CAN-2004-0914)

[Branden Robinson]

Could I get a second opinion (or more than one) from you guys as to whether
this is actually an exploitable security problem?

I have been talking to Steve Langasek in his capacity as a Release Manager
about this, and he says if it's not an exploitable problem, then it's not
really a security issue, not really RC, and therefore not deserving of
excepting from the freeze.

Note that I cloned this bug for stable as #309143, and whatever conclusions
are reached here will probably map to that as well.

I asked Matej to follow-up with more information about this, and to contact
freedesktop.org and/or MITRE for a CAN allocation, but haven't heard
anything back from him yet.

If there's any more information I can provide, please let me know.

- Forwarded message from Matej Vela [EMAIL PROTECTED] -

From: Matej Vela [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Bug#308783: libxpm4: problems with s_popen (CAN-2004-0914)
Date: Thu, 12 May 2005 12:59:04 +0200
Message-ID: [EMAIL PROTECTED]
List-Id: debian-x.lists.debian.org
X-Mailing-List: debian-x@lists.debian.org archive/latest/26382
User-Agent: Mutt/1.5.6+20040907i
X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE 
autolearn=no version=2.60-bugs.debian.org_2005_01_02

Package: libxpm4
Version: 4.3.0.dfsg.1-12
Severity: grave
Justification: may allow access to the accounts of users who use the package

The CAN-2004-0914 patch introduced a s_popen() function as a safe
replacement for popen().  Instead of invoking a shell, it splits
arguments on whitespace and passes the command directly to execvp(3).
However, it doesn't handle quoting or redirection, so code like

  WrFFrI.c:339:   snprintf(buf, sizeof(buf), gzip -q  \%s\, filename);
  WrFFrI.c:340:   if (!(mdata-stream.file = s_popen(buf, w)))

results in a  argument and superfluous quotes:

  execve(/bin/gzip, [gzip, , \foo.gz\], [/* 19 vars */])

This completely breaks the transparent compression and decompression.

Furthermore, since gzip processes all arguments regardless of errors, an
attacker can use filenames with whitespace to compress arbitrary files:
(xpmtest taken from https://bugs.freedesktop.org/show_bug.cgi?id=1920)

  # ./xpmtest crab.xpm 'fnord -v /etc/hosts.deny fnord.gz'
  w=28, h=28, cpp=2, cols=6, vmask=, hotspot=0,0
  gzip: : No such file or directory
  gzip: fnord: No such file or directory
  /etc/hosts.deny:   -50.0% -- replaced with /etc/hosts.deny.gz
  gzip: fnord.gz: No such file or directory

The above would effectively disable TCP wrappers.  The -r option can be
used to compress whole directory trees.

s_popen() also has issues with error handling, signals, and runaway
child processes.  All of this has been fixed in X11R6.8.2, though I
don't think they're aware of the security implications (patches at
http://ftp.x.org/pub/X11R6.8.1/patches/ are still vulnerable).

Thanks,

Matej


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


- End forwarded message -

-- 
G. Branden Robinson| Communism is just one step on the
Debian GNU/Linux   | long road from capitalism to
[EMAIL PROTECTED] | capitalism.
http://people.debian.org/~branden/ | -- Russian saying


signature.asc
Description: Digital signature

Bug#308783: libxpm4: problems with s_popen (CAN-2004-0914)

[Branden Robinson]

# This doesn't actually have much to do with CAN-2004-0914.
retitle 308783 libxpm4: new s_popen() function is insecure garbage
# X.Org X11R6.8.2 has code that fixes this.
tag 30783 fixed-upstream
# David Nusinow is working on this.
owne 308783 David Nusinow [EMAIL PROTECTED]
# XFree86 4.1.0 in woody, which ships the Xpm library in a different
# package, has this flaw as well.
clone 308783 -1
retitle -1 xlibs: libxpm4's new s_popen() function is insecure garbage
reassign -1 xlibs
tag -1 woody
thanks

Matej,

If there is a security problem here, and I suppose there is given the
failure of s_open() to properly scrutinize its arguments as you indicate,
then please contact MITRE and ask for a CAN number, and/or ask
freedesktop.org to do so.

-- 
G. Branden Robinson|   If atheism is a religion, then
Debian GNU/Linux   |   health is a disease.
[EMAIL PROTECTED] |   -- Clark Adams
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

Accepted xfree86 4.1.0-16woody6 (powerpc all source)

[Branden Robinson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Thu, 10 Mar 2005 17:08:14 -0500
Source: xfree86
Binary: xserver-common xlibs-dev xfs xfree86-common xfonts-pex x-window-system 
xlibmesa-dev xspecs xlibmesa3 xfonts-cyrillic xlibmesa3-dbg xserver-xfree86 
xlibs-dbg libxaw6 libxaw7 xterm xvfb xfonts-scalable xfonts-75dpi xlib6g 
proxymngr libxaw6-dev xlibs-pic libdps1-dbg xlib6g-dev xfonts-base xutils 
libxaw7-dev xnest xlibs libxaw6-dbg xmh lbxproxy libxaw7-dbg 
xfonts-base-transcoded xbase-clients xprt xlibosmesa3 x-window-system-core 
xlibosmesa-dev twm xfwp xfonts-100dpi-transcoded xlibosmesa3-dbg xfonts-100dpi 
xdm libdps-dev xfonts-75dpi-transcoded libdps1
Architecture: source all powerpc
Version: 4.1.0-16woody6
Distribution: stable-security
Urgency: high
Maintainer: Branden Robinson [EMAIL PROTECTED]
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description: 
 lbxproxy   - Low Bandwidth X (LBX) proxy server
 libdps-dev - Display PostScript (DPS) client library development files
 libdps1- Display PostScript (DPS) client library
 libdps1-dbg - Display PostScript (DPS) client library (unstripped)
 libxaw6- X Athena widget set library (version 6)
 libxaw6-dbg - X Athena widget set library (version 6) (unstripped)
 libxaw6-dev - X Athena widget set library development files (version 6)
 libxaw7- X Athena widget set library
 libxaw7-dbg - X Athena widget set library (unstripped)
 libxaw7-dev - X Athena widget set library development files
 proxymngr  - X proxy services manager
 twm- Tab window manager
 x-window-system - X Window System
 x-window-system-core - X Window System core components
 xbase-clients - miscellaneous X clients
 xdm- X display manager
 xfonts-100dpi - 100 dpi fonts for X
 xfonts-100dpi-transcoded - 100 dpi fonts for X (transcoded from ISO 10646-1)
 xfonts-75dpi - 75 dpi fonts for X
 xfonts-75dpi-transcoded - 75 dpi fonts for X (transcoded from ISO 10646-1)
 xfonts-base - standard fonts for X
 xfonts-base-transcoded - standard fonts for X (transcoded from ISO 10646-1)
 xfonts-cyrillic - Cyrillic fonts for X
 xfonts-pex - fonts for minimal PEX support in X
 xfonts-scalable - scalable fonts for X
 xfree86-common - X Window System (XFree86) infrastructure
 xfs- X font server
 xfwp   - X firewall proxy server
 xlib6g - pseudopackage providing X libraries
 xlib6g-dev - pseudopackage providing X library development files
 xlibmesa-dev - XFree86 version of Mesa 3D graphics library development files
 xlibmesa3  - XFree86 version of Mesa 3D graphics library
 xlibmesa3-dbg - XFree86 version of Mesa 3D graphics library (unstripped)
 xlibosmesa-dev - Mesa/XFree86 off-screen rendering library development files
 xlibosmesa3 - Mesa/XFree86 off-screen rendering library
 xlibosmesa3-dbg - Mesa/XFree86 off-screen rendering library (unstripped)
 xlibs  - X Window System client libraries
 xlibs-dbg  - X Window System client libraries (unstripped)
 xlibs-dev  - X Window System client library development files
 xlibs-pic  - X Window System client extension library PIC archives
 xmh- X interface to the MH mail system
 xnest  - nested X server
 xprt   - X print server
 xserver-common - files and utilities common to all X servers
 xserver-xfree86 - the XFree86 X server
 xspecs - X protocol, extension, and library technical specifications
 xterm  - X terminal emulator
 xutils - X Window System utility programs
 xvfb   - virtual framebuffer X server
Closes: 298939
Changes: 
 xfree86 (4.1.0-16woody6) stable-security; urgency=high
 .
   * Security update release.  Resolves the following issue:
 + CAN-2005-0605: Xpm library's scan.c file may allow attackers to execute
   arbitrary code via a negative bitmap_unit value that leads to a buffer
   overflow.  (Closes: #298939)
 .
   * Update patch #076 (XPM library security fixes) to revert regressions in
 functionality caused by overly aggressive validation of filespec strings
 in OpenReadFile() and OpenWriteFile().  (Fixes #286164 for woody.)
Files: 
 008341b53216f4243930c7ab9eefee78 1512 x11 optional xfree86_4.1.0-16woody6.dsc
 30487abd663a975a939c91657964104d 1620968 x11 optional 
xfree86_4.1.0-16woody6.diff.gz
 7eaf6c70e8487b40326858efe9a6cede 141976 x11 optional 
lbxproxy_4.1.0-16woody6_powerpc.deb
 2c4328c9b53c408534f5b7e664f34de7 188518 libs optional 
libdps1_4.1.0-16woody6_powerpc.deb
 7426a90be3e1ab4521a0936c3fd97a9c 446608 devel extra 
libdps1-dbg_4.1.0-16woody6_powerpc.deb
 d027aec099ddc53fa7ca9e343c68163e 260638 devel optional 
libdps-dev_4.1.0-16woody6_powerpc.deb
 e71a3371682dc101956a645115629c83 179438 libs optional 
libxaw6_4.1.0-16woody6_powerpc.deb
 57afc54ca1cb13c8bf2dae55bb6a31ee 356790 devel extra 
libxaw6-dbg_4.1.0-16woody6_powerpc.deb
 d212615fe6cef3bdf1f6a1dbd43a7c99 331614 devel extra 
libxaw6-dev_4.1.0-16woody6_powerpc.deb
 a4ca4226ecaf53de53ffda14610951e5 233048 libs optional 
libxaw7_4.1.0-16woody6_powerpc.deb

Bug#298939: Regarding xfree86 and CAN-2005-0609

[Branden Robinson]

Hi Joey,

xfree86's fix for CAN-2005-0609 has not yet been uploaded to
testing/unstable.  I expect to make an upload soon, however; the packages
are currently in preparation, and you can view the current status of the
SVN trunk at:

  http://necrotic.deadbeast.net/svn/xfree86/trunk/

specifically:

  http://necrotic.deadbeast.net/svn/xfree86/trunk/debian/changelog

Please go ahead and do the advisory for woody's xfree86 once you're ready.
I've been working with vorlon regarding 4.3.0.dfsg.1-13, and there's no
reason to expect that release to not fix CAN-2005-0609.

-- 
G. Branden Robinson| Suffer before God and ye shall be
Debian GNU/Linux   | redeemed.  God loves us, so He
[EMAIL PROTECTED] | makes us suffer Christianity.
http://people.debian.org/~branden/ | -- Aaron Dunsmore


signature.asc
Description: Digital signature

Bug#298939: Regarding xfree86 and CAN-2005-0609

[Branden Robinson]

Joey,

You can write in the xfree86 DSA for CAN-2005-0609 that the sarge/sid
vulnerability will be fixed by xfree86 4.3.0.dfsg.1-13, which is currently
in preparation.

-- 
G. Branden Robinson|  Never underestimate the power of
Debian GNU/Linux   |  human stupidity.
[EMAIL PROTECTED] |  -- Robert Heinlein
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

Bug#285807: MiscPassMessage() broken

[Branden Robinson]

tag 285807 - moreinfo
thanks

On Fri, Mar 25, 2005 at 05:07:55PM -0500, Branden Robinson wrote:
 Hi Thomas,
 
 I'm sorry it's taken a long time to get back to you.
 
 I'm attaching a patch, based on freedesktop.org CVS (xorg module).
 
 I note that your latest fixes to the MiscPassMessage() implementation
 are only on xorg HEAD, and not in the X.Org X11 6.8.2 release.  I would
 therefore need to backport these fixes into the new xorg-x11 SVN repository
 as well so that this fix doesn't regress.
 
 Do my observations and patch look sane to you?

I never got a reply to this, so I'm going ahead with what I've got,
assuming it compiles and the X server runs.

-- 
G. Branden Robinson|Those who fail to remember the laws
Debian GNU/Linux   |of science are condemned to
[EMAIL PROTECTED] |rediscover some of the worst ones.
http://people.debian.org/~branden/ |-- Harold Gordon


signature.asc
Description: Digital signature

Bug#289328: Processed: retitling and changing severity of 289328

[Branden Robinson]

severity 298328 normal
tag 298328 - upstream
severity 289328 wishlist
tag 289328 + upstream
thanks

On Sun, Apr 10, 2005 at 10:34:39AM +0300, Tommi Virtanen wrote:
 That seems like a typo. Care to fix your mess?

Sorry.  Done.

Consider me spanked.

 Also, please use the package command in the future.

I generally don't because I maintain source packages that create multiple
binaries, and particularly in the case of xfree86, I need to reassign bugs
among the different binary packages.

What I really need is a source command, or a more general constraint
mechanism.  Please see
URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=208130  for more
information.

-- 
G. Branden Robinson| When I die I want to go peacefully
Debian GNU/Linux   | in my sleep like my ol' Grand
[EMAIL PROTECTED] | Dad...not screaming in terror like
http://people.debian.org/~branden/ | his passengers.


signature.asc
Description: Digital signature

Bug#285871: xdm logrotate script eats logs

[Branden Robinson]

clone 285871 -1 -2
retitle 285871 xdm: logrotate script needs improvement
severity 285871 normal
retitle -1 xdm: incapable of reopening its logfile, preventing sane log rotation
retitle -2 xdm: sets up signal handlers that call unsafe functions
tag -1 = upstream
tag -2 = upstream
thanks

On Fri, Mar 25, 2005 at 11:26:17PM +, Andrew Suffield wrote:
 While xdm is running, edit /var/lib/logrotate/status and set the date
 on /var/log/xdm.log to a couple of days ago, then run:
 
 logrotate /etc/logrotate.conf
 
 as root. This causes a new rotation, rather than having to wait for
 it.
 
 After this, you should see:
 
 [EMAIL PROTECTED]:~$ ls -l /var/log/xdm.log*
 -rw-r-  1 root adm0 Mar 25 23:16 /var/log/xdm.log
 -rw-r-  1 root adm 1573 Mar 25 23:16 /var/log/xdm.log.1.gz
 
 [EMAIL PROTECTED]:~$ sudo lsof | grep var/log/xdm
 xdm1965  root2w  REG3,6   8376 179574 
 /var/log/xdm.log.1 (deleted)
 XFree862023  root2w  REG3,6   8376 179574 
 /var/log/xdm.log.1 (deleted)
 xdm2024  root2w  REG3,6   8376 179574 
 /var/log/xdm.log.1 (deleted)
 
 xdm will now proceed to log into this deleted file. Eventually
 xdm.log.1.gz will be rotated out of existance, and xdm will continue
 logging into the deleted file, leaving you with no xdm logs at all.

Fixing this doesn't require just an updated logrotate script; in fact, xdm
never reopens its log file (which is just stderr dup2()ed).

While looking further into this (with some help from Andrew Suffield and
Adam Heath on IRC), I learned that signal handling in general in xdm
appears to be done a bit carelessly -- signal handlers call functions that
are not guaranteed to be safe (like vsnprintf(), which is used by the
logging functions like Debug() and LogInfo() in error.c, and called from
signal handlers like RescanNotify() in dm.c).

The quick-and-dirty way to fix this is just to bolt a new signal handler
onto xdm, for SIGUSR2 (SIGUSR1 is already used internally by xdm as a crude
means of IPC between a parent xdm daemon and its children).

The good way to fix this is to do the above and tidy up xdm's signal
handling in general while I'm at it, but the code has nice(?) features like
nonlocal exits from signal handlers, and I'm going to have to curl up with
_APUE_ before I can make much more progress on that front.  I'll also very
much want someone to audit my changes.  With the sarge freeze imminent, I'm
afraid the quick-and-dirty fix may be the only feasible one for the time
being.

-- 
G. Branden Robinson| Humor is a rubber sword -- it
Debian GNU/Linux   | allows you to make a point without
[EMAIL PROTECTED] | drawing blood.
http://people.debian.org/~branden/ | -- Mary Hirsch


signature.asc
Description: Digital signature

Re: dri_util.c:157: warning: pointer targets differ in signedness.

[Branden Robinson]

On Wed, Dec 29, 2004 at 09:11:29AM +, Philip Armstrong wrote:
 This is now a FAQ answered in the Debian X package docs :) Synopsis:
 Debian is waiting for the modular, autotooled X.org sources to
 happen before shifting to the new X release, on the grounds that
 otherwise they'd have to do all the work (porting the patches,
 checking it all etc etc) twice -- once for the monolithic X.org
 sources and again for the autotooled sources.

[This is a bit off-topic, to say nothing of 3 months late, but I thought
I'd offer the correction nonetheless.]

That's not true.  We do intend to package the monolithic X.Org X11 release,
much as Ubuntu has done.

That work has started at
URL: http://necrotic.deadbeast.net/svn/xorg-x11/trunk/ .

While there's still a fair amount of work to be done, that repository makes
things look even leaner than they are because a lot of the stuff that just
copies over from the xfree86 packaging without modification hasn't been
copied yet.  Right now I'm working through some fairly low-level decisions
with the X Strike Force guys, such as selection of a new patch management
system.

-- 
G. Branden Robinson| That's the saving grace of humor:
Debian GNU/Linux   | if you fail, no one is laughing at
[EMAIL PROTECTED] | you.
http://people.debian.org/~branden/ | -- A. Whitney Brown


signature.asc
Description: Digital signature

Bug#287557: /usr/include/GL/GLwDrawAP.h should not be shipped

[Branden Robinson]

/RCUtilsP.h
lesstif2-dev: /usr/include/Xm/RowColumnP.h
lesstif2-dev: /usr/include/Xm/SashP.h
lesstif2-dev: /usr/include/Xm/ScreenP.h
lesstif2-dev: /usr/include/Xm/ScrollBarP.h
lesstif2-dev: /usr/include/Xm/SelectioBP.h
lesstif2-dev: /usr/include/Xm/SeparatoGP.h
lesstif2-dev: /usr/include/Xm/SeparatorP.h
lesstif2-dev: /usr/include/Xm/ShellEP.h
lesstif2-dev: /usr/include/Xm/TearOffBP.h
lesstif2-dev: /usr/include/Xm/TearOffP.h
lesstif2-dev: /usr/include/Xm/TextFP.h
lesstif2-dev: /usr/include/Xm/TextFSelP.h
lesstif2-dev: /usr/include/Xm/TextInP.h
lesstif2-dev: /usr/include/Xm/TextOutP.h
lesstif2-dev: /usr/include/Xm/TextP.h
lesstif2-dev: /usr/include/Xm/TextSelP.h
lesstif2-dev: /usr/include/Xm/TextStrSoP.h
lesstif2-dev: /usr/include/Xm/VaSimpleP.h
lesstif2-dev: /usr/include/Xm/VendorSP.h
lesstif2-dev: /usr/include/Xm/VirtKeysP.h
lesstif2-dev: /usr/include/Xm/WorldP.h
lesstif2-dev: /usr/include/Xm/XmosP.h
lesstif2-dev: /usr/include/Xm/ArrowBGP.h
lesstif2-dev: /usr/include/Xm/ArrowBP.h
lesstif2-dev: /usr/include/Xm/ColorObjP.h
lesstif2-dev: /usr/include/Xm/ComboBoxP.h
lesstif2-dev: /usr/include/Xm/ContainerP.h
lesstif2-dev: /usr/include/Xm/DisplayP.h
lesstif2-dev: /usr/include/Xm/DrawP.h
lesstif2-dev: /usr/include/Xm/DrawingAP.h
lesstif2-dev: /usr/include/Xm/FileSBP.h
lesstif2-dev: /usr/include/Xm/GadgetP.h
lesstif2-dev: /usr/include/Xm/GrabShellP.h
lesstif2-dev: /usr/include/Xm/IconGP.h
lesstif2-dev: /usr/include/Xm/LabelP.h
lesstif2-dev: /usr/include/Xm/LabelGP.h
lesstif2-dev: /usr/include/Xm/ListP.h
lesstif2-dev: /usr/include/Xm/MenuShellP.h
lesstif2-dev: /usr/include/Xm/NotebookP.h
lesstif2-dev: /usr/include/Xm/PanedWP.h
lesstif2-dev: /usr/include/Xm/PrimitiveP.h
lesstif2-dev: /usr/include/Xm/ScaleP.h
lesstif2-dev: /usr/include/Xm/ScrolledWP.h
lesstif2-dev: /usr/include/Xm/SpinBP.h
lesstif2-dev: /usr/include/Xm/ToggleBGP.h
lesstif2-dev: /usr/include/Xm/ToggleBP.h
lesstif2-dev: /usr/include/Xm/TraitP.h
lesstif2-dev: /usr/include/Xm/TransferP.h
lesstif2-dev: /usr/include/Xm/XmP.h
lesstif2-dev: /usr/include/Xm/XpmP.h
lesstif2-dev: /usr/include/Xm/VendorSEP.h
lesstif2-dev: /usr/include/Xm/PrintSP.h
lesstif2-dev: /usr/include/Xm/SSpinBP.h
lesstif2-dev: /usr/include/Xm/TransltnsP.h

[ 2 asides:
  1) libxaw6-dev will ship much the same files as libxaw7-dev.
  2) WTF is xpaint doing shipping header files?! ]

I'm open to people's thoughts on this.  There's nothing in Debian Policy on
point, as far as I know.

Might private header files be necessary for non-C implementations of
library interfaces?  (XML-RPC and what have you...)

-- 
G. Branden Robinson|It was a typical net.exercise -- a
Debian GNU/Linux   |screaming mob pounding on a greasy
[EMAIL PROTECTED] |spot on the pavement, where used to
http://people.debian.org/~branden/ |lie the carcass of a dead horse.


signature.asc
Description: Digital signature

Bug#287608: Missing dependency on lesstif2-dev?

[Branden Robinson]

retitle 287608 xlibmesa-gl-dev: uses Motif in some fashion, and thus should 
depend on it somehow
tag 287608 + moreinfo
thanks

On Tue, Dec 28, 2004 at 07:34:15PM -0600, Marcelo E. Magallon wrote:
 Package: xlibmesa-gl-dev
 Version: 4.3.0.dfsg.1-9
 Severity: normal
 
 Hi,
 
  the GLw library shipped with the xlibmesa-gl-dev package uses Motif
  (both 1.2 and 2), so some sort of dependency should be declared on
  lesstif2-dev (Depends, Suggests, Recommends).

Can you elaborate, please?

No version of the Motif API is required to build the xfree86 packages, so
this dependency must be pretty weak.

Is it the case that anyone programming against libGLw would also be
#including X11/Xm.h or so?

That's my guess for a quick look at xc/lib/GLw, but GL is really not my
area of expertise.

(If my guess is right, either Recommends or Suggests is warranted, as
people may install xlibmesa-gl-dev without actually planning or needing to
do Motif/LessTif development.)

-- 
G. Branden Robinson|   The software said it required
Debian GNU/Linux   |   Windows 3.1 or better, so I
[EMAIL PROTECTED] |   installed Linux.
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

Bug#287876: File $HOME/.xsession-errors grows very large

[Branden Robinson]

severity 287876 wishlist
retitle 287876 xfree86-common: Xsession does nothing to prevent 
$HOME/.xsession-errors from growing very large
merge 276545 287876
thanks

On Tue, Jan 04, 2005 at 05:06:51PM +0100, Bastian Kleineidam wrote:
 Hi,
 
 is this a duplicate of bug #276545?

Yes.

 I am wondering if it is sufficient to truncate .xsession-errors only on X
 startup, or really make sure that the file never exceeds a certain size.

There are a number of approaches that could be taken.

The only one that no one seems to like is the status quo, where the
responsibility lies on X client software to stop blasting crap to standard
error like a fire hose.

One can't expect too much of GUI programmers, I suppose.

-- 
G. Branden Robinson|I must despise the world which does
Debian GNU/Linux   |not know that music is a higher
[EMAIL PROTECTED] |revelation than all wisdom and
http://people.debian.org/~branden/ |philosophy. -- Ludwig van Beethoven


signature.asc
Description: Digital signature

Bug#287900: xlibs: Want us_intl without deadkeys

[Branden Robinson]

On Thu, Jan 13, 2005 at 11:38:07PM +0100, Denis Barbier wrote:
 On Thu, Dec 30, 2004 at 09:08:44PM +0100, Tim Dijkstra (tdykstra) wrote:
  Package: xlibs
  Version: 4.3.0.dfsg.1-10
  Severity: normal
  Tags: l10n patch
  
  
  In the Netherlands all (well probably  99%) of the pc users have a US
  international keyboard, they also do want to type the Euro character.
  The pc/us(intl) and pc/us_intl (and pc/us(alt-intl) which is identical) 
  layouts
  give you that, but they also gives you very annoying deadkeys. At the moment
  there is no easy way (other then editing one of these files oneself) to get 
  a 
  functional Euro key on a US-intl keyboard _without_ deadkeys.
  
  I added a very small patch that adds this possibility. One can then use
  layout = us_intl, variant = nodeadkeys to get such a layout.
 
 A much better alternative is to add a symbols/eurosign file, as is done
 in xkeyboard-config, so that EuroSign becomes available from any layout.
 But all my previous changes in xlibs were broken, and my intention was
 to not make changes anymore.  Branden and Fabio, what do you think?
 May I add this file and potentially introduce new bugs?

I think you're learned your lesson.  :)

Go ahead, if you like.

-- 
G. Branden Robinson| Never attribute to malice that
Debian GNU/Linux   | which can be adequately explained
[EMAIL PROTECTED] | by stupidity.
http://people.debian.org/~branden/ | -- Hanlon's Razor


signature.asc
Description: Digital signature

Bug#287798: config script for xserver-xfree86 limits refresh rates

[Branden Robinson]

retitle 287798 xserver-xfree86: debconf doesn't always choose optimal monitor 
characteristics automatically
thanks

On Thu, Dec 30, 2004 at 01:03:28AM -0500, chris wrote:
 Package:xserver-xfree86
 Version: 4.3.0.dfsg.1-8_i386  
 
 xserver-xfree86_4.3.0.dfsg.1-8_i386.deb
 
Linux  2.6.8-1-k7  i686 GNU/Linux
 
libc6 Version: 2.3.2.ds1-18
 
 The config script for xserver-xfree86 has a Design, which makes
 it impossible to get maximal/optimal HorizSync/VertRefresh ranges.

That's an overstatement, in my opinion.  You can always pick the Advanced
monitor selection method and enter whatever horizontal sync and vertical
refresh parameters you want.

 /var/lib/dpkg/info/xserver-xfree86.config has limitation of 75 Hz @ 
 1024x768, why it gets 85 Hz I don't know, but my *Reflex FX*7200 model 
 1792E [approx. ~ CTX-1785GM] monitor can do 117 Hz.
 xvidtune picks up a max of 105 Hz:
 
 Vendor: , Model:
 Num hsync: 1, Num vsync: 1
 hsync range 0:  30.00 -  95.00
 vsync range 0:  50.00 - 105.00
 1024x768113.31   1024 1096 1208 1392768  769  772  814 -hsync 
 +vsync

Autodetction is a hard problem, for tedious technical reasons having to do
with the DDC extension to VESA signaling standards, the multiple DDC
implementations out there, the sometimes conflicting versions of those
standards that monitors vs. display adapters choose to support, the
real-mode x86 programming that is required to perform DDC probing, and so
forth.

Due to the above unholy mess, I plan to get Debian's X Window System
packages out of the hardware detection business altogether.  The X server's
maintainer scripts will become a dumb interface to the configuration file,
and it's going to be up to the installation system to get a hardware
detection system in place on the system before configuring the X server.

(Strictly speaking, that's already true, but the fact that the X server's
maintainer scripts actually *try* to do detection today if it hasn't been
done already tempts people to just leave the problem in the X packages'
court.)

The other advantage to decoupling as I propose is that we can just publish
an interface (being a set of debconf templates), and as many X detectors
as the Debian Project chooses to write and/or maintain can fight for
supremacy and userbase.

However, don't look for this overhaul before xorg-x11 6.8.2 enters
unstable.

-- 
G. Branden Robinson|If the license you accept is
Debian GNU/Linux   |oppressive in its terms, that means
[EMAIL PROTECTED] |you can be oppressed.
http://people.debian.org/~branden/ |-- Pamela Jones


signature.asc
Description: Digital signature

Bug#273993: Does not affect the NVIDIA proprietary drivers

[Branden Robinson]

On Sat, Jan 22, 2005 at 04:11:12PM +0100, DEGAND Nicolas wrote:
 Using the NVIDIA proprietary drivers, I'm able to upgrade to 4.3-10

We still need a full backtrace for this problem.  The Debian X FAQ
describes how to get one.

Remember to set LC_MESSAGES=C when running the GNU Debugger, e.g.:

$ LC_MESSAGES=C gdb

Please visit the following URL for a tutorial on debugging the X server:

http://necrotic.deadbeast.net/svn/xfree86/trunk/debian/local/FAQ.xhtml#debugxserver

-- 
G. Branden Robinson|Half of being smart is knowing what
Debian GNU/Linux   |you're dumb at.
[EMAIL PROTECTED] |-- David Gerrold
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

Bug#288225: missing *.png files

[Branden Robinson]

):  
$(DESTDIR)$(DOCHTMLDIR)); \ @@\
  4696  1.2  (eich 23-Apr-04):for i in name*.png; do \  
@@\
  4697  1.2  (eich 23-Apr-04):  if [ -f $$i ]; then (set 
-x; \  @@\
  4698  1.2  (eich 23-Apr-04):$(INSTALL) 
$(INSTALLFLAGS) $(INSTDATFLAGS) $$i \  @@\
  4699  1.2  (eich 23-Apr-04):  
$(DESTDIR)$(DOCHTMLDIR)); \ @@\
  4700  1.2  (eich 23-Apr-04):  fi; \   
@@\
  4701  1.2  (eich 23-Apr-04):done; \   
@@\
  4702  1.2  (eich 23-Apr-04):  fi  
@@\
  4703  1.2  (eich 23-Apr-04):  MakeDir($(DESTDIR)$(DOCPDFDIR)) 
@@\
  4704  1.2  (eich 23-Apr-04):  @if [ -f name.pdf -a X$(NOPDF) 
= X ]; then set -x; \@@\
  4705  1.2  (eich 23-Apr-04):$(INSTALL) $(INSTALLFLAGS) 
$(INSTDATFLAGS) name.pdf \ @@\
  4706  1.2  (eich 23-Apr-04):  $(DESTDIR)$(DOCPDFDIR); 
\   @@\
  4707  1.2  (eich 23-Apr-04):  fi
  4708  1.2  (eich 23-Apr-04): #endif

I expect this bug to be fixed when xorg-x11 6.8.2 is uploaded to unstable.

-- 
G. Branden Robinson| You don't just decide to break
Debian GNU/Linux   | Kubrick's code of silence and then
[EMAIL PROTECTED] | get drawn away from it to a
http://people.debian.org/~branden/ | discussion about cough medicine.


signature.asc
Description: Digital signature

Bug#233870: Processed: moving old pending bugs to my current e-mail

[Branden Robinson]

On Sun, Jan 02, 2005 at 04:48:17PM -0800, Debian Bug Tracking System wrote:
  submitter 233870 !
 Bug#233870: xserver-xfree86: [debconf] write defoma font paths to generated 
 XF86Config files
 Changed Bug submitter from Martin-ric Racine [EMAIL PROTECTED] to 
 =?iso-8859-1?Q?Martin-=C9ric_Racine?= [EMAIL PROTECTED].

On Mon, Jan 03, 2005 at 05:06:25PM +0200, Martin-ric Racine wrote:
 Dear Maintainers,
 
 As reported yesterday by the BTS, I still had bugs submitted via my former
 e-mail address, which I have just reassigned to my current e-mail address.
 
 I would obviously appreciate a followup, because most of those bugs have been
 left unresolved for a LONG time and it would be nice to discuss a solution, so
 that we can eventually close at least some of the bugs.
 
 http://bugs.debian.org/cgi-bin/pkgreport.cgi?submitter=q-funk%40iki.fi

Well, there was only one bug assigned to an X Strike Force package.

That bug has been merged with #230597; you may want to consult my recent
comments there.

-- 
G. Branden Robinson|   The software said it required
Debian GNU/Linux   |   Windows 3.1 or better, so I
[EMAIL PROTECTED] |   installed Linux.
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

Bug#257062: xserver-xfree86: please backport new Intel i910 driver

[Branden Robinson]

On Fri, Mar 18, 2005 at 04:45:57PM +1300, Nick Phillips wrote:
 On 18/03/2005, at 8:04 AM, Branden Robinson wrote:
 If an i915 patch is prepared, works, and has been signed off on by
 i810/i830/i845/i855/i865 as well as i915 users, then the patch submitter
 and these testers can join me in making a case to the Release Managers
 for pushing this into testing-proposed-updates (if xfree86 is frozen by
 then).
 
 OK, I'm working on it. If Jason Lunz gets there first, fine. If not, I'll
 probably get there in a few days, depending on the quantity (and quality)
 of distractions that come up in the meantime...

How's this coming along?

-- 
G. Branden Robinson|The word power is an obscenity in
Debian GNU/Linux   |a democracy.
[EMAIL PROTECTED] |-- Andy Jacobs, Jr.
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

Bug#255749: xterm: Dies with segmentation fault

[Branden Robinson]

tag 255749 + unreproducible
thanks

On Tue, Mar 15, 2005 at 08:44:56PM +0100, Christian Aichinger wrote:
 Hi,
 I can't reproduce the described problem here at all.
 
 Could you possibly provide some more information, for example these
 2 files:
 /etc/X11/app-defaults/XTerm
 /etc/X11/app-defaults/XTerm-color
 
 since these were the last 2 config files read by xterm.

Yes, that's a good point.  The app-defaults or X resources might be
configured such that they're not stock, and are provoking the SEGV.  That
would still be a bug in the underlying application or libraries, as one
shouldn't be able to DoS XTerm with bogus configuration settings.

But until someone can reproduce this problem, we're stuck.  Tagging.

-- 
G. Branden Robinson| The more ridiculous a belief
Debian GNU/Linux   | system, the higher the probability
[EMAIL PROTECTED] | of its success.
http://people.debian.org/~branden/ | -- Wayne R. Bartz


signature.asc
Description: Digital signature