View Issue Details

IDProjectCategoryView StatusLast Update
0000734channel: elrepo/el7--elrepo--request-for-enhancement--public2017-07-03 12:44
Reportervychytraly Assigned Totoracat  
PrioritynormalSeverityfeatureReproducibilityhave not tried
Status resolvedResolutionfixed 
Summary0000734: Primus
DescriptionHello friends,

Im one of the laptop-using members of Centos community currently set up with great ElRepo packages using bumblebee and kmod-nvidia. (Thank you very much for creating it :) ) But the more I am reading about optirun and its options I think that it would be better if we had also an option for using primus with bumblebee (it can run VirtualGL or Primus but many websites mention that Primus is newer and faster method and dont have the problems VirtualGL often has - for example "hack" with running 2 terminals etc. - https://askubuntu.com/questions/669011/what-is-the-difference-between-optirun-and-primusrun ) Even current implementation of optirun on Centos laptops has an option to run apps via primus and also the bumblebee config file is pointing to primus libraries ( PrimusLibraryPath=/usr/lib/primus:/usr/lib32/primus ). But when I was looking for these folders I found out that they dont exist, so I think that I dont have primus installed and elrepo repository dont provide this package. Please do you think it would be possible to include primus to elrepo repository? I think that it could bring performance gain to all the Centos laptop users :)

//Itecs seems to have primus for el7 in their repos, but they are not compatible with elrepo packages:

http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/rhel7/x86_64/

(And no other repository provides primus)

//I also enclose github page I found mentioning primus:
https://github.com/amonakov/primus

Thank you very much for consideration and have a nice day :)

(P.S.1: There is also a function called PRIME, but I am not sure if it does the same thing as primus (primusrun) does)

(P.S.2: I am willing to test it and also to write documentation for other users how to set it up and use it! :) )

Vych
TagsNo tags attached.
Reported upstream

Activities

vychytraly

2017-05-03 14:36

reporter   ~0005165

Arch Docmumentation for Primus:
https://wiki.archlinux.org/index.php/bumblebee#Primusrun

toracat

2017-05-03 14:55

administrator   ~0005166

Last edited: 2017-05-04 13:49

Can you try a package distributed by SuSE? I rebuilt it under RHEL7. You can find it here:

http://elrepo.org/people/akemi/testing/el7/primus/

Note that it is not signed, just a rebuild of the original srpm without any modifications.

vychytraly

2017-05-05 16:16

reporter   ~0005170

Thank you very much, I will be testing it during this weekend and let you know how does it work :)

vychytraly

2017-05-05 16:32

reporter   ~0005171

First impression is great Akemi :)
Until now I tried only gfxgears and the performance boost is superb:

Just for comparison:
glxgears on virtualgl -> cca 8400 frames/5 seconds = cca 1700 FPS
glxgears on primus (with disabled vsync) -> cca 12000 frames/5 seconds = cca 2500 FPS

I will test it more also on some "production" applications and let you know how does it work, thank you very much :)

BTW is it difficult to rebuild SuSE packages for RHEL? Does it require some advanced programming skills? (Im sorry if its a stupid question, Im still a newbie in this area) :)

Have a nice day

toracat

2017-05-05 23:47

administrator   ~0005172

@vychytraly

Sounds like you've got quite encouraging results.

About rebuilding SuSE's packages for RHEL... in this particular case I did not do anything. Took the source rpm and just rebuilt it. However this may or may not work depending on the dependencies of the package you are building.

vychytraly

2017-05-10 14:30

reporter   ~0005179

Hello Akemi, to this day I tried primus with native gnome apps, darktable, blender and mpv, everything seems running fine, even on hidpi display, hardware acceleration seems working too :)

maybe you can pass it to elrepo-testing and can I write some documentation for other users about how to set it up and use it? :)

toracat

2017-05-10 18:27

administrator   ~0005180

@vychytraly

Great! I will try to package it up and release it to the testing repo. And, yes, it will be very helpful if you could do a write up. We can then publish it through our wiki.

toracat

2017-05-18 17:44

administrator   ~0005209

@vychytraly

I have updated the version to 20150328 and rebuilt the package. It is being released to the elrepo-testing repo. Could you do a test run with this newer version?

