Re: kde 4.3.4 is building for unstable now ;-)
On Saturday 12 December 2009 10:41:39 Modestas Vainius wrote: > You clearly ask for trouble installing proprietary nvidia drivers > non-debian way. Probably mesa was upgraded breaking > "installation" produced with nvidia installer. Switch to the > debian way. On Saturday 12 December 2009 17:30:51 Modestas Vainius wrote: > Could somebody tell me what's so attractive about that broken nvidia > installer? Hi Modestas, I think 'asking for trouble' is a little disingenuous - as I'm not actually asking for trouble. If my way failed to work and caused me problems, then I'd take your point - I should change my ways. The fact that my way has worked well for me for the 15 years I've been using Debian suggests that no one's asking for anything here. The nvidia installer has never been broken - more often it's X or udev or KDE or something else that you get caught out by when you live on unstable / experimental. FWIW the problem I saw, I have since put down to the 4.3.2 and 4.3.4 mix - everything is fine now. I compile my own kernels - my way - and compile the nvidia drivers based on those kernels. I grab the linux-source deb, of course, it's just that I don't use make-kpkg - I find it's just not worth the bother. I understand there are some compelling benefits for many people ... just not for me. Out of curiosity I went through The Process yesterday and today. Part of the problem is the transition from custom to Debian way, I know. For instance the presence of the /lib/modules/2.6.30 directory was confusing for dpkg--install. I thought I'd be tricky and just move to 2.6.32 using the full Debian way - you know, good opportunity for a clean break and all that. make-kpkg -bzimage *should* give me a /boot/bzImage.2632, and I see that the bzImage stuff floating past during the compilation and package-making process - but it still just produces a vmlinuz file. The make-kpkg fails out of the gate for me, as it doesn't respect (or at least quietly ignore) the MAKEFLAGS setting I have (-j 10). So that's another little step I have to do to make make-kpkg work. The vbox modules I had on 2.6.30 - installed via the Debian way - are not under the /lib/modules/2.6.32 directory now - I'll have to investigate why they failed to be built or added to the modules deb. The kernel that it created failed to boot - with a VFS error - because I run an encrypted root file system, and so had to revert to a safe kernel, run the mkinitrd script manually, and patch the grub2 files then re-run grub-mkconfig. I'm happy to do this, as I know I'm not a vanilla user ... and I kind of know what I'm doing. I mention all of this just to explain why some of us don't jump on the Debian way for kernel and video drivers. Sure, for people who are new to GNU/Linux, and/or new to Debian, the stock kernel is just tickety-boo, and the transition for them to use the tools to generate driver and kernel .deb files is probably a bit easier for them. In any case, back on topic, 4.2.4 is now installed on laptop and desktop, and .. doesn't seem savagely different, but it's nice to know that it's all there now. :) cheers, Jedd. -- To UNSUBSCRIBE, email to debian-kde-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: kde 4.3.4 is building for unstable now ;-)
Alle domenica 13 dicembre 2009, jedd ha scritto: > On Saturday 12 December 2009 10:41:39 Modestas Vainius wrote: > > You clearly ask for trouble installing proprietary nvidia drivers > > non-debian way. Probably mesa was upgraded breaking > > "installation" produced with nvidia installer. Switch to the > > debian way. > > > cheers, > Jedd. > Ok Jedd, do everything your own way, but let me underscore that you are quite often complaining about the way KDE doesn't work for you and reporting numerous malfunctions in your system that none else is experiencing. Maybe that following your own way is causing some troubles? If I was you, I would consider this possibility. I hope you understand that mine is just a fair critics. Bye Valerio -- To UNSUBSCRIBE, email to debian-kde-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: kde 4.3.4 is building for unstable now ;-) [OT] nvidia-installer Vs m-a
El Domingo 13 Diciembre 2009 01:11:53 Modestas Vainius escribió: > Well, what you helps you is that you are experienced enough user to be able > to > deal with all bad side effects of nvidia installer. No, not really a very experienced user, honestly. What helps me is that Nvidia installer has never caused any problem on my machines nor has it taken from my scarce -and worth being spent in more interesting things- time more than a minute or two. I would spend more time on dealing with m-a, GCC versions, xorg.conf & al. and praying to several gods from all over the world for m-a installing process to work -direct rendering included- at the first attempt, if I'd see a clear, doubtless remarkable, benefit, but honestly all those messes you mention, by the official installer... I only can say that I have not had any issue at all; and using the Debian way to install some, still closed, drivers doesn't even satisfy my sympathy for the Debianish "ideology", which might be a good reason, O.T.H. > Nvidia installer generally causes: > > 1) System pollution with libraries and other files some of which might not be > needed. Like might not be needed Cups, Vim, Ed, and some other apps and libraries that are installeed by default, and I manually have to purge right after "netinstalling" my basic system (since I use Nano and don't even have a printer), or just put up with them in order to not breaking something. Not to talk about that "obesity inducer" habit that kernel hackers have including every driver on earth, in it. What I mean with these examples is that I suppose some pollution is the price to pay if one wants a comfortable Linux system instead of compiling by hand or dealing with more "harsh", even if "KISS", distros. Less pollution as possible is always a good practice, yes, and some inevitable pollution doesn't mean we have to include even more, but from my Nvidia-problems-free experience, it's not worth the complication when after all, we aren't going to get a perfectly unpolluted system. > I've already had a "pleasure" to help users clean up system from the > mess caused by nvidia installer a couple of times. Believe me, it was not fun I do believe you and all others who don't like Nvidia installer; I've never put into doubt your points; but, once again, I honestly just can say that the official installer has always worked perfectly and fast for me, I even remember being unable to make drivers a la Debian work correctly on one of my old machines, and ending up installing the official driver which worked perfectly, that's how I began to like it. I also can't believe that all of those who use the official installer have experienced bad issues; if they have, obviously should switch to the Debian way inmediately. No, I think that most of Nvidia installer users just have an experience as good as mine. Ironic enough, I have had more porblems in other computer with ATI free drivers and Xorg libraries a copule of months ago (cause identified thanks to your kind guidance, Modestas, by the way). The official installer is an option more. All in all, we have not to forget that their drivers are still as closed as always, no matter which method we use to install them. A different subject would be if there were open and totally functional drivers, or Nvidia changes its policy, but it seems frogs will grow hair before that. Bye. -- To UNSUBSCRIBE, email to debian-kde-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: kde 4.3.4 is building for unstable now ;-)
On Sunday 13 December 2009 20:18:39 Valerio Passini wrote: > Ok Jedd, do everything your own way, but let me underscore that you are > quite often complaining about the way KDE doesn't work for you and > reporting numerous malfunctions in your system that none else is > experiencing. Maybe that following your own way is causing some > troubles? If I was you, I would consider this possibility. > I hope you understand that mine is just a fair critics. Bye Hey Valerio ... I feel I might be about to 'protest too much' :) I accept that many of my posts are a bit complainy in nature, but I dispute that (m)any of them could be tracked back to a self-compiled kernel or self-compiled nvidia driver. I accept that some people think that one or two of the bugs I've asked about on here are related to the nvidia driver per se, specifically the delay while resizing one application (konsole). I've pointed out already that my earlier message in this thread, regarding snow on the screen, turned out to be due to the mix of 4.2.4 and 4.2.2 packages. It was posted more as a warning to others to delay updating their unstable box for a few hours. I should probably have been more explicit about that, I suppose, but I appreciate when others post such recommendations, as it can save you a whole heap of pain. Looking at the output of make-kpkg, specifically the kernel image and the nvidia drivers - they (as you'd expect) come out to be binary-identical files, no matter what packaging method you use. (This makes sense because for the kernel, I'm using the Debian kernel source packages, and for the nvidia driver, we'll we're all using the same file from the nvidia site.) That is, native nvidia installer, or Debian wrapper around same - will both produce identical kernel and xorg modules. As I say, this is exactly what you'd expect. Similarly, a 'make bzImage && make modules && make modules_install' will produce an identical set of binaries in /boot and /lib/modules as using make-kpkg and then doing a dpkg --install on the resultant .deb would. Again, as you'd expect. If there *were* any differences, then I'd be very worried. I doubt you're suggest that there's some kind of weird homeopathic 'memory of the command line that made it' influencing factor such that a kernel knows whether it was made with make bzImage or via make-kpkg. If it does know this, *and* behaves differently, then that's very bad news for all the RH, CentOS, Suse (etc) users. :) J. -- To UNSUBSCRIBE, email to debian-kde-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: kde 4.3.4 is building for unstable now ;-)
Alle domenica 13 dicembre 2009, jedd ha scritto: > On Sunday 13 December 2009 20:18:39 Valerio Passini wrote: > > Ok Jedd, do everything your own way, but let me underscore that you > > are quite often complaining about the way KDE doesn't work for you > > and reporting numerous malfunctions in your system that none else > > is experiencing. Maybe that following your own way is causing some > > troubles? If I was you, I would consider this possibility. I hope > > you understand that mine is just a fair critics. Bye > > Hey Valerio ... I feel I might be about to 'protest too much' :) > > I accept that many of my posts are a bit complainy in nature, > but I dispute that (m)any of them could be tracked back to a > self-compiled kernel or self-compiled nvidia driver. > > I accept that some people think that one or two of the bugs > I've asked about on here are related to the nvidia driver per se, > specifically the delay while resizing one application (konsole). > > I've pointed out already that my earlier message in this thread, > regarding snow on the screen, turned out to be due to the mix > of 4.2.4 and 4.2.2 packages. It was posted more as a warning > to others to delay updating their unstable box for a few hours. > > I should probably have been more explicit about that, I suppose, > but I appreciate when others post such recommendations, as it can > save you a whole heap of pain. > > Looking at the output of make-kpkg, specifically the kernel image > and the nvidia drivers - they (as you'd expect) come out to be > binary-identical files, no matter what packaging method you use. > > (This makes sense because for the kernel, I'm using the Debian > kernel source packages, and for the nvidia driver, we'll we're all > using the same file from the nvidia site.) > > That is, native nvidia installer, or Debian wrapper around same - > will both produce identical kernel and xorg modules. As I say, this > is exactly what you'd expect. Similarly, a 'make bzImage && make > modules && make modules_install' will produce an identical set of > binaries in /boot and /lib/modules as using make-kpkg and then doing > a dpkg --install on the resultant .deb would. Again, as you'd > expect. If there *were* any differences, then I'd be very worried. > You were right if you didn't forget about APT. You are lucky because Debian doesn't introduce too much differences in the paths of libraries, executables and so on, at least on fundamental stuff like the kernel this allows you to mix source code compiled from tarballs and binaries belonging to the Debian repositories. Anyhow, even if you have the same library/executable and path, apt cannot track the stuff you compiled and installed using "make". This is the main reason why using .deb is strongly recommended everywhere unless you have special needs or you want a software that is not yet packaged. > I doubt you're suggest that there's some kind of weird homeopathic > 'memory of the command line that made it' influencing factor such > that a kernel knows whether it was made with make bzImage or > via make-kpkg. If it does know this, *and* behaves differently, > then that's very bad news for all the RH, CentOS, Suse (etc) users. > :) No weird belief in "PC mistery" here. I'm just suggesting: 1) you are probably screwing your system and fooling apt; 2) you are missing all the good features that a debianized kernel has, like calling update-grub at the end of the installation process automatically or not to have to go inside /lib/modules/ and use "rm" to remove stuff when you want to purge a kernel or having the chance to compile and install external modules from m-a. The proof that the two methods (debs and compiled sources) are not exactly the same is in the fact that every time Xorg is upgraded, you _need_ to rerun nvidia-installer. Why? Because apt removed links and files from the nvidia drivers during the upgrade. On the opposite, this doesn't happen to those which use m-a. This is the reason why I have completely abandoned the "make this and that" workflow and I have embraced make-kpkg and m-a: it's simply superior. Try it. Valerio -- To UNSUBSCRIBE, email to debian-kde-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
