Bug#168098: xserver-xfree86: [mga] XVideo broken in 4.2 for G400
Package: xserver-xfree86 Version: 4.2.1-3 Severity: normal Since XFree 4.2 came into testing, XVideo is broken on MGA G400. The symptoms: when overlay is done via SDL, lower half of the image is shown in the upper half on the overlay window and the lower half of the window is just blue. Or, in some applications, the upper half of the overlay window contains vertically compressed full image and the lower half is blue. It's not exactly half, the upper part is somewhat smaller than the lower part. Things that work: mplayer -vo xv and mplayer with default settings; xawtv. Things that show the symptoms: mplayer -vo sdl and aviplay (start it up, press f for fullscreen). A search through Xpert archives didn't find anything useful, only one similar fuzzy post: http://www.xfree86.org/pipermail/xpert/2002-August/020115.html At first I thought this is because of BIOS upgrade that moved AGP GART from 0xd000 to 0xe000 but a friend had similar symptoms with matrox & xfree 4.2 in sid but with mplayer -xv and these are fixed in 4.2.1-3, at least he cannot reproduce them any more. But this leads me to believe it's a software problem on xfree side. Standard XFree mga driver, no mgahal, no kernel dri module loaded. XVideo worked fine with the latest pre-4.2 X binary in testing. After restart with new X and new BIOS, things got broken (I had forgotten I had upgraded and not restarted X otherwise I would have tested X first). 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 05) 01:00.0 Class 0300: 102b:0525 (rev 05) ### BEGIN DEBCONF SECTION # XF86Config-4 (XFree86 server configuration file) generated by dexconf, the # Debian X Configuration tool, using values from the debconf database. # # Edit this file with caution, and see the XF86Config-4 manual page. # (Type "man XF86Config-4" at the shell prompt.) # # If you want your changes to this file preserved by dexconf, only make changes # before the "### BEGIN DEBCONF SECTION" line above, and/or after the # "### END DEBCONF SECTION" line below. Section "Files" FontPath"unix/: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/Speedo" FontPath"/usr/lib/X11/fonts/100dpi" FontPath"/usr/lib/X11/fonts/75dpi" EndSection Section "ServerFlags" Option "BlankTime" "15" Option "StandbyTime" "30" Option "SuspendTime" "45" Option "OffTime" "60" EndSection Section "Module" Load"GLcore" Load"bitmap" Load"dbe" Load"ddc" Load"dri" Load"extmod" Load"freetype" Load"glx" Load"int10" Load"pex5" Load"record" Load"speedo" Load"type1" Load"vbe" Load"xie" EndSection Section "InputDevice" Identifier "Generic Keyboard" Driver "keyboard" Option "CoreKeyboard" Option "XkbRules" "xfree86" Option "XkbModel" "pc105" Option "XkbLayout" "ee" EndSection Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" Option "CorePointer" Option "Device""/dev/input/mice" Option "Protocol" "ImPS/2" Option "ZAxisMapping" "4 5" EndSection Section "Device" Identifier "Matrox G400 Dualhead" Driver "mga" Option "AGPMode" "4" # Option "UseFBDev" "true" # Option "HWCursor" "false" EndSection Section "Monitor" Identifier "S/M 700IFT" HorizSync 30-92 VertRefresh 50-85 Option "DPMS" EndSection Section "Screen" Identifier "Default Screen" Device "Matrox G400 Dualhead" Monitor "S/M 700IFT" DefaultDepth16 SubSection "Display" Depth 1 Modes "1280x960" "1152x864" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 4 Modes "1280x960" "1152x864" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 8 Modes "1280x960" "1152x864" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth
Re: Some annoying problems with ATi Radeon 7200!
On Mit, 2002-11-06 at 21:17, Manuel Bilderbeek wrote: > > goemon:~> glxgears > Radeon DRI driver: > Compatibility mode for DRM driver version 1.1.1 > TCL will be disabled, expect reduced performance > (prefer DRM radeon.o 1.3.x or newer) > disabling TCL support > glxgears: radeon_ioctl.h:168: radeonAllocCmdBuf: Assertion > `rmesa->dri.drmMinor >= 3' failed. > Abort It's still using the old DRM (radeon.o kernel module), have you installed the drm-module-trunk package you built? Nevertheless, this is a bug, the compatibility code is rotting... > By the way, I saw this: > > (II) RADEON(0): AGP Fast Write disabled by default > > What is AGP Fast Write? I saw in my BIOS an option to turn this on. Is > this useful? It's a performance optimization which may cause instability. Use Option "AGPFastWrite" if you want to try it. > > I don't see anything unusual in the log. Does Option "HWcursor" make the > > problem go away? > > Do I have to put that in the driver section? > I did so, but: > > (II) RADEON(0): Using hardware cursor (scanline 4808) > (WW) RADEON(0): Option "HWcursor" is not used D'oh, I meant Option "SWcursor" of course. The device section is the right place. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast
Re: Some annoying problems with ATi Radeon 7200!
Hi again, Michel Dänzer wrote: >>I configed it more than one time and I can't remember that debconf asked >>me about FBDev... > > Maybe it's a low priority question, otherwise it's probably autodetected > from /proc/fb . Could be, but my /proc/fb is empty. >>However, I have serious problems with the dri packags: >>I can't login anymore, there is a problem with my .xsession; from >>.xsession-errors: >>Xlib: connection to ":0.0" refused by server >>Xlib: Protocol not supported by server >> >>xrdb: Can't open display ':0' >> >>Should I set some permissions somewhere? >> >>Also, my xdm login screen looks entirely different, but I guess that is >>normal... (It looks a lot more ugly, by the way... ;-) > > > In the next version, > /usr/share/doc/xserver-xfree86-dri-trunk/README.Debian will contain: > > * xdm: in /etc/X11/xdm/xdm-config, set > > DisplayManager*authorize: false > > Does this help? It seems to! At least, I could log in now. At first I thought I did something wrong, but the xdm login screen looks normal now, not white anymore! Anyway, there is still a big problem though, my 3D seems broken: goemon:~> glxgears Radeon DRI driver: Compatibility mode for DRM driver version 1.1.1 TCL will be disabled, expect reduced performance (prefer DRM radeon.o 1.3.x or newer) disabling TCL support glxgears: radeon_ioctl.h:168: radeonAllocCmdBuf: Assertion `rmesa->dri.drmMinor >= 3' failed. Abort The XFree86.0.log seems just fine. (Yep, it starts with XFree86 Version 4.2.0 (DRI trunk) / X Window System !) There are no errors there. By the way, I saw this: (II) RADEON(0): AGP Fast Write disabled by default What is AGP Fast Write? I saw in my BIOS an option to turn this on. Is this useful? One very good thing: it seems that the ghosting is a bit less now! I couldn't test with openGL programs (which caused the worst ghosting effects), but it seems that it is a bit less now... (dragging windows around is still causing some of the ghosting though...)) >>How can I tell what depth? > > xdpyinfo|grep 'depth of root' It's 24 planes. > BTW, I just recall experiencing color problems on the 7200 in the gf's > Cube. Seems to be a radeonfb glitch which happens intermittently and > randomly. Well, I don't need fb anyway. > I don't see anything unusual in the log. Does Option "HWcursor" make the > problem go away? Do I have to put that in the driver section? I did so, but: (II) RADEON(0): Using hardware cursor (scanline 4808) (WW) RADEON(0): Option "HWcursor" is not used According to my XFree86 log. Note that the first line was also already in my original log, with the 4.2.1. drivers from Debian. -- Grtjs, Manuel PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ ) PPS: Visit my homepage at http://manuel.msxnet.org/
Bug#168098: xserver-xfree86: [mga] XVideo broken in 4.2 for G400
Package: xserver-xfree86 Version: 4.2.1-3 Severity: normal Since XFree 4.2 came into testing, XVideo is broken on MGA G400. The symptoms: when overlay is done via SDL, lower half of the image is shown in the upper half on the overlay window and the lower half of the window is just blue. Or, in some applications, the upper half of the overlay window contains vertically compressed full image and the lower half is blue. It's not exactly half, the upper part is somewhat smaller than the lower part. Things that work: mplayer -vo xv and mplayer with default settings; xawtv. Things that show the symptoms: mplayer -vo sdl and aviplay (start it up, press f for fullscreen). A search through Xpert archives didn't find anything useful, only one similar fuzzy post: http://www.xfree86.org/pipermail/xpert/2002-August/020115.html At first I thought this is because of BIOS upgrade that moved AGP GART from 0xd000 to 0xe000 but a friend had similar symptoms with matrox & xfree 4.2 in sid but with mplayer -xv and these are fixed in 4.2.1-3, at least he cannot reproduce them any more. But this leads me to believe it's a software problem on xfree side. Standard XFree mga driver, no mgahal, no kernel dri module loaded. XVideo worked fine with the latest pre-4.2 X binary in testing. After restart with new X and new BIOS, things got broken (I had forgotten I had upgraded and not restarted X otherwise I would have tested X first). 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 05) 01:00.0 Class 0300: 102b:0525 (rev 05) ### BEGIN DEBCONF SECTION # XF86Config-4 (XFree86 server configuration file) generated by dexconf, the # Debian X Configuration tool, using values from the debconf database. # # Edit this file with caution, and see the XF86Config-4 manual page. # (Type "man XF86Config-4" at the shell prompt.) # # If you want your changes to this file preserved by dexconf, only make changes # before the "### BEGIN DEBCONF SECTION" line above, and/or after the # "### END DEBCONF SECTION" line below. Section "Files" FontPath"unix/: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/Speedo" FontPath"/usr/lib/X11/fonts/100dpi" FontPath"/usr/lib/X11/fonts/75dpi" EndSection Section "ServerFlags" Option "BlankTime" "15" Option "StandbyTime" "30" Option "SuspendTime" "45" Option "OffTime" "60" EndSection Section "Module" Load"GLcore" Load"bitmap" Load"dbe" Load"ddc" Load"dri" Load"extmod" Load"freetype" Load"glx" Load"int10" Load"pex5" Load"record" Load"speedo" Load"type1" Load"vbe" Load"xie" EndSection Section "InputDevice" Identifier "Generic Keyboard" Driver "keyboard" Option "CoreKeyboard" Option "XkbRules" "xfree86" Option "XkbModel" "pc105" Option "XkbLayout" "ee" EndSection Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" Option "CorePointer" Option "Device""/dev/input/mice" Option "Protocol" "ImPS/2" Option "ZAxisMapping" "4 5" EndSection Section "Device" Identifier "Matrox G400 Dualhead" Driver "mga" Option "AGPMode" "4" # Option "UseFBDev" "true" # Option "HWCursor" "false" EndSection Section "Monitor" Identifier "S/M 700IFT" HorizSync 30-92 VertRefresh 50-85 Option "DPMS" EndSection Section "Screen" Identifier "Default Screen" Device "Matrox G400 Dualhead" Monitor "S/M 700IFT" DefaultDepth16 SubSection "Display" Depth 1 Modes "1280x960" "1152x864" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 4 Modes "1280x960" "1152x864" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 8 Modes "1280x960" "1152x864" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth
Re: userspace servers and /tmp/.X11-unix permissions/owners
On Wed, Nov 06, 2002 at 03:09:26AM -0500, Branden Robinson wrote:
> On Tue, Nov 05, 2002 at 04:04:19PM -0800, Chris Waters wrote:
> > So, when I tried to run startx, I got a complaint that the permissions
> > on /tmp/.X11-unix were "suspicious". Turns out that the permissions
> > were fine ("drwxrwxrwt"), but the dir was owned by "aaron:aaron",
> > rather than "root:root".
> There's a different error message for that:
Interesting. Neither of those messages seem right, but I'm going from
memory here. I'll try to recreate the problem when I have a little time.
> > So, I was wondering: is there a reason that the XFree86 server can't
> > just chown the directory, in the case where the permissions are fine
> > but the owner is wrong? Because otherwise, there seems to be an
> > impasse of sorts.
> Symlink attacks.
Dammit, that even makes sense. Well, if this were C, I could devise
an easy workaround. But since it's shell, I dunno. I'll have to look
into it. Crap. Thanks.
cheers
--
Chris Waters | Pneumonoultra-osis is too long
[EMAIL PROTECTED] | microscopicsilico-to fit into a single
or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: Some annoying problems with ATi Radeon 7200!
On Mit, 2002-11-06 at 21:17, Manuel Bilderbeek wrote: > > goemon:~> glxgears > Radeon DRI driver: > Compatibility mode for DRM driver version 1.1.1 > TCL will be disabled, expect reduced performance > (prefer DRM radeon.o 1.3.x or newer) > disabling TCL support > glxgears: radeon_ioctl.h:168: radeonAllocCmdBuf: Assertion > `rmesa->dri.drmMinor >= 3' failed. > Abort It's still using the old DRM (radeon.o kernel module), have you installed the drm-module-trunk package you built? Nevertheless, this is a bug, the compatibility code is rotting... > By the way, I saw this: > > (II) RADEON(0): AGP Fast Write disabled by default > > What is AGP Fast Write? I saw in my BIOS an option to turn this on. Is > this useful? It's a performance optimization which may cause instability. Use Option "AGPFastWrite" if you want to try it. > > I don't see anything unusual in the log. Does Option "HWcursor" make the > > problem go away? > > Do I have to put that in the driver section? > I did so, but: > > (II) RADEON(0): Using hardware cursor (scanline 4808) > (WW) RADEON(0): Option "HWcursor" is not used D'oh, I meant Option "SWcursor" of course. The device section is the right place. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#135075: xterm: no dead keys in uxterm
On Tue, Feb 19, 2002 at 08:18:56PM +0200, Thomas PARIS wrote: > It seams uxterm starts an xterm that does not support dead keys. > > According to my tests, the problem lies in the fact that uxterm changes > the locale before starting the xterm. > > In fact, I first tried to change my locale to fr_FR.UTF-8 (supported by > my system) and then to start an xterm with the -u8 option and I couldn't > use the dead keys. I have the same (or at least a similar) problem with current X packages (version 4.2.1-3). I am using an UTF-8 locale now by exporting LANG=de_DE.UTF-8 from .xsession, xterm runs with with utf8 resource set. I'm using the compose key instead of dead keys and I can't enter any of the accented characters (like äáàâ etc.). Other chars like ø and ß can be entered without a problem. Problem can be worked around by starting xterm with a locale that's not UTF-8 (e.g. de_DE) then setting LANG in the running xterm. Setting LANG to empty seems to make every non-ASCII character unavailable however, the compose is interpreted like an escape sequence or something ( + " + o acts like esc + 6). The thing is, the same happens to other apps (I just tested galeon, gnumeric, xedit - the accent composes don't even seem to arrive at the app, like in xterm) and can be worked around the same way. The only exception is that other programs do not act differently with empty LANG and LANG=de_DE. There is something going wrong below xterm, either xlibs or libc locales are messing something up with the combination of UTF-8 and accents. -- Andreas Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44
Re: Some annoying problems with ATi Radeon 7200!
Hi again, Michel Dänzer wrote: >>I configed it more than one time and I can't remember that debconf asked >>me about FBDev... > > Maybe it's a low priority question, otherwise it's probably autodetected > from /proc/fb . Could be, but my /proc/fb is empty. >>However, I have serious problems with the dri packags: >>I can't login anymore, there is a problem with my .xsession; from >>.xsession-errors: >>Xlib: connection to ":0.0" refused by server >>Xlib: Protocol not supported by server >> >>xrdb: Can't open display ':0' >> >>Should I set some permissions somewhere? >> >>Also, my xdm login screen looks entirely different, but I guess that is >>normal... (It looks a lot more ugly, by the way... ;-) > > > In the next version, > /usr/share/doc/xserver-xfree86-dri-trunk/README.Debian will contain: > > * xdm: in /etc/X11/xdm/xdm-config, set > > DisplayManager*authorize: false > > Does this help? It seems to! At least, I could log in now. At first I thought I did something wrong, but the xdm login screen looks normal now, not white anymore! Anyway, there is still a big problem though, my 3D seems broken: goemon:~> glxgears Radeon DRI driver: Compatibility mode for DRM driver version 1.1.1 TCL will be disabled, expect reduced performance (prefer DRM radeon.o 1.3.x or newer) disabling TCL support glxgears: radeon_ioctl.h:168: radeonAllocCmdBuf: Assertion `rmesa->dri.drmMinor >= 3' failed. Abort The XFree86.0.log seems just fine. (Yep, it starts with XFree86 Version 4.2.0 (DRI trunk) / X Window System !) There are no errors there. By the way, I saw this: (II) RADEON(0): AGP Fast Write disabled by default What is AGP Fast Write? I saw in my BIOS an option to turn this on. Is this useful? One very good thing: it seems that the ghosting is a bit less now! I couldn't test with openGL programs (which caused the worst ghosting effects), but it seems that it is a bit less now... (dragging windows around is still causing some of the ghosting though...)) >>How can I tell what depth? > > xdpyinfo|grep 'depth of root' It's 24 planes. > BTW, I just recall experiencing color problems on the 7200 in the gf's > Cube. Seems to be a radeonfb glitch which happens intermittently and > randomly. Well, I don't need fb anyway. > I don't see anything unusual in the log. Does Option "HWcursor" make the > problem go away? Do I have to put that in the driver section? I did so, but: (II) RADEON(0): Using hardware cursor (scanline 4808) (WW) RADEON(0): Option "HWcursor" is not used According to my XFree86 log. Note that the first line was also already in my original log, with the 4.2.1. drivers from Debian. -- Grtjs, Manuel PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ ) PPS: Visit my homepage at http://manuel.msxnet.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: userspace servers and /tmp/.X11-unix permissions/owners
On Wed, Nov 06, 2002 at 03:09:26AM -0500, Branden Robinson wrote:
> On Tue, Nov 05, 2002 at 04:04:19PM -0800, Chris Waters wrote:
> > So, when I tried to run startx, I got a complaint that the permissions
> > on /tmp/.X11-unix were "suspicious". Turns out that the permissions
> > were fine ("drwxrwxrwt"), but the dir was owned by "aaron:aaron",
> > rather than "root:root".
> There's a different error message for that:
Interesting. Neither of those messages seem right, but I'm going from
memory here. I'll try to recreate the problem when I have a little time.
> > So, I was wondering: is there a reason that the XFree86 server can't
> > just chown the directory, in the case where the permissions are fine
> > but the owner is wrong? Because otherwise, there seems to be an
> > impasse of sorts.
> Symlink attacks.
Dammit, that even makes sense. Well, if this were C, I could devise
an easy workaround. But since it's shell, I dunno. I'll have to look
into it. Crap. Thanks.
cheers
--
Chris Waters | Pneumonoultra-osis is too long
[EMAIL PROTECTED] | microscopicsilico-to fit into a single
or [EMAIL PROTECTED] | volcaniconi- standalone haiku
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#135075: xterm: no dead keys in uxterm
On Tue, Feb 19, 2002 at 08:18:56PM +0200, Thomas PARIS wrote: > It seams uxterm starts an xterm that does not support dead keys. > > According to my tests, the problem lies in the fact that uxterm changes > the locale before starting the xterm. > > In fact, I first tried to change my locale to fr_FR.UTF-8 (supported by > my system) and then to start an xterm with the -u8 option and I couldn't > use the dead keys. I have the same (or at least a similar) problem with current X packages (version 4.2.1-3). I am using an UTF-8 locale now by exporting LANG=de_DE.UTF-8 from .xsession, xterm runs with with utf8 resource set. I'm using the compose key instead of dead keys and I can't enter any of the accented characters (like äáàâ etc.). Other chars like ø and ß can be entered without a problem. Problem can be worked around by starting xterm with a locale that's not UTF-8 (e.g. de_DE) then setting LANG in the running xterm. Setting LANG to empty seems to make every non-ASCII character unavailable however, the compose is interpreted like an escape sequence or something ( + " + o acts like esc + 6). The thing is, the same happens to other apps (I just tested galeon, gnumeric, xedit - the accent composes don't even seem to arrive at the app, like in xterm) and can be worked around the same way. The only exception is that other programs do not act differently with empty LANG and LANG=de_DE. There is something going wrong below xterm, either xlibs or libc locales are messing something up with the combination of UTF-8 and accents. -- Andreas Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Signal 11 in xserver-xfree86 4.2.1-3
Jacob Elder wrote: > Thank's for the tip, but I'm confused. Do you suggest that I try the > non-free drivers, or just remove mga_hal_drv.o? mga_hal_drv.o *is* a non-free driver, but the one you are using is compiled for X4.03. Either remove it or replace it with the version that is compiled for X4.2 that's in the matrox tarball. You don't need the matrox drivers to do single-head or dual-head with a g450, the only advantage they offer with this particular card is improved 3D performance. -- Simon Hepburn.
Re: Signal 11 in xserver-xfree86 4.2.1-3
Jacob Elder wrote: > Thank's for the tip, but I'm confused. Do you suggest that I try the > non-free drivers, or just remove mga_hal_drv.o? mga_hal_drv.o *is* a non-free driver, but the one you are using is compiled for X4.03. Either remove it or replace it with the version that is compiled for X4.2 that's in the matrox tarball. You don't need the matrox drivers to do single-head or dual-head with a g450, the only advantage they offer with this particular card is improved 3D performance. -- Simon Hepburn. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#167908: xlibs: /usr/X11R6/lib/X11/app-defaults, conflict with cxterm
reassign 167908 cxterm-common thanks On Tue, Nov 05, 2002 at 12:38:17PM -0500, Moses Moore wrote: > Package: xlibs > Version: 4.1.0-17 > Severity: minor > > Preparing to replace xlibs 4.1.0-17 (using .../xlibs_4.2.1-3_i386.deb) > ... > Unpacking replacement xlibs ... > dpkg: error processing /var/cache/apt/archives/xlibs_4.2.1-3_i386.deb > (--unpack): > trying to overwrite `/usr/X11R6/lib/X11/app-defaults', which is also in > package cxterm-common > apt-getErrors were encountered while processing: > /var/cache/apt/archives/xlibs_4.2.1-3_i386.deb > > I know this same bug showed up for conflict with another package. Not > sure if I should be reporting this bug as 'cxterm-common' instead. I'm reassigning it. Thanks for the report. -- G. Branden Robinson|Any man who does not realize that Debian GNU/Linux |he is half an animal is only half a [EMAIL PROTECTED] |man. http://people.debian.org/~branden/ |-- Thornton Wilder pgpyhroziBuaP.pgp Description: PGP signature
Processed: Re: Bug#167908: xlibs: /usr/X11R6/lib/X11/app-defaults, conflict with cxterm
Processing commands for [EMAIL PROTECTED]: > reassign 167908 cxterm-common Bug#167908: xlibs: /usr/X11R6/lib/X11/app-defaults, conflict with cxterm Bug reassigned from package `xlibs' to `cxterm-common'. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Re: userspace servers and /tmp/.X11-unix permissions/owners
On Tue, Nov 05, 2002 at 04:04:19PM -0800, Chris Waters wrote:
> So, when I tried to run startx, I got a complaint that the permissions
> on /tmp/.X11-unix were "suspicious". Turns out that the permissions
> were fine ("drwxrwxrwt"), but the dir was owned by "aaron:aaron",
> rather than "root:root".
There's a different error message for that:
if ((statbuf.st_uid != 0) || (statbuf.st_gid != 0)) {
(void) fprintf(stderr, "X: %s has suspicious ownership (not root:root),
aborting.\n", X_SOCKET_DIR);
exit(1);
}
if (statbuf.st_mode != (S_IFDIR | X_SOCKET_DIR_MODE)) {
(void) fprintf(stderr, "X: %s has suspicious mode (not %o) or is not a
directory, aborting.\n", X_SOCKET_DIR, X_SOCKET_DIR_MODE);
exit(1);
}
Is there something wrong with my code? Why do you think you didn't see
the former message?
> So, I was wondering: is there a reason that the XFree86 server can't
> just chown the directory, in the case where the permissions are fine
> but the owner is wrong? Because otherwise, there seems to be an
> impasse of sorts.
Symlink attacks.
--
G. Branden Robinson| You could wire up a dead rat to a
Debian GNU/Linux | DIMM socket and the PC BIOS memory
[EMAIL PROTECTED] | test would pass it just fine.
http://people.debian.org/~branden/ | -- Ethan Benson
pgpoLPmY7SVMI.pgp
Description: PGP signature
Re: Signal 11 in xserver-xfree86 4.2.1-3
On Tue, Nov 05, 2002 at 11:12:53PM -0500, Jacob Elder wrote: > On Tue, Nov 05, 2002 at 11:35:05PM +, Simon Hepburn wrote: > > http://lists.debian.org/debian-x/2002/debian-x-200210/msg00300.html [...] > Thank's for the tip, but I'm confused. Do you suggest that I try the > non-free drivers, or just remove mga_hal_drv.o? Remove mga_hal_drv.o. It's not compatible with the new version of XFree86. -- G. Branden Robinson| It doesn't matter what you are Debian GNU/Linux | doing, emacs is always overkill. [EMAIL PROTECTED] | -- Stephen J. Carpenter http://people.debian.org/~branden/ | pgpkiSRqX6drR.pgp Description: PGP signature
Ynt: margo flwg
SADECE TÜRK KAÞARLAR VAR!!! DÜNYANIN EN SEKSÝ KIZLARINI CANLI SEYREDÝN! KARÞILIKLI CHAT YAPIN, WEBCAM DE ÝSTEDÝÐÝNÝZ HERÞEYÝ YAPSINLAR! SÝZ ÝSTEYÝN ONLAR SOYUNSUN! TÜRK KIZLARI-TÜRK KAÞARLARI-TÜRK ÜNV. KIZLARI-TÜRK EV KADINLARI VAR! YABANCI HATUN YOK! HEPSÝ SADECE AMA SADECE TÜRK HATUNLARI! VAKÝT KAYBETMEYÝN! Hiçbir yerde göremeyeceðiniz içerik Margo mekanda. http://www.margosex.com
Bug#167908: xlibs: /usr/X11R6/lib/X11/app-defaults, conflict with cxterm
reassign 167908 cxterm-common thanks On Tue, Nov 05, 2002 at 12:38:17PM -0500, Moses Moore wrote: > Package: xlibs > Version: 4.1.0-17 > Severity: minor > > Preparing to replace xlibs 4.1.0-17 (using .../xlibs_4.2.1-3_i386.deb) > ... > Unpacking replacement xlibs ... > dpkg: error processing /var/cache/apt/archives/xlibs_4.2.1-3_i386.deb > (--unpack): > trying to overwrite `/usr/X11R6/lib/X11/app-defaults', which is also in > package cxterm-common > apt-getErrors were encountered while processing: > /var/cache/apt/archives/xlibs_4.2.1-3_i386.deb > > I know this same bug showed up for conflict with another package. Not > sure if I should be reporting this bug as 'cxterm-common' instead. I'm reassigning it. Thanks for the report. -- G. Branden Robinson|Any man who does not realize that Debian GNU/Linux |he is half an animal is only half a [EMAIL PROTECTED] |man. http://people.debian.org/~branden/ |-- Thornton Wilder msg04634/pgp0.pgp Description: PGP signature
Processed: Re: Bug#167908: xlibs: /usr/X11R6/lib/X11/app-defaults, conflict with cxterm
Processing commands for [EMAIL PROTECTED]: > reassign 167908 cxterm-common Bug#167908: xlibs: /usr/X11R6/lib/X11/app-defaults, conflict with cxterm Bug reassigned from package `xlibs' to `cxterm-common'. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: userspace servers and /tmp/.X11-unix permissions/owners
On Tue, Nov 05, 2002 at 04:04:19PM -0800, Chris Waters wrote:
> So, when I tried to run startx, I got a complaint that the permissions
> on /tmp/.X11-unix were "suspicious". Turns out that the permissions
> were fine ("drwxrwxrwt"), but the dir was owned by "aaron:aaron",
> rather than "root:root".
There's a different error message for that:
if ((statbuf.st_uid != 0) || (statbuf.st_gid != 0)) {
(void) fprintf(stderr, "X: %s has suspicious ownership (not root:root),
aborting.\n", X_SOCKET_DIR);
exit(1);
}
if (statbuf.st_mode != (S_IFDIR | X_SOCKET_DIR_MODE)) {
(void) fprintf(stderr, "X: %s has suspicious mode (not %o) or is not a
directory, aborting.\n", X_SOCKET_DIR, X_SOCKET_DIR_MODE);
exit(1);
}
Is there something wrong with my code? Why do you think you didn't see
the former message?
> So, I was wondering: is there a reason that the XFree86 server can't
> just chown the directory, in the case where the permissions are fine
> but the owner is wrong? Because otherwise, there seems to be an
> impasse of sorts.
Symlink attacks.
--
G. Branden Robinson| You could wire up a dead rat to a
Debian GNU/Linux | DIMM socket and the PC BIOS memory
[EMAIL PROTECTED] | test would pass it just fine.
http://people.debian.org/~branden/ | -- Ethan Benson
msg04632/pgp0.pgp
Description: PGP signature
Re: Signal 11 in xserver-xfree86 4.2.1-3
On Tue, Nov 05, 2002 at 11:12:53PM -0500, Jacob Elder wrote: > On Tue, Nov 05, 2002 at 11:35:05PM +, Simon Hepburn wrote: > > http://lists.debian.org/debian-x/2002/debian-x-200210/msg00300.html [...] > Thank's for the tip, but I'm confused. Do you suggest that I try the > non-free drivers, or just remove mga_hal_drv.o? Remove mga_hal_drv.o. It's not compatible with the new version of XFree86. -- G. Branden Robinson| It doesn't matter what you are Debian GNU/Linux | doing, emacs is always overkill. [EMAIL PROTECTED] | -- Stephen J. Carpenter http://people.debian.org/~branden/ | msg04631/pgp0.pgp Description: PGP signature
