-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello all, I've been thinking about 3 separate issues regarding the tuna GUI, and I have some proposals to address them. I'll list each one separately.
1. The CPU view doesn't scale well to really large numbers of CPUs. Modern server systems have 64 or more processing units. It would be good to be able to refer to CPU as sets such as NUMA nodes, sockets, shared cache, or distance groups. This would help us move applications or IRQs to specific sets of CPUs. I'm working on an example design that would move the CPU view to a pop-up window and display CPUs in a topological view. There would be an overview of the current CPU selection in the header bar of the main window, and that would be a drop target for dragged IRQs or processes. The popup window could also display which CPUs are available to which PCI devices. This can be helpful on NUMA systems for instance.
2. The tuna GUI ought to be in an RPM package that "Requires" the necessary graphics packages. Right now, it just suggests on the commandline what you might need to install to get it to work. This is a silent failure when tuna is invoked as a desktop app. I suggest we break the GUI into a separate program in a separate RPM package. The tuna command-line program can exec the GUI when it is invoked without arguments. The tuna GUI RPM can specify the appropriate package requirements so it can run successfully.
3. Tuna now only runs as root. This was implemented because the profile management section failed fatally when access permissions failed. Some of this has been resolved, but the profile tabs are not useful and look incomplete when the GUI is run without proper privileges. I suggest we break out the profile handling into its own program also. We can make it use PolicyKit and require root access to run. The main tuna GUI can have a button to launch the profile GUI program. The tuna command-line can have an option to launch the profile application as well. When run without privileges, the main tuna GUI could pop up a notification that some operations make fail, and offer to re-launch through PolicyKit to obtain root privilege. We should also verify that every failed operation in the GUI is properly reported, so a non-root user would know their attempted adjustments did not take place.
That's it. Let me know if you have questions about my proposals, and also if you have other suggested solutions or other enhancements we might consider.
thanks, - --Guy
Em Mon, Jun 08, 2015 at 02:08:06PM -0500, Guy Streeter escreveu:
Hello all, I've been thinking about 3 separate issues regarding the tuna GUI, and I have some proposals to address them. I'll list each one separately.
- The CPU view doesn't scale well to really large numbers of CPUs. Modern
server systems have 64 or more processing units. It would be good to be able to refer to CPU as sets such as NUMA nodes, sockets, shared cache, or distance groups. This would help us move applications or IRQs to specific sets of CPUs. I'm working on an example design that would move the CPU view to a pop-up window and display CPUs in a topological view. There would be an overview of the current CPU selection in the header bar of the main window, and that would be a drop target for dragged IRQs or processes. The popup window could also display which CPUs are available to which PCI devices. This can be helpful on NUMA systems for instance.
How to do this properly is a challenge, i think, but I agree that this needs improvement to cope with the ever increasing number of cores. A vision that reflects the grouping done at the hardware level looks like a sensible first approach.
Thing is, this is how it is now, so probably what we need is to make it more compact, right? I.e. remove, in the default, first level view, the per cpu information, leaving just the per CPU socket stuff.
So, agreed that clicking on a socket would expand info about it, etc.
Agreed that, in the same vein, making the per irq info more compact is interesting as well, i.e. show just the IRQs that have in its affinity mask CPUs that are in the CPU Socket being expanded/selected.
Ditto for the threads, right?
- The tuna GUI ought to be in an RPM package that "Requires" the necessary
graphics packages. Right now, it just suggests on the commandline what you might need to install to get it to work. This is a silent failure when tuna is invoked as a desktop app. I suggest we break the GUI into a separate program in a separate RPM package. The tuna command-line program can exec the GUI when it is invoked without arguments. The tuna GUI RPM can specify the appropriate package requirements so it can run successfully.
I think that is a good idea, we can have a tuna-gui, or make 'tuna' be the one for the gui while 'tuna-cmdline' would be just the command line utility, what we call 'tuna' today.
I.e. the expectation, I think, is that when installing 'tuna', one has the gui available, something that, as you described above, has been a source of confusion so far.
- Tuna now only runs as root. This was implemented because the profile
management section failed fatally when access permissions failed. Some of this has been resolved, but the profile tabs are not useful and look incomplete when the GUI is run without proper privileges. I suggest we break out the profile handling into its own program also. We can make it use PolicyKit and require root access to run. The main tuna GUI can have a button to launch the profile GUI program. The tuna command-line can have an option to launch the profile application as well. When run without privileges, the main tuna GUI could pop up a notification that some operations make fail, and offer to re-launch through PolicyKit to obtain root privilege. We should also verify that every failed operation in the GUI is properly reported, so a non-root user would know their attempted adjustments did not take place.
Right, agreed, no need to prevent a user from running it just because one of the things that can be done with it requires more priviledges.
That's it. Let me know if you have questions about my proposals, and also if you have other suggested solutions or other enhancements we might consider.
thanks,
- --Guy
Here are some screen shots of my idea for the GUI change. I hope these attachments make it through the mailing-list server. "mini_cpu.png" shows the CPU selection widget in the header bar. The widget to the left is a CPU usage meter. Clicking on the selection widget pops up the topological view, "top-level-topo.png". Clicking on one of the NUMA nodes drills down to the next "significant" hardware level, "socket-level.png". If there had been for instance some distance grouping of the sockets in the node, a group-level view would have shown there. You can keep clicking until you get all the way to processing units, "cores.png", "PUs.png". At any grouping level you can go into selection mode and click the check-boxes to select or un-select and object, as in "selecting.png".
If the attachments don't make it through, I'll share them somehow. --Guy
Em Tue, Jun 09, 2015 at 11:33:44AM -0500, Guy Streeter escreveu:
Here are some screen shots of my idea for the GUI change. I hope these attachments make it through the mailing-list server. "mini_cpu.png" shows the CPU selection widget in the header bar. The widget
Humm, perhaps we could have an aggregate usage level for those CPUs in this widget?
to the left is a CPU usage meter. Clicking on the selection widget pops up the topological view, "top-level-topo.png". Clicking on one of the NUMA nodes drills down to the next "significant" hardware level, "socket-level.png". If there had been for instance some distance grouping of the sockets in the node, a group-level view would have shown there. You can keep clicking until you get all the way to processing units, "cores.png",
Right, so I think where you have "Socket 0" that you should change it to "Cores in Socket 0", and then remove the duplicated "Core" from "Core 0", "Core 2", etc, ditto for the "Contains " dups.
I.e. something like:
+---------------------------------------------+ | Cores in Socket 0 | +---------------------------------------------| | 0 ===== [x]| | 8 ===== [ ]| | 10 == [x]| | 1 = [x]| | 9 ============ [x]| +---------------------------------------------|
"PUs.png". At any grouping level you can go into selection mode and click the check-boxes to select or un-select and object, as in "selecting.png".
If the attachments don't make it through, I'll share them somehow. --Guy
tuna-devel mailing list tuna-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/tuna-devel
On 06/09/2015 03:01 PM, Arnaldo Carvalho de Melo wrote:
Em Tue, Jun 09, 2015 at 11:33:44AM -0500, Guy Streeter escreveu:
...
Humm, perhaps we could have an aggregate usage level for those CPUs in this widget?
Do you mean putting the aggregate usage meter inside the button with the selection text, instead of beside it? That's easily doable.
Trying to save message size, I trimmed the window to the part I was talking about. I have attached here full captures of the pop-out window, showing the PCI view that indicates what devices are fully, partially, or not covered by the current CPU selection. Do you think that's useful?
If the extra PCI information isn't useful, I could change it from a pop-out window to an in-place replacement for the current CPU view.
I'm in favor of presenting all the information we can, and it seems like making the CPU selection a task-specific window is a good plan, but I know I'm not a trained UI designer.
--Guy
Em Wed, Jun 10, 2015 at 01:49:16PM -0500, Guy Streeter escreveu:
On 06/09/2015 03:01 PM, Arnaldo Carvalho de Melo wrote:
Em Tue, Jun 09, 2015 at 11:33:44AM -0500, Guy Streeter escreveu:
...
Humm, perhaps we could have an aggregate usage level for those CPUs in this widget?
Do you mean putting the aggregate usage meter inside the button with the selection text, instead of beside it? That's easily doable.
Trying to save message size, I trimmed the window to the part I was talking
about. I have attached here full captures of the pop-out window, showing the PCI view that indicates what devices are fully, partially, or not covered by the current CPU selection. Do you think that's useful?
I guess that is useful, i.e. when selecting a group of CPUs having the various list of objects have just the ones that have those CPUs in its affinity masks.
But after looking at it I think it has way too much info, i.e. and cryptic ones at that, i.e. it should state "Intel ixgbe NIC", say, instead of all those vendor and model codes :-)
Probably allowing to see a more compact representation that could be turned into something more detailed by pressing a hotkey, like 'V' or a button (I would prefer the hotkey, so that the screen doesn't get too crowded) would be better, i.e. go from a high level view to a more detailed.
Also those hex cpu masks should be turned into compact CSV, i.e. "1,3-15,20,22", say.
Looking at selection2 I see that you don't filter out, just highlight, well, with a bigger machine maybe it would be better to filter out, showing just the devices that have the CPU selection on it.
If the extra PCI information isn't useful, I could change it from a pop-out window to an in-place replacement for the current CPU view.
I think it is useful.
I'm in favor of presenting all the information we can, and it seems like making the CPU selection a task-specific window is a good plan, but I know I'm not a trained UI designer.
Neither am I, so at some point we would better try to show these sketches to people like Shak to ask his impressions,
- Arnaldo
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/10/2015 03:27 PM, Arnaldo Carvalho de Melo wrote:
Em Wed, Jun 10, 2015 at 01:49:16PM -0500, Guy Streeter escreveu:
...
Also those hex cpu masks should be turned into compact CSV, i.e. "1,3-15,20,22", say.
I currently have it set so that shorter strings (under 20 chars) are shown as lists instead of hex masks. I could increase the max length.
- --Guy
Em Wed, Jun 10, 2015 at 03:32:25PM -0500, Guy Streeter escreveu:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/10/2015 03:27 PM, Arnaldo Carvalho de Melo wrote:
Em Wed, Jun 10, 2015 at 01:49:16PM -0500, Guy Streeter escreveu:
...
Also those hex cpu masks should be turned into compact CSV, i.e. "1,3-15,20,22", say.
I currently have it set so that shorter strings (under 20 chars) are shown as lists instead of hex masks. I could increase the max length.
Perhaps do it as CSV and check the lenght, if it is too big, switch to the more compact, albeit more cryptic, form.
- Arnaldo
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/10/2015 03:48 PM, Arnaldo Carvalho de Melo wrote:
Em Wed, Jun 10, 2015 at 03:32:25PM -0500, Guy Streeter escreveu:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/10/2015 03:27 PM, Arnaldo Carvalho de Melo wrote:
Em Wed, Jun 10, 2015 at 01:49:16PM -0500, Guy Streeter escreveu:
...
Also those hex cpu masks should be turned into compact CSV, i.e. "1,3-15,20,22", say.
I currently have it set so that shorter strings (under 20 chars) are shown as lists instead of hex masks. I could increase the max length.
Perhaps do it as CSV and check the lenght, if it is too big, switch to the more compact, albeit more cryptic, form.
Yeah that's what it does now. I just had a very small length limit. - --Guy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I've been looking at the current "process view" frame in tuna. Can someone explain to me what the value of the "cgroups" column is?
I admit I don't understand cgroups very well, but the displayed information doesn't seem useful. Is there something more or different we could display there?
What would an administrator do with the current cgroups information? Should we consider adding cgroups configuration/administration to tuna, or is there already a GUI for that?
thanks, - --Guy
Em Wed, Sep 02, 2015 at 02:24:56PM -0500, Guy Streeter escreveu:
I've been looking at the current "process view" frame in tuna. Can someone explain to me what the value of the "cgroups" column is?
I admit I don't understand cgroups very well, but the displayed information doesn't seem useful. Is there something more or different we could display there?
Yeah, I think someone involved with cgroups could try to make that more compact somehow, but indeed, I find that column not that useful.
What would an administrator do with the current cgroups information? Should we consider adding cgroups configuration/administration to tuna, or is there already a GUI for that?
I am not sure about that, i.e. about any adminstrative tool for that.
What I think would be useful would be for the _command line_ to be able to, in addition to --socket, --cpu, --thread, --irq to also have support for --cgroup.
In the GUI, I think cgroups, at least the cpuset part, could be thought of as a "soft CPU socket", i.e. one that is not "written in stone", but in the kernel cgroup filesystem, i.e. for each cgroup we would have some box, showing which CPUs are in it, and also if one selected one of these boxes, then the thread view would show just the ones in that box (CPU socket, CPU core, cgroup).
And when we select some cgroup, then automagically that cgroups column in the thread view (if we keep it in some fashion) would disappear, i.e. no sense in showing something that has just one value.
Try 'perf top' press 'f' to freeze the events, then press enter to Zoom into a DSO and see how it elides the "Shared Object" column, since now all will have the same value:
# perf top # Wait a bit till things get interesting, press 'f' to freeze Samples: 41K of event 'cycles', Event count (approx.): 13344188516 Overhead Shared Object Symbol 2.29% libc-2.20.so [.] _int_malloc 1.61% [kernel] [k] page_fault 1.47% [kernel] [k] get_vmalloc_info 1.16% [kernel] [k] clear_page_c_e 1.13% cc1 [.] rtx_cost 1.10% [kernel] [k] unmap_single_vma 1.02% cc1 [.] ira_init_register_move_cost 0.95% cc1 [.] ira_init <SNIP>
# press enter + Zoom into the libc-2.20.so DSO: Samples: 41K of event 'cycles', Event count (approx.): 13344188516, DSO: libc-2.20.so Overhead Symbol 2.29% [.] _int_malloc 0.89% [.] free 0.74% [.] __memset_sse2 0.68% [.] __GI___strcmp_ssse3 0.60% [.] malloc 0.53% [.] __GI___strncmp_ssse3 0.45% [.] _dl_addr 0.36% [.] malloc_consolidate 0.31% [.] __libc_calloc 0.30% [.] strlen 0.28% [.] getenv 0.27% [.] __memcpy_avx_unaligned 0.26% [.] vfprintf
But I haven't been following how all this plays with systemd, that makes heavy use of cgroups, etc. Would this be done directly via looking at the cgroups FS? Or would we use something else, like some dbus systemd service that would enumerate/create/delete/other-operations cgroups, etc?
- Arnaldo
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/02/2015 03:20 PM, Arnaldo Carvalho de Melo wrote:
Em Wed, Sep 02, 2015 at 02:24:56PM -0500, Guy Streeter escreveu:
I've been looking at the current "process view" frame in tuna. Can someone explain to me what the value of the "cgroups" column is?
I admit I don't understand cgroups very well, but the displayed information doesn't seem useful. Is there something more or different we could display there?
Yeah, I think someone involved with cgroups could try to make that more compact somehow, but indeed, I find that column not that useful.
What would an administrator do with the current cgroups information? Should we consider adding cgroups configuration/administration to tuna, or is there already a GUI for that?
I am not sure about that, i.e. about any adminstrative tool for that.
What I think would be useful would be for the _command line_ to be able to, in addition to --socket, --cpu, --thread, --irq to also have support for --cgroup.
I've written Python bindings for libcgroup: https://git.fedorahosted.org/cgit/python-libcgroup.git/
In the GUI, I think cgroups, at least the cpuset part, could be thought of as a "soft CPU socket", i.e. one that is not "written in stone", but in the kernel cgroup filesystem, i.e. for each cgroup we would have some box, showing which CPUs are in it, and also if one selected one of these boxes, then the thread view would show just the ones in that box (CPU socket, CPU core, cgroup).
...
But I haven't been following how all this plays with systemd, that makes heavy use of cgroups, etc. Would this be done directly via looking at the cgroups FS? Or would we use something else, like some dbus systemd service that would enumerate/create/delete/other-operations cgroups, etc?
- Arnaldo
On systems with systemd running, every process has a cgroup list at least this long:
$ cat /proc/self/cgroup 10:hugetlb:/ 9:perf_event:/ 8:net_cls,net_prio:/ 7:freezer:/ 6:devices:/user.slice 5:memory:/ 4:blkio:/ 3:cpu,cpuacct:/ 2:cpuset:/ 1:name=systemd:/user.slice/user-5160.slice/session-1.scope
Services have an even longer list. None of it means anything to me :)
In the long run, letting systemd handle cgroups is probably the right thing to do. There needs to be centralized control of them. There is a published systemd dbus interface for cgroups, but I can't tell if it is proposed or actually implemented.
As an aside, I haven't seen any evidence that systemd uses cgroups for CPU Affinity. I tried modifying the unit file for a service on my system, specifying the CPUAffinity property. systemd started the service with the specified affinity, but I think it just used taskset or sched_setaffinity. I could not see a cgroups change that limited the affinity, and I was able to change the affinity with tuna.
- --Guy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/08/2015 02:08 PM, Guy Streeter wrote:
Hello all, I've been thinking about 3 separate issues regarding the tuna GUI, and I have some proposals to address them. I'll list each one separately.
- The CPU view doesn't scale well to really large numbers of CPUs.
...
- The tuna GUI ought to be in an RPM package that "Requires" the
necessary graphics packages.
...
- Tuna now only runs as root.
...
I have continued to play with the ideas I had. I have an application ready to try, temporarily called "pianofish" to distinguish it from the current tuna GUI. This is only the original system view tab. I haven't worked on the tuning profile tabs.
I have builds available for Fedora, in a COPR repo. You can get the yum/dnf repo file from https://copr.fedoraproject.org/coprs/streeter/python-hwloc/ and then install pianofish. The unreleased dependencies are there. Note this will install the upstream version of python-linux-procfs, since I needed a fix from that.
The --nonroot command-line option will allow it to run unprivileged. Also, if you search for it from GNOME Shell, you can right-click on it's icon and select "unprivileged".
There are a lot of changes from the tuna GUI, and some things that are the sam e.
- - The CPU display is compressed to a button on the header bar. It can be expanded to its own window by clicking on it. CPUs can be selected from the expanded window.
- - Selections from the process view or the IRQ view can be dragged to the CPU overview button to set their affinity.
- - The Search button (or ^F) can be used to narrow the process display by command-line regex.
- - The process and IRQ attributes dialogs have a check-mark by the attributes you want to change. (TODO: The check-mark is supposed to automatically get set if you modify the attribute, but that's not always working)
- - The process attributes dialog doesn't have a way to specify what processes to modify. It will show the processes that were selected when the dialog was opened. The search-bar can be used to narrow processes down for selection. If a collapsed thread is selected, all the threads of that process are included. If the thread display is expanded, only the selected threads are included in the dialog. (TODO: The dialog needs to open at a larger size to show the process list)
- - In the expanded CPU view window, the CPU view is hierarchical. It opens at the highest-level significant object (e.g., NUMA node or CPU socket), and you can click on it to drill down to things contained in it, all the way to processing units. The check-mark button on the header takes you into selection mode. You can select or deselect the grouped objects at the displayed level. The check-box on a group entry will display at dash instead of a check if only some of the grouped object's children are selected.
One more known bug: The application menu (in the GNOME Shell) is unresponsive when the app is running privileged. This might be un-fixable, so I added a Settings button to the header bar.
If you don't have a large, complex system to try it on, the CPU selection changes might not make sense. It you want to try it on a more complicated system, I can show you how to run it with a fake topology.
Let me know what you think. This is just a suggestion to be considered.
thanks, - --Guy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/10/2015 01:39 PM, Guy Streeter wrote:
On 06/08/2015 02:08 PM, Guy Streeter wrote:
...
I have continued to play with the ideas I had. I have an application ready to try, temporarily called "pianofish" to distinguish it from the current tuna GUI. This is only the original system view tab. I haven't worked on the tuning profile tabs.
Just FYI, I was looking at upstream tuned, and it now has a GUI interface of it's own. It seems to do what the profile tabs of the current tuna GUI do. - --Guy
Em Tue, Dec 15, 2015 at 01:10:48PM -0600, Guy Streeter escreveu:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/10/2015 01:39 PM, Guy Streeter wrote:
On 06/08/2015 02:08 PM, Guy Streeter wrote:
...
I have continued to play with the ideas I had. I have an application ready to try, temporarily called "pianofish" to distinguish it from the current tuna GUI. This is only the original system view tab. I haven't worked on the tuning profile tabs.
Just FYI, I was looking at upstream tuned, and it now has a GUI interface of it's own. It seems to do what the profile tabs of the current tuna GUI do.
Cool, probably it'll be a good idea to deprecate the duplicate feature in tuna, pointing the user to the tuned GUI.
- Arnaldo
- --Guy
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2
iEYEARECAAYFAlZwZbcACgkQ0Bme0QyNhPRdJQCfScU08+c5E5TGgG7UqyXHMGFG 6BIAmwb8CqcbaPRG+aG4K9YehSycbXFn =gWNb -----END PGP SIGNATURE----- _______________________________________________ tuna-devel mailing list tuna-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/tuna-devel@lists.fedorahosted.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/10/2015 01:39 PM, Guy Streeter wrote: ...
I have continued to play with the ideas I had. I have an application ready to try, temporarily called "pianofish" to distinguish it from the current tuna GUI. This is only the original system view tab. I haven't worked on the tuning profile tabs.
I have builds available for Fedora, in a COPR repo. You can get the yum/dnf repo file from https://copr.fedoraproject.org/coprs/streeter/python-hwloc/ and then install pianofish. The unreleased dependencies are there. Note this will install the upstream version of python-linux-procfs, since I needed a fix from that.
The --nonroot command-line option will allow it to run unprivileged. Also, if you search for it from GNOME Shell, you can right-click on it's icon and select "unprivileged".
I've added a build for epel7 to that repo.
Some of the dependencies won't build for epel6 because the version of Cython there is too old.
- --Guy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/06/2016 10:17 AM, Guy Streeter wrote:
On 12/10/2015 01:39 PM, Guy Streeter wrote: ...
I have continued to play with the ideas I had. I have an application ready to try, temporarily called "pianofish" to distinguish it from the current tuna GUI. This is only the original system view tab. I haven't worked on the tuning profile tabs.
I have builds available for Fedora, in a COPR repo. You can get the yum/dnf repo file from https://copr.fedoraproject.org/coprs/streeter/python-hwloc/ and then install pianofish. The unreleased dependencies are there. Note this will install the upstream version of python-linux-procfs, since I needed a fix from that.
The --nonroot command-line option will allow it to run unprivileged. Also, if you search for it from GNOME Shell, you can right-click on it's icon and select "unprivileged".
I've added a build for epel7 to that repo.
Some of the dependencies won't build for epel6 because the version of Cython there is too old.
I've updated pianofish. In version 0-1.10, the GUI runs as the logged-in user, and authenticates with a privileged DBUS back-end to make policy, priority and affinity changes.
This doesn't (yet) work on rhel7 because of bugs in the Python GIO bindings. I'll try to find a work-around for that.
- --Guy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/06/2016 10:17 AM, Guy Streeter wrote:
On 12/10/2015 01:39 PM, Guy Streeter wrote: ...
I have continued to play with the ideas I had. I have an application ready to try, temporarily called "pianofish" to distinguish it from the current tuna GUI. This is only the original system view tab. I haven't worked on the tuning profile tabs.
I have builds available for Fedora, in a COPR repo. You can get the yum/dnf repo file from https://copr.fedoraproject.org/coprs/streeter/python-hwloc/ and then install pianofish. The unreleased dependencies are there. Note this will install the upstream version of python-linux-procfs, since I needed a fix from that.
The --nonroot command-line option will allow it to run unprivileged. Also, if you search for it from GNOME Shell, you can right-click on it's icon and select "unprivileged".
I've added a build for epel7 to that repo.
Some of the dependencies won't build for epel6 because the version of Cython there is too old.
I'm planning to retire effective Friday, Feb 5. I'll try to keep up with tuna development, but in a limited capacity. - --Guy
tuna-devel@lists.fedorahosted.org