Bug#579102: Depends on non-main packages to compile
notfound 579102 conky/1.8.0-1 quit Vincent Bernat wrote: found 579102 1.8.1-1 found 579102 1.8.1-2 severity 579102 serious thanks Hi! 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. It seems that the meaning of this bug drifted over time. :) I'm marking this as not affecting squeeze because the release-critical side-bug --- conky being in main but Build-Depending on a package outside main --- did not hit squeeze. The non release-critical original bug --- that conky should be in main --- is probably not something that could be fixed in squeeze at this point in the release cycle. Thanks for your work. Sorry for the noise, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579102: Depends on non-main packages to compile
2011/8/9 Aron Xu happyaron...@gmail.com: Stay at current approach is the most reasonable way I can think of. As Dererk said he had asked ftp-masters about the problem on this personally, it would be fine to ask them reply to this bug if anyone still want to ask the question. Our points on this issue are already very clear so we need an agreement in the end, and I think there are no better solutions than asking ftp-masters because it's them that decide what's ACCEPTED and what's not. Vincent, do you think we need their answer? If yes, can you ask them to reply here? -- Regards, Aron Xu Well, I trust Dererk's word, so I'm not all that inclined to trouble the ftp-masters again. Vincent, are you satisfied with Dererk's reply, or would you like me to contact the ftp-masters regardless? As for the issue of users with only main enabled in their sources.list being left with a conky that's somewhat stripped of features (conky-std), I plan to address this by enabling a few more common features in conky-std (rather than adding another binary package); see #579893 for details. Is that an acceptable solution for you? Kind regards, - Vincent Cheng -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579102: Depends on non-main packages to compile
OoO En cette fin de nuit blanche du jeudi 11 août 2011, vers 05:52, Vincent Cheng vincentc1...@gmail.com disait : Well, I trust Dererk's word, so I'm not all that inclined to trouble the ftp-masters again. Vincent, are you satisfied with Dererk's reply, or would you like me to contact the ftp-masters regardless? As for the issue of users with only main enabled in their sources.list being left with a conky that's somewhat stripped of features (conky-std), I plan to address this by enabling a few more common features in conky-std (rather than adding another binary package); see #579893 for details. Is that an acceptable solution for you? Fine by me. -- Vincent Bernat ☯ http://vincent.bernat.im Make sure input cannot violate the limits of the program. - The Elements of Programming Style (Kernighan Plauger) pgpII4Hnz6vlv.pgp Description: PGP signature
Bug#579102: Depends on non-main packages to compile
On 08/08/11 21:59, Vincent Cheng wrote: [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. Although It might appear in the first sight that it's against the policy, a further look around shows a different scenario. The main packages themselves , conky-cli and conky-std, do not depend in any way on contrib ones, opposite to conky-all. The tricky part for the policy is that the _source_ package is the one that requires a contrib package to build all their binary ones, and that's not specified in any part. Moreover, and not to judge by my misguided daemons, I personally asked one FTP-Master on this, and his answer was crystal clean, word by word quoting: We are going to call you names, but it's OK. There are a few package on that situation and It's better this way. Cheers, Dererk -- BOFH excuse #28: CPU radiator broken signature.asc Description: OpenPGP digital signature
Bug#579102: Depends on non-main packages to compile
Stay at current approach is the most reasonable way I can think of. As Dererk said he had asked ftp-masters about the problem on this personally, it would be fine to ask them reply to this bug if anyone still want to ask the question. Our points on this issue are already very clear so we need an agreement in the end, and I think there are no better solutions than asking ftp-masters because it's them that decide what's ACCEPTED and what's not. Vincent, do you think we need their answer? If yes, can you ask them to reply here? -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579102: Depends on non-main packages to compile
On Mon, 08 Aug 2011 07:50:38 +0200 Vincent Bernat 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). Actually, I was suspecting that something did not really comply with Debian Policy... And I expressed some doubts in the bug log, indeed. I hope that this may be solved for the best. Therefore, conky should be moved back into contrib. No, please! I waited for so long to see conky back in main! [...] 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. I really hope that we can find a way to have conky (at least the conky-std and conky-cli binary packages) in main! If I understand correctly, you are proposing to use system calls to invoke the nvidia-settings command, if installed. That would turn the Build-Depends on nvidia-settings into a Suggests and let all binary packages built from the conky source package to be allowed in main. I hope this solution is viable. Thanks for proposing it! Now, let's hear what Vincent (Cheng) thinks about it. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpPQYQV8RpWt.pgp Description: PGP signature
Bug#579102: Depends on non-main packages to compile
OoO Vers la fin de l'après-midi du lundi 08 août 2011, vers 16:36, Francesco Poli invernom...@paranoici.org disait : Therefore, conky should be moved back into contrib. No, please! I waited for so long to see conky back in main! Sure, but currently, there is a problem with the policy. But I hope we will find a way to keep it or get it back quickly into main. 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. I really hope that we can find a way to have conky (at least the conky-std and conky-cli binary packages) in main! If I understand correctly, you are proposing to use system calls to invoke the nvidia-settings command, if installed. That would turn the Build-Depends on nvidia-settings into a Suggests and let all binary packages built from the conky source package to be allowed in main. I hope this solution is viable. Thanks for proposing it! Yes. And I propose to implement it but I cannot test it since I don't use the proprietary nvidia driver. -- Vincent Bernat ☯ http://vincent.bernat.im /* * Hash table gook.. */ 2.4.0-test2 /usr/src/linux/fs/buffer.c pgpK6KDjGA2Wi.pgp Description: PGP signature
Bug#579102: Depends on non-main packages to compile
[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
Bug#579102: Depends on non-main packages to compile
found 579102 1.8.1-1 found 579102 1.8.1-2 severity 579102 serious thanks Hi! 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. 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. 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. -- Vincent Bernat ☯ http://vincent.bernat.im panic(aha1740.c); /* Goodbye */ 2.2.16 /usr/src/linux/drivers/scsi/aha1740.c -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
