Package Details: radicale 1.1.1-4

Git Clone URL: (read-only)
Package Base: radicale
Description: Simple calendar (CalDAV) and contact (CardDAV) server
Upstream URL:
Licenses: GPL3
Submitter: guibou
Maintainer: mlq (fordprefect)
Last Packager: mlq
Votes: 59
Popularity: 0.943028
First Submitted: 2011-02-14 23:17
Last Updated: 2016-08-04 08:45

Dependencies (5)

Required by (1)

Sources (4)

Latest Comments

klemens commented on 2017-01-09 20:57

The package release number should be bumped because of the python 3.6 update.

heddson commented on 2016-08-23 20:07

python-passlib is also needed if you want MD5 as htpasswd encryption method. So the optdepends-array should say: 'python-passlib: md5 and bcrypt support for htpasswd access'

gemunu commented on 2016-08-04 08:40

Hi, the checksums of radicale.service need to be updated
(the description in radicale.service has changed)

Arvedui commented on 2016-08-04 08:00

Kind of, he forgot to update the .SRCINFO file.

demaio commented on 2016-08-04 06:38

Huh? I already have version 1.1.1-2 installed (install date 2016-06-13). Maybe you forgot to update the version number recently?

Yamakaky commented on 2016-08-02 09:09

Please fix the PKGBUILD or disown

Siosm commented on 2016-04-10 01:57

I've pushed a version with a few fixes at Feel free to merge.

Captain_Rage commented on 2016-03-29 16:27

In order for the 'bcrypt' option (password hashing) to work, the packages python-bcrypt python-libpass have to be installed. Hence, they should be added as optional dependencies.

hobarrera commented on 2016-02-12 17:18

Why would they need to be executable? You don't generally run them as, are, but execute them via something else (eg: gunicorn?).

FWIW, I don't even have a /usr/share/webapps, nor do I see any package providing anything in there:

$ pkgfile /usr/share/webapps

Maribu commented on 2016-02-12 17:10


I believe the two files "/usr/share/radicale/radicale.{fcgi,wsgi}" should be executable (chmod +x). Also they might be better located at "/usr/share/webapps/radicale/radicale.{fcgi,wsgi}", as other webapps in Arch packages seem to be located under "/usr/share/webapps/${pkgname}/" (e. g. cgit).

Thanks for your work!

Best wishes,

PS: @untitaker: The package group base-devel is mostly needed for development in C, as it includes a C compiler, linker, make, automake, etc. As python is an interpreted language, no compiling/building is needed. I believe most arch=('any') packages do build fine without base-devel installed, including this one. Did you try do build this package without base-devel and ran into any problems?

dhaines commented on 2016-02-01 12:31

PKGBUILD is broken as of pacman 5; namely 'arch' should be an array like pretty much every other variable.

untitaker commented on 2015-12-28 14:07

base-devel is required for any AUR build. It is explained in the wiki.

n0m1s commented on 2015-12-28 14:01

I was getting "PKGBUILD: line 33: patch: command not found", so patch should be added as a build-time dependency.

bidossessi commented on 2015-12-20 10:48

It seems radicale will work with both python2 and python3, and some specific features, like LDAP auth, are only available for python2.
I suggest you make a split package in the vein of pyhon-radicale and python2-radicale, and split optional deps between each.

post-factum commented on 2015-12-12 08:27

==> Validating source files with md5sums...
Radicale-1.0.1.tar.gz ... Passed
radicale-1.0.1.patch ... Passed
radicale.service ... FAILED
radicale.install ... Passed

hobarrera commented on 2015-12-11 20:08

Actually, Type should stay as-is, and and ExecStart should change:

ExecStart=/usr/bin/radicale -f

post-factum commented on 2015-12-11 08:34

Service type must be forking instead of simple as radicale forks by default.

mynegation commented on 2015-12-01 13:44

