Seafile Client .deb packages on ubuntu and debian

Never mind of compiling. It’s 2018. You can download DEB package from launchpad and install it by double click. But it’s true, there can be some incompatibility with new Ubuntu (shouldn’t but can be). If some appear then try compile it your self.

Download ccnet, libsearpc1, seafile-daemon and seafile-gui in same version.

Order of installation should(guessing):

  1. libsearpc1
  2. ccnet
  3. seafile-daemon
  4. seafile-gui (I’m sure this should be last)

Can you provide a link? Last time I checked Seafile’s launchpad a couple of weeks ago, they still had older versions out there… I think 6.1.2 was the latest version of the client. And, launchpad provided a link to the build link that @sjentzsch referenced.

Yes, 6.1.2 is lates in repo, but he was first ask for repo so I didn’t care about version. And I don’t prefer compiling cause, people returning with compile error and it run for long way. Here is link to seafile client 6.1.2 x64 DEB

Thanks for your feedback!

Indeed, I am interested in the latest version, because: It’s 2018 ! :wink:

I will compile myself on 18.04 and let you guys know here about my results.

Just wanted to add that 6.1.5 is in official ubuntu repos (universe). No need for ppa.

1 Like

Hello everyone,

I’m reponsible for packaging the Seafile Desktop Client and its dependencies for Debian (and thus for all its derivatives like Ubuntu).
We try to keep those packages up to date as good as we can.

The current state can be nicely tracked at DDPO -- Debian Quality Assurance

Currently, 6.1.7 is in the progress of migrating through unstable to testing.
For Debian Stretch, we will update the backports version when all 6.1.7 versions are finally arrived in testing.
You see that Ubuntu has imported the 6.1.5 series for their Bionic release.

Additions: If you’re running Debian Stretch and want to install the current backports version, please follow this instructions: Instructions

If you have any questions, feel free to contact me.
However, regarding packaging the Seafile Server, please see
Also, since the SeaDrive client is not open source (yet), there’s also no way we can package that.



You’re saying that move package from unstable to stable in repo take half-year? I’m still on 6.1.2 on Ubuntu 16.04 and 17.10.

Look, no one blame on seafile that in ppa is not SeaDrive or it take alot of time to get newest version into it. So why you don’t provide *.deb package to install manually? It worked for 5 years. PPA is always better to get stable and newer version without additional work, but sometime we want to check our translation or test it for you :slight_smile:

This is for whole Seafile team:
Keep doing great work, but listen to your community we are trying to help you build great system, but I’m feeling you don’t care (and think I’m not alone), so if not, just say it, I have more things to do :slight_smile:
For example I made some API DOC update in Octobe 2017, yesterday someone start care about my pull-request. So solution is made more contributor from community(not saying me), which can help you solv PRs and improve things like DOC.


I can’t find the packages in the backports, stretch i686 and amd64, even with the browser. Is " seafile-client" the package name or something else?

Package name is seafile-gui.

Ok, thank you, I think I was confused, because of the name in the AUR.

im not 100% sure if this is my fault, but on debian testing (buster) using debians repo for seafile-cli seafile-daemon and ccnet i get ccnet in version 6.1.7 and the rest in 6.1.5 and when i try to use seaf-cli it always says
Traceback (most recent call last):
File "/usr/bin/seaf-cli", line 95, in <module>
import ccnet
ImportError: No module named ccnet

using the seafile debian repo for stretch doen’t work anymore because it wants some old libevent-2.0-5.

I also can not build seafile 6.1.7:
valac: symbol lookup error: /usr/lib/x86_64-linux-gnu/ undefined symbol: g_date_copy

If you can handle with unstable OSses and you really want to use the client, you should to try Arch, if you compile seafile-client 6.1.7 with yaourt, it will work without any problems.

Be careful with the dates on the files and your system time, there are often issues. Maybe I’ll try it, then I’ll know.

@schlarbm, is there maybe something wrong in the package.xml or the CmakeLists.txt ? (Of version 6.1.5)

Even debian unstable has seafile-cli 6.1.5 and ccnet 6.1.7

ATM, until the “seafile” package in version 6.1.5 gets moved out of the NEW queue (look closely in the above screenshot), you would need to manually install “python-ccnet”…

src:ccnet and src:seafile-client have already been accepted into unstable and have migrated to testing already. src:seafile hasn’t, because it needs a manual approval, since we needed to (re-)introduce the binary python-seafile package.
I’m sorry for the hickup this currently causes, but I did not expect it to take so long (since it was the same with the new binary python-ccnet).

The current workaround (for Debian testing!) is to just manually install python-ccnet, too.

For the current Debian stable (“Stretch”), you can install 6.1.1 from the backports repository like I said before.
Before I can release a newer version of the backports, the packages have to be in testing, that is a strict requirement.

In 6.1.7 we had to split out the Python libraries to separate packages python-ccnet and python-seafile. Previously, they were included in the lib* packages, but that was actually in violation of the Debian Policy.
But, as I said, this introduction of new binary packages causes their upload to require manual intervention, which increases the time it takes for them to be available.

installing python-ccnet fixes the ImportError, but now i get the same Error when i run seaf-cli start as when i was compiling 6.1.7:
Starting ccnet daemon ...
ccnet: symbol lookup error: /usr/lib/x86_64-linux-gnu/ undefined symbol: g_date_copy
CCNet daemon failed to start.

6.1.2. was never in the Debian repositories, so I think you’re talking about the PPA, right?
In Debian, there are no version upgrades of packages within a stable release. So new versions and new packages can only go to testing (until that becomes the new stable release) - that’s why backports was created.