Re: [gentoo-user] virtual eselect - how to
[image: 56973125-e55d8300-6b74-11e9-99c7-142bfc4b2b11.png]
[image: 56973077-d1198600-6b74-11e9-97a0-315e789142cd.png]
[image: 56973043-c3640080-6b74-11e9-9415-90b3fa01ee9f.png]
Hasan Ç. , 29 Haz 2019 Cmt, 04:20 tarihinde şunu yazdı:
> Hi All,
>
> I mentioned my active PR a few times on dev-lists that covers *openblas
> ebuild (for main gentoo tree ~amd64)* + *integrated switch script between
> openblas and gentoo reference set* {c,}blas, lapack and gsl (gnu
> scientific library) *system-wide.* It seems i could not announce it
> enough.
>
> Here is the complete openblas PR + system-wide switch script, if someone
> interested in -->
> https://github.com/gentoo/gentoo/pull/11700
>
> *Here is the code who want to inspect switch script before use it -->*
>
> https://github.com/gentoo/gentoo/blob/04b5fc9c117571ce040a94f63c6d09e0ce15c5f8/sci-libs/openblas/files/openblas
>
>- I believe the proper way is eselect instead of this script but
>openblas switch script is my quick fix until openblas fully integrated to
>main tree and eselect.
>- After switching to openblas system wide with script i tested it with
> *numpy
>& scipy, *both of them compiled with openblas support without any
>issue.
>- *This is not officially merged PR and maybe it never will.Also
>switch script not reviewed deeply by gentoo devs and may need
>improvement.This is my own solution.Please consider this before use it.*
>
> Screenshot's of the openblas switch script -->
>
> *openblas --status*
> [image: 56973125-e55d8300-6b74-11e9-99c7-142bfc4b2b11.png]
>
> *openblas --openblas*
> [image: 56973077-d1198600-6b74-11e9-97a0-315e789142cd.png]
>
> *openblas --help*
> [image: 56973043-c3640080-6b74-11e9-9415-90b3fa01ee9f.png]
>
> Hasan Calisir | Proxy Maint
>
> Helmut Jarausch , 26 Haz 2019 Çar, 16:05 tarihinde
> şunu yazdı:
>
>> Hi,
>> what is the relationship of a virtual package and eselect.
>> E.g.
>> I have installed openblas but 'eselect blas list' doesn't know about
>> this.
>> I have even modified virtual/blas to include openblas.
>>
>> How does eselect get the list of alternatives?
>>
>> Many thanks for a hint,
>> Helmut
>>
>>
Re: [gentoo-user] virtual eselect - how to
Hi All,
I mentioned my active PR a few times on dev-lists that covers *openblas
ebuild (for main gentoo tree ~amd64)* + *integrated switch script between
openblas and gentoo reference set* {c,}blas, lapack and gsl (gnu scientific
library) *system-wide.* It seems i could not announce it enough.
Here is the complete openblas PR + system-wide switch script, if someone
interested in -->
https://github.com/gentoo/gentoo/pull/11700
*Here is the code who want to inspect switch script before use it -->*
https://github.com/gentoo/gentoo/blob/04b5fc9c117571ce040a94f63c6d09e0ce15c5f8/sci-libs/openblas/files/openblas
- I believe the proper way is eselect instead of this script but
openblas switch script is my quick fix until openblas fully integrated to
main tree and eselect.
- After switching to openblas system wide with script i tested it
with *numpy
& scipy, *both of them compiled with openblas support without any issue.
- *This is not officially merged PR and maybe it never will.Also switch
script not reviewed deeply by gentoo devs and may need improvement.This is
my own solution.Please consider this before use it.*
Screenshot's of the openblas switch script -->
*openblas --status*
[image: 56973125-e55d8300-6b74-11e9-99c7-142bfc4b2b11.png]
*openblas --openblas*
[image: 56973077-d1198600-6b74-11e9-97a0-315e789142cd.png]
*openblas --help*
[image: 56973043-c3640080-6b74-11e9-9415-90b3fa01ee9f.png]
Hasan Calisir | Proxy Maint
Helmut Jarausch , 26 Haz 2019 Çar, 16:05 tarihinde şunu
yazdı:
> Hi,
> what is the relationship of a virtual package and eselect.
> E.g.
> I have installed openblas but 'eselect blas list' doesn't know about
> this.
> I have even modified virtual/blas to include openblas.
>
> How does eselect get the list of alternatives?
>
> Many thanks for a hint,
> Helmut
>
>
Re: [gentoo-user] Re: What the devil?!! [or Plasma teething problems Ia.]
On Friday, 28 June 2019 16:06:50 BST »Q« wrote: > On Thu, 27 Jun 2019 12:42:56 +0100 > > Mick wrote: > > On Thursday, 27 June 2019 10:55:16 BST Mick wrote: > > > The next thing to try: > > > > > > I don't have elogind starting up as a boot level rc service, > > > because it is launched when needed by dbus or pam. Perhaps if > > > elogind is running as a background service sddm will (re)launch > > > differently? > > > > I just tried it and it works. :-) > > > > With elogind running as a boot service, sddm launches with the > > Shutdown/Reboot buttons shown and they work as expected. However, as > > I do not have a /usr/ bin/loginctl, all I can assume is irrespective > > of the HaltCommand path specified in the default sddm config, when > > launched sddm searches all paths and eventually finds /bin/loginctl, > > which it runs when a button is pressed. > > > > As we've established with no -elogind +consolekit the commands > > specified in the default sddm config file are different. Also, with > > consolekit being a default rc service, it is running at the time sddm > > is launched. > > I use openrc, so I have sddm installed with -elogind -systemd > +consolekit +pam. Putting consolekit in the default runlevel does make > the buttons work the first time sddm is launched, on reboot. > > Without the conosolekit service in the default runlevel, the buttons > are greyed out after reboot, but restarting xdm some time after booting, > still without consolekit running, makes the buttons come alive and > work. At this stage, when you are restarting xdm, you've logged in the console and (I'm guessing) dbus+polkit+pam are running even if consolekit is not. Consolekit is needed for multiple users, so it is not necessary for this purpose, although if it's already running I understand it helps with the authentication by calling on pam. So, I'm surmising, dbus calls in polkit & pam, since you're logged in, which allows access to /sbin/shutdown. # ldd /usr/bin/sddm | grep dbus libdbus-1.so.3 => /usr/lib64/libdbus-1.so.3 (0x7f537416) > So there's something in play other than consolekit for me. > > (I don't actually need to sort this out -- I'm just curious.) It may have something to do with dbus/polkit, which authenticates access to the /sbin/shutdown file locally by sddm and this makes the buttons visible/ actionable. If you have not logged in yet, after a reboot, then only dbus is running at that stage with no authentication mechanism. I may be *wildly* wrong, but no doubt more knowledgeable members will drop by soon to correct me. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: What the devil?!! [or Plasma teething problems Ia.]
On Thu, 27 Jun 2019 12:42:56 +0100 Mick wrote: > On Thursday, 27 June 2019 10:55:16 BST Mick wrote: > > > The next thing to try: > > > > I don't have elogind starting up as a boot level rc service, > > because it is launched when needed by dbus or pam. Perhaps if > > elogind is running as a background service sddm will (re)launch > > differently? > > I just tried it and it works. :-) > > With elogind running as a boot service, sddm launches with the > Shutdown/Reboot buttons shown and they work as expected. However, as > I do not have a /usr/ bin/loginctl, all I can assume is irrespective > of the HaltCommand path specified in the default sddm config, when > launched sddm searches all paths and eventually finds /bin/loginctl, > which it runs when a button is pressed. > > As we've established with no -elogind +consolekit the commands > specified in the default sddm config file are different. Also, with > consolekit being a default rc service, it is running at the time sddm > is launched. I use openrc, so I have sddm installed with -elogind -systemd +consolekit +pam. Putting consolekit in the default runlevel does make the buttons work the first time sddm is launched, on reboot. Without the conosolekit service in the default runlevel, the buttons are greyed out after reboot, but restarting xdm some time after booting, still without consolekit running, makes the buttons come alive and work. So there's something in play other than consolekit for me. (I don't actually need to sort this out -- I'm just curious.)