primus-20150328-1.el7.elrepo.x86_64.rpm

vychytraly

2017-05-19 02:15

reporter   ~0005212

Thank you very much, I just installed it and will run some tests this weekend

BTW Akemi I dont know how you did it, but I just ran quick initial test and it looks like more that a 100% performance gain

Just for comparison:
glxgears on virtualgl -> cca 8400 frames/5 seconds = cca 1700 FPS
glxgears on primus2013 (with disabled vsync) -> cca 12000 frames/5 seconds = cca 2500 FPS
glxgears on primus2015 (with disabled vsync) -> cca 28000 frames/5 seconds = cca 5800 FPS

Sorry for my delay with documentation, Im working on it :)

vychytraly

2017-05-20 05:08

reporter   ~0005217

Hello Akemi, I'm sending my first iteration of the documentation, please let me know if there is anything I should add, or describe in better way :)

Description:

Primus is a shared library that provides OpenGL and GLX APIs and implements low-overhead local-only client-side OpenGL offloading via GLX forking, similar to VirtualGL. It intercepts GLX calls and redirects GL rendering to a secondary X display, presumably driven by a faster GPU. On swapping buffers, rendered contents are read back using a PBO and copied onto the drawable it was supposed to be rendered on in the first place. For more information, refer to [technotes.md] (https://github.com/amonakov/primus/blob/master/technotes.md).

When using bumblebee, primusrun (from package primus) is becoming recommened choice, because it consumes less power and sometimes provides better performance than optirun/virtualgl. It may be run separately, but it does not accept options as optirun does. Setting primus as the bridge for optirun provides more flexibility. According to the Bumblebee G+ page, this has the following advantages over the optirun (VirtualGL) solution used by default in Bumblebee:

- Less overhead (better framerates) and cleaner solution (no networking or compression involved at all)
- Fixes the "bug" that causes Bumblebee to shut down the GPU too early sometimes (no more need for the "optirun bash" workaround)
- Less buggy/glitchy, easier to debug
- Only uses/starts secondary GPU for OpenGL parts of applications - everything else remains on your main GPU (power savings)

The Bumblebee developers explain what Primus does and the difference between Primus / optirun in simple terms in a comment on their G+ page: Bumblebee uses VirtualGL to copy the image generated by the second (faster) GPU to your display. VirtualGL was intended for use over a network though, so it takes a great many steps to enable this (compression, sending the image over a network link, decompression, etc). Primus doesn't perform all these "extra" steps, instead taking a more direct route (copying the rendered image in memory to the other GPU, then displaying there). In theory this should get you better performance as well as better compatibility. Running applications will "see" the OpenGL implementation of your real hardware, nothing virtual is presented to them.

Testing on EL7 (Nvidia GTX960M) shows huge performance improvements when using primus instead of VirtualGL:
glxgears on virtualgl (optirun glxgears) -> cca 8400 frames/5 seconds = cca 1700 FPS
glxgears on primus (vblank_mode=0 primusrun glxgears) -> cca 28000 frames/5 seconds = cca 5800 FPS



Installation on EL7:

$ sudo yum install primus

Configure the /etc/bumblebee/bumblebee.conf file the same way as described in Elrepo's Bumblebee manual page ( https://elrepo.org/tiki/bumblebee ), but change line PrimusLibraryPath=/usr/lib/primus:/usr/lib32/primus to PrimusLibraryPath=/usr/lib/primus:/usr/lib64/primus (The final bumblebee.conf file should look like this):

[bumblebeed]
VirtualDisplay=:8
KeepUnusedXServer=false
ServerGroup=bumblebee
TurnCardOffAtExit=false
NoEcoModeOverride=false
Driver=nvidia
XorgConfDir=/etc/bumblebee/xorg.conf.d

[optirun]
Bridge=auto
VGLTransport=proxy
PrimusLibraryPath=/usr/lib/primus:/usr/lib64/primus
AllowFallbackToIGC=false

[driver-nvidia]
KernelDriver=nvidia
PMMethod=bbswitch
LibraryPath=/usr/lib64/nvidia:/usr/lib64/vdpau:/usr/lib/nvidia:/usr/lib/vdpau
XorgModulePath=/usr/lib64/xorg/modules/extensions/nvidia,/usr/lib64/xorg/modules/drivers,/usr/lib64/xorg/modules

XorgConfFile=/etc/bumblebee/xorg.conf.nvidia

[driver-nouveau]
KernelDriver=nouveau
PMMethod=auto
XorgConfFile=/etc/bumblebee/xorg.conf.nouveau



Usage:

$ primusrun [name of your app]

For example:

$ primusrun glxgears

Usage (as a bridge for optirun):
The default configuration of bumblebee sets virtualgl as the bridge. Override that on the command line:

$ optirun -b primus glxgears

Or, set Bridge=primus in /etc/bumblebee/bumblebee.conf and you won't have to specify it on the command line.



Possible issues:

For primusrun, VSYNC is enabled by default and as a result, it could make mouse input delay lag or even slightly decrease performance. Test primusrun with VSYNC disabled:

$ vblank_mode=0 primusrun glxgears

Since compositing hurts performance, invoking primus when a compositing WM is active is not recommended. If you need to use primus with compositing and see flickering or bad performance, synchronizing primus' display thread with the application's rendering thread may help:

$ PRIMUS_SYNC=1 primusrun ...

This makes primus display the previously rendered frame. Alternatively, with PRIMUS_SYNC=2 primus will display the latest rendered frame, trading frame rate for reduced visual latency.



FAQ:

Q: Performance does not exceed 60 fps, I was getting more with optirun/VirtualGL.
A: This is the effect of vblank synchronisation. For benchmarking, you can use vblank_mode=0 primusrun ..., but in practice this will probably only waste power, as your LCD panel does not display more than 60 frames per second anyway.



Note: Big thanks to Akemi Yagi (toracat) for creating primus package for EL7!



Written by me, with citations from https://github.com/amonakov/primus , https://wiki.archlinux.org/index.php/bumblebee and http://www.webupd8.org/2012/11/primus-better-performance-and-less.html

toracat

2017-05-20 08:43

administrator   ~0005218

Thank you for the extensive documentation. I will try to put it on our wiki and have you proofread it.

vychytraly

2017-05-20 09:32

reporter   ~0005219

Ok thank you very much :) for now I would just like to add one more line under Possible issues section:

...
$ PRIMUS_SYNC=1 primusrun ...

This makes primus display the previously rendered frame. Alternatively, with PRIMUS_SYNC=2 primus will display the latest rendered frame, trading frame rate for reduced visual latency.

On some laptops you can encounter strange issue, when running an application with primusrun command will run it under integrated graphics instead of nVidia. You can overcome this issue with command:

$ optirun -b primus [name of your app]

In this case the -b argument will tell bumblebee to choose primus as a bridge instead of VirtualGL, so the effect is the same as launching your application with primusrun command. As mentioned earlier in this text, you can make optirun use primus as default bridge by setting Bridge=primus in /etc/bumblebee/bumblebee.conf and you won't have to specify it on the command line.



FAQ:

Q: Performance does not exceed 60 fps, I was getting more with optirun/VirtualGL.
...

vychytraly

2017-05-20 10:20

reporter   ~0005220

Hello Akemi I just ran into the first issues with new primus2015:

When I run this command I get these errors:

$ primusrun nvidia-settings -c :8.0

ERROR: libnvidia-gtk3.so.375.66: cannot open shared object file: No such file
       or directory
       libnvidia-gtk3.so: cannot open shared object file: No such file or
       directory
       libnvidia-gtk2.so.375.66: cannot open shared object file: No such file
       or directory
       libnvidia-gtk2.so: cannot open shared object file: No such file or
       directory


ERROR: A problem occured when loading the GUI library. Please check your
       installation and library path. You may need to specify this library when
       calling nvidia-settings. Please run `nvidia-settings --help` for usage
       information.

With primus2013 you sent me before it worked fine

Also Darktable dont seem to be able to use OpenCL acceleration on new primus2015, on primus2013 it works fine

Same with blender - with primus2013 it saw nVidia as compute device but with primus2015 it falls back to CPU

