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.
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.
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.
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 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865830
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
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
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.
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/libgobject-2.0.so.0: 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.
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/libgobject-2.0.so.0: 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.