View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000734 | channel: elrepo/el7 | --elrepo--request-for-enhancement-- | public | 2017-05-03 14:16 | 2017-07-03 12:44 |
| Reporter | vychytraly | Assigned To | toracat | ||
| Priority | normal | Severity | feature | Reproducibility | have not tried |
| Status | resolved | Resolution | fixed | ||
| Summary | 0000734: Primus | ||||
| Description | Hello 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 | ||||
| Tags | No tags attached. | ||||
| Reported upstream | |||||
|
|
Arch Docmumentation for Primus: https://wiki.archlinux.org/index.php/bumblebee#Primusrun |
|
|
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. |
|
|
Thank you very much, I will be testing it during this weekend and let you know how does it work :) |
|
|
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 |
|
|
@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. |
|
|
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? :) |
|
|
@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. |
|
|
@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 |
|
|
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 :) |
|
|
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 |
|
|
Thank you for the extensive documentation. I will try to put it on our wiki and have you proofread it. |
|
|
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. ... |
|
|
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). |
|
|
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. |
|
|
So, you may want to add another note to the possible issues section? Here is a draft: http://elrepo.org/tiki/primus |
|
|
What is the kernel version of the machine you are running the test on? |
|
|
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 |
|
|
I use standart CentOS kernel (3.10...), with latest updates (not kernel-lt or kernel-ml) |
|
|
Thanks. Let's add some note and a reference link (like the one to the ubuntu question) as needed. |
|
|
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? |
|
|
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]") |
|
|
I had to escape [ ] because it has special meanings in the wiki. Corrected. |
|
|
@vychytraly Can we move the package from the testing repo to the main and then make an announcement? |
|
|
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? :) |
|
|
Yes, let's revise the wiki and release it. I'll be waiting for your amendment. |
|
|
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 |
|
|
@vychytraly I have updated the wiki page. Could you look it through once again? Would you rather not show your real name? |
|
|
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 :) |
|
|
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. |
|
|
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 |
|
|
Thanks for letting me of the missing entry. It is there now. I've also added 'primus' to the category of the bug tracker. |
| 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 |
