[Adding Dererk, my original sponsor, to cc: for his input] On Sun, Aug 7, 2011 at 10:50 PM, Vincent Bernat <ber...@luffy.cx> wrote: > I am pretty sorry but providing a binary package that does not depend on > nvidia blob does not make conky allowed to be in main. Policy 2.2.1 > states that a package in main "must not require a package outside of > main for compilation or execution (thus, the package must not declare a > "Depends", "Recommends", or "Build-Depends" relationship on a non-main > package)". > > Therefore, conky should be moved back into contrib.
I was worried that this would be the case, which was why I originally planned on uploading conky as two separate source packages (see my earlier reply at [1] for my rationale), but my sponsor convinced me that this was unnecessary and not preferable, since it would result in two source packages that would be exactly the same. and that it's still possible for a source package in main to build-depend on contrib components and produce binary packages for main. I guess it is indeed possible since the buildds haven't been complaining about uninstallable build dependencies...but if it violates Policy, this shouldn't be at all possible and needs to be fixed. > Moreover, conky-std was lacking some functionalities of conky-all. This > is a pity that users that choose to keep their system with only free > stuff do not have access to a complete version of conky just because the > complete version also has nvidia stuff in it. Users of "main" should not > be second-class citizens. That's true; I couldn't think of any solutions earlier however, besides building yet another binary conky package (conky-all-nvidia?), but building additional binary conky packages is something I'd rather avoid. I hadn't thought about the possible solution you mention below though. ;) > It seems that nvidia.c could be provided into an alternate version that > uses nvidia-settings if installed. From: > https://wiki.archlinux.org/index.php/NVIDIA#Method_1_-_nvidia-settings > > $ nvidia-settings -q gpucoretemp -t > 41 > > If you can provide the name of other settings, I could come up with a > patch to solve this. An excerpt from [2] (scroll down to "nvidia"): Nvidia graficcard support for the XNVCtrl library. Each option can be shortened to the least significant part. Temperatures are printed as float, all other values as integer. threshold - The thresholdtemperature at which the gpu slows down temp - Gives the gpu current temperature ambient - Gives current air temperature near GPU case gpufreq - Gives the current gpu frequency memfreq - Gives the current mem frequency imagequality - Which imagequality should be chosen by OpenGL applications Example Conky output: ${nvidia threshold} -> "127" (in degrees celsius) ${nvidia temp} -> "40" (also in degrees celsius) ${nvidia ambient} -> "N/A" ("ambient" doesn't seem to be working for me for some reason) ${nvidia gpufreq} -> "169" (in MHz) ${nvidia memfreq} -> "100" (also in MHz) ${nvidia imagequality} -> "1" (valid values are from 0 to 3, 0 = high quality, 3 = high performance) This is what I've managed to deduce so far: $ nvidia-settings -q GPUCurrentClockFreqs -t 169,100 (first value = ${nvidia gpufreq}, second value = ${nvidia memfreq}) $ nvidia-settings -q OpenGLImageSettings -t 1 (= output of ${nvidia imagequality}) I've also dumped the output of "nvidia-settings -q all" into a pastebin [3], if it helps any. I'm not sure about ${nvidia threshold} or ${nvidia ambient} though, sorry. If you'd like to write a patch to implement this, I'd be glad to test it! - Vincent [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579102#47 [2] http://conky.sourceforge.net/variables.html [3] http://pastebin.com/KNGHiCVm -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