Thank your for fast response, but somehow removing and reinstalling radicale and all python packages from non-updated pc i got it working with python 3.4
I exactly don't know what was the issue, but maybe this did the trick:

wget -O - | python

hobarrera commented on 2015-12-01 13:40

Looks like the current error quite differs from the original post.

I'm not really sure what your issue is. Running `sudo -u radicale radicale` will spit the entire output (which is trimmed below). But I'm not certain if *I* will be able to make something of it.

mynegation commented on 2015-12-01 12:50

python -c "import setuptools" outputs nothing.

wehn i try "systemctl status radicale -l" it says:

radicale.service - RadiCAL Server
Loaded: loaded (/usr/lib/systemd/system/radicale.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Tue 2015-12-01 14:48:51 EET; 1min 38s ago
Process: 1521 ExecStart=/usr/bin/radicale (code=exited, status=1/FAILURE)
Main PID: 1521 (code=exited, status=1/FAILURE)

Dec 01 14:48:51 istn radicale[1521]: File "/usr/lib/python3.4/logging/", line 76, in fileConfig
Dec 01 14:48:51 istn radicale[1521]: formatters = _create_formatters(cp)
Dec 01 14:48:51 istn radicale[1521]: File "/usr/lib/python3.4/logging/", line 109, in _create_formatters
Dec 01 14:48:51 istn radicale[1521]: flist = cp["formatters"]["keys"]
Dec 01 14:48:51 istn radicale[1521]: File "/usr/lib/python3.4/", line 937, in __getitem__
Dec 01 14:48:51 istn radicale[1521]: raise KeyError(key)
Dec 01 14:48:51 istn radicale[1521]: KeyError: 'formatters'
Dec 01 14:48:51 istn systemd[1]: radicale.service: Main process exited, code=exited, status=1/FAILURE
Dec 01 14:48:51 istn systemd[1]: radicale.service: Unit entered failed state.
Dec 01 14:48:51 istn systemd[1]: radicale.service: Failed with result 'exit-code'.

hobarrera commented on 2015-12-01 12:11

@mynegation The entire error message would help a lot in finding out what the issue is.

Also, what's the output of python -c "import setuptools"?

mynegation commented on 2015-12-01 10:51

Hi! My radicale server is not working anymore, i assume this is because of python update. I tried updating both python and radicale to latest wersion, it still does not start.
Now i downgraded python to 3.4, but radicale still does not start. When i try to reinstall radicale, setup stops with ERROR saying - ImportError: No module named 'setuptools'
Tried reinstalling python-setuptools, but radicale does not install, stops with 'setuptools' error.
Any ideas?

Latest radicale installs fine with python 3.5, but service does not starts.
My workaround would be downgrading python to 3.4 and radicale to previous version, but how do I downgrade radicale when it is not anymore in my tmp dir?

Captain_Rage commented on 2015-11-04 08:00

I had to install python-setuptools in order for 1.0.1-1 to build.

fordprefect commented on 2015-10-30 14:22

radicale has been updated several times since you last update - please take more care of this package or release it, so someone else can do.
thank you

Captain_Rage commented on 2015-10-05 10:36

Ah, I see! I ought to read my update logs more carefully. Indeed, the command you provided returned a single entry saying 'radicale'. After rebuilding radicale started working again. :-)

Arvedui commented on 2015-10-04 14:44

It's failing because python 3 got updated to 3.5.

the 3.5 binary can't find the radicale because it's still in the 3.4 path.

Just rebuild radicale and all python 3 packages you installed from the aur.

The following command should give you a list of packages that still have files in python 3.4 folders
pacman -Ql | grep python3.4 | sed -r 's/(\S+) \S+/\1/' | uniq

Captain_Rage commented on 2015-10-04 14:07

Suddenly radicale started failing on startup:

Oct 04 15:55:54 Amber radicale[304]: Traceback (most recent call last):
Oct 04 15:55:54 Amber radicale[304]: File "/usr/bin/radicale", line 29, in <module>
Oct 04 15:55:54 Amber radicale[304]: import radicale.__main__
Oct 04 15:55:54 Amber radicale[304]: ImportError: No module named 'radicale'
Oct 04 15:55:54 Amber systemd[1]: radicale.service: Main process exited, code=exited, status=1/FAILURE
Oct 04 15:55:54 Amber systemd[1]: radicale.service: Unit entered failed state.
Oct 04 15:55:54 Amber systemd[1]: radicale.service: Failed with result 'exit-code'.

Did some dependency break in a recent update? I am not sure I understand why it is failing to start now.

eigengrau commented on 2015-06-01 19:02

I second setting $HOME to /var/lib/radicale. radicale reads the config from /etc/radicale/config, even if the $HOME is somewhere else.

fordprefect commented on 2015-03-10 14:09

sorry for checking back so late.
it is not true, that radicale only looks for its config in its HOME.
i modified you PKGBUILD to make /var/lib/radicale HOME and the config is still residing in /etc/radicale. i am using it that way since my last post here.
you are right if you point out, that its easy to configure the storage backend to the desired point, but even if i respect kiss and vanilla principles of arch, i strongly encourage to set sane defaults.

oi_wtf commented on 2015-02-16 21:04

Problem here is, that you can't "configure" the location of the config file,
radicale will look, afair, only in it's users HOME.
But making /var/lib/radicale HOME, the config file would have to go there as well instead of /etc where it belongs!

You easily can, however, configure the storage backed correctly and all files go in the correct places.

For example:
type = filesystem
filesystem_folder = /var/lib/radicale/collections

hobarrera commented on 2015-02-14 23:14

@fordprefect is quite right. Variable data should *not* be placed in /etc. /etc is for configuration.

In hardened systems /etc will even be mounted read-only, so variable data here will fail quite horribly.

Standard practice is to use /var/db/radicale or /var/radicale. I've noticed a few packages use /var/lib. A few arch packages use /srv. I kinda dislike that a bit, but it would also be quite acceptable, since at least it stays in-line with other arch packages.

fordprefect commented on 2015-02-14 23:08

hi, thanks for maintaining this.
atm, you use /etc/radicale as home-dir for the created user. that leads to the collections created in /etc/radicale/.config/radicale/collections/ by default.
that does make little sense.
i propose including an empty dir /var/lib/radicale/ as ~ to store mutable data in it. that would make perfect sense also from the lsb viewpoint.
thanks for considering!

Yamakaky commented on 2014-09-14 11:06

May you include radicale.wsgi in the package ?

harshad1 commented on 2014-08-30 03:44

For those having trouble with clients being unable to list resources after the 2014-08-19 update, offers a solution

asch commented on 2014-04-10 16:12

Can somebody confirm running radicale without python2? I cannot sync, if python2 is not installed.

Yamakaky commented on 2014-03-31 07:05

Oh, yeah ^^

But I confirm for the opts dependencies.

Yamakaky commented on 2014-03-31 07:04

Yamakaky commented on 2014-03-31 07:03

Oh, yeah ^^

But I confirm for the opts dependencies.

hobarrera commented on 2014-03-30 11:20

@Yamakaky: The package is fine as it is. You need to rebuild it locally if (and when) you upgrade dependencies.

Yamakaky commented on 2014-03-30 11:07

(just increment the package version)

Yamakaky commented on 2014-03-30 10:57

Package broken, it needs to be rebuilt for python3.4

Yamakaky commented on 2014-03-30 10:51

You should add python-pam, python-requests and python-ldap to the opts dependencies.

Yamakaky commented on 2014-02-15 12:41

Oh, yeah ^^

untitaker commented on 2014-02-15 10:25

Yes, this is also what my gist further below fixes

Yamakaky commented on 2014-02-15 10:06

Systemd works better without fork (see daemon(7)). Simpler but equal in functionalities (-f switch is the default, so so need to add it) :