Same with glxspheres64 with primus2013 it displays: OpenGL Renderer: GeForce GTX 960M/PCIe/SSE2 but with primus2015 OpenGL Renderer: Mesa DRI Intel(R) HD Graphics 530 (Skylake GT2), however when i use optirun -b primus under primus2015, glxspheres64 displays: GeForce GTX 960M/PCIe/SSE2

The same with rest of the apps, when i run them with optirun -b primus (when using primus2015) all these apps seems working fine, they all can run and they see GPU, however I cant measure the performance since primus automatically does vsync and i cant pass it any parameters when running it under optirun.

To sum up it still works, with optirun -b primus workaround, but Im not sure if this is expected behavior, or is there some problem (the error with libnvidia-gtk when trying to start nvidia-settings seems strange since Im sure I have these files in /usr/lib64/nvidia, which is also defined bumblebee config file - LibraryPath=/usr/lib64/nvidia:/usr/lib64/vdpau:/usr/lib/nvidia:/usr/lib/vdpau).

vychytraly

2017-05-20 10:28

reporter   ~0005221

Update:

When running this command I get these errors (I tried to specify libnvidia-gtk path):

$ primusrun nvidia-settings -c :8.0 -I '/usr/lib64/nvidia/libnvidia-gtk3.so.375.66'

(nvidia-settings:5452): Gtk-WARNING **: Theme parsing error: gtk-dark.css:2989:31: Missing name of pseudo-class

(nvidia-settings:5452): Gtk-WARNING **: Theme parsing error: gtk-dark.css:2992:33: Missing name of pseudo-class

(nvidia-settings:5452): Gtk-WARNING **: Theme parsing error: gtk-dark.css:2996:33: Missing name of pseudo-class

(nvidia-settings:5452): Gtk-WARNING **: Theme parsing error: gtk-dark.css:3177:25: Missing name of pseudo-class

(nvidia-settings:5452): Gtk-WARNING **: Theme parsing error: gtk-dark.css:3182:31: Missing name of pseudo-class

(nvidia-settings:5452): Gtk-WARNING **: Theme parsing error: gtk-dark.css:3187:32: Missing name of pseudo-class

(nvidia-settings:5452): Gtk-WARNING **: Theme parsing error: gtk-dark.css:3192:34: Missing name of pseudo-class

(nvidia-settings:5452): Gtk-WARNING **: Theme parsing error: gtk-dark.css:3197:33: Missing name of pseudo-class

(nvidia-settings:5452): Gtk-WARNING **: Theme parsing error: gtk-dark.css:3202:39: Missing name of pseudo-class

(nvidia-settings:5452): Gtk-WARNING **: Theme parsing error: gtk-dark.css:3207:40: Missing name of pseudo-class

(nvidia-settings:5452): Gtk-WARNING **: Theme parsing error: gtk-dark.css:3212:42: Missing name of pseudo-class

ERROR: Unable to find display on any available system

//explanation from nvidia-settings --help :

-I GTK-LIBRARY, --gtk-library=GTK-LIBRARY
      Specify the graphical user interface library to use if a nvidia-settings user interface is required. This value may be the exact location
      of the library or it may be the directory containing the appropriately named library. If this is the exact location, the 'use-gtk2' option
      is ignored.

toracat

2017-05-20 10:31

administrator   ~0005222

So, you may want to add another note to the possible issues section?

Here is a draft:

http://elrepo.org/tiki/primus

toracat

2017-05-20 10:37

administrator   ~0005223

What is the kernel version of the machine you are running the test on?

vychytraly

2017-05-20 10:42

reporter   ~0005224

Yes it looks great! :)

Update: I found a way to disable vsync with optirun -b primus by using vblank_mode=0 optirun -b primus... This way it seems that primus2015 is really used instead of virtualgl since there is big performance boost.

However primus2015 package seems not working compatible with command primusrun - primusrun starts Intel GPU, only way to use primus2015 is to use optirun -b primus.

Im not sure if this is a problem of our particular package, or newer release of primus in general, since many people seem reporting this behavior:

https://askubuntu.com/questions/287113/primusrun-doesnt-seem-to-use-my-nvidia-card

vychytraly

2017-05-20 10:44

