Package: xbase-clients
Version: 4.3.0-7
Severity: normal
xclock(1x) does not document the use of Xrender extensions
in xclock. These extensions change the way the xclock
handles command line options; for example the -hd and -hl
options no longer work unless you also specify -norender.
Xfree86 has
Eric Van Buggenhaut <[EMAIL PROTECTED]> wrote in #104241:
> xwd(1) mentions
>
> SEE ALSO
>xwud(1), xpr(1), X(1)
>
> however xpr(1) doesn't exist.
This is fixed in xbase-clients/4.3.0-7 (and perhaps earlier
versions as well).
--Andre
Bugs #80404 and #168147, about typos in the copyright lines
which caused roff to barf on the manpages of several
programs in xbase-clients are fixed in xbase-clients/4.3.0-7
(and perhaps earlier versions too).
--Andre
Alexander Gun <[EMAIL PROTECTED]> wrote in #159325:
> xload -help says:
> -geometry geom size and location of window
>
> but in the manpage there is nothing about this parameter
> and xload doesnt support it.
This is not an issue in 4.1.3. The standard toolkit option
-geometry does w
On Thu, 2 Oct 2003, Branden Robinson wrote:
> There is a tool called "mdetect" (in a package of the same name) that is
> used by the xserver-xfree86 configuration script for this purpose.
> ...
> Well, if the problem comes and goes depending on which version of the
> kernel is running, yes, I'd be
On Thu, 2 Oct 2003, Branden Robinson wrote:
> There is a tool called "mdetect" (in a package of the same name) that is
> used by the xserver-xfree86 configuration script for this purpose.
> ...
> Well, if the problem comes and goes depending on which version of the
> kernel is running, yes, I'd be
On Thu, 2 Oct 2003, Branden Robinson wrote:
> Unfortunately, I can't see any evidence that dexconf tried to set your
> mouse protocol to NetScrollPS/2.
>
> In fact, I can't find any evidence, even in your original report, that
> either mouse device was ever described as using the NetScrollPS/2
> pr
On Thu, 2 Oct 2003, Branden Robinson wrote:
> Unfortunately, I can't see any evidence that dexconf tried to set your
> mouse protocol to NetScrollPS/2.
>
> In fact, I can't find any evidence, even in your original report, that
> either mouse device was ever described as using the NetScrollPS/2
> pr
On Tue, 30 Sep 2003, Branden Robinson wrote:
> Well, I see from the debconf data in your initial report that your mouse
> is in fact configured to use protocol "PS/2". Did you change that in
> the debconf database (e.g., by running dpkg-reconfigure) before filing
> the report?
Sort of. I upgrade
On Tue, 30 Sep 2003, Branden Robinson wrote:
> Well, I see from the debconf data in your initial report that your mouse
> is in fact configured to use protocol "PS/2". Did you change that in
> the debconf database (e.g., by running dpkg-reconfigure) before filing
> the report?
Sort of. I upgrade
On Sat, 27 Sep 2003, Branden Robinson wrote:
> What version did you upgrade from?
The version that was previously in Testing. (I did a
dist-upgrade last week when AJ pushed glibc in.) Poking
around on snapshot.debian.net makes me think it was 4.2.1-6,
but I'm not positive. Sorry I can't be more
On Sat, 27 Sep 2003, Branden Robinson wrote:
> What version did you upgrade from?
The version that was previously in Testing. (I did a
dist-upgrade last week when AJ pushed glibc in.) Poking
around on snapshot.debian.net makes me think it was 4.2.1-6,
but I'm not positive. Sorry I can't be more
Package: xserver-xfree86
Version: 4.2.1-11
Severity: important
When I upgraded to 4.2.1-11 the mouse configuration was
automatically switched from PS/2 to NetscrollPS/2. This led
to random button events whenever I rolled the mouse. Prior
to the upgrade I believe the only customization in my
XF86
Package: xserver-xfree86
Version: 4.2.1-11
Severity: important
When I upgraded to 4.2.1-11 the mouse configuration was
automatically switched from PS/2 to NetscrollPS/2. This led
to random button events whenever I rolled the mouse. Prior
to the upgrade I believe the only customization in my
XF86
A possible workaround is to add '-DNDEBUG' when invoking
makedepend -- this prevents the problem part of assert.h
from being evaluated. Worked for me, since I don't use
NDEBUG to control anything other than assert().
A possible workaround is to add '-DNDEBUG' when invoking
makedepend -- this prevents the problem part of assert.h
from being evaluated. Worked for me, since I don't use
NDEBUG to control anything other than assert().
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe
16 matches
Mail list logo