Description=RadiCAL Server



Additionally, I modified it with User=radicale, and in my /etc/passwd :


xduugu commented on 2013-11-29 19:08

It seems to be fixed in git, but not in version 0.8.

mlq commented on 2013-11-28 08:55

Thats because hash randomization is enabled by default since 3.3 in python. I will check on the other comments later on.

untitaker commented on 2013-11-28 05:59

That said, it seems to run fine for me.

untitaker commented on 2013-11-28 05:59

@xduugu If all improper uses of hash() are fixed, i don't think there is anything to worry about.

xduugu commented on 2013-11-27 22:17

radicale doesn't seem to be ready for python3 yet[1]. Maybe this package should therefore use python2 instead.


untitaker commented on 2013-11-25 14:19

I see i got the file permissions wrong, but you get the idea.

untitaker commented on 2013-11-25 14:06

Here is an attempt to make this: (seems to work for me)

untitaker commented on 2013-11-25 13:25

please let the systemd daemon run as an unprivileged user by default. The current way of running radicale as root is horrible.

techryda commented on 2013-10-23 01:28

The changes below will allow systemd to better manage the service.
Please update the radicale.service file as follows:

Description=RadiCAL Server

ExecStart=/usr/bin/radicale -d -p /run/


mbroemme commented on 2013-09-09 14:13

I'll support Enverex, otherwise you can't enable the service. :)

Enverex commented on 2013-08-19 10:18

What's with the dodgy .system file? Currently it is:

Description=RadiCAL Server


But this lacks an install section so it can't be enabled at startup. Surely it should have a:


... section?

roentgen commented on 2013-08-16 10:30

This installs the config and the systemd service with executable bit.

It should have -m644 for install lines in the PKGBUILD.

milouse commented on 2013-07-22 15:30

Package is out of date. New 0.8.0 version has been released. Warning, it comes with a lot of improvement and configuration change.

fauno commented on 2013-05-09 16:15

Added to Parabola's [pcr] repo with psytoolkit's .service. Thanks! :)

hobarrera commented on 2013-05-02 15:55

Package is not out-of-date; 0.7.1 is the latest release.

psytoolkit commented on 2013-01-19 12:37

The 0.7.1-1 version has a problem with the systemd startup. To fix this, I had to remove the /usr/lib/systemd/system/radicale.service file and replace it with my own which I put in /etc/systemd/system

You can set up the service with: systemctl enable radicale

Here is the code, hopefully it can help some people. The file to put the lines below in is: /etc/systemd/system/radicale.service

Description=Radicale caldav server

ExecStop=/bin/kill -HUP $MAINPID


guibou commented on 2012-09-25 14:01

Up + systemd unit

Still runs as root

punkrockguy318 commented on 2012-09-25 11:01

it would also nice to have a systemd unit for this

guibou commented on 2012-01-13 20:18

version dumped to 0.6.4

I have no issue with python 3.2 (but I just tested to add one or two items to the calendar using evolution).

Perhaps you may open a bug request upstream if the issue stays.

petelewis commented on 2012-01-13 15:57

Is this supposed to work with Python 3? I'm getting:

File "/usr/lib/python3.2/wsgiref/", line 137, in run
self.result = application(self.environ, self.start_response)
File "/usr/lib/python3.2/site-packages/radicale/", line 243, in __call__
"Response content:\n%s" % self.decode(answer, environ))
File "/usr/lib/python3.2/site-packages/radicale/", line 139, in decode
return text.decode(charset)
AttributeError: 'str' object has no attribute 'decode'
500 Internal Server Error
2012-01-13 15:55:36 ERROR 500: Internal Server Error.


guibou commented on 2011-02-14 23:19

Please note that this PKGBUILD contains some minor bug which may, I guess, be fixed upstream :

- Currently the daemon runs as root
- There is no check when launching daemon for already running instance