Bug#667459: Bug confirmed
I just encountered the same bug yesterday. I was running a custom kernel that did not have KMS enabled, and the radeon driver (6.14.4-1) crashes with a segfault upon startup (regardless of the KMS setting in modprobe, so it's not the setting but the KMS itself that made the difference). Downgrading to 6.14.3-2 resolves the problem. Today, I rebuilt the kernel with KMS enabled, and now 6.14.4-1 works without any problem. T -- "I'm not childish; I'm just in touch with the child within!" - RL -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120413153113.ga2...@quickfur.ath.cx
Bug#382120: This bug turns out to be related to running multiple local servers
# This bug also occurs in unstable tags 382120 -experimental # This bug appears to be the same as the multi-head bug severity 382120 important merge 382120 390359 thanks Hi, after upgrading to the latest xorg release in unstable and playing around with my configuration, I discovered that this bug appears to be related to #390359. I don't have a dual head config, but I do have multiple X servers running locally off XDM (on different VT's). As I've filed more information in #390359, I'm merging this bug. T -- Nearly all men can stand adversity, but if you want to test a man's character, give him power. -- Abraham Lincoln -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#392911: Polytonic Greek keyboard map breaks ctrl-alt-F* vt switch sequence
On Sat, Oct 14, 2006 at 10:54:32AM +0200, Denis Barbier wrote:
> On Fri, Oct 13, 2006 at 11:37:38PM -0700, H. S. Teoh wrote:
> > Package: xkb-data
> > Version: 0.9-1
> > Severity: normal
> >
> > Hi, after the latest upgrade, I found that I couldn't switch VT's
> > using the ctrl-alt-F* sequence anymore. After a bit of digging, I
> > discovered that it was because I was using the 'gr(polytonic)'
> > layout using XKB. Removing that mapping from my XKB config fixed
> > the problem. This problem does not occur with monotonic Greek layout
> > ('gr' without the 'polytonic' variant).
> >
>
> Hi,
>
> I cannot reproduce this bug, please send your XKB settings and the
> server-0.xkb file generated by running
> $ xkbcomp :0
[...]
Hmm, `xkbcomp :0` gives no output.
I'm currently using setxkbmap to alternate between different keyboard
layouts. The working configuration is:
setxkbmap us,ru -variant ,phonetic \
-option grp:lwin_toggle,grp_led:scroll
(This is done from .Xsession, but can also be used from any X terminal
like xterm or rxvt.)
The non-working configuration is:
setxkbmap us,ru,gr -variant ,phonetic,polytonic \
-option grp:lwin_toggle,grp_led:scroll
I've tried it with non-polytonic Greek, and it also works:
setxkbmap us,ru,gr -variant ,phonetic, \
-option grp:lwin_toggle,grp_led:scroll
Basically, I use the left 'windows' key to toggle between us, ru, and
gr. The ctrl-alt sequence doesn't work when I specify gr(polytonic) to
setxkbmap, regardless of whether the current layout (selected by lwin)
is actually gr(polytonic) or not. I do get the right characters in
gr(polytonic); the only obvious problem is that the vt-switch sequence
doesn't work (it inserts carets and other symbols instead).
Anyway, I tried to capture the keyboard events using xev, hopefully this
will help you track down the problem. The following is from the
non-working configuration (run xev, type ctrl-alt-F1, which does
nothing, and quit xev):
KeyPress event, serial 24, synthetic NO, window 0xc1,
root 0x4c, subw 0x0, time 1196328814, (1021,765), root:(1022,766),
state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 24, synthetic NO, window 0xc1,
root 0x4c, subw 0x0, time 1196328814, (1021,765), root:(1022,766),
state 0x4, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 24, synthetic NO, window 0xc1,
root 0x4c, subw 0x0, time 1196329991, (1021,765), root:(1022,766),
state 0xc, keycode 67 (keysym 0xffbe, F1), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 24, synthetic NO, window 0xc1,
root 0x4c, subw 0x0, time 1196330220, (1021,765), root:(1022,766),
state 0xc, keycode 67 (keysym 0xffbe, F1), same_screen YES,
XLookupString gives 0 bytes:
KeyRelease event, serial 24, synthetic NO, window 0xc1,
root 0x4c, subw 0x0, time 1196330351, (1021,765), root:(1022,766),
state 0xc, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes:
KeyRelease event, serial 24, synthetic NO, window 0xc1,
root 0x4c, subw 0x0, time 1196330384, (1021,765), root:(1022,766),
state 0x4, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
KeyPress event, serial 24, synthetic NO, window 0xc1,
root 0x4c, subw 0x0, time 1196331253, (1021,765), root:(1022,766),
state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
The following is from the working configuration (run xev, type
ctrl-alt-F1, which switches to vt01, then alt-F7 to switch back to X,
then exit xev):
KeyPress event, serial 24, synthetic NO, window 0xc1,
root 0x4c, subw 0x0, time 1196543663, (1021,765), root:(1022,766),
state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 24, synthetic NO, window 0xc1,
root 0x4c, subw 0x0, time 1196543663, (1021,765), root:(1022,766),
state 0x4, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString giv
Bug#392911: Polytonic Greek keyboard map breaks ctrl-alt-F* vt switch sequence
On Sat, Oct 14, 2006 at 10:54:32AM +0200, Denis Barbier wrote:
[...]
> I cannot reproduce this bug, please send your XKB settings and the
> server-0.xkb file generated by running
> $ xkbcomp :0
[...]
Oops, sorry, I misunderstood. Attached is the server-0.xkb file
generated by xkbcomp.
T
--
The best way to destroy a cause is to defend it poorly.
xkb_keymap {
xkb_keycodes "xfree86+aliases(qwerty)" {
minimum = 8;
maximum = 255;
= 9;
= 10;
= 11;
= 12;
= 13;
= 14;
= 15;
= 16;
= 17;
= 18;
= 19;
= 20;
= 21;
= 22;
= 23;
= 24;
= 25;
= 26;
= 27;
= 28;
= 29;
= 30;
= 31;
= 32;
= 33;
= 34;
= 35;
= 36;
= 37;
= 38;
= 39;
= 40;
= 41;
= 42;
= 43;
= 44;
= 45;
= 46;
= 47;
= 48;
= 49;
= 50;
= 51;
= 52;
= 53;
= 54;
= 55;
= 56;
= 57;
= 58;
= 59;
= 60;
= 61;
= 62;
= 63;
= 64;
= 65;
= 66;
= 67;
= 68;
= 69;
= 70;
= 71;
= 72;
= 73;
= 74;
= 75;
= 76;
= 77;
= 78;
= 79;
= 80;
= 81;
= 82;
= 83;
= 84;
= 85;
= 86;
= 87;
= 88;
= 89;
= 90;
= 91;
= 92;
= 93;
= 94;
= 95;
= 96;
= 97;
= 98;
= 99;
= 100;
= 101;
= 102;
= 103;
= 104;
= 105;
= 106;
= 107;
= 108;
= 109;
= 110;
= 111;
= 112;
= 113;
= 114;
= 115;
= 116;
= 117;
= 118;
= 119;
= 120;
= 121;
= 122;
= 123;
= 124;
= 125;
= 126;
= 127;
= 128;
= 129;
= 130;
= 131;
= 132;
= 133;
= 134;
= 135;
= 136;
= 137;
= 138;
= 139;
= 140;
= 141;
= 142;
= 143;
= 144;
= 145;
= 146;
= 147;
= 148;
= 149;
= 150;
= 151;
= 152;
= 153;
= 154;
= 155;
= 156;
= 157;
= 158;
= 159;
= 160;
= 161;
= 162;
= 163;
= 164;
= 165;
= 166;
= 167;
= 168;
= 169;
= 170;
= 171;
= 172;
= 173;
= 174;
= 175;
= 176;
= 177;
= 178;
= 179;
= 180;
= 181;
= 182;
= 183;
= 184;
= 185;
= 186;
= 187;
= 188;
= 189;
= 190;
= 191;
= 192;
= 193;
= 194;
= 195;
= 196;
= 197;
= 198;
= 199;
= 200;
= 201;
= 202;
= 203;
= 204;
= 205;
= 206;
= 207;
= 208;
= 209;
= 210;
= 211;
= 212;
= 213;
= 214;
= 215;
= 216;
= 217;
= 218;
= 219;
= 220;
= 221;
= 222;
= 223;
= 224;
= 225;
= 226;
= 227;
= 228;
= 229;
= 230;
= 231;
= 232;
= 233;
= 234;
= 235;
= 236;
= 237;
= 238;
= 239;
= 240;
= 241;
= 242;
= 243;
= 244;
= 245;
= 246;
= 247;
= 248;
= 249;
= 250;
= 251;
= 252;
= 253;
= 254;
= 255;
indicator 1 = "Caps Lock";
indicator 2 = "Num Lock";
indicator 3 = "Scroll Lock";
virtual indicator 4 = "Shift Lock";
virtual indicator 5 = "Group 2";
virtual indicator 6 = "Mouse Keys";
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
};
xkb_types "complete" {
virtual_modifiers
NumLock,Alt,LevelThree,ScrollLock,LevelFive,AltGr,Meta,Super,Hyper;
type "ONE_LEVEL" {
modifiers= none;
level_name[Level1]= "Any";
};
type "TWO_LEVEL" {
modifiers= Shift;
map[Shift]= Level2;
level_name[Level1]= "Base";
level_name[Level2]= "Shift";
};
type "ALPHABETIC" {
modifiers= Shift+Lock;
map[Shift]= Level2;
map[Lock]= Level2;
level_name[Level
Bug#392911: Polytonic Greek keyboard map breaks ctrl-alt-F* vt switch sequence
Package: xkb-data
Version: 0.9-1
Severity: normal
Hi, after the latest upgrade, I found that I couldn't switch VT's using
the ctrl-alt-F* sequence anymore. After a bit of digging, I discovered
that it was because I was using the 'gr(polytonic)' layout using XKB.
Removing that mapping from my XKB config fixed the problem. This problem
does not occur with monotonic Greek layout ('gr' without the 'polytonic'
variant).
T
--
There's light at the end of the tunnel. It's the oncoming train.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#390359: Bug confirmed (i810 driver malfunctioning on multi-head setup)
Hi, I just wanted to say that I'm seeing the same problem here, albeit with a slightly different configuration, which hopefully will give some insight into where the bug is. I'm running XDM with two local X servers, :0 and :1, running on vt07 and vt08. This is not a true dual-headed setup; I just have the servers share the same screen but on different VT's. This setup was working fine with the previous version of the i810 driver. After the latest upgrade (to xserver-xorg-video-i810 1.6.5-3), I can login just fine to either one of the servers, but as soon as I log out, the X server crashes. This causes XDM to attempt several times to restart it, which doesn't work. Eventually this leaves the video card in a bad state where neither X server can ever start again until I reboot the machine. Judging from the server logs (attached), the server is getting a bad V_BIOS checksum and an unknown exception (related?), as well as some permission problems. Commenting out the second X server in the xdm config (run only a single X server) causes the problem to go away. My chipset is Intel 82852/855GM, if that helps locate the source of the problem. T -- "Why waste time learning, when ignorance is instantaneous?" -- Calvin & Hobbes Xorg.0.log.old Description: application/trash
Bug#382120: xserver-xorg-video-i810 (experimental) leaves video in bad state
On Wed, Aug 09, 2006 at 03:00:39PM +1000, Drew Parsons wrote: > > Just thought I should let the X team know, that although the i810 driver > > in experimental fixes the ValidatePci() bug (see #345914, etc.), now it > > has problems terminating > > To get full support for the new i810 versions you really need the full > suite of upgrades, including xserver 1.1 and mesa (libgl) 6.5. I'm already using mesa 6.5 (the version in unstable doesn't work properly on my system for some reason), and apt-get refuses to install the i810 driver from experimental unless I install xserver-xorg-core (1.1.1-1) as well. Of course, maybe it's conflicting with the other xserver-xorg-* components. I'll try again with a more complete upgrade later this week. (I already have a patched X server for 1.0.2-9 to deal with the ValidatePCI() bug, so I'm not in a hurry to upgrade.) > Have you included these upgrades as well as the i810 driver? Yep. > Also, try again with the new i810 1.6.3, released this week. [...] OK, I'll try that. And this time I'll try to capture crash logs as well, if that helps to track down the problem. T -- People tell me that I'm skeptical, but I don't believe it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#382120: xserver-xorg-video-i810 (experimental) leaves video in bad state
Package: xserver-xorg-video-i810 Version: 2:1.6.1-2 Severity: normal Tags: experimental Hi, Just thought I should let the X team know, that although the i810 driver in experimental fixes the ValidatePci() bug (see #345914, etc.), now it has problems terminating (e.g., logout, or ctrl-alt-Backspace). Sometimes it leaves the virtual terminal in a bad state, so that it cannot be restarted: subsequent attempts to start the X server gives: (WW) xf86OpenConsole: setpgid failed: Operation not permitted (WW) xf86OpenConsole: setsid failed: Operation not permitted Other times, it leaves the video card in a bad state so that no X further servers can start at all, on any VT, until a reboot. The logfiles show that xf86() caught signal 4. (SIGILL??) Unfortunately I don't have the original error message; when I tried to reproduce it, X crashed horribly and locked up the entire system (not ctrl-alt-SysRq, not even the power button which triggers shutdown via acpid, responded). I use xdm to spawn the servers; I'm not sure if this has anything to do with it. Downgrading to unstable (1.5.1.0-2) fixes all of these problems. ii xdm1.0.5-1X display manager T -- Life is too short to run proprietary software. -- Bdale Garbee -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345914: The freedesktop.org patch for i8xx works perfectly
On Sun, Aug 06, 2006 at 06:04:36PM +, David Nusinow wrote: [...] > I'm in the process of updating the i810 driver to 1.6.1, which should > contain this fix. It'll be in experimental tomorrow. Please test it and let > me know if it works for you. [...] Yes it does! apt-get -t experimental install xserver-xorg-video-i810, and then restart X. Everything works normally. We can probably tag these bugs as pending now. Thanks for making this work. :-) T -- They pretend to pay us, and we pretend to work. -- Russian saying -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345914: The freedesktop.org patch for i8xx works perfectly
Hi, I've just applied the patch from: https://bugs.freedesktop.org/show_bug.cgi?id=6750 against the latest Debian source (xserver-xorg-core) and it works perfectly on my i850 chipset. I strongly urge the X maintainers to add this patch to the official Debian package before the next release---it's a showstopper for people with these Intel chipsets. This particular patch is non-intrusive; it detects exactly those chipsets that need to be fixed, and nothing else. For those who wish to test the fix (or need a fixed package to use with their Intel chipsets), I've built an (unofficial!) package for i386 here: http://eusebeia.dyndns.org/~hsteoh/debian/xserver-xorg-core_1.0.2-9_i386.deb Hope this helps. T -- Why ask rhetorical questions? -- JC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347774: Bug is still there
Hi, This is just a quick followup note, that this bug still exists. Apparently, it's not as simple as I had first thought: it only happens once in a while (race condition?). My window manager is ratpoison, which automatically maximizes all windows, and I've configured 'C-t c' to spawn xterm. Usually, there are no problems, but occasionally, it seems that the SIGWINCH is not sent to the shell, and it continues to think that it's at 80x24 (the default xterm geometry). This is still happening on xterm (210-3). T -- There's light at the end of the tunnel. It's the oncoming train. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345914: Problem source has been identified upstream [PATCH]
tags 345914 +patch thanks Hi, I've been hit by the same problem in all xorg servers above 6.8.2, and after searching around online, I've found the upstream bug report, which contains the solution: https://bugs.freedesktop.org/show_bug.cgi?id=5443 Basically, it's a call to ValidatePCI() that needs to be commented out. I've tested this fix myself: apt-get source xorg-xserver-core and all the build dependencies, then edit xf86Bus.c and comment out the ValidatePCI() call, then dpkg-buildpackage and install the patched package. It finally works on my Intel 855GM. I've attached the patch, for people who use the i810 driver and is running into the same problem (it was very annoying for me). Also, I've uploaded the (UNOFFICIAL!) fixed package here (i386 only, sorry), for those who badly need to get their Intel chips working: http://eusebeia.dyndns.org/~hsteoh/debian/xserver-xorg-core_1.0.2-7_i386.deb CAVEAT: this patch is probably too general; it really should be applied only if the i810 module is being used (and maybe in a few other cases---see the bug report for details). So, you should only install the above package if you are using the i810 module. I have no guarantees what it will do if you are using another chipset! USE AT YOUR OWN RISK. T -- Latin's a dead language, as dead as can be; it killed off all the Romans, and now it's killing me! -- Schoolboy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345914: Oops, patch attached for real this time
Oops, I forgot to actually attach the patch in the last mail. T -- There's light at the end of the tunnel. It's the oncoming train. --- hw/xfree86/common/xf86Bus.c.orig2006-05-01 10:39:34.0 -0700 +++ hw/xfree86/common/xf86Bus.c 2006-04-30 16:48:06.0 -0700 @@ -2488,7 +2488,9 @@ * No need to validate on Alpha Linux or OpenBSD/sparc64, * trust the kernel. */ + /* H. S. Teoh: attempt to fix i810 bug ValidatePci(); + */ #endif xf86MsgVerb(X_INFO, 3, "resource ranges after probing:\n");
Bug#347774: Does this bug still happen with 208-3.1?
Hi, A quick question for the bug submitter: could you check to see if this bug still happens in xterm (208-3.1)? I was seeing similar problems with 208-1, but the odd behaviour seems to have gone away recently when I upgraded to 208-3.1. It may have been fixed in the interim. T -- There's light at the end of the tunnel. It's the oncoming train. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345958: Bug confirmed
merge 345958 345914 severity 345958 grave thanks Hi, FWIW, this problem also occurs on my machine (LinuxCertified LC2210D laptop w/ Intel 82852/855GM chipset). Running the X server causes it to segfault, and it doesn't release the keyboard/console, so I have to reboot forcefully (Ctrl-Alt-SysRq-B). Downgrading to 6.8.2 fixes the problem. I'm escalating this bug to grave 'cos it "makes the package in question unusable or mostly so" (http://www.debian.org/Bugs/Developer). Relevant packages: ii debconf1.4.67 Debian configuration management system ii laptop-detect 0.12.1 attempt to detect a laptop ii libc6 2.3.5-11 GNU C Library: Shared libraries and Timezone ii libgcc14.0.2-5GCC support library ii libxau66.9.0.dfsg.1-1 X Authentication library ii libxdmcp6 6.9.0.dfsg.1-1 X Display Manager Control Protocol library ii mdetect0.5.2.1mouse device autodetection tool ii xlibs 6.9.0.dfsg.1-1 X Window System client libraries metapackage ii xserver-common 6.9.0.dfsg.1-1 files and utilities common to all X servers ii zlib1g 1.2.3-9compression library - runtime Hope this helps. --T -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#184198: Help needed
tags 184198 + help thanks Hi, does anyone know how to handle Xlib/Xt translations? This bug (#184198) is involved with migrating XLookupString() to XmbLookupString() (?), which is out of my depth. Any help from people better acquianted with Xt is much appreciated. Thanks! T -- Just because you can, doesn't mean you should.
Bug#184198: Help needed
tags 184198 + help thanks Hi, does anyone know how to handle Xlib/Xt translations? This bug (#184198) is involved with migrating XLookupString() to XmbLookupString() (?), which is out of my depth. Any help from people better acquianted with Xt is much appreciated. Thanks! T -- Just because you can, doesn't mean you should. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#18191: Is this bug still alive??
Mark W. Eichin <[EMAIL PROTECTED]> wrote: > It's *really really* unlikely that this is anything to do with Xlib, > but I'll leave it open for a few weeks to give you a chance to probe > further into the rest of the code. It's been a few *years* and nothing seems to have happened. Can the bug submitter please confirm this still happens?? Anyway, from the bug description, this looks very much like an error in the application, not in XLib. Probably the XImage structure was not created properly. XDestroyImage() is used *all over* every single X application, directly or indirectly via toolkits; something this blatantly wrong would've showed up in many other places. If there's no response from the bug submitter, I recommend this bug be put to sleep. T -- Bare foot: (n.) A device for locating thumb tacks on the floor.
Bug#18191: Is this bug still alive??
Mark W. Eichin <[EMAIL PROTECTED]> wrote: > It's *really really* unlikely that this is anything to do with Xlib, > but I'll leave it open for a few weeks to give you a chance to probe > further into the rest of the code. It's been a few *years* and nothing seems to have happened. Can the bug submitter please confirm this still happens?? Anyway, from the bug description, this looks very much like an error in the application, not in XLib. Probably the XImage structure was not created properly. XDestroyImage() is used *all over* every single X application, directly or indirectly via toolkits; something this blatantly wrong would've showed up in many other places. If there's no response from the bug submitter, I recommend this bug be put to sleep. T -- Bare foot: (n.) A device for locating thumb tacks on the floor. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#5212: xdm *still* allows login for /bin/true users
On Tue, Dec 10, 2002 at 12:58:31PM -0500, Branden Robinson wrote: > On Sun, Dec 01, 2002 at 09:28:34AM +1100, Herbert Xu wrote: [snip] > > What Steven Durham may have meant is that after switching to PAM, the > > people who want to allow only FTP access can use something other than > > /bin/true to do so, e.g., a simple list through pam_listfile. > > Okay, I need an explicit recommendation for a course of action on this > issue. Well, you could either: (1) decide this bug is a real problem, and so try to come up with a solution (perhaps forwarding it upstream); or, (2) decide this bug is "bogus", as Herbert puts it, and just close it. I don't think I am in the position to recommend either way. Disregarding for a moment what fixing XDM would entail, the fundamental question here seems to be whether setting a user's shell to /bin/false implies that every program that performs login functions should disallow logins as that user. The bug submitter obviously thinks so; but not everyone may agree with that. It seems to me that setting a user's login shell as /bin/true or /bin/false to prevent logins is a historical artifact of how /bin/login (one of several login applications) works. Obviously, FTP logins and XDM logins (and other logins) work differently; whether or not that constitutes a bug, I don't think I am qualified to answer. Should every login program behave exactly like /bin/login? I don't know, but it does seem a bit far-fetched. If PAM provides another way of prohibiting logins for specific users, then this whole issue would be moot, IMHO. But judging by bugs and recent questions on -devel about setting users' shells to /bin/false or /bin/true, this feature, if it exists, isn't very well-known. Perhaps it should be documented somewhere people will actually notice? :-) (A simple "how to manage user accounts" document should do it... if there's already such a document somewhere, we should add this to it.) [Disclaimer: I do not know how PAM works. So I might just be totally off the wall here, in which case, ignore me as you suggested. ;-) ] > Does that mean "ignore Mr. Teoh"? :) [snip] See above. :-) T -- Some people complain about the Instant Gratification Syndrome of today's generation, and just *can't wait* to let everyone know that.
Bug#5212: xdm *still* allows login for /bin/true users
On Tue, Dec 10, 2002 at 12:58:31PM -0500, Branden Robinson wrote: > On Sun, Dec 01, 2002 at 09:28:34AM +1100, Herbert Xu wrote: [snip] > > What Steven Durham may have meant is that after switching to PAM, the > > people who want to allow only FTP access can use something other than > > /bin/true to do so, e.g., a simple list through pam_listfile. > > Okay, I need an explicit recommendation for a course of action on this > issue. Well, you could either: (1) decide this bug is a real problem, and so try to come up with a solution (perhaps forwarding it upstream); or, (2) decide this bug is "bogus", as Herbert puts it, and just close it. I don't think I am in the position to recommend either way. Disregarding for a moment what fixing XDM would entail, the fundamental question here seems to be whether setting a user's shell to /bin/false implies that every program that performs login functions should disallow logins as that user. The bug submitter obviously thinks so; but not everyone may agree with that. It seems to me that setting a user's login shell as /bin/true or /bin/false to prevent logins is a historical artifact of how /bin/login (one of several login applications) works. Obviously, FTP logins and XDM logins (and other logins) work differently; whether or not that constitutes a bug, I don't think I am qualified to answer. Should every login program behave exactly like /bin/login? I don't know, but it does seem a bit far-fetched. If PAM provides another way of prohibiting logins for specific users, then this whole issue would be moot, IMHO. But judging by bugs and recent questions on -devel about setting users' shells to /bin/false or /bin/true, this feature, if it exists, isn't very well-known. Perhaps it should be documented somewhere people will actually notice? :-) (A simple "how to manage user accounts" document should do it... if there's already such a document somewhere, we should add this to it.) [Disclaimer: I do not know how PAM works. So I might just be totally off the wall here, in which case, ignore me as you suggested. ;-) ] > Does that mean "ignore Mr. Teoh"? :) [snip] See above. :-) T -- Some people complain about the Instant Gratification Syndrome of today's generation, and just *can't wait* to let everyone know that. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#5212: xdm *still* allows login for /bin/true users
Hi, I've just verified that XDM still exhibits this bug, contrary to what Steve Durham said about PAM fixing it. I added /bin/true to /etc/shells, and changed a user's shell to /bin/true. XDM still logged me in. T -- The two rules of success: 1. Don't tell everything you know. -- YHL
Bug#5212: xdm *still* allows login for /bin/true users
Hi, I've just verified that XDM still exhibits this bug, contrary to what Steve Durham said about PAM fixing it. I added /bin/true to /etc/shells, and changed a user's shell to /bin/true. XDM still logged me in. T -- The two rules of success: 1. Don't tell everything you know. -- YHL -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#77498: xlibs: [Xaw7] scrollbars with text widgets don't work like Xaw6 did
On Tue, Nov 12, 2002 at 10:52:53AM -0500, Branden Robinson wrote: > On Tue, Nov 12, 2002 at 08:47:07AM -0500, H. S. Teoh wrote: > > Hi, I've been going through my list of submitted bugs, and noticed this > > old one still lying around. > > > > Here's an update on the status of this bug: as of xbase-clients 4.2.1-3, > > this bug has been partially fixed. Xmessage now displays a vertical > > scrollbar when the output is very long; however, it still fails to show a > > horizontal scrollbar when the output is too wide to fit in the window. > > Just wondering if upstream is aware of this bug. (Or is it a configuration > > issue?) > > Xaw 7 doesn't support the "whenNeeded" value of the scrollbar resource. > > See Xaw(7) for more information. Weird, the manpage says that "whenNeeded" is not supported for *both* horizontal and vertical scrollbars. Or does xmessage create a vertical scrollbar by default now? > I think the opinion of the upstream Xaw maintainer is that this report > is a feature, not a bug. [snip] OK. I don't have a problem with that. :-) T -- Don't throw out the baby with the bathtub. Use your hands...
Bug#24878: xserver-svga: X display glitches during virtual console switching
Hi, here's another very old bug I submitted many suns ago. I just wanted to say that I no longer own a Trident 9440AGi, and therefore, I am no longer able to test whether or not this bug has been fixed. Also, I no longer use xserver-svga since X 4.x now uses xserver-xfree86. Is there any point at all leaving this bug open any longer? :-) T -- I see that you JS got Bach.
Bug#77498: xlibs: [Xaw7] scrollbars with text widgets don't work like Xaw6 did
On Tue, Nov 12, 2002 at 10:52:53AM -0500, Branden Robinson wrote: > On Tue, Nov 12, 2002 at 08:47:07AM -0500, H. S. Teoh wrote: > > Hi, I've been going through my list of submitted bugs, and noticed this > > old one still lying around. > > > > Here's an update on the status of this bug: as of xbase-clients 4.2.1-3, > > this bug has been partially fixed. Xmessage now displays a vertical > > scrollbar when the output is very long; however, it still fails to show a > > horizontal scrollbar when the output is too wide to fit in the window. > > Just wondering if upstream is aware of this bug. (Or is it a configuration > > issue?) > > Xaw 7 doesn't support the "whenNeeded" value of the scrollbar resource. > > See Xaw(7) for more information. Weird, the manpage says that "whenNeeded" is not supported for *both* horizontal and vertical scrollbars. Or does xmessage create a vertical scrollbar by default now? > I think the opinion of the upstream Xaw maintainer is that this report > is a feature, not a bug. [snip] OK. I don't have a problem with that. :-) T -- Don't throw out the baby with the bathtub. Use your hands... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#24878: xserver-svga: X display glitches during virtual console switching
Hi, here's another very old bug I submitted many suns ago. I just wanted to say that I no longer own a Trident 9440AGi, and therefore, I am no longer able to test whether or not this bug has been fixed. Also, I no longer use xserver-svga since X 4.x now uses xserver-xfree86. Is there any point at all leaving this bug open any longer? :-) T -- I see that you JS got Bach. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#77498: xlibs: [Xaw7] scrollbars with text widgets don't work like Xaw6 did
Hi, I've been going through my list of submitted bugs, and noticed this old one still lying around. Here's an update on the status of this bug: as of xbase-clients 4.2.1-3, this bug has been partially fixed. Xmessage now displays a vertical scrollbar when the output is very long; however, it still fails to show a horizontal scrollbar when the output is too wide to fit in the window. Just wondering if upstream is aware of this bug. (Or is it a configuration issue?) T -- Why can't you just be a nonconformist like everyone else? -- YHL
Bug#77498: xlibs: [Xaw7] scrollbars with text widgets don't work like Xaw6 did
Hi, I've been going through my list of submitted bugs, and noticed this old one still lying around. Here's an update on the status of this bug: as of xbase-clients 4.2.1-3, this bug has been partially fixed. Xmessage now displays a vertical scrollbar when the output is very long; however, it still fails to show a horizontal scrollbar when the output is too wide to fit in the window. Just wondering if upstream is aware of this bug. (Or is it a configuration issue?) T -- Why can't you just be a nonconformist like everyone else? -- YHL -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Short inquiry: Xaw packages
Hi Aaron :-) On Fri, Dec 15, 2000 at 08:38:56AM -0800, Aaron Lehmann wrote: > On my X workstation, there are currently 3 Xaw packages installed for > a small selection of Athena apps (all from Debian): libxaw6, libxaw7, > and xaw3dg. Oh yeah, and xaw-wrappers. The dependencies seem to be a [snip] > filed on those that depend on the wrong one? A dependency on xaw3dg > looks fishy to me, since the xaw3dg description claims it changes the > appearance of applications dynamically linked against libXaw. xaw3dg is supposed to be an API-compatible replacement for Xaw, replacing the standard Xaw widgets with 3D workalikes. Unfortunately, xaw3dg is not 100% compatible with all Xaw apps -- see xaw-wrappers for more info. Xaw3d causes some plain Xaw apps to crash. The current mess with libxaw6 and libxaw7 is because we're slowly moving from X 3.3.* to 4.0.*. libxaw6 is the 3.3.* version of Xaw, which many of our X packages still depend on. libxaw7 is the 4.0.* version of Xaw, which is much better, but we need to recompile all packages against it and it's not 100% API-compatible. (There are some minor changes which aren't hard to fix in theory, but in practice, some programs, like the aXe editor which I'm maintaining, have "unclean" code that makes assumptions on non-API features of libxaw6 -- which is a nightmare to fix so that it compiles against the new Xaw.) As for why some packages explicitly depends on xaw3dg, it just shows that Xaw3d and plain Xaw are not 100% compatible -- see gv, for example. I'm not sure if gv is exactly *dependent* on xaw3d-specific features; maybe it is. T -- I haven't lost my mind: it's backed up on tapes -- CompuMan pgpspSFNScsKz.pgp Description: PGP signature
Re: Short inquiry: Xaw packages
Hi Aaron :-) On Fri, Dec 15, 2000 at 08:38:56AM -0800, Aaron Lehmann wrote: > On my X workstation, there are currently 3 Xaw packages installed for > a small selection of Athena apps (all from Debian): libxaw6, libxaw7, > and xaw3dg. Oh yeah, and xaw-wrappers. The dependencies seem to be a [snip] > filed on those that depend on the wrong one? A dependency on xaw3dg > looks fishy to me, since the xaw3dg description claims it changes the > appearance of applications dynamically linked against libXaw. xaw3dg is supposed to be an API-compatible replacement for Xaw, replacing the standard Xaw widgets with 3D workalikes. Unfortunately, xaw3dg is not 100% compatible with all Xaw apps -- see xaw-wrappers for more info. Xaw3d causes some plain Xaw apps to crash. The current mess with libxaw6 and libxaw7 is because we're slowly moving from X 3.3.* to 4.0.*. libxaw6 is the 3.3.* version of Xaw, which many of our X packages still depend on. libxaw7 is the 4.0.* version of Xaw, which is much better, but we need to recompile all packages against it and it's not 100% API-compatible. (There are some minor changes which aren't hard to fix in theory, but in practice, some programs, like the aXe editor which I'm maintaining, have "unclean" code that makes assumptions on non-API features of libxaw6 -- which is a nightmare to fix so that it compiles against the new Xaw.) As for why some packages explicitly depends on xaw3dg, it just shows that Xaw3d and plain Xaw are not 100% compatible -- see gv, for example. I'm not sure if gv is exactly *dependent* on xaw3d-specific features; maybe it is. T -- I haven't lost my mind: it's backed up on tapes -- CompuMan PGP signature
Re: 4.0.1-11 breaks text and images on SiS 86C326
On Tue, Dec 12, 2000 at 05:54:22PM -0800, Benjamin Redelings I wrote: > > > > Very interestingly, I experience a similar problem under the 4.0.1 X > > server with the game X Scavenger (xscavenger). When Scavenger first starts > > up, the outer borders of the window are leftover bits of comics that I've > > been looking at. When I start the game, though, the screen is cleared and > > everything goes to normal. > > This is a bit different than my problem: > ALL my applications fail at ALL points. (OK, actually I guess the > applications that fail are: icewm, GNOME, gdm, and gnome-terminal). For > some reason, the arrow on the menus in icewm still work, though no text > is shown. Weird. I just upgraded to -11 and when xdm starts, the login widget shows up as a blank box. Even weirder, switching to a text console and back suddenly brings the text back! (Except that it cleared the background to white in the process) Everything seems to work OK now, but earlier on, on my first attempt to restart X, the X server crashed after I logged in. > YOUR problem may be that you have not added the line > "VideoRAM 4096" > to you card specification? If X tries to use all 8 megs, then screen > redraws become somewhat untrustworthy. X 3.3.x automagically only used > 4M on 8M cards, but on 4.0.1 you have to do this manually it seems. No, my XF86Config-4 explicitly states "VideoRam 4096", and I'm still getting the same problem with Scavenger. In fact, it still does the same thing right now, after that text-console-switching weirdness I just described. So, although your problem probably isn't caused by gdm, I suspect Scavenger has a bug (or perhaps library incompatibility?) [snip] > This IS the same card I think: I got the model number from /proc/pci, I > think it is also called a 6326. OK, I thought so... the numbers look too similar to be a coincidence anyway :-) > So, in summary, this is NOT a bug against gdm, but a bug in the > xserver. [snip] Hmm. Might it have anything to do with what I described? Sounds like we're experiencing the same problem. Try switching to a text VC and back, and see if that helps. It worked for me (tm), YMMV. T -- Winners never quit, quitters never win. But those who never quit AND never win are idiots. pgpVTajka01BJ.pgp Description: PGP signature
Re: 4.0.1-11 breaks text and images on SiS 86C326
On Tue, Dec 12, 2000 at 05:54:22PM -0800, Benjamin Redelings I wrote: > > > > Very interestingly, I experience a similar problem under the 4.0.1 X > > server with the game X Scavenger (xscavenger). When Scavenger first starts > > up, the outer borders of the window are leftover bits of comics that I've > > been looking at. When I start the game, though, the screen is cleared and > > everything goes to normal. > > This is a bit different than my problem: > ALL my applications fail at ALL points. (OK, actually I guess the > applications that fail are: icewm, GNOME, gdm, and gnome-terminal). For > some reason, the arrow on the menus in icewm still work, though no text > is shown. Weird. I just upgraded to -11 and when xdm starts, the login widget shows up as a blank box. Even weirder, switching to a text console and back suddenly brings the text back! (Except that it cleared the background to white in the process) Everything seems to work OK now, but earlier on, on my first attempt to restart X, the X server crashed after I logged in. > YOUR problem may be that you have not added the line > "VideoRAM 4096" > to you card specification? If X tries to use all 8 megs, then screen > redraws become somewhat untrustworthy. X 3.3.x automagically only used > 4M on 8M cards, but on 4.0.1 you have to do this manually it seems. No, my XF86Config-4 explicitly states "VideoRam 4096", and I'm still getting the same problem with Scavenger. In fact, it still does the same thing right now, after that text-console-switching weirdness I just described. So, although your problem probably isn't caused by gdm, I suspect Scavenger has a bug (or perhaps library incompatibility?) [snip] > This IS the same card I think: I got the model number from /proc/pci, I > think it is also called a 6326. OK, I thought so... the numbers look too similar to be a coincidence anyway :-) > So, in summary, this is NOT a bug against gdm, but a bug in the > xserver. [snip] Hmm. Might it have anything to do with what I described? Sounds like we're experiencing the same problem. Try switching to a text VC and back, and see if that helps. It worked for me (tm), YMMV. T -- Winners never quit, quitters never win. But those who never quit AND never win are idiots. PGP signature
Re: 4.0.1-11 breaks text and images on SiS 86C326
On Tue, Dec 12, 2000 at 11:14:13AM -0800, Benjamin Redelings I wrote: > Hello all, > I have been using the new X server packages, and have been quite happy, > up through 4.0.1-10. However, when I ran gdm after installing 4.0.1-11, > the image was missing - it was replaced in fact by a bit of a dilbert > comic that I had been looking at when running 4.0.1-10. Also, no text [snip] Very interestingly, I experience a similar problem under the 4.0.1 X server with the game X Scavenger (xscavenger). When Scavenger first starts up, the outer borders of the window are leftover bits of comics that I've been looking at. When I start the game, though, the screen is cleared and everything goes to normal. I've glanced over the source code of X Scavenger, and it appears to be a problem with the screen-clearing routine. Perhaps an undocumented feature (i.e., bug) of X 3.3.* that was "fixed" in 4.0.1? I suspect it's a 3.3.* bug because Scavenger exhibits similar problems when compiled on a Solaris workstation -- which leads me to suspect that it's relying on an old (broken) behaviour of the X libraries. If so, then I'd file a bug against gdm. (But of course, I didn't spend much time to look into this, so I might be totally off to lunch here.) I also use a SiS chipset, but it's the 6326 not the 86C326 (or are they the same thing?). I'm not sure if this problem is chipset-specific, but I don't know for sure. T -- INTEL = Only half of "intelligence". pgpEtcqGy1LZT.pgp Description: PGP signature
Re: 4.0.1-11 breaks text and images on SiS 86C326
On Tue, Dec 12, 2000 at 11:14:13AM -0800, Benjamin Redelings I wrote: > Hello all, > I have been using the new X server packages, and have been quite happy, > up through 4.0.1-10. However, when I ran gdm after installing 4.0.1-11, > the image was missing - it was replaced in fact by a bit of a dilbert > comic that I had been looking at when running 4.0.1-10. Also, no text [snip] Very interestingly, I experience a similar problem under the 4.0.1 X server with the game X Scavenger (xscavenger). When Scavenger first starts up, the outer borders of the window are leftover bits of comics that I've been looking at. When I start the game, though, the screen is cleared and everything goes to normal. I've glanced over the source code of X Scavenger, and it appears to be a problem with the screen-clearing routine. Perhaps an undocumented feature (i.e., bug) of X 3.3.* that was "fixed" in 4.0.1? I suspect it's a 3.3.* bug because Scavenger exhibits similar problems when compiled on a Solaris workstation -- which leads me to suspect that it's relying on an old (broken) behaviour of the X libraries. If so, then I'd file a bug against gdm. (But of course, I didn't spend much time to look into this, so I might be totally off to lunch here.) I also use a SiS chipset, but it's the 6326 not the 86C326 (or are they the same thing?). I'm not sure if this problem is chipset-specific, but I don't know for sure. T -- INTEL = Only half of "intelligence". PGP signature
Re: XFree 4 && NeoMagic
On Mon, Nov 13, 2000 at 06:11:28PM -0100, Rodrigo Moya wrote: > Hi! > > After a couple of weeks trying to get my Neomagic card to work in 1024x768 > with XF 4, I'm now thinking about downgrading to 3.3.6, because I really > need 1024x768. > > Is there a sort of procedure to downgrade? [snip] I don't know off-hand, but you can simply re-install the XF3 server: apt-get install xserver-svga(or whichever 3.3.* server you were using before) Then edit /etc/X11/xserver to use XF86_SVGA (or the appropriate binary if you're using another 3.3.* server) instead of XFree86. This is what I'm currently using, as I'm less than happy with the XF 4 server on my SiS 6326, and I'm sticking with the trusty 3.3.6 server. :-) T -- Let's eat some disquits while we format the biskettes.
Re: XFree 4 && NeoMagic
On Mon, Nov 13, 2000 at 06:11:28PM -0100, Rodrigo Moya wrote: > Hi! > > After a couple of weeks trying to get my Neomagic card to work in 1024x768 > with XF 4, I'm now thinking about downgrading to 3.3.6, because I really > need 1024x768. > > Is there a sort of procedure to downgrade? [snip] I don't know off-hand, but you can simply re-install the XF3 server: apt-get install xserver-svga(or whichever 3.3.* server you were using before) Then edit /etc/X11/xserver to use XF86_SVGA (or the appropriate binary if you're using another 3.3.* server) instead of XFree86. This is what I'm currently using, as I'm less than happy with the XF 4 server on my SiS 6326, and I'm sticking with the trusty 3.3.6 server. :-) T -- Let's eat some disquits while we format the biskettes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
