Package Details: radicale 2.1.8-2

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: fordprefect
Votes: 66
Popularity: 1.703394
First Submitted: 2011-02-14 23:17
Last Updated: 2018-01-09 21:56

Latest Comments

Arvedui commented on 2018-01-09 22:27

While we are at it: May I suggest using an EnvironmentFile to configure the ReadWritePath? That way one would not have to edit the service file and I think it makes sense with something like the collection path, since it's location is highly dependent on personal taste.

mzuther commented on 2018-01-09 22:23

@fordprefect On second thought, I think it would be a good idea to change "ReadWritePaths=/var/lib/radicale/collections" to "ReadWritePaths=/var/lib/radicale" in case someone wants to put data for radicale (such as a rights file) in this folder. Most people would expect this folder to be readable by radicale, and I don't see any security issues with that.


mzuther commented on 2018-01-09 22:07

Damn, you're fast! But then, the "real" Ford Prefect always liked to move fast... :) Thanks!

fordprefect commented on 2018-01-09 21:56

@mzuther: thanks for the suggestion. I enabled it and put a notification into post_install (not post_upgrade though), since a README is not a common file used in the AUR.

mzuther commented on 2018-01-09 21:49

@fordprefect I really think that you should uncomment the line "ReadWritePaths=/var/lib/radicale/collections" in "radicale.service". If not, almost every user of this package will run into trouble. After all, this directory is the default value of the configuration variable "filesystem_folder". Moreover, "radicale.install" explicitly creates this directory.

Finally, it would be nice if you added a small README which stated that people might have to change "/usr/lib/systemd/system/radicale.service" in case they use non-default radicale folders (such as when using symbolic links or the conversion directory "/var/lib/radicale2").

Thanks! And happy new year... :)

mzuther commented on 2018-01-09 20:49

@robinde @ntfc To find out more about the "ProtectSystem", see "man 5 systemd.exec". Basically, "ProtectSystem=full" mounts /boot, /usr and /etc as read-only.

robinde commented on 2017-11-30 09:49

@ntfc the `ProtectSystem` option relates to hardening security by mounting the entire fs ro. I didn't find much more info than this:

I was having a similar [Errno 30] Read-only file system problem until I noticed there is a ReadWritePath in the supplied radicale.service I added my /var/lib/radicale to this which I assume gave radicale write permission. You may need to add /var/log/radicale in order to give radicale rw permission on this folder. If this doesn't work you may also try `ProtectSystem=full` I don't know what this does in detail but it should be more secure than commenting out the option.

ntfc commented on 2017-11-28 21:23

Using the `radicale.service` option `ProtectSystem=strict`, I find that my radicale instance cannot write logs to `/var/log/radicale/log`, and thus is always restarting itself. Journalctl output:
Nov 28 21:17:23 hostname systemd[1]: Started radicale - A simple CalDAV (calendar) and CardDAV (contact) server.
Nov 28 21:17:25 hostname radicale[4235]: ERROR: Failed to start logger: Failed to load logging configuration file '/etc/radicale/logging': [Errno 30] Read-only file system: '/var/log/radicale/log'
Nov 28 21:17:25 hostname systemd[1]: radicale.service: Main process exited, code=exited, status=1/FAILURE
Nov 28 21:17:25 hostname systemd[1]: radicale.service: Failed with result 'exit-code'.

Disabling `ProtectSystem=strict` fixed it for me

fordprefect commented on 2017-11-27 21:54

@SataMaxx: you are right, I commented the unit at that point, which seemed to me like the best solution.

SataMaxx commented on 2017-11-27 03:33

@aurl & @fordprefect: except the last line in this service file is referencing an arbitrary absolute path (albeit the default one), which breaks the installations of users who decided to set their own path.

It would be cool if you could insert a warning in the .install file :-)

To users who set their own collection path, simply edit the .service file in /usr/lib/systemd/system/radicale.service after the update and change the ReadWritePaths to your custom path.

fordprefect commented on 2017-11-26 21:50

@aurl: thank you for your suggestion, I included the best of both worlds.

aurl commented on 2017-11-26 21:38

The documentation ( comes with a more comprehensive systemd service file than what is packaged here. I think it may be worthwhile to borrow it.

MazeChaZer commented on 2017-10-19 04:53

Sure, in radicale/ pkg_resources is being imported, which is provided by setuptools.

fordprefect commented on 2017-10-18 21:32

@MazeChaZer: sorry, just catched up with this. Thanks for the hint with the dependencies. However, I was not able to find any hints that setuptools is a runtime dependency. Its only occurence is in the, which is only called during package build. Could you detail your finding?

MazeChaZer commented on 2017-10-10 21:00

Radicale 2.0 additionally has a runtime dependency on python-setuptools. This is easily overlooked because many other python packages depend on it so it's likely already installed on many machines.

MazeChaZer commented on 2017-10-08 00:07

Could you clean up the optional dependencies? python-dulwich is definitly not used anymore in version 2.0. Neither is python-requests, as it seems, but I'm not sure about that.

fordprefect commented on 2017-08-27 18:02

@sbechet: thanks for looking into it. it should then be listed as dependency in the PKGBUILD of python-vobject. can you report it there?

sbechet commented on 2017-08-25 18:29

It seems python-pytz dependency come from [vobject](

sbechet commented on 2017-08-24 21:25

Hello @fordperfect and @djanos.

I confirm python-pytz is a missing dependency for something in radicale.

fordprefect commented on 2017-07-03 20:58

@djanos: do you mind to elaborate why you think so? neither namcap nor a grep through the code revealed anything related to pytz for me, the website contains no hint either.

djanos commented on 2017-07-03 13:22

Hello, python-pytz is a missing dependency

fordprefect commented on 2017-06-25 16:00

Update to 2.0.0 - please pay attention to the update instructions.
Thanks to thor77 for the main work on the update.

fordprefect commented on 2017-06-16 15:04

The 2.0 update of radicale is a major one, breaking compatibility with 1.x configs. It will take a while to sort this out. Contributions welcome.

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.

WhyNotHugo 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

WhyNotHugo 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

WhyNotHugo 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'.

WhyNotHugo 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

WhyNotHugo 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.

WhyNotHugo 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! :)

WhyNotHugo 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