reporter   ~0005225

I use standart CentOS kernel (3.10...), with latest updates (not kernel-lt or kernel-ml)

toracat

2017-05-20 10:45

administrator   ~0005226

Thanks.

Let's add some note and a reference link (like the one to the ubuntu question) as needed.

vychytraly

2017-05-20 10:55

reporter   ~0005227

Here is some more information:

https://askubuntu.com/questions/285885/primus-failed-to-load-libraries-in-raring

"I had a chat with Amonakov (one of the developpers of primus) about this yesterday in IRC. He told me that this is a problem that occurs presently in the primus version available in the Ubuntu PPA. As Mr Double Xxx suggested, the remedy is to use optirun -b primus instead. It is a different command than primusrun, but it does the same. The -b option stands for the bridge you use.

Update:
In the latest version of primus for Ubuntu, the command primusrun is again fully functional."

So it seems that some specific version of primus was having this problem on all platforms but only some new update fixed it?

vychytraly

2017-05-20 11:11

reporter   ~0005228

Akemi and I was looking on this wiki page again, and signs I used ( [name of your app] ) probably makes from words "name of your app" hyperlink which leads "nowhere" (or to blank page https://elrepo.org/tiki/name%20of%20your%20app respectively). Maybe we should change it to //name of your app// or something like that? :)

(Line "$ primusrun [name of your app]" and "$ optirun -b primus (name of your app]")

toracat

2017-05-20 11:41

administrator   ~0005229

I had to escape [ ] because it has special meanings in the wiki. Corrected.

toracat

2017-05-31 17:19

administrator   ~0005239

@vychytraly

Can we move the package from the testing repo to the main and then make an announcement?

vychytraly

2017-06-01 03:53

reporter   ~0005240

Well, the new package is usable now, but only with optirun -b primus workaround, when using "standard" command primusrun it usually starts integrated graphics (probably a small bug) as mentioned in ubuntu forums. Maybe I can rewrite the instructions to recommend users to use optirun -b primus workaround (and then it would be fully functional) and we could release it? :)

toracat

2017-06-01 15:17

administrator   ~0005244

Yes, let's revise the wiki and release it. I'll be waiting for your amendment.

vychytraly

2017-06-05 13:59

reporter   ~0005251

Ok Akemi, new revision is here :) :

Description:

