Intel HD 4400 hardware on Wheezy
Dear Debian X developers If have touble getting debian wheezy installed on a standard business PC (HP Elite 800 G1) with Intel HD 4400 graphics. lspsi -v gives: 00:02.0 VGA compatible controller: Intel Corporation Device 041e (rev 06) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company Device 1998 Flags: bus master, fast devsel, latency 0, IRQ 45 Memory at f780 (64-bit, non-prefetchable) [size=4M] Memory at e000 (64-bit, prefetchable) [size=256M] I/O ports at f000 [size=64] Expansion ROM at unassigned [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [a4] PCI Advanced Features Kernel driver in use: i915 On plain wheezy the server falls back to the fbdev driver, which gives poor video results and does not support a multihead configuration. I installed a recent linux kernel from backports (linux-image-3.14-0.bpo.2-amd64) and on to of that I compiled and installed the xserver-xorg-video-intel from jessie (2.21.15) on that system. On this setup the module is loaded, but it does not seem to be able to interact properly with the hardware. See Xorg.0.log later Do you have any hints, how to get HD 4400 hardware running under Wheezy? Since it is the standard intel hardware even in the business desktop systems, there must be several demands for that. I am running Debian as a desktop distro in a professional environment since 2002 and we always had the problem of getting business hardware running the stable releases at some point. However in the resent release cycles you always provided a backported version of the X server (etch-and-a-half, squeeze-backports). Do you plan on doing so as well for Wheezy? I would be very happy to hear so. Thanks for you great work Hendrik Naumann PS. Please CC me to the answers since I am not member of the debian-x maililng list. --- Xorg.0.log -- [ 657.453]ABI class: X.Org Video Driver, version 12.1 [ 657.453] (II) intel: Driver for Intel(R) Integrated Graphics Chipsets: i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G, 915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, GM45, 4 Series, G45/G43, Q45/Q43, G41, B43, HD Graphics, HD Graphics 2000, HD Graphics 3000, HD Graphics 2500, HD Graphics 4000, HD Graphics P4000, HD Graphics 4600, HD Graphics 5000, HD Graphics P4600/P4700, Iris(TM) Graphics 5100, HD Graphics 4400, HD Graphics 4200, Iris(TM) Pro Graphics 5200 [ 657.453] (++) using VT number 9 [ 657.455] drmOpenDevice: node name is /dev/dri/card0 [ 657.455] drmOpenDevice: open result is 8, (OK) [ 657.455] drmOpenByBusid: Searching for BusID pci::00:02.0 [ 657.455] drmOpenDevice: node name is /dev/dri/card0 [ 657.455] drmOpenDevice: open result is 8, (OK) [ 657.455] drmOpenByBusid: drmOpenMinor returns 8 [ 657.455] drmOpenByBusid: drmGetBusid reports pci::00:02.0 [ 657.455] drmOpenDevice: node name is /dev/dri/card0 [ 657.455] drmOpenDevice: open result is 9, (OK) [ 657.455] drmOpenByBusid: Searching for BusID pci::00:02.0 [ 657.455] drmOpenDevice: node name is /dev/dri/card0 [ 657.455] drmOpenDevice: open result is 9, (OK) [ 657.455] drmOpenByBusid: drmOpenMinor returns 9 [ 657.455] drmOpenByBusid: drmGetBusid reports pci::00:02.0 [ 657.455] (II) intel(0): Creating default Display subsection in Screen section Default Screen for depth/fbbpp 24/32 [ 657.455] (==) intel(0): Depth 24, (--) framebuffer bpp 32 [ 657.455] (==) intel(0): RGB weight 888 [ 657.455] (==) intel(0): Default visual is TrueColor [ 657.455] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD Graphics [ 657.455] (II) UnloadModule: intel [ 657.455] (EE) Screen(s) found, but none have a usable configuration. [ 657.456] Fatal server error: [ 657.456] no screens found [ 657.456] Please consult the The X.Org Foundation support at http://wiki.x.org for help. [ 657.456] Please also check the log file at /var/log/Xorg.0.log for additional information. [ 657.456] [ 657.457] Server terminated with error (1). Closing log file. -- Dr. Hendrik Naumann Technische Universität Berlin Institut für Chemie, Sekr. C3 Leiter EDV Chemie Strasse des 17. Juni 115 10623 Berlin Tel.: +49 30 314 29892 Mobil: +49 172 314 0410 Fax: +49 30 314 29309 WWW: http://www.chemie.tu-berlin.de/it E-Mail: naum...@tu-berlin.de signature.asc Description: This is a digitally signed message part.
Bug#607683: xvideo lost after upgrade to squeeze
Hi, I have the same problem. After installing squeeze from scratch I cannot play any videos any more. xvinfo outputs X-Video Extension version 2.2 screen #0 no adaptors present and lspci shows 02:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (rev 01) 02:00.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (Secondary) (rev 01) Bye, Hendrik -- 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/19822.43308.867567.124...@gromit.tews.net
Bug#607683: Video does not stretch to frame on Debian Squeeze
Cyril Brulebois writes: Wild guess, missing firmware-linux* packages? Thanks so much, firmware-linux-nonfree solved the problem. Hendrik -- 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/19823.17175.628000.339...@blau.inf.tu-dresden.de
Bug#558786: X.org radeon driver breaks KDE when radeon.ko is present
Hi, this actually has a deeper impact. DRI1 is used by the radeon X.org driver when radeon.modeset=0 (linux-2.6.32) but then KDE is horribly broken (scrolling in any KDE application gives render errors). Forcing XAA doesn't work (EXA is always used). This is only solved by preventing radeon.ko from being loaded. This issue is also present in linux-2.6.31. DRI2 is tried by the radeon X.org driver when radeon.modeset=1 (which works great on the VT). But since libdrm doesn't support that in unstable, it breaks X completely (KDM doesn't show any useful screen, all garbled). I didn't test compiling libdrm and mesa myself (didn't want to mess with my system). Thus, any DRI is currently impossible on my Radeon Mobility HD 2400 XT (RV610 / M7[24]). However, not using radeon.ko and thus only 2D works fine :) I would really like to test libdrm-radeon, too. HS -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#486507: libx11-6: Locking assertion failure with vmware-server-console
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, i had the same bug running vmware-server-console 1.0.8 (deb created by vmware-package) on testing (x86) and i was able to solve this issue with installing gtkhtml3.14 (3.18.3-1) with all of it dependencies. Maybe this bug can be closed? Bye Hendrik -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklLoDUACgkQjWcQfAgCZA+6KACaAmsUFSM3aiY57vuJWkWQTdST an4AoIAwqn3auJH/rLDH/QwfToBlymyt =IkX9 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#411716: installation almost succeeds - is X misconfigured or broken?
Enclosed a xonfiguration file from the newly-installed etch system, and a corresponding one for my working sarge system on the same machine. There's probably more information you need, tests you might want me to run; just ask. Here's /etc/X11/xorg.conf from the installed etch system. # /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 /etc/X11/xorg.conf manual page. # (Type man /etc/X11/xorg.conf 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 command: # sudo dpkg-reconfigure -phigh xserver-xorg Section Files FontPath/usr/share/fonts/X11/misc FontPath/usr/X11R6/lib/X11/fonts/misc FontPath/usr/share/fonts/X11/cyrillic FontPath/usr/X11R6/lib/X11/fonts/cyrillic FontPath/usr/share/fonts/X11/100dpi/:unscaled FontPath/usr/X11R6/lib/X11/fonts/100dpi/:unscaled FontPath/usr/share/fonts/X11/75dpi/:unscaled FontPath/usr/X11R6/lib/X11/fonts/75dpi/:unscaled FontPath/usr/share/fonts/X11/Type1 FontPath/usr/X11R6/lib/X11/fonts/Type1 FontPath/usr/share/fonts/X11/100dpi FontPath/usr/X11R6/lib/X11/fonts/100dpi FontPath/usr/share/fonts/X11/75dpi FontPath/usr/X11R6/lib/X11/fonts/75dpi # path to defoma fonts FontPath/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType EndSection Section Module Loadi2c Loadbitmap Loadddc Loaddri Loadextmod Loadfreetype Loadglx Loadint10 Loadvbe EndSection Section InputDevice Identifier Generic Keyboard Driver kbd Option CoreKeyboard Option XkbRules xorg Option XkbModel pc104 Option XkbLayout us EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer Option Device/dev/input/mice Option Protocol ImPS/2 Option Emulate3Buttons true EndSection Section Device Identifier ATI Technologies Inc R200 BB [Radeon All in Wonder 8500DV] Driver ati BusID PCI:2:0:0 EndSection Section Monitor Identifier S/T 77E/76E Option DPMS EndSection Section Screen Identifier Default Screen Device ATI Technologies Inc R200 BB [Radeon All in Wonder 8500DV] Monitor S/T 77E/76E DefaultDepth24 SubSection Display Depth 1 Modes 1280x1024 1024x768 832x624 800x600 720x400 640x480 EndSubSection SubSection Display Depth 4 Modes 1280x1024 1024x768 832x624 800x600 720x400 640x480 EndSubSection SubSection Display Depth 8 Modes 1280x1024 1024x768 832x624 800x600 720x400 640x480 EndSubSection SubSection Display Depth 15 Modes 1280x1024 1024x768 832x624 800x600 720x400 640x480 EndSubSection SubSection Display Depth 16 Modes 1280x1024 1024x768 832x624 800x600 720x400 640x480 EndSubSection SubSection Display Depth 24 Modes 1280x1024 1024x768 832x624 800x600 720x400 640x480 EndSubSection EndSection Section ServerLayout Identifier Default Layout Screen Default Screen InputDevice Generic Keyboard InputDevice Configured Mouse EndSection Section DRI Mode0666 EndSection -- And, just for reference, the /etc/X11/XF86Config-4 file from my working sarge system on the same computer: -- # XF86Config-4 (XFree86 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 XF86Config-4 manual page. # (Type man XF86Config-4 at the shell prompt.) # # This file is automatically updated on xserver-xfree86 package upgrades *only* # if it has not been modified since the last upgrade of the
Bug#379480: Good news
I upgraded my AMD64 etch system yesterday (2006 Dec 13) and the freezes seem to have stopped. If this situation persists for a week I'll consider the bug I originally posted fixed and report it so. I can't say whether the other problems some people have written in about are fixed, though. Perhaps this is a good time for them to upgrade and report success or failure. For the record, aptitude reports I now have installed xserver-xorg-core 2:1.1.1-11 xserver-xorg-input-all 1:7.1.0-7 xserver-xorg-input-evdev 1:1.1.2-6 xserver-xorg-input-kbd 1:1.1.0-4 xserver-xorg-input-mouse 1:1.1.0-3 xserver-xorg-input-synaptics 0.14.6-1 * xserver-xorg-input-wacom 0.7.4.1-5 * xserver-xorg-video-dummy 1:0.2.0-3 * xserver-xorg-video-flxdev 1:0.3.0-3 xserver-xorg-video-nv 1:1.2.0-3 * xserver-xorg-video-vesa 1:1.2.1-3 * xserver-xorg-video-vga 1:4.1.0-3 * and I'm using kernel linux-image-2.6.18-3-amd64 * I'm not actually using these as far as I know. The video driver I'm using is the framebuffer driver, in an attempt several months ago to get the minimum possible complexity (hoping for the freezes to stop). It's probably time to go back to nv, or even the proprietary nvidia drivers -- hendrik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379480: Upgraded etch; still freezes.
Just updated etch to current today, 2006 Nov 9; some xorg componenets were updates, but bug 379480 is still present. It is still a show-stopper, and I manage to get any useful work done on the system only by running Ubuntu. I am prepared to help try and solve the problem; I just don't know where to start. I could look through the Ubuntu patches as see if any of them look relevant, but I have not succeeded in finding them -- where are they? I've tried bot a 32-bit and a 64-bit Debian system -- both had the same problem. so it's probably bot a 64-bit-cleanliness issue. I have tried several xservers, all of them have failed in the same way (I thought that should narrow it somewhat). What server-side components are *not* part of the xservers, or are shared by them, and affect mouse events and only some keystrokes? Is there some way I could start X with various logging or tracing options to further isolate the problem? Is there even any documentation available telling me how server-side X is put together so I might gain some understanding of the situation? Is there somewhere else I should be posting these questions? --hendrik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379480: (no subject)
On Wed, Sep 20, 2006 at 09:59:44PM +0200, Ji?? Pale?ek wrote: Could you try upgrading xserver-xorg-xxx to unstable version to see whether the problem persists in later versions? Just tried -- again -- upgrading xserver-xorg-core to sid. aptitude added a number of dependencies, and the upgrade worked this time. However, the bug is still present. Mousee frose while using Mozilla, keyboard still worked except fot the ctl-alt combinations for switching consoles, and ctl-alt-backspace for killing X, Did a hardware reset to shut down and reboot. Back to running Ubuntu. Do we need one of the fixes Ubuntu developers should be feeding back to Debian in comprehensible form? -- hendrik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379480: X Key/Mouse Freeze might be time/clock based
On Sat, Sep 30, 2006 at 11:23:47PM -0400, [EMAIL PROTECTED] wrote: On Sat, Sep 30, 2006 at 03:34:48PM -0600, Berg, Michael wrote: So I started really looking into time-based triggers. During my troubleshooting experiments, I found that if the system clock is adjusted even a few seconds backward, X input will freeze up a few seconds later. For example: 1. Make sure any NTP software is turned off (since we want to know what changes are being made to the clock). It's chrony I'm using, which, I believe, doesn't set the clock backward, but adjusts the speed of the clock instead. Maybe that has the same effect as adusting it more often, hence minutes instead of months? I uninstalled chrony, and do not have ntp installed, and I rebooted before the test just to make sure it was really gone. 2. Execute the date command and then adjust the time back slightly (about 2 minutes backward is used in this example). # date Sat Sep 30 15:02:22 MDT 2006 # date -s 'Sat Sep 30 15:00:00 MDT 2006' Every time I tried this, X keyboard and mouse input would freeze up a few seconds later. Desktop applets like the system clock, CPU monitor, network activity, etc would all still be actively displaying (so the screen is still updating), but I would be unable to mouse between windows, hot-key between windows, type into the currently focused xterm, Ctrl-Alt-backspace to kill X, or Ctrl-Alt-F2 to a terminal window. Regulas ASCII keyboard characters still work oafter a freeze -- if I happen to be in a shell at the time the mouse freezes, I can still go on merrily entering commands. But I'd better not try to start any commands that create windows! I tried this test, set the time back about two minutes. It did indeed freeze after minute or so. The system clock froze too, which is different from your experience. The test is not conclusive, though. I performed it on the second reboot. On the first reboot, the system froze within a second of starting icewm, without any clock setting (and ssh'ing in did not work at all -- no route to host any more). So the clock-set freeze may just be coincidence. -- hendrik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379480: X Key/Mouse Freeze might be time/clock based
On Sat, Sep 30, 2006 at 03:34:48PM -0600, Berg, Michael wrote: Several of my friends and I have been having similar problems - X keyboard/mouse input occasionally freezing. The problem has been encountered on both i386 and AMD64 systems, with both nvidia and ati video cards, with both free and proprietary drivers. The interesting thing is that most of our systems would freeze at almost the exact same time each time it happened (once every few months). It happened again today, and three of our systems (in various locations around the city and state) all froze up during the same 1-2 minute period. Mine freezes within minutes. So I started really looking into time-based triggers. During my troubleshooting experiments, I found that if the system clock is adjusted even a few seconds backward, X input will freeze up a few seconds later. For example: 1. Make sure any NTP software is turned off (since we want to know what changes are being made to the clock). It's chrony I'm using, which, I believe, doesn't set the clock backward, but adjusts the speed of the clock instead. Maybe that has the same effect as adusting it more often, hence minutes instead of months? 2. Execute the date command and then adjust the time back slightly (about 2 minutes backward is used in this example). # date Sat Sep 30 15:02:22 MDT 2006 # date -s 'Sat Sep 30 15:00:00 MDT 2006' Every time I tried this, X keyboard and mouse input would freeze up a few seconds later. Desktop applets like the system clock, CPU monitor, network activity, etc would all still be actively displaying (so the screen is still updating), but I would be unable to mouse between windows, hot-key between windows, type into the currently focused xterm, Ctrl-Alt-backspace to kill X, or Ctrl-Alt-F2 to a terminal window. Regulas ASCII keyboard characters still work oafter a freeze -- if I happen to be in a shell at the time the mouse freezes, I can still go on merrily entering commands. But I'd better not try to start any commands that create windows! ssh'ing in from another computer and then stopping gdm and/or X would allow me to recover, restart X and run other test scenarios. Yes, this true for me, too, except that it's all so slow that ssh times out during login. But if I'm alreaddy ssh'd in, I can do things -- slowly. Keystroke echo can take a minute! Can those of you who are also having this problem try the clock adjustment test above and see if you have the same results? Will try and report results. How many of you who are experiencing the problem are running NTP synchronization software on your system? Just chrony. I should also note that I could adjust the clock forward as much as I wanted with no adverse effects (I had test cases of moving forward a few seconds, a few minutes, a few hours, and almost an entire day), but any adjustment of the clock backward from its current setting triggered the problem. I'm running openbox, and my friends were both running GNOME (one on top of openbox and one on top of metacity). running icewm. I had the same results in my tests whether the X session was started through GDM or from startx on the command line, and the same results whether xscreensaver was running or not. My theory on the three computers having having the problem at the same time is that a small backward re-adjustment may have propagated through the NTP servers we're using - which triggered the problem. For those of you who are experiencing this problem more frequently, if you have worse than average clock drift and are running NTP software, your system would probably be having to skip the clock back more often than most on most systems. Or you may be using a very jittery NTP server. People who aren't running NTP probably wouldn't encounter the problem. But please respond to this if you are experiencing this and don't use NTP (every data point can help track down a bug). Anyway, hopefully this helps track down the problem. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379480: (no subject)
On Wed, Sep 20, 2006 at 09:59:44PM +0200, Ji?? Pale?ek wrote: On Wed, 20 Sep 2006 18:12:02 +0200, [EMAIL PROTECTED] wrote: On Mon, Aug 14, 2006 at 12:42:51AM +0200, Ji Pale??ek wrote: Hi! I'd be stunned if this was actually a server problem, and not a client-side problem related to grabs. Which window manager do you use? Does changing it fix anything? I use openbox. However, I don't think it's a client side problem, as no grabs can prevent Ctrl-Alt-F1 and such to work. The freezes seem random -- the last one I experienced (after ~week of flawless work) occured after I opened a file with kate. You're lucky. I might be able to use X in Debian if it only crashed once a week. As it is, I'm still dual-booting Ubuntu if I want to get any work done. I use icewm and gdm. As mentioned on the original bug report, it randomly freezes even when I use a remote machine via XDMCP. The local machine that's running the X server still freezes randomly. I suppose the remote client could ask for things that freeze the server, but isn't that still a server problem? If you get freezes regularly, you could possibly debug it. However, I'm not an X developper, so I can't give you advice on that. I think that it is an internal server problem which doesn't depend on whether the clients are local or remote. (The only difference I can tell is that the remote cannot use the shared memory extension). Could you try upgrading xserver-xorg-xxx to unstable version to see whether the problem persists in later versions? Regards Jiri Palecek Just tried that, setting source.list to unstable, starting interactive aptitude, and trying to '+' various xorg-related packages. All of them seemed to run afoul of xserver_xorg-code conflicts with xserver-xorg-video (provided by lots of packages, including the xserver-xorg-video-fbdev 1:0.1.0.5-2 I'm currently using.) or the like. Telling it to update xserver-xorg-video-fbdev doesn't help. Telling it to update *every( installed package whose name contains the text xerver-xorg doesn't help either. By the way, installing a complete sid system a few months ago didn't help either. -- hendrik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379480: (no subject)
On Mon, Aug 14, 2006 at 12:42:51AM +0200, Ji Pale??ek wrote: Hi! I'd be stunned if this was actually a server problem, and not a client-side problem related to grabs. Which window manager do you use? Does changing it fix anything? I use openbox. However, I don't think it's a client side problem, as no grabs can prevent Ctrl-Alt-F1 and such to work. The freezes seem random -- the last one I experienced (after ~week of flawless work) occured after I opened a file with kate. Regards Jiri Palecek You're lucky. I might be able to use X in Debian if it only crashed once a week. As it is, I'm still dual-booting Ubuntu if I want to get any work done. I use icewm and gdm. As mentioned on the original bug report, it randomly freezes even when I use a remote machine via XDMCP. The local machine that's running the X server still freezes randomly. I suppose the remote client could ask for things that freeze the server, but isn't that still a server problem? -- hendrik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379480: Mouse and partial keyboard freeze
Just used aptitude to upgrade etch to current versions of everything (except python; some package depended on the old version). Still using the 2.6.16 kernel, though. The problem still exists, so I'll be back to Ubuntu for another while. I ask again -- is there anything I can do here to help identify the problem? -- hendrik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379480: workaround? problem does not occur in Ubuntu.
I've now installed the Ubuntu server, assed in the desktop software I prefer, the crashes are not occurring, and my system is performing all the essential functions I had originally planned to run under Debian. It's not the workaround I had hoped for, but it'll do intil Debian gets fixed. Is there anything useful I can do in terms of trying to identify meaningful differences between the two systems? -- hendrik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379480: problem also occurs in sid, but not in Ubuntu: there is hope.
The problem I reported does occur with sid. It does not occur with the Ubuntu live CD. So this narrows it down somewhat. It's software, and the fis probably lies in the differences between Ubunto and Debian. -- hendrik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#371874: x11-common postinst error: trouble with /usr/include/X11
Package: x11-common Version: 1:7.0.20 Severity: grave X-Debbugs-CC: Henk Boom [EMAIL PROTECTED] x11-common postinst error: trouble with /usr/include/X11 We get this problem on two different systems -- an etch AMD-64 (installed as Debian-AMD64, but upgraded as Debian since a few weeks ago), and etch running on a 32-bit Athlon (installed as sarge, subsequently dist-upgraded to etch). We are trying to upgrade our machines from xorg 6.9 to xorg 7.0, and have been stymied by the installation behaviour of x11-common, specifically the one that appears as /var/cache/apt/archives/x11-common_1%3a7.0.20_amd64.deb on the AMD64, and /var/cache/apt/archives/x11-common_1%3a7.0.20_i386.deb on the 32-bit system. The post-install script complains that the symbolic link /usr/include/X11 does not exist. On the AMD-64 we managed to get past this point, but we're not sure exactly what we did that did the trick. We tried uninstalling x11-common in order to install it again. Forcing uninstallation and installation did not *seem* to work, but we are not familiar enough with the behavious of apt-get to know this for sure. We succeeded on tha AMD-64 only after deleting about a hundred packages that directly or indirectly depended on x11-common, then uninstalling and reinstalling it. On the 32-bit machine we are utterly at a standstill, since there are far, far too many packages to delete by hand. In case it's relevant, both machines use nvidia drivers built from the Debian nveidia-kernel-source package. On the 32-bit machine, we took inspiration from someone's advice on the net, and tried creating the /usr/include/X11 directory ourselves, since although x11-common complains about a missing symbolic link, it is apparently supposed to end up with a directory. But in this case it complains that /usr/include/X11 is not a symbolic link. If we re-create the symbolic link as it appears on other systems still using 6.9, it reports that the symbolic link does not exist, and when we check afterwards, the symbolic link has disappeared. -- [EMAIL PROTECTED] -- Henk Boom [EMAIL PROTECTED] AMD-64: [EMAIL PROTECTED]:~$ uname -a Linux april 2.6.12-1-amd64-generic #1 Wed Sep 28 02:05:15 CEST 2005 x86_64 GNU/Linux [EMAIL PROTECTED]:~$ dpkg -s libc6 | grep ^Version Version: 2.3.6-7 Athlon 32: [EMAIL PROTECTED]:/home/henk$ uname -a Linux henk-linux 2.6.15-1-686 #2 Mon Mar 6 15:27:08 UTC 2006 i686 GNU/Linux [EMAIL PROTECTED]:/home/henk$ dpkg -s libc6 | grep ^Version Version: 2.3.6-7 [EMAIL PROTECTED]:/home/henk$ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
left-over stuff in testing installation with new xorg
Hi, the new xorg left some cruft on my system: not in testing, yet: pm-dev libice-dev libxft-dev libice6 xfonts-dosemu gsfonts-x11 Packages that simply don't exist anymore (bug?): xfonts-base-transcoded So at least, xfonts-base-transcoded is something not dealt with. Should I simply remove it? Also note: some users have extra files in /usr/X11R6. For me, it is the firmware that the theatre200 driver (radeon related) wanted at /usr/X11R6/lib/modules/multimedia. It was simply left there and thus the new driver did not find it anymore. :-/ HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#260099: xlibmesa-gl: for Voodoo3 cards, should suggest libglide3-dev instead of only libglide3
Package: xlibmesa-gl Version: 4.3.0.dfsg.1-4 Severity: normal Hi, direct rendering is disabled until libglide3-dev is installed since libglide3.so is dlopened which is (due to Debian policy, I guess) only in package libglide3-dev. Thus, this package needs to Suggest: libglide3-dev and not libglide3 (pulled in by libglide3-dev) unless you get the maintainer to not follow policy, here. Maybe this suggest should even be moved to xlibmesa-dri since the tdfx_dri.so module causes this effect (or I got it all wrong ;) HS -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] Versions of packages xlibmesa-gl depends on: ii libc6 2.3.2.ds1-13 GNU C Library: Shared libraries an ii libxext6 4.3.0.dfsg.1-4 X Window System miscellaneous exte ii xlibs 4.3.0.dfsg.1-4 X Window System client libraries m -- no debconf information
Splitting packages of video drivers in XF4.2 ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I have some kind of wish to discuss which would makes life much less hard for users of non-Debian-files: It is fact that not all graphics hardware runs with the drivers supplied with XF4.x, some examples are: some NVidia cards (if you want any acceleration at all) Matrox cards (if you need the mga_hal, e.g. for DRI) 3Dfx-V3 on earlier XFree version (the YUV support) maybe others, too The problem is: most of those drivers (best example is Matrox) simply replace some original files in /usr/X11R6/lib/modules. As those are not marked and config files (and they are no config files and this is no_ request to make them), they silently get overwritten. The surprise is then on a non-funtional X on restart :( I think the probably best solution would be to split off the video cards drivers into one extra package, only keeping generic drivers in xserver-xfree86. Sincerly... Hendrik Sattler PS: Actually, the problem that files get silently overwritten is also with other files likes Lepieds' wacom_drv.o but it should not address a majority of users. - -- Mein GPG-Key ist auf meiner Homepage verfügbar: http://www.hendrik-sattler.de oder über pgp.net PingoS - Linux-User helfen Schulen: http://www.pingos.schulnetz.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8ynHzzvr6q9zCwcERAmrSAJ4npAaSbDjdev6tOZI+FzdpaW+bAQCfXdBG kCrEAGJLvaormhzACpGkVPM= =E+F1 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Splitting packages of video drivers in XF4.2 ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Samstag, 27. April 2002 23:19 schrieben Sie: On Sat, 2002-04-27 at 11:39, Hendrik Sattler wrote: I have some kind of wish to discuss which would makes life much less hard for users of non-Debian-files: It is fact that not all graphics hardware runs with the drivers supplied with XF4.x, some examples are: some NVidia cards (if you want any acceleration at all) Matrox cards (if you need the mga_hal, e.g. for DRI) 3Dfx-V3 on earlier XFree version (the YUV support) maybe others, too The problem is: most of those drivers (best example is Matrox) simply replace some original files in /usr/X11R6/lib/modules. As those are not marked and config files (and they are no config files and this is no_ request to make them), they silently get overwritten. The surprise is then on a non-funtional X on restart :( I think the probably best solution would be to split off the video cards drivers into one extra package, only keeping generic drivers in xserver-xfree86. You don't have to overwrite package-controlled files in this case; the X server supports several module paths, just put them in /usr/local/X11R6 or wherever. To the above: Where are those paths defined? There is nothing in /etc/X11 that specifies something in /usr/local. Maybe they are compiled in (or even hard-coded)? Anyway, this would not work anyway because the module names are equal and I guess that XFree will prefer /usr/X11R6 to anything else. Well, dpkg-divert works alright, I just did not know about that feature of dpkg (and how to search for a feature you do not even know the word for?). Hendrik Sattler -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8yzg8zvr6q9zCwcERAiUQAJ42DIB7dfKjYXR/5sqcEVfpsYY0uwCgh10e NG6L9XfjwqUyInqKbsOxDCo= =1xUU -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
