On Tue, Oct 06, 2009 at 09:45:58AM +0200, thveillon.debian wrote: > I currently have 185.18.36-2 from Sid installed, my package list look like : > > aptitude search ~S~i~nnvidia > > i nvidia-glx > i nvidia-glx-ia32 > i nvidia-kernel-2.6.31.2-vanilla64 << this is the kernel module built > with "module-assistant", you won't find this one in your package manager > i nvidia-kernel-common > i nvidia-kernel-source > i nvidia-libvdpau1 > i nvidia-libvdpau1-ia32 > i nvidia-settings > i nvidia-xconfig
Thanks! How did you figure out which packages you need? When I look at the description for nvidia-glx, it says "binary drivers" and leaves it totally unclear which kernel versions it supports. Besides, the version in testing doesn't even support my graphics card. It must be a couple years old ... Then look at the description for nvidia-glx-ia32: "These XFree86 4.0 binary drivers provide optimized hardware acceleration of OpenGL applications via a direct-rendering X Server." I'm not on ia32, I'm on amd64. That can't be the right package, and when you look at the description, nvidia-glx does the same as nvidia-glx-ia32. And nvidia-kernel-common: "This package contains files shared between NVIDIA module packages." For which kernel???? For which driver version??????? nvidia-kernel-source: "This package builds the NVIDIA Xorg binary kernel module needed by nvidia-glx." For which kernel???? For which driver version??????? I don't know about vdpaul --- is that included in the nvidia installer? You see why I don't want to mess with all that? I've been downloading the installer from nvidias website and used that ever since I got my first nvidia card 10 years or so ago. Until now, it has been working just fine. Why are the package descriptions so poor, and why can't there just be one package you install? > Off course if you want the Sid version you need Sid "main" and Since my card isn't even supported in testing, I'd have to get those packages from unstable. I've tried using packages from unstable a couple times, but the results haven't been good. > "non-free" in your sources.list, and do package (or rather level) > pinning to prevent a global switch to Sid. In simple words, create a > /etc/apt/apt.conf file (or in /etc/apt/apt.conf.d/), and put in it : > > APT::Default-Release "testing"; > > You can also do more fine-grained "pinning" in /etc/apt/preferences (to > be created) OR /etc/apt/apt.conf.d/00preferences (to be created). > Something like : > > Package: * > Pin: release a=unstable > Pin-Priority: 101 > > Should give you manual control over what's installed from Sid/unstable. > Just google around for "apt package pinning" Well, that reminds me of getting an ATI mach32 to work with OS/2 (especially 3.0), and I really don't want to go back to that. That's why I keep buying nvidia: No problems to get them to work (until now). Really, it's funny: The ATI mach32 worked with OS/2 3.0 only for so long, then the driver suddenly quit working for no reason, and you had to go back and try to install it again. About 60% of the time you could; when you couldn't, you had to install OS/2 again. Now nvidia and Debian are almost the same. And if you ever tried OS/2 with an ATI mach32, you might understand how tired I am of this. > > Why can't I just use the nvidia installer? What's the difference? > > > >> If you do that directly it will build the default testing version, if > >> you install Sid packages first, you can use m-a to build the Sid > >> version, that's what I am using now on my Squeeze amd64 box. > > > > But I'm not using a Debian kernel. > > Neither am I, 2.6.31.2 here. There doesn't seem to be a newer version of the nvidia driver available than 190.32. So what's the difference? > Nvidia installer complains, then goes on spreading bogus links all over > the place, then the program tries to use 64bits libs in place of 32bits > compat ones and fails. I am not a specialist in Nvidia driver internals, > but it looks like it's seriously out of sync with Debian amd64 > development right now. Maybe that is because you mixed testing with unstable? > >> I am afraid it's more a problem with the proprietary nature of the > >> Nvidia driver. If it sucks big time it will always be in last resort > >> Nvidia's fault... Debian doesn't have to be tailored around proprietary > >> programs just to meet their needs. > > > > It doesn't help users when things suddenly quit working. > > Sure it's frustrating, I hate when Skype or GoogleEarth go "boom" after > an upgrade, but you've got to put the blame where it belongs. And all > the more when running Testing or Sid, development and testing are what > they are meant for. So who is to blame? Obviously Debian changed something that made the nvidia driver stop working. That is very much like the kernel developers (or Debian developers, if you want to) making a change that makes 50% of the harddisks suddenly stop working, and your comment would be that the kernel (Debian) doesn't have to be tailored around proprietary hardware just to meet the hardware manufacturers needs. That still doesn't help the users. And is there no Debian debian developer involved who has an nvida card? If there was, the problem would never have entered into testing. > Iceape is available in Sid only for now : > > apt-cache policy iceape > iceape: > Installed : (none) > Candidat : 1.1.17-2 > Table de version : > 1.1.17-2 0 > 500 http://ftp.fr.debian.org sid/main Packages > > It has been deprecated for a while in Testing, should reenter anytime > (by popular demand as I understand ?). If that's mozilla, the other browsers just can't replace it. They don't even work right. > If you don't feel like doing full-blown bug reports, open a specific > topic on the relevant list (here for instance) for each problem you > encounter (one per program), give as much specifics as you can so that > others can try to reproduce the problem, or confirm the exact same > setting is working for them (then you know it's probably a local > configuration problem). Most of the time you will find help and be able > to solve the problem. Otherwise you'll have material for your bug > report, or if a more experienced user is able to reproduce the problem > he might file the bug himself. As if I didn't have other things to do ... > Take a look at the "reportbug" program, it helps. IMHO testing or sid > users should be (at least a bit) familiar with bug reports, that's the > way to go with free opensource software. Yeah, take a look at that: " *** Please submit non packaging issue (e.g. feature requests) bugs to the Debian BTS and the upstream bugzilla (https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox) and put a reference to the bugzilla bug in the Debian bug report to ease bug triage for the maintainers. You may need to reproduce this with upstream's Firefox for upstream to take you seriously. Thank you. *** Iceweasel extensions being a big source of problems, please either try to reproduce your bug with a clean user or with your current user in safe mode, with the "iceweasel -safe-mode" command line before filing any bugs. If your bug disappears with a clean user or in safe mode, you might want to find which extension is responsible for it and file a bug to the appropriate package, bug tracking system, or author. If your previous Iceweasel installation pre-dates 3.0, you might have had problems since upgrading from one release to another can lack clean support for some features. Please try moving your ~/.mozilla/firefox directory out of the way to see if it helps with your issue. Iceweasel requires the loopback interface (lo) to be up and unfiltered to accept keyboard input and function correctly. Please make sure this is the case before filing any bugs. If you get crashes and none of the above hints helped, please also try to run "MOZILLA_DISABLE_PLUGINS=1 iceweasel". If Iceweasel still crashes, please install the iceweasel-dbg package and run gdb with the "iceweasel -g" command line. At the gdb prompt, type the following commands: set pagination off run bt full And attach the resulting backtrace to your bug report. If you see XML parsing errors, please make sure you kill all running Iceweasels and reload before filing any bugs. " So I'm supposed to spend a day or two messing around with it before sending a bug report because the browser keeps printing "(firefox-bin:17068): Gdk-WARNING **: XID collision, trouble ahead" (whatever that's supposed to mean) and eventually crashes. Great. I'm not willing to go to all these lengths. I take it this browser just still sucks and we might have to be without a working web browser forever or until mozilla eventually comes back. How long is this situation going on now? About a year? Galeon doesn't even start anymore. Konqueror for a web browser is more a bad joke, and it draws all the KDE crap with it that then continues to run in the background so that I have to go and kill it manually. > I use Iceweasel mostly, I have Konqueror and Opera installed too, > mostly for decoration purpose ;-), I don't feel restrained in my > choice. They all work well mostly, most crashes I encountered by the > past where linked to bad behaving extensions, or proprietary flash > plug-in. It doesn't matter to me if they crash because they can't deal with an extension or because there is another problem. I haven't tried opera in a very long time, but the other browsers currently available for Debian only sort-of work since quite a long time now. If the developers are at the point where they can't figure out if the browser crashes because of an extension or because of something else, maybe there is a need to develop some sort of interface or standard for browser extensions that protect the browser against extensions. Consider the extension as a program running under an OS: The program shouldn't be able to crash the OS. And why are meaningful error messages out of fashion? > > Things used to just work in Debian, but they do that less and > > less. That isn't good. > > > > > > Well, if stable doesn't meet your needs and other levels "bugs" you, One problem with stable was that it took way too long before a new release came out because when it finally came out, it could be a rather big leap to upgrade, causing problems. The other problem was that I sometimes needed more recent versions of some software or the kernel which then wasn't available in/possible with stable. This might have become better since they changed the release schedule, though. But testing used to be stable. Now it's unstable. > you can always try another Debian famous derivative where > semi-automatic bug reporting is well integrated... (there's no > bitter irony here, freedom of choice is what free software is > about). Yeah, but I'm not (yet) inclined to get a couple more disks and change them around to try out different distributions. And are they so much different? They do some things differently, but basically, they're all using the same software. And if other distributions have working web browsers, then why doesn't Debian? > If you want to carry on you can find help, and documentation > too. But ranting about Debian's quality going down is just the way > to attract flames, not helping hands... Why should pointing out that the quality seems to continue to go down since quite a while now attract flames? I've said it before, and it didn't change. Perhaps that is something that needs to be discussed and then can be improved upon, and it would be much better than forcing users to seek more help and make seeking help and sending bug reports more complicated and more time consuming. But it is not something I could discuss, I can only point it out. Hm, interesting. Try google for "debian quality statistic": There doesn't seem be any. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org