Primus is a shared library that provides OpenGL and GLX APIs and implements low-overhead local-only client-side OpenGL offloading via GLX forking, similar to VirtualGL. It intercepts GLX calls and redirects GL rendering to a secondary X display, presumably driven by a faster GPU. On swapping buffers, rendered contents are read back using a PBO and copied onto the drawable it was supposed to be rendered on in the first place. For more information, refer to [technotes.md] (https://github.com/amonakov/primus/blob/master/technotes.md).

When using bumblebee, primusrun (from package primus) is becoming recommened choice, because it consumes less power and sometimes provides better performance than optirun/virtualgl. It may be run separately, but it does not accept options as optirun does. Setting primus as the bridge for optirun provides more flexibility. According to the Bumblebee G+ page, this has the following advantages over the optirun (VirtualGL) solution used by default in Bumblebee:

- Less overhead (better framerates) and cleaner solution (no networking or compression involved at all)
- Fixes the "bug" that causes Bumblebee to shut down the GPU too early sometimes (no more need for the "optirun bash" workaround)
- Less buggy/glitchy, easier to debug
- Only uses/starts secondary GPU for OpenGL parts of applications - everything else remains on your main GPU (power savings)

The Bumblebee developers explain what Primus does and the difference between Primus / optirun in simple terms in a comment on their G+ page: "Bumblebee uses VirtualGL to copy the image generated by the second (faster) GPU to your display. VirtualGL was intended for use over a network though, so it takes a great many steps to enable this (compression, sending the image over a network link, decompression, etc). Primus doesn't perform all these "extra" steps, instead taking a more direct route (copying the rendered image in memory to the other GPU, then displaying there). In theory this should get you better performance as well as better compatibility. Running applications will "see" the OpenGL implementation of your real hardware, nothing virtual is presented to them."

Testing on EL7 (Nvidia GTX960M) shows huge performance improvements when using primus instead of VirtualGL:
glxspheres64 on virtualgl (optirun -b virtualgl glxspheres64) -> cca 220 FPS
glxspheres64 on primus (vblank_mode=0 optirun -b primus glxgspheres64) -> cca 320 FPS



Installation on EL7:

$ sudo yum install primus

Configure the /etc/bumblebee/bumblebee.conf file the same way as described in Elrepo's Bumblebee manual page ( https://elrepo.org/tiki/bumblebee ), but change line PrimusLibraryPath=/usr/lib/primus:/usr/lib32/primus to PrimusLibraryPath=/usr/lib/primus:/usr/lib64/primus (The final bumblebee.conf file should look like this):

[bumblebeed]
VirtualDisplay=:8
KeepUnusedXServer=false
ServerGroup=bumblebee
TurnCardOffAtExit=false
NoEcoModeOverride=false
Driver=nvidia
XorgConfDir=/etc/bumblebee/xorg.conf.d

[optirun]
Bridge=auto
VGLTransport=proxy
PrimusLibraryPath=/usr/lib/primus:/usr/lib64/primus
AllowFallbackToIGC=false

[driver-nvidia]
KernelDriver=nvidia
PMMethod=bbswitch
LibraryPath=/usr/lib64/nvidia:/usr/lib64/vdpau:/usr/lib/nvidia:/usr/lib/vdpau
XorgModulePath=/usr/lib64/xorg/modules/extensions/nvidia,/usr/lib64/xorg/modules/drivers,/usr/lib64/xorg/modules

XorgConfFile=/etc/bumblebee/xorg.conf.nvidia

[driver-nouveau]
KernelDriver=nouveau
PMMethod=auto
XorgConfFile=/etc/bumblebee/xorg.conf.nouveau



Usage:

Primus is usually run with $ primusrun command, but since this command could be sometimes a little bit buggy (runs integrated graphics instead of Nvidia - as mentioned in ubuntu forums: https://askubuntu.com/questions/285885/primus-failed-to-load-libraries-in-raring ) we recommend using primus with $ optirun -b primus command, or setting primus as default bridge for optirun (this command does exact same thing as calling primusrun command, but without mentioned occassional bugs. There is also no performance difference between using primusrun or optirun -b primus commands).

If you want to launch your app with primus run this command:

$ optirun -b primus [name of your app]

Argument -b tells optirun which bridge it should use. Optirun by default uses VirtualGL, but you can configure it to use primus as default bridge by changing the line Bridge=auto to Bridge=primus in /etc/bumblebee/bumblebee.conf and you won't have to specify it on the command line.

If you decide to set primus as default bridge for optirun, there is no need to specify bridge with -b argument, so you could just use command:

$ optirun [name of your app]

Alternatively if you would like to run an app with VirtualGL bridge you could use command:

$ optirun -b virtualgl [name of your app]

(Argument -b overrides the setting in bumblebee.conf)




Possible issues:

For primus bridge, VSYNC is enabled by default and as a result, it could make mouse input delay lag or even slightly decrease performance. Test primus with VSYNC disabled:

$ vblank_mode=0 optirun -b primus glxspheres64

Since compositing hurts performance, invoking primus when a compositing WM is active is not recommended. If you need to use primus with compositing and see flickering or bad performance, synchronizing primus' display thread with the application's rendering thread may help:

$ PRIMUS_SYNC=1 optirun -b primus ...

This makes primus display the previously rendered frame. Alternatively, with PRIMUS_SYNC=2 primus will display the latest rendered frame, trading frame rate for reduced visual latency.



FAQ:

Q: Performance does not exceed 60 fps, I was getting more with optirun/VirtualGL.
A: This is the effect of vblank synchronisation. For benchmarking, you can use vblank_mode=0 optirun -b primus ..., but in practice this will probably only waste power, as your LCD panel does not display more than 60 frames per second anyway.



Note: Big thanks to Akemi Yagi (toracat) for creating primus package for EL7!



Written by me, with citations from https://github.com/amonakov/primus , https://wiki.archlinux.org/index.php/bumblebee and http://www.webupd8.org/2012/11/primus-better-performance-and-less.html

toracat

2017-06-07 00:21

administrator   ~0005252

@vychytraly

I have updated the wiki page. Could you look it through once again?

Would you rather not show your real name?

vychytraly

2017-06-07 13:51

reporter   ~0005258

Hello Akemi, everything seems fine, except one "cosmetic" issue :)

check a line:

"...as mentioned in ubuntu forums: https://askubuntu.com/questions/285885/primus-failed-to-load-libraries-in-raring [^] ) we recommend..."

in wiki page the end-bracket sign ")" is included in hyperlink, but it should not be. (But the link works so it is not a functional issue at all, only a cosmetic one - I think that the page is ready for publishing :) )

