Re: [gentoo-dev] maintainer-wanted: x11-drivers/nvidia-drivers
On Tue, Mar 05, 2013 at 02:01:31AM -0500, Walter Dnes wrote: On Mon, Mar 04, 2013 at 03:44:33PM -0100, Carlos Silva wrote On Mon, Mar 4, 2013 at 3:28 PM, Walter Dnes waltd...@waltdnes.org wrote: I'm not a C programmer, let alone a developer, so this may be a stupid question, but here goes... has anyone ever tried doing a HAL (Hardware Abstraction Layer) to present a reasonably stable interface to binary video drivers? Think of it as a shim translating a pseudo-API into the real API that the kernel exposes directly. Surely, we can do better than VESA. Give drivers 2 options... 1) direct kernel access like now 2) access via the HAL/shim Just read this file and you'll have the answer: /usr/src/linux/Documentation/stable_api_nonsense.txt Thanks. That was an eye-opener. If user-space drivers are really that slow, we may as well stick with VESA as a fallback. Ok, I'll bite, What do you mean by that? Where does the stable_api_nonsense.txt file talk about userspace drivers? greg I wrote that file k-h
[gentoo-dev] Last rites: dev-php/PEAR-PEAR_PackageFileManager_Cli
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Ole Markus With olemar...@gentoo.org (05 Mar 2013) # Conflicts with app-misc/pfm (bug 460222). Upstream gone. # Masked for removal in 30 days. dev-php/PEAR-PEAR_PackageFileManager_Cli -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQF8BAEBCgBmBQJRNbGmXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQyOEZEMjNGNzBENkE5N0Q2Q0ZFMkFDNDA2 QkFCNEFFNUM0QTkyQkY1AAoJEGurSuXEqSv1CgYH/iPsYaa5t9abd30T4CGYOdL2 fyoxD5SBDUFRkk1QKHIJuCC85q5OKKhYnhH4WoQhzMNEFhuES9G0KQTr1bZqJjpP mVjR6mYmaWfrEt7ACfsEVWTCSGD+LkHk/u3BV9oVhLaLdDcFTXoYHK6SEOgsKglN oJMrVqLRW7tNnG60JxfNTLImHytTZ2a91qcBUvdDDQ6EEvWq7JIYJNoTofAsz1MX hgItL4sTCsSzwyP+r9NYzF3xXhyR7sKnessVvpk3MUndBq+dnYUgF6mJRvvt0rWK I9HqgHU1NOQ0W2C4RAoWNAA+0mDhoIIcH2z2VeqQkwxG0ho9xo09ANXXSVXZfsM= =XogR -END PGP SIGNATURE-
Re: [gentoo-dev] maintainer-wanted: x11-drivers/nvidia-drivers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/03/13 08:01, Walter Dnes wrote: If user-space drivers are really that slow, we may as well stick with VESA as a fallback. You misunderstood something. «Please realize that this article describes the _in kernel_ interfaces, not the kernel to userspace interfaces.» - -- Alexander alexan...@plaimi.net http://plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlE1tDUACgkQRtClrXBQc7WDCgD/UKpbHP6MFTBZZruGIXIkeNfy qkNTPS/0c5QaoLSrDZ0A/jmyPwUDTybYVnHC3JvSyxQuicc6vNK+bfFSnJP8vIyB =j6Io -END PGP SIGNATURE-
Re: [gentoo-dev] proxy-maintainers herd as a backup herd for all the user-maintained packages
On 5 March 2013 03:41, Jeroen Roovers j...@gentoo.org wrote: On Sun, 03 Mar 2013 19:35:24 + Markos Chandras hwoar...@gentoo.org wrote: A number of packages in the tree are maintained by a Gentoo developer and a user. As a result of which, we are unable to monitor these packages in bugzilla. This is useful in case one of the maintainers goes MIA so we can find an alternative maintainer for them. So I am kindly asking you to add the proxy-maintainers herd as a backup herd for the packages that you proxy-maintain. I will go ahead and do it myself in two weeks if you don't want to bother fixing your metadata. If you want your packages to be excluded please let me know. This is mainly for tracking purposes and we don't intend to take over the maintainership of your packages (unless you want us to). Excellent idea. But how will proxy-maint@ devs know not to take over? jer If there is at least one Gentoo developer in metadata.xml we assume the package is properly maintained by him so we never touch it. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] C++ TR1 virtuals
2013/3/4 Diego Elio Pettenò flamee...@flameeyes.eu: virtual/c++-tr1-functional virtual/c++-tr1-memory virtual/c++-tr1-type-traits Given that these will have a (bad) GCC dependnecy and a boost dependency on them, should we just drop them? Sounds like best solution, so i would go for it. Cheers Tom
Re: [gentoo-dev] proxy-maintainers herd as a backup herd for all the user-maintained packages
On Tue, 5 Mar 2013 09:09:47 + Markos Chandras hwoar...@gentoo.org wrote: If there is at least one Gentoo developer in metadata.xml we assume the package is properly maintained by him so we never touch it. Sounds fine. I for one am converted (and the packages I maintain in that fashion). jer
Re: [gentoo-dev] maintainer-wanted: x11-drivers/nvidia-drivers
On Tue, Mar 05, 2013 at 04:47:09PM +0800, Greg KH wrote On Tue, Mar 05, 2013 at 02:01:31AM -0500, Walter Dnes wrote: On Mon, Mar 04, 2013 at 03:44:33PM -0100, Carlos Silva wrote On Mon, Mar 4, 2013 at 3:28 PM, Walter Dnes waltd...@waltdnes.org wrote: I'm not a C programmer, let alone a developer, so this may be a stupid question, but here goes... has anyone ever tried doing a HAL (Hardware Abstraction Layer) to present a reasonably stable interface to binary video drivers? Think of it as a shim translating a pseudo-API into the real API that the kernel exposes directly. Surely, we can do better than VESA. Give drivers 2 options... 1) direct kernel access like now 2) access via the HAL/shim Just read this file and you'll have the answer: /usr/src/linux/Documentation/stable_api_nonsense.txt Thanks. That was an eye-opener. If user-space drivers are really that slow, we may as well stick with VESA as a fallback. Ok, I'll bite, What do you mean by that? Where does the stable_api_nonsense.txt file talk about userspace drivers? greg I wrote that file k-h My statement was a general response to the entire thread. Sorry, I should've retitled it [REDUX whatever] * stable_api_nonsense.txt explained lack of a stable *KERNEL* api * Duncan's message talked about slow *USERSPACE* API... Of course it's possible to implement a userspace driver that wouldn't have the same issues as it'd use the stable userspace API, but that's generally accepted to be far too high a performance cost for graphics drivers, regardless of the kernel involved (MS tried it too for stability reasons and gave up at the performance penalty they were taking). So between your file, and Duncan's message, I saw that... 1) a stable kernel API is not possible 2) a userspace API is too slow. I apologize again for the vagueness in my previous reply. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
[gentoo-dev] [RFC] New category for LeechCraft
Hi, Currently there are 61 leechcraft packages in tree scattered across several categories. We propose to move them to one new category to make maintaining easy as well as rsync --exclude'ing. So, two questions: 1) Do you agree with adding new category? 2) How should we call it: app-leechcraft, leechcraft-base or anything else? Thanks, Maxim.
Re: [gentoo-dev] [RFC] New category for LeechCraft
2013/3/6 Maxim Koltsov maksbo...@gentoo.org: 1) Do you agree with adding new category? Yep :) 2) How should we call it: app-leechcraft, leechcraft-base or anything else? Personally I'd prefer app-leechcraft (or maybe app-lc to save some typing). I doubt there will be anything but that single category in the foreseeable future, and leechcraft-base suggests also something like leechcraft-addons. -- Georg Rudoy LeechCraft — http://leechcraft.org
