Package Details: targetcli-fb 2.1.fb43-1

Git Clone URL: https://aur.archlinux.org/targetcli-fb.git (read-only)
Package Base: targetcli-fb
Description: free branch of the targetcli LIO administration shell (iSCSI + Co)
Upstream URL: https://github.com/agrover/targetcli-fb
Licenses: Apache
Provides: targetcli
Submitter: JonnyJD
Maintainer: JonnyJD
Last Packager: JonnyJD
Votes: 8
Popularity: 0.075156
First Submitted: 2012-02-27 01:05
Last Updated: 2016-05-08 16:53

Latest Comments

JonnyJD commented on 2016-05-17 18:41

Oh thanks. I missed "Make use of pyudev package as much as possible in utils module." as a new dependency in the changelog.
Fixed (in rtslib, where the actual dependency is).

archfan777 commented on 2016-05-12 20:30

community/python-pyudev package required for targetcli-fb
please add depend

JonnyJD commented on 2015-12-08 10:59

thanks, fixed

forumi0721 commented on 2015-12-08 05:58

python-dbus package required to run targetcli
please add depend

JonnyJD commented on 2015-02-23 11:21

I didn't see that yesterday either, but now I see it:

You had python2-configshell-fb installed (Python 2) and now you installed that and python-configshell-fb (Python 3). Pacman said the Python 2 version was installed and installed the Python 3 version ;-)

Many tools still need Python 2, including other LIO tools, but this one works with Python 3 so I use that ;-).

James_Epp commented on 2015-02-22 18:48

@JonnyJD:
I could have sworn I had it installed last night. For whatever reason, today It's working. I decided to re-do the python-configshell-fb installation, and I got this output which I didn't get yesterday, so whatever happened it had to have been my error.

$ sudo pacman -U *.xz
loading packages...
warning: python2-configshell-fb-1.1.fb17-1 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...

Packages (4) python-pyparsing-2.0.3-1 python-urwid-1.3.0-1 python-configshell-fb-1.1.fb17-1 python2-configshell-fb-1.1.fb17-1

Total Download Size: 0.39 MiB
Total Installed Size: 4.22 MiB
Net Upgrade Size: 3.49 MiB

:: Proceed with installation? [Y/n]
:: Retrieving packages ...
python-urwid-1.3.0-1-x86_64 332.9 KiB 876K/s 00:00 [#######################################################################################] 100%
python-pyparsing-2.0.3-1-any 68.0 KiB 6.64M/s 00:00 [#######################################################################################] 100%
(4/4) checking keys in keyring [#######################################################################################] 100%
(3/4) checking package integrity [#######################################################################################] 100%
(3/4) loading package files [#######################################################################################] 100%
(4/4) checking for file conflicts [#######################################################################################] 100%
(4/4) checking available disk space [#######################################################################################] 100%
(1/4) reinstalling python2-configshell-fb [#######################################################################################] 100%
(2/4) installing python-pyparsing [#######################################################################################] 100%
(3/4) installing python-urwid [#######################################################################################] 100%
(4/4) installing python-configshell-fb [#######################################################################################] 100%
[

It hadn't downloaded python-urwid or python-pyparsing yesterday when I did this, but it still says that python2-configshell-fb is up to date. This output really sends my head for a spin. Whatever, it works now.

JonnyJD commented on 2015-02-22 11:11

@James_Epp:
Do you have python-configshell-fb 1.1.fb17, or an earlier version, or python2-configshell? There is a minimum required version of python-configshell-fb which currently is *only* the current version of https://aur.archlinux.org/packages/python-configshell-fb/

Having a previous version installed will lead to that error (same as not having it installed at all, I guess).

James_Epp commented on 2015-02-22 02:10

Install dependency error, yet I definitely have the package installed. Can anyone else confirm?

==> Making package: targetcli-fb 2.1.fb39-1 (Sat Feb 21 19:50:43 CST 2015)
==> Checking runtime dependencies...
==> Missing dependencies:
-> python-configshell-fb>=1.1.fb17
==> Checking buildtime dependencies...
==> ERROR: Could not resolve all dependencies.

James_Epp commented on 2015-02-22 02:04

Error during install, I definitely have the dependency met.

==> Making package: targetcli-fb 2.1.fb39-1 (Sat Feb 21 19:50:43 CST 2015)
==> Checking runtime dependencies...
==> Missing dependencies:
-> python-configshell-fb>=1.1.fb17
==> Checking buildtime dependencies...
==> ERROR: Could not resolve all dependencies.

JonnyJD commented on 2014-09-16 13:19

Well, leaving old kernel modules would leave the problem of these accumulating. And on Arch Linux kernel updates are not rare at all.

Anyways, the configfs module is part of the kernel packages, not targetcli/rtslib. That is also the reason it is removed together with the old kernel.
So there is nothing really I can do about that. You have to open an Arch request/ticket for a feature to keep kernel modules on install/update and removing them with a reboot. (you can link the ticket here then)

ad1x commented on 2014-09-16 08:57

The error I had about modprobe(configfs) failing was caused by upgrading the kernel packages. It causes /lib/modules/$(uname -r) to be replaced by /lib/modules/$(newer_kernel_version).

This causes modprobe to fail, since it tries to read from /lib/modules/$(uname -r)/modules.softdep etc.

After rebooting and loading the new kernel everything is ok again. I don't know if it's possible to keep older kernel modules available in Arch.

JonnyJD commented on 2014-06-21 12:20

A new python-rtslib-fb version (fb48) was released and packaged. This hopefully fixes the pi_prot_type problem.

ad1x commented on 2014-06-16 09:51

mgmartin, thanks for the heads up. It saved me a lot of time figuring out what was happening.

mgmartin commented on 2014-04-28 02:18

A heads up: Newer kernels expose a target attribute--pi_prot_type--which is un-writable in the configfs tree. If you try to restore from a saved config.json file, the current python-rtslib-fb will error out, since it expects to be able to write all attributes. See https://lists.fedorahosted.org/pipermail/targetcli-fb-devel/2014-April/000073.html for some more info.

A quick fix is to remove any lines from your saved config file which set the attribute: -- "pi_prot_type": 0, -- then, be careful anytime you save your config (or autosave saves your config )

ad1x commented on 2014-04-24 07:20

Hey JonnyJD,

The configfs mount on /sys/kernel/config was present, modprobe -v configfs failed with exit status 1.

I decided to reboot the server, after that everything was working again. So for now I'm not sure what caused it.

Thanks for your help!

PS. The server was running kernel version 3.12.9 (now I'm at 3.14.1)

JonnyJD commented on 2014-04-23 13:26

One problem would be if you had a custom kernel with configfs (CONFIG_CONFIGFS_FS) either built as a module and not having the module available for the currently running kernel or you disabled it altogether.
Either way: You need configfs for LIO to work.

I am no kernel expert, but I don't know why else `modprobe configfs` would fail, except for not using su/sudo.

JonnyJD commented on 2014-04-23 13:09

First of all: You don't need kmod. There is a python module with that name: https://github.com/agrover/python-kmod but that is completely optional.
The ImportError is catched and running modprobe is then tried by rtslib.

Running modprobe is what gave the error and the ImportError is only part of the Trace, not the actual problem.

What failed is `modprobe configfs`.
The question is now why that failed. "configfs" is nothing that shows up in "lsmod" since this should be built into the kernel on Arch (CONFIG_CONFIGFS_FS=y)
What should show up is a file system that shows up with `mount` (after it is mounted):
configfs on /sys/kernel/config type configfs (rw,relatime)

Does `modprobe -v configfs` show any error messages?
Does configfs appear mounted (`mount`)?
Anything regarding this showing up in /var/log/messages?

I am not completely up to date on my machine. Maybe there is some problem with some kernel version.
Does a restart help? What kernel version do you have installed?

I don't think it has to do with the actual upgrade (as in the current versions of targetcli/rtslib) but possibly with the "overall" state of the system or kernel.

ad1x commented on 2014-04-23 12:35

After an upgrade I rebuild and upgraded python-configshell-fb, python-rtslib-fb and targetcli-fb (in that order).

Now targetcli.service fails with:

target.service - Restore LIO kernel target configuration
Loaded: loaded (/usr/lib/systemd/system/target.service; enabled)
Active: failed (Result: exit-code) since Wed 2014-04-23 14:25:13 CEST; 8s ago
Process: 20346 ExecStart=/usr/bin/targetctl restore (code=exited, status=1/FAILURE)
Main PID: 20346 (code=exited, status=1/FAILURE)

Apr 23 14:25:13 srv target[20346]: File "/usr/bin/targetctl", line 47, in restore
Apr 23 14:25:13 srv target[20346]: errors = RTSRoot().restore_from_file(restore_file=from_file)
Apr 23 14:25:13 srv target[20346]: File "/usr/lib/python3.4/site-packages/rtslib/root.py", line 73, in __init__
Apr 23 14:25:13 srv target[20346]: modprobe('configfs')
Apr 23 14:25:13 srv target[20346]: File "/usr/lib/python3.4/site-packages/rtslib/utils.py", line 370, in modprobe
Apr 23 14:25:13 srv target[20346]: raise RTSLibError(stderrdata)
Apr 23 14:25:13 srv target[20346]: rtslib.utils.RTSLibError: b''
Apr 23 14:25:13 srv systemd[1]: target.service: main process exited, code=exited, status=1/FAILURE
Apr 23 14:25:13 srv systemd[1]: Failed to start Restore LIO kernel target configuration.
Apr 23 14:25:13 srv systemd[1]: Unit target.service entered failed state.

Trying to get into targetcli yields:

Traceback (most recent call last):
File "/usr/lib/python3.4/site-packages/rtslib/utils.py", line 362, in modprobe
import kmod
ImportError: No module named 'kmod'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/usr/bin/targetcli", line 100, in <module>
main()
File "/usr/bin/targetcli", line 63, in main
root_node = UIRoot(shell, as_root=is_root)
File "/usr/lib/python3.4/site-packages/targetcli/ui_root.py", line 44, in __init__
self.rtsroot = RTSRoot()
File "/usr/lib/python3.4/site-packages/rtslib/root.py", line 73, in __init__
modprobe('configfs')
File "/usr/lib/python3.4/site-packages/rtslib/utils.py", line 370, in modprobe
raise RTSLibError(stderrdata)
rtslib.utils.RTSLibError: b''

I guess I'm missing kmod, but I don't know where to get it from :(

TheImperial2004 commented on 2014-03-30 23:45

That did the trick .

Thanks a lot Jonny!

JonnyJD commented on 2014-03-30 23:37

Just a guess:

You have one of targetcli/rtslib installed with Python 3.3 and one with Python 3.4. So you need to rebuild one.

TheImperial2004 commented on 2014-03-30 21:45

Hello Jonny

A recent full system upgrade results in target.service failure :

Mar 31 00:42:45 srv1 target[1012]: Traceback (most recent call last):
Mar 31 00:42:45 srv1 target[1012]: File "/usr/bin/targetctl", line 27, in <module>
Mar 31 00:42:45 srv1 target[1012]: from rtslib import RTSRoot
Mar 31 00:42:45 srv1 target[1012]: ImportError: No module named 'rtslib'
Mar 31 00:42:45 srv1 systemd[1]: target.service: main process exited, code=exited, status=1/FAILURE
Mar 31 00:42:45 srv1 systemd[1]: Failed to start Restore LIO kernel target configuration.
Mar 31 00:42:45 srv1 systemd[1]: Unit target.service entered failed state.

Thank you for your efforts .

JonnyJD commented on 2014-03-11 11:45

Hm, I don't really know actually.

Well, I do know that the original targetcli uses lio-utils to save the configuration in *.py files in /etc, which are basically just a list of lio-utils commands which are meant to be executed, not "read/parsed".
Targetcli-fb/rtslib-fb read and write json files.

Both formats are human-readable and you are supposed to be able to edit the json files by hand. There is a manpage "saveconfig.json.5" created when building rtslib-fb. Here if you don't have that at hand: download https://raw.github.com/agrover/rtslib-fb/master/doc/saveconfig.json.5 and open it with "man ./saveconfig.json.5".

One way would be to have a look at the /etc/*.py and/or start lio-utils/original targetcli and list the configuration there.
Then try to re-create this configuration with targetcli-fb and adjust the json manually for ids/strings that are "off".

I forwarded your request upstream, maybe there will be a nice idea about upgrading there:
https://github.com/agrover/targetcli-fb/issues/38

andyshinn commented on 2014-03-11 05:39

I was reading the wiki for setting up iSCSI and noticed: "The original targetcli is also available but has a different way of saving the configuration...". Does this mean that a configuration started on targetcli should not be upgraded to targetcli-fb? Is there an upgrade path?

JonnyJD commented on 2014-03-02 09:30

@mgmartin:
Thanks a lot for reporting. That issue must have been existing since ages.

This is fixed in a new pkgrel of python-rtslib-fb (where /etc/target is also created and the service file "lives"):
https://aur.archlinux.org/packages/python-rtslib-fb/

mgmartin commented on 2014-03-02 00:48

Thanks for the package, it's working very well.

I had to manually mkdir /etc/target/backup in order for the auto config backups to work, but no other problems.

JonnyJD commented on 2013-11-18 12:20

Yes, setuptools is now a makedepends.
Thanks, fixed in all packages (no pkgrel bump).

mr_evil commented on 2013-11-18 09:05

Working fine, thank you very much, JohnnyJD.

A small remark for the "python-configshell-fb" package:
it needs the "python-setuptools" package which ist not necessarily installed, atleast on a fresh install, and is not included as a dependency.

Anyways, thanks gain.

TheImperial2004 commented on 2013-11-15 20:10

Yes , it is fixed now .

moving the service file isn't an issue as those two packages install and update at the same time anyway .

Thank you again , Jonny .

JonnyJD commented on 2013-11-15 20:09

All PKGBUILDs (free branch or not) can still be found here:
https://github.com/JonnyJD/PKGBUILDs/tree/master/_lio

JonnyJD commented on 2013-11-15 20:03

I updated the free branch packages now and also updated the wiki:
https://wiki.archlinux.org/index.php/ISCSI_Target#Setup_with_LIO_Target

Like mentioned below, the target.service file moved from targetcli-fb to python-rtslib-fb so these packages should be upgraded at the same time.
The configuration file and format itself didn't change.

That translate() bug mentioned was introduced while moving targetcli-fb from Python2 to Python3 and was fixed in python-rtslib-fb.

JonnyJD commented on 2013-11-15 19:19

Nothing to worry about. The config format and file name is still the same and it should be a drop-in replacement.
That is: users of targetcli-fb have python3-rtslib-fb as requirement anyways and won't really notice that the service file is in another package now and that it works a bit different under the hood now.

Should be done later today.

JonnyJD commented on 2013-11-15 18:57

Yes, targetctl is actually new. What I meant is: The service file "target" will move from targetcli-fb to python3-rtslib-fb and use "targetctl" instead of targetcli.

This is only for the service file, targetcli still works as before (and could technically still be used to save and restore configuration).

The reason for that change is, that targetcli is not needed anymore when something else is used (like targetd, not yet in Arch Linux).

TheImperial2004 commented on 2013-11-15 18:55

"targetctl" ?

I never heard of it , and it doesn't exist in my /usr/bin as of now .

There are going to the change the way we configure fabrics ?

JonnyJD commented on 2013-11-15 18:47

Yes, I am working on it. The problem is known and fixed upstream, but with the next release something else changes: The service file and targetctl moves from targetcli to python3-rtslib-fb.

TheImperial2004 commented on 2013-11-15 18:45

Hi .

I can confirm this error too , when starting the target.service .

Nov 15 21:43:58 srv1 target[2604]: translate() takes exactly one argument (2 given)


Any way to fix this ? Thanks JonnyJD .

mr_evil commented on 2013-11-15 08:51

Hi,

when i try to start targetcli from this package, i get
"python translate() takes exactly one argument (2 given)"
and the tool will not start.

journal looked like this:

systemd[1]: Starting Restore LIO kernel target configuration...
target[6261]: translate() takes exactly one argument (2 given)
systemd[1]: target.service: main process exited, code=exited, status=255/n/a
systemd[1]: Failed to start Restore LIO kernel target configuration.
systemd[1]: Unit target.service entered failed state.

from what i googled this looks like a unicode problem. Since there is barely any error output, i have no idea where to start looking.

JonnyJD commented on 2013-11-01 17:05

I updated the package and also switched to using Python 3, which is now supported upstream.

TheImperial2004 commented on 2013-09-15 13:31

Working as it should now after applying your fix .

Thank you very much Jonny .

JonnyJD commented on 2013-09-15 12:39

Thank you for the report. I can't reproduce this with my setup, but this looks like an easy fix anyways.

I added a patch in the package https://aur.archlinux.org/packages/python2-rtslib-fb/. Please update that package and report back if that fixes your issue.
I would like to report the fix upstream then.

TheImperial2004 commented on 2013-09-15 10:50

Sorry . This is the full log :

Sep 15 10:04:49 srv1 target[456]: Traceback (most recent call last):
Sep 15 10:04:49 srv1 target[456]: File "/usr/bin/targetcli", line 89, in <module>
Sep 15 10:04:49 srv1 target[456]: main()
Sep 15 10:04:49 srv1 target[456]: File "/usr/bin/targetcli", line 72, in main
Sep 15 10:04:49 srv1 target[456]: shell.run_cmdline(" ".join(sys.argv[1:]))
Sep 15 10:04:49 srv1 target[456]: File "/usr/lib/python2.7/site-packages/configshell/shell.py", line 934, in run_cmdline
Sep 15 10:04:49 srv1 target[456]: self._execute_command(path, command, pparams, kparams)
Sep 15 10:04:49 srv1 target[456]: File "/usr/lib/python2.7/site-packages/configshell/shell.py", line 909, in _execute_command
Sep 15 10:04:49 srv1 target[456]: result = target.execute_command(command, pparams, kparams)
Sep 15 10:04:49 srv1 target[456]: File "/usr/lib/python2.7/site-packages/targetcli/ui_node.py", line 87, in execute_command
Sep 15 10:04:49 srv1 target[456]: pparams, kparams)
Sep 15 10:04:49 srv1 target[456]: File "/usr/lib/python2.7/site-packages/configshell/node.py", line 1417, in execute_command
Sep 15 10:04:49 srv1 target[456]: result = method(*pparams, **kparams)
Sep 15 10:04:49 srv1 target[456]: File "/usr/lib/python2.7/site-packages/targetcli/ui_root.py", line 108, in ui_command_restoreconfig
Sep 15 10:04:49 srv1 target[456]: errors = RTSRoot().restore(json.loads(f.read()), clear_existing)
Sep 15 10:04:49 srv1 target[456]: File "/usr/lib/python2.7/site-packages/rtslib/root.py", line 213, in restore
Sep 15 10:04:49 srv1 target[456]: Target.setup(fm_obj, t, err_func)
Sep 15 10:04:49 srv1 target[456]: File "/usr/lib/python2.7/site-packages/rtslib/target.py", line 130, in setup
Sep 15 10:04:49 srv1 target[456]: TPG.setup(t_obj, tpg, err_func)
Sep 15 10:04:49 srv1 target[456]: File "/usr/lib/python2.7/site-packages/rtslib/target.py", line 418, in setup
Sep 15 10:04:49 srv1 target[456]: NodeACL.setup(tpg_obj, acl, err_func)
Sep 15 10:04:49 srv1 target[456]: File "/usr/lib/python2.7/site-packages/rtslib/target.py", line 955, in setup
Sep 15 10:04:49 srv1 target[456]: MappedLun.setup(tpg_obj, acl_obj, mlun, err_func)
Sep 15 10:04:49 srv1 target[456]: NameError: global name 'MappedLun' is not defined
Sep 15 10:04:49 srv1 systemd[1]: target.service: main process exited, code=exited, status=1/FAILURE
Sep 15 10:04:49 srv1 systemd[1]: Failed to start Restore LIO kernel target configuration.
Sep 15 10:04:49 srv1 systemd[1]: Unit target.service entered failed state.


Thank you .

TheImperial2004 commented on 2013-09-15 10:44

Hi .

Updating to the last version breaks the daemon service :

Sep 15 13:41:45 srv1 target[733]: File "/usr/lib/python2.7/site-packages/rtslib/target.py", line 130, in setup
Sep 15 13:41:45 srv1 target[733]: TPG.setup(t_obj, tpg, err_func)
Sep 15 13:41:45 srv1 target[733]: File "/usr/lib/python2.7/site-packages/rtslib/target.py", line 418, in setup
Sep 15 13:41:45 srv1 target[733]: NodeACL.setup(tpg_obj, acl, err_func)
Sep 15 13:41:45 srv1 target[733]: File "/usr/lib/python2.7/site-packages/rtslib/target.py", line 955, in setup
Sep 15 13:41:45 srv1 target[733]: MappedLun.setup(tpg_obj, acl_obj, mlun, err_func)
Sep 15 13:41:45 srv1 target[733]: NameError: global name 'MappedLun' is not defined
Sep 15 13:41:45 srv1 systemd[1]: target.service: main process exited, code=exited, status=1/FAILURE
Sep 15 13:41:45 srv1 systemd[1]: Failed to start Restore LIO kernel target configuration.
Sep 15 13:41:45 srv1 systemd[1]: Unit target.service entered failed state.

JonnyJD commented on 2013-07-25 08:49

Please note that the license changed from AGPL3 to Apache 2.0 with fb27.

JonnyJD commented on 2013-04-08 10:20

There was a change in targetcli-fb to only show the backends you have the hardware available for:
https://github.com/agrover/targetcli-fb/commit/e302e0b781a38d852d89e4faf3a29689b10f5f0d
So you might be looking at the wrong place to check general support or targetcli-fb can't find your hardware.

These targets were not removed from the code:
https://github.com/agrover/rtslib-fb/blob/master/rtslib/fabric.py#L483


The difference between targetcli and targetcli-fb is that there is not much of development and no community for targetcli, but there are lots of changes and some community patches for targetcli-fb (free branch).
Have a look at https://github.com/agrover/targetcli-fb/network
The "upstream" branch is targetcli. "master" is targetcli-fb.

Risingtidesystems have a commercial product (rtsadmin) and are probably mainly working on that. Targetcli is open source, but not a community project.

quartz64 commented on 2013-04-08 09:55

What is the main difference between targetcli-fb and targetcli? I've noticed that there is no FC target (qla2xxx) and FCoE target (tcm_fc) in targetcli-fb.

TheImperial2004 commented on 2013-04-05 20:13


I edited all the files manually since I had free time .

I'm not in an urgent need for a -git package now .

Thanks .

TheImperial2004 commented on 2013-04-05 18:16

Oops ! I used the wrong words ..

What I meant was exactly what you explained . Every time I update the package using yaourt , it checks the git repo and compile from there .

Currently I reformated the server because of an RC kernel issues (noob) , and I would really use a -git package of RTSlib-fb + Targetcli-fb as editing those files manually would take alot of time . Of course if you have the time .

Thank you , really appreciated .

JonnyJD commented on 2013-04-05 17:42

That is not how it works.
-git packages are updated every time they are built. So the PKGBUILD doesn't change in the AUR, but "makepkg" will check for the current commit and update the pkgver with the current date.
So it would be up to you to build targetcli-fb-git/rtslib everytime you need it or automatically (I wouldn't suggest that. It can break things unexpectedly)

You can also create a "-local" package that basically just creates symlinks to a folder on your machine, which again is a repository, which again gets a "git pull" with cron.
I can't create that in the AUR, since it does depend on your local machine.
Have a look at this example though:
https://gist.github.com/JonnyJD/5321159 (another package, but this is how it works)

There will be a new targetcli/rtslib release "early this coming week".
I'd recommend to stick to that.
You do have a running build now after updating some files manually once, right?

Ping me again if you would still use a -git. I will create one then.

TheImperial2004 commented on 2013-04-05 15:50

Yes , if a -git package is going to be updated automatically as new commits get pushed into the repo .

Thanks !

JonnyJD commented on 2013-04-05 10:28

Hm, I followed that ticket, but there is no new release yet and I can't find that one commit (or 2) I could use as a patch without breaking other things.

I could create -git packages for rtslib and targetcli. Would that help?

TheImperial2004 commented on 2013-04-05 09:16

Can you update the package please ?

The GitHub repo contains an important ib_srpt bug fix now .

thank you .

JonnyJD commented on 2013-02-18 00:11

I included the systemd file from fedora, which works fine.
The old sysvinit file is still provided for now, but will go away in a couple of releases.

I also explicitely added the free branch of configshell to make automatic install easier without pulling epydoc.
Feel free to uninstall epydoc and dependencies now.

JonnyJD commented on 2013-02-12 02:50

This package still doesn't include a systemd file.
Help is appreciated at https://github.com/JonnyJD/PKGBUILDs/tree/master/_lio/targetcli-fb

JonnyJD commented on 2012-02-27 01:08

This also needs the free branch of rtslib. You can use either version of python2-configshell, though. The free branch doesn't depend on epydoc: https://aur.archlinux.org/packages.php?ID=57005

For this version there is also a manpage available.