Also if users will have any questions regarding primus and the wiki page after the release of this package, I will be happy to answer them and also update wiki page accordingly :) (dont hesitate to redirect them to my mail or this bugtracker)

And please dont take it personally, but to be honest I am a little bit paranoid so I think that I will introduce myself a little bit later :)

toracat

2017-06-07 14:00

administrator   ~0005259

Thanks. Fixed.

I will promote the packages to the main repo and send out an announcement to our mailing list. I will be referring to this bug tracker in the announcement.

vychytraly

2017-06-09 02:11

reporter   ~0005265

Hello Akemi, thanks for releasing the primus package :) everything seems working fine, I just noticed that primus package (and its wiki) is not visible on ElRepo's "Packages Page":

https://elrepo.org/tiki/Packages

(People can probably get to it only via the link you sent in email) - but maybe ElRepo expects more testing before adding it to "main packages"? :) I don't know, I just wanted to remind you of this "problem" :)

Have a nice day

toracat

2017-06-09 10:04

administrator   ~0005266

Thanks for letting me of the missing entry. It is there now.

I've also added 'primus' to the category of the bug tracker.

Issue History

Date Modified Username Field Change
2017-05-03 14:16 vychytraly New Issue
2017-05-03 14:16 vychytraly Status new => assigned
2017-05-03 14:16 vychytraly Assigned To => toracat
2017-05-03 14:36 vychytraly Note Added: 0005165
2017-05-03 14:55 toracat Note Added: 0005166
2017-05-04 13:49 toracat Note Edited: 0005166
2017-05-05 16:16 vychytraly Note Added: 0005170
2017-05-05 16:32 vychytraly Note Added: 0005171
2017-05-05 23:47 toracat Note Added: 0005172
2017-05-10 14:30 vychytraly Note Added: 0005179
2017-05-10 18:27 toracat Note Added: 0005180
2017-05-18 17:44 toracat Note Added: 0005209
2017-05-19 02:15 vychytraly Note Added: 0005212
2017-05-20 05:08 vychytraly Note Added: 0005217
2017-05-20 08:43 toracat Note Added: 0005218
2017-05-20 09:32 vychytraly Note Added: 0005219
2017-05-20 10:20 vychytraly Note Added: 0005220
2017-05-20 10:28 vychytraly Note Added: 0005221
2017-05-20 10:31 toracat Note Added: 0005222
2017-05-20 10:37 toracat Note Added: 0005223
2017-05-20 10:42 vychytraly Note Added: 0005224
2017-05-20 10:44 vychytraly Note Added: 0005225
2017-05-20 10:45 toracat Note Added: 0005226
2017-05-20 10:55 vychytraly Note Added: 0005227
2017-05-20 11:11 vychytraly Note Added: 0005228
2017-05-20 11:41 toracat Note Added: 0005229
2017-05-31 17:19 toracat Note Added: 0005239
2017-06-01 03:53 vychytraly Note Added: 0005240
2017-06-01 15:17 toracat Note Added: 0005244
2017-06-05 13:59 vychytraly Note Added: 0005251
2017-06-07 00:21 toracat Note Added: 0005252
2017-06-07 13:51 vychytraly Note Added: 0005258
2017-06-07 14:00 toracat Note Added: 0005259
2017-06-09 02:11 vychytraly Note Added: 0005265
2017-06-09 10:04 toracat Note Added: 0005266
2017-07-03 12:44 toracat Status assigned => resolved
2017-07-03 12:44 toracat Resolution open => fixed