Created attachment 323344 [details, diff] patch for eselect-xvmc-0.3.eselect Please include the following patch in the next version of eselect-xvmc.
Created attachment 323370 [details, diff] patch for eselect-xvmc-0.3.eselect Updated version of the first patch.
@Ulm: could you incorporate this patch into the eselect repository.
(In reply to comment #2) > @Ulm: could you incorporate this patch into the eselect repository. I can do, but cardoe should give his O.K. to this, as he's listed as maintainer of the xvmc module.
@cardoe: ping
@ulm: it is nearly 4 months later, how long should we wait for the OK to fix all these eselect-xvmc bugs?
Yes, I think that we should fix it ourselves. However, I just noticed that there are calls to get_libname and uname in global scope. This should be avoided, see eselect's developer guide: .. Warning:: In ebuilds, global scope code can cause problems. In eselect modules, global scope code is **absolutely forbidden**. Your module *will* be sourced for tasks other than running your actions. For example, if ``eselect modules list`` is executed, your module will be sourced to obtain the description. Any code being run here would be a very bad thing. So, could you move these calls to local scope of some function please? (Probably it would also improve performance if the output was cached in some variable, instead of calling uname a dozen times.)
(In reply to comment #6) > So, could you move these calls to local scope of some function please? > (Probably it would also improve performance if the output was cached in some > variable, instead of calling uname a dozen times.) How would one do that? get_libname is used to create the content of XVMCLIBS. Would it be ok to do something to replace XVMCLIBS by function xvmclibs_options() ?
(In reply to comment #7) > > So, could you move these calls to local scope of some function please? > > (Probably it would also improve performance if the output was cached in some > > variable, instead of calling uname a dozen times.) > How would one do that? get_libname is used to create the content of XVMCLIBS. > Would it be ok to do something to replace XVMCLIBS by function > xvmclibs_options() ? I'd just move the variable assignment into an init function that is called at the beginning of all do_* functions.
(In reply to comment #5) > @ulm: it is nearly 4 months later, how long should we wait for the OK to fix > all these eselect-xvmc bugs? Yes please. Go for it, I've been too busy to really look into this.
@ulm: I added it to proj/eselect.git, please have a look if you agree with the solution.
(In reply to comment #10) > @ulm: I added it to proj/eselect.git, please have a look if you agree with > the solution. I've made a small change, namely replaced the uname -s call by the OSTYPE variable, which is faster (and more reliable): http://git.overlays.gentoo.org/gitweb/?p=proj/eselect.git;a=commit;h=59a88458c795674b63f5d668695712a2c063d9ab See also this commit for a similar change elsewhere: http://git.overlays.gentoo.org/gitweb/?p=proj/eselect.git;a=commit;h=40f82c2ca4450db7fbc70c3e281361deb8fc8e90
+*eselect-xvmc-0.4 (11 Mar 2013) + + 11 Mar 2013; Christoph Junghans <ottxor@gentoo.org> +eselect-xvmc-0.4.ebuild, + +files/eselect-xvmc-0.4.eselect, metadata.xml: + version bump (fixes bugs #393027, #292120 and #434518)