Package Details: seafile-shared 6.0.0-2

Git Clone URL: https://aur.archlinux.org/seafile.git (read-only)
Package Base: seafile
Description: Shared components of Seafile (seafile-daemon, libseafile, python bindings, manuals)
Upstream URL: https://github.com/haiwen/seafile
Licenses: GPL3
Conflicts: ccnet<6.0.0
Submitter: eolianoe
Maintainer: eolianoe (fordprefect, thealchemist)
Last Packager: eolianoe
Votes: 67
Popularity: 7.167328
First Submitted: 2016-08-11 16:38
Last Updated: 2016-09-11 18:18

Dependencies (9)

Sources (7)

  • 0001-Revert-server-put-pids-folder-out-of-seafile-data.patch
  • create-default-conf-dir.patch
  • libseafile.in.patch
  • seafile-admin_virtualenv.patch
  • seafile-server-6.0.0.tar.gz
  • seafile-server@.service
  • seahub-preupgrade

Pinned Comments

eolianoe commented on 2016-09-25 20:28

@all: For now I cannot update the package to the latest version (6.0.4 at the moment) due to conflicts and missing file for the clients, see [1] and [2] for the actual state of the problem.

[1] https://forum.seafile.com/t/seafile-server-and-seafile-client-packaging-guidelines/662/4
[2] https://github.com/haiwen/seafile/issues/1766

eolianoe commented on 2016-09-11 15:39

@thealchemist: I will merge your changes, but with the 6.0.3 version in [1] the
`seaf-daemon` is no more present compared to the 5.1.4 (or 6.0.0) version in [2] and this binary is needed for the client [3,4]

[1] https://github.com/haiwen/seafile-server
[2] https://github.com/haiwen/seafile
[3] https://github.com/haiwen/seafile-client
[4] https://aur.archlinux.org/packages/seafile-client

Latest Comments

Captain_Rage commented on 2016-09-25 21:26

Shouldn't python2-urllib3 be a dependency now? Since

"Warning:

The concept of sub-library is removed in version 5.1. You can do selective sync with the latest desktop client
The group message reply function is removed, and the old reply messages will not be shown with the new UI

Note: when upgrade from 5.1.3 or lower version to 5.1.4+, you need to install python-urllib3 (or python2-urllib3 for Arch Linux) manually:"

eolianoe commented on 2016-09-25 20:28

@all: For now I cannot update the package to the latest version (6.0.4 at the moment) due to conflicts and missing file for the clients, see [1] and [2] for the actual state of the problem.

[1] https://forum.seafile.com/t/seafile-server-and-seafile-client-packaging-guidelines/662/4
[2] https://github.com/haiwen/seafile/issues/1766

pvagner commented on 2016-09-23 09:21

@thealchemist Thank you! Now I'm using your 6.0.3 packages. I am not using seafile-client on the same machine so I don't need it at present. I am still keeping mysql setup and working seafile client on my todo list, however I don't feel confident enough to be able to suggest final solutions at this time. If I'll get something working, I'll post it here.

eolianoe commented on 2016-09-11 15:39

@thealchemist: I will merge your changes, but with the 6.0.3 version in [1] the
`seaf-daemon` is no more present compared to the 5.1.4 (or 6.0.0) version in [2] and this binary is needed for the client [3,4]

[1] https://github.com/haiwen/seafile-server
[2] https://github.com/haiwen/seafile
[3] https://github.com/haiwen/seafile-client
[4] https://aur.archlinux.org/packages/seafile-client

thealchemist commented on 2016-09-10 18:04

@eolianoe: I flagged the packages that I updated out-of-date

@TesterMcTest and @pvagner: maybe someone from the seafile-forums can help you with MYSQL. Would be nice to have it here.

thealchemist commented on 2016-09-10 17:52

Hi,
I went through all seafile dependencies (libevhtp, libsearpc, ccnet) and updated them to their last version I could find. As far as I can say, it is working fine this way (tested the built on the RPi 2*, file upload through seahub works on a server with SSL/DDNS/nginx). You can find my stuffs here:**
http://s000.tinyupload.com/?file_id=08827869627534314726

If I get this right, there are many changes in version 6.x.x, hence documentation [1] is currently not up-to-date. Generally speaking, the manual mainly covers the binary distribution and configuration is done with supplied scripts. Sadly the sources distribution is not really compatible with the scripts of the binary distribution (i.e. setup-seafile-mysql.sh), hence I found no option to deploy the server with mysql resp. mariadb.

@eolianoe: TMHO the 6.0.3 version is now only the seafile-server so I unified your split package to a single seafile-server. I did not went through the patches so they are still applied.

*not the seafile-rpi package but the "mainline" or development sources.
**does anybody see the irony in using an uploader for such software...

[1] http://manual.seafile.com/

thealchemist commented on 2016-09-06 11:45

I was not alone. I solved the issue by giving executable permissions to the /srv/seafile directory, i.e.
# chmod 711 /srv/seafile
The source was https://forum.seafile.com/t/website-not-working-properly/433

@pvagner: Did you already succeed with 6.0.2 or 6.0.3 and do you think about (co-)maintaining the package?

pvagner commented on 2016-09-01 05:56

@thealchemist sorry for the late reply. No I haven't changed the systemd service file. I am starting like systemctl start seafile-server@thatfoldername I've described in my previous comment. Anyway I'm getting some seahub tracebacks in the django_requests.log so I am just going try tupdating to freshly released 6.0.2 now.

thealchemist commented on 2016-08-23 14:24

@pvagner: This would mean, your setup is the same despite you use a subdirectory as mentioned in the Wiki. This may be the problem. Did you also change the systemd-service accordingly, i.e. replaced both occurrences of %i (wiki: %h) with your directory name?

pvagner commented on 2016-08-22 08:59

@thealchemist The arch wiki instructions worked for me i.e. I've created a user, created a directory for the whole site inside its home folder, created seafile-server directory in that, unpacked corresponding seahub.

thealchemist commented on 2016-08-16 18:50

Hello,

firstly thanks for maintaining these packages. As far as I can tell compiles fine using makepkg or yaourt (Tested on a Cubieboard 2 and Raspberry Pi 2, hence ARMv7). The server also starts when using the systemd service, BUT the seahub web interface is messed, i.e. no images are loaded, instead there is a language list and a login mask when scrolled down. I poke on my nginx configuration for some time now and loosly followed both the seafile documentation (http://manual.seafile.com/build_seafile/server.html --> deployment section) and our own outdated wiki article. My setup only differs in not using a separate <server-url.org> directory.

Any idea what I did wrong?

eolianoe commented on 2016-08-12 13:25

Updated to 6.0.0, according to [1] this is a beta version so be careful when updating.


[1] https://seacloud.cc/group/3/wiki/server-changelog

TesterMcTest commented on 2016-08-11 05:57

@pvagner @lulingar
The Arch installation deploys seafile with sqlite3. However you can migrate it afterwards. The people from seafile offer a migration part in their manual:

http://manual.seafile.com/deploy/migrate_from_sqlite_to_mysql.html

I did this quite some time back (approx. at 4.0.6). I needed to dump the migration scripts from above into the home directory of the domain I wanted to run seafile on (according to the wiki: $HOME/example.org).
Furthermore, if you are having python3 installed you need to change the first line in the python script to:

#!/usr/bin/env python2

(note the '2' at the end!).

As a recommendation I would run seafile once and set it up properly, so that the migration scripts aren't throwing errors due to missing databases. (I did not do that and I had to comment out the lines and cross my fingers that it still would work :-) )

pvagner commented on 2016-08-10 10:34

I appear to be unable to figure out how to deploy it with mysql as well. According to the docs it's using mysql-python for mysql connection, installing this one does not help though. Running seafile-admin setup will install with sqlite3.

lulingar commented on 2016-08-10 02:02

Using version 5.1.4, I haven't been able to deploy a MySQL-based instance (as per the instructions at https://wiki.archlinux.org/index.php/seafile), even by modifying the seafile-admin script or otherwise. The PKGBUILD was built and installed successfully. Does anyone have any pointers?

Armael commented on 2016-08-09 19:41

Even with openjpeg2 installed (which was not a dependency), the Pillow python library installed by seafile-server.install was not compiled with jpeg support. Thus, after adding a (.jpg) avatar to an account, seahub would crash with the following traceback: http://paste.isomorphis.me/Gqy .

A workaround I found (not sure if it's a proper one though) is to install python2-pillow, and replace "Pillow>=2.6.1,<3.0.0" by "Pillow>=2.6.1" in seafile-server.install.

eolianoe commented on 2016-08-01 21:02

Updated to 5.1.4, as previously said the server part is not fully tested.
I'm in process to separate the seafile-server and seahub (the front-end https://github.com/haiwen/seahub) in order to get clearer packaging. I you wish to test or help, feel free to send e-mails.

BytEvil commented on 2016-06-08 07:07

Seafile-admin setup failed with error.

***
Now initializing seahub database, please wait...

/usr/lib/seafile/seafileenv/bin/python2: can't open file 'manage.py': [Errno 2] No such file or directory
Error: Seahub syncdb failed
***

eolianoe commented on 2016-06-05 16:11

@pssd: sha56sum fixed, and yes you can change by yourself the checksums.

pssd commented on 2016-06-05 15:56

cannot install the package.

==> Überprüfe source Dateien mit sha256sums...
seafile-server-5.1.3.tar.gz ... Durchgelaufen
seafile-admin_virtualenv.patch ... Durchgelaufen
seafile-server@.service ... Durchgelaufen
seahub-preupgrade ... FEHLGESCHLAGEN
create-default-conf-dir.patch ... Durchgelaufen
0001-Revert-server-put-pids-folder-out-of-seafile-data.patch ... Durchgelaufen
libseafile.in.patch ... Durchgelaufen

I realized:
sha256sum of seahub-preupgrade: '333b78e2ac2ce03b243a70223975bfb0f8e1998edc074b4307c9a96df1b5883f'
and in PKGBUILD:'2a1e079cbea3543f356e6e9571f3d7d2a4b0ab75131ee417115d738ea191c4fb'
Is it due to Your changes in the seahub-preupgrade script? Can i just change that line?
(sorry for the newbish question)

fordprefect commented on 2016-06-04 17:07

@andreymal: i see, my fault. eolianoe already fixed this.

eolianoe commented on 2016-06-04 17:06

@andreymal, @fordprefect: made the appropriate change in seahub-preupgrade

andreymal commented on 2016-06-04 17:05

@fordprefect no, I want russian, just seahub-preupgrade script is broken.

Line 11:
SEAFILE_VERSION="$(pacman -Qi seafile-server | grep Version | sed 's|[^\n]*: \(.*\)-.*|\1|g')"

SEAFILE_VERSION has empty value for non-english locales. It is bug. Changing locale for script fixes this.

fordprefect commented on 2016-06-04 16:19

@andreymal: AUR packages will never change the locale of the environment they are build or installed in. If I understand you correctly, you want your pacman output to be english instead of russian. You can achieve this in several ways one of which would be defining an alias "alias pacman='LANG=C pacman'".
This package has nothing to do with this intent at all.

EDIT: exchanged yaourt and pacman. misread.

andreymal commented on 2016-06-04 16:14

Please add "LANG=C; export LANG" or something like this in seahub-preupgrade, because "pacman -Qi seafile-server | grep Version" not working for non-english locales

andreymal@home:~$ pacman -Qi seafile-server | grep Version
andreymal@home:~$ echo $LANG
ru_RU.UTF-8
andreymal@home:~$ pacman -Qi seafile-server | grep Версия
Версия : 5.1.3-1
andreymal@home:~$ export LANG=C
andreymal@home:~$ pacman -Qi seafile-server |Version
Version : 5.1.3-1

eolianoe commented on 2016-06-02 19:31

I just adopted the whole seafile packages after the good work of edacval. I'm using the client daily but I don't run a server, so feel free to get in touch if you wish to (co-)maintain this package.

edacval commented on 2016-05-27 05:33

@craftyguy Its upstream bug, introduced at https://github.com/haiwen/seafile/commit/c832f9c3bb2e22e0e06c84c2576b62695c2f604a . Working on patch.
update1: Pull request merged upstream

craftyguy commented on 2016-05-27 04:06

After the last update, seaf-cli fails with:

%  seaf-cli status
Traceback (most recent call last):
File "/usr/sbin/seaf-cli", line 832, in <module>
main()
File "/usr/sbin/seaf-cli", line 828, in main
args.func(args)
File "/usr/sbin/seaf-cli", line 626, in seaf_status
conf_dir = _conf_dir()
File "/usr/sbin/seaf-cli", line 151, in _conf_dir
if args.confdir:
NameError: global name 'args' is not defined


There's an upstream bug filed here, though it's not clear if it's an issue with seafile itself or with it being repackaged/installed here.

https://github.com/haiwen/seafile/issues/1646

edacval commented on 2016-05-20 01:49

@Magus Use AUR helper which properly supports split-pkgbuilds and you be happy. Forget BROKEN yaourt

magus commented on 2016-05-19 08:36

I would really love if it were easier to build only the seafile-shared package, I don't need the other two and don't really want to keep installing their dependencies when I re-build.

ngoonee commented on 2016-05-05 09:15

seafile-admin setup gives up on me due to python2-django not being installed (and after installing that, because the version is 1.9 since Nov 2015). Odd thing is that it worked just an hour or so ago, but I messed something up and tried the same thing again, no dice. I didn't have django installed then either...

EDIT: Hmmm now I notice the install file runs pip and creates a virtual env. It didn't seem to do that when reinstalling though. Odd.

foxlg commented on 2016-04-29 09:52

error:

In file included from http-server.c:15:0:
/usr/include/evhtp.h:12:23: fatal error: onigposix.h: No such file or directory
compilation terminated.

community/oniguruma - must be install

vit commented on 2016-04-28 14:19

Thanks. It works now.

vit commented on 2016-04-28 11:56

@edacval I've already up to date. Any further updates are coming?

vit commented on 2016-04-28 09:07

Am I the only one experiencing crashes?
Here is journalctl log:

апр 28 13:36:31 * systemd-coredump[22800]: Process 22693 (seaf-server) of user 1004 dumped core.
Stack trace of thread 22702:
#0 0x00007f76945f1ca9 x86_64_fallback_frame_state (libgcc_s.so.1)
#1 0x00007f76945f35c8 _Unwind_Backtrace (libgcc_s.so.1)
#2 0x00007f76a06cbc1f __backtrace (libc.so.6)
#3 0x00007f76a05f69b5 backtrace_and_maps (libc.so.6)
#4 0x00007f76a0646364 __libc_message (libc.so.6)
#5 0x00007f76a06cf017 __fortify_fail (libc.so.6)
#6 0x00007f76a06cefe0 __stack_chk_fail (libc.so.6)
#7 0x00007f76a27bbb5a n/a (libevhtp.so)
#8 0xffffffffffffffff n/a (n/a)

More details on seafile forum:
https://forum.seafile-server.org/t/issue-after-upgrade-to-5-1-1/4760/3

oberg commented on 2016-04-26 14:01

I am new to Arch. So sorry if I miss something simple.
My intend to install seafile client following instructions from @dreamingincode in comments below failed. I got the error message: "target not found: ccnet>=5.1.1"
I tried then to install first ccnet 5.1.1-1 from AUR although I thougt this would happen automatically by the package through dependencies.
This failed also with error: Ziel nicht gefunden: libsearpc (target not found: libsearpc)
Note: I first tried to install the seafile-client-cli package (https://aur.archlinux.org/packages/seafile-client-qt5/) via yaourt which failed also at some point with error. see: http://pastebin.com/QyiTswU9
I than followed instructions i found here https://www.reddit.com/r/archlinux/comments/nznu8/i_accidentally_installed_around_400_packages_with/ to delete the already installed files before trying again to install as mentioned above with pacman as described here: https://wiki.archlinux.org/index.php/Arch_User_Repository#Installing_packages

Any advice how to proceed?

dreamingincode commented on 2016-04-10 06:06

For users who don't want the seafile-server package, you can edit PKGBUILD like this:

1. Remove 'seafile-server' from pkgname.
2. Remove 'libevhtp-seafile' from makedepends.
3. Remove the '--enable-server' line from build().
4. Remove the 'package_seafile-server()' function.

Then you've got a clean PKGBUILD for seafile-shared and seafile-client-cli.

Personally I did this on every update.

Captain_Rage commented on 2016-03-06 11:31

@eolianoe: Thanks. I used the PKGBUILD, which apparently creates more than one package. Then I could choose and install which packges I wanted install using pacman -U.
Thanks for the clarification, since I didn't understand that it would create many packages.

hopimet commented on 2016-03-02 10:40

@elianoe, thx for the tip. I'll try to do this for the next upgrade.

@craftyguy, when you'll reach the question: do you want to install seafile-shared only (Y/N) or something like that, just answer N and this will install the 3 parts of this split package (seafile-shared, server and cli). Then you'll have to remove (as detailed below) server and cli if you don't want to use them.

eolianoe commented on 2016-03-02 09:22

@hopimet, @Captain_Rage: You may directly use 'makepkg' rather than AUR helper to build the package and then only install which one you want with 'pacman -U pkg.tar.xz'.
You may also report to your AUR helper that the '--pkg' option no longer exists in 'makepkg' since 'pacman=5.0.0' ("the ability to build a single package in a PKGBUILD has been removed")

@craftyguy: This PKGBUILD describes a split package containing 'seafile-shared', 'seafile-client-cli' and 'seafile-server'.

craftyguy commented on 2016-03-02 07:25

@hopimet

What do you mean by "entire package"?

hopimet commented on 2016-03-02 06:14

A workaround is to install the entire package (it works), then to remove seafile-server and seafile-client-cli, if you want seafile-shared only.

So, after installation:
sudo pacman -Rs seafile-server
sudo pacman -Rs seafile-client-cli

Hope that it will help.

Captain_Rage commented on 2016-03-02 05:40

Getting the same error as hopimet.

hopimet commented on 2016-03-01 20:41

When installing seafile-shared only it doesn't compile because of the following error:
makepkg: invalid option '--pkg'

gergan_penkov commented on 2016-01-26 21:19

it's missing a dependency on python2-chardet. The server stopped to work for me after the last update and I had errors in the logs:

2016/01/26 22:13:52 [error] 1377#0: *2199 FastCGI sent in stderr: "Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/flup/server/fcgi_base.py", line 558, in run
protocolStatus, appStatus = self.server.handler(self)
File "/usr/lib/python2.7/site-packages/flup/server/fcgi_base.py", line 1118, in handler
result = self.application(environ, start_response)
File "/usr/lib/seafile/seafileenv/lib/python2.7/site-packages/django/core/handlers/wsgi.py", line 255, in __call__
response = self.get_response(request)
File "/usr/lib/seafile/seafileenv/lib/python2.7/site-packages/django/core/handlers/base.py", line 176, in get_response
response = self.handle_uncaught_exception(request, resolver, sys.exc_info())
File "/usr/lib/seafile/seafileenv/lib/python2.7/site-packages/django/core/handlers/base.py", line 218, in handle_uncaught_exception
if resolver.urlconf_module is None:
File "/usr/lib/seafile/seafileenv/lib/python2.7/site-packages/django/core/urlresolvers.py", line 361, in urlconf_module
self._urlconf_module = import_module(self.urlconf_name)
File "/usr/lib/seafile/seafileenv/lib/python2.7/site-packages/django/utils/importlib.py", line 35, in import_module
__import__(name)
File "/usr/lib/seafile/seafileenv/lib/python2.7/site-packages/djblets/util/rooturl.py", line 40, in <module>
(r'^%s' % settings.SITE_ROOT[1:], include(settings.SITE_ROOT_URLCONF)),
File "/usr/lib/seafile/seafileenv/lib/python2.7/site-packages/django/conf/urls/__init__.py", line 25, in include
urlconf_module = import_module(urlconf_module)
File "/usr/lib/seafile/seafileenv/lib/python2.7/site-packages/django/utils/importlib.py", line 35, in import_module
__import__(name)
File "/srv/seafile/xxxxxx.xxxxx.com/seafile-server/seahub/seahub/urls.py", line 7, in <module>
from seahub.views.file import view_repo_file, view_history_file, view_trash_file,\
File "/srv/seafile/xxxxxx.xxxxx.com/seafile-server/seahub/seahub/views/file.py", line 12, in <module>
import chardet

After installing the python2-chardet all is back to normal again.

fordprefect commented on 2016-01-25 13:04

@BunBum: i see. you could try debugging this by yourself, but as stated a few days ago, this package needs some care anyways. i will have a closer look at it later this week…

BunBum commented on 2016-01-25 12:50

Thank you but now I get a

libtool: warning: '../lib/libseafile.la' has not been installed in '/usr/lib'

and

File "/usr/lib/python2.7/site-packages/virtualenv_support/pip-8.0.2-py2.py3-none-any.whl/pip/_vendor/requests/packages/urllib3/connectionpool.py", line 348, in _make_request
self._raise_timeout(err=e, url=url, timeout_value=conn.timeout)
File "/usr/lib/python2.7/site-packages/virtualenv_support/pip-8.0.2-py2.py3-none-any.whl/pip/_vendor/requests/packages/urllib3/connectionpool.py", line 318, in _raise_timeout
if 'timed out' in str(err) or 'did not complete (read)' in str(err): # Python 2.6
TypeError: __str__ returned non-string (type Error)

and

File "/usr/lib/python2.7/site-packages/virtualenv.py", line 781, in call_subprocess
% (cmd_desc, proc.returncode))
OSError: Command /usr/lib/seafile/seafileenv/bin/python2 -c "import sys, pip; sys...d\"] + sys.argv[1:]))" setuptools pip wheel failed with error code 2
The environment doesn't have a file /usr/lib/seafile/seafileenv/bin/activate_this.py -- please re-run virtualenv on this environment to update it

and

Requirement already satisfied (use --upgrade to upgrade): jdcal in /usr/lib/python3.5/site-packages (from openpyxl==2.3.0)
/tmp/alpm_JRITAD/.INSTALL: line 21: deactivate: command not found

fordprefect commented on 2016-01-25 10:27

@BunBum: looks like a python 2 vs 3 issue. since there is no direct call to "python setup.py", you could either temporary link /usr/bin/python to python2 (be careful with this! revert as soon as possible) or some more dirty tricks including . in front of the PATH (in the PKGBUILD only) and having a local link to python2.
either way you need to be careful and know what you are doing, thus i havent given you more detail so far.

BunBum commented on 2016-01-25 07:38

I can't install the package. I tried a completely fresh installation and get:

File "/tmp/pip-2kihmcij-build/setup.py", line 182
print "--- using Tcl/Tk libraries at", TCL_ROOT
^
SyntaxError: Missing parentheses in call to 'print'

File "/tmp/pip-build-c6whfwqo/Djblets/ez_setup.py", line 94
except pkg_resources.VersionConflict, e:
^
SyntaxError: invalid syntax

/tmp/alpm_Km0Ax3/.INSTALL: line 21: deactivate: command not found
error: command failed to execute correctly

fordprefect commented on 2016-01-21 10:49

this package has some issues, i think.
• in the post_install, it installs untracked files to the filesystem. this should definitely not happen, thats what dependencies and packages are for
• the data goes to /usr/share/seafile-server, but webapps are to be installed to /usr/share/webapps
• this package is named seafile-server, but it produces 3 seafile-related packages. it sould be renamed to seafile by reuploading under correct name (and with pkgbase=seafile, which is missing in the pkgbuild) and a merge request is to be filed.
• this package poorly corresponds with the wiki article (which itself is quite in a bad shape).

please consider refactoring this package to conform packaging standards.

@hillbicks: this is a split package. its PKGBUILD builds several packages at once. that does not mean, you need to install them all.

hillbicks commented on 2016-01-18 20:57

I don't understand why this package also provides seafile-server? If I just want to install seafile-client, I'm apparently forced to install the server as well? Would like to know reason for this :)

ERamseth commented on 2016-01-15 20:57

@MadMe of course I read that. seahub-preupgrade is either specific to the AUR package or undocumented (I believe specific to AUR since it calls pacman). From reading the script it seems to rely on upgrading first, but I wanted to be sure.

EDIT: Nevermind... I thought you were pointing me to the seafile docs, not the arch wiki. Thanks for reminding me about that... now if i can just get captcha and seafdav working....

MadMe commented on 2016-01-15 20:21

Maybe you should look here:
https://wiki.archlinux.org/index.php/Seafile#Upgrading
1. Stop seafile
2. Upgrade the Server from AUR
3. run preupdate (I think it brings the Database in a clean state?)
4. run the version upgrade
5. and start it again

ERamseth commented on 2016-01-15 20:14

Am I supposed to upgrade packages then run the seahub-preupgrade? or run the pre-upgrade then upgrade the packages? I'm thinking I upgrade packages first, but I wasn't 100% sure.

edacval commented on 2016-01-14 14:22

Seafile-* depends on exactly same ccnet version. This is upstream decision, not mine - see http://manual.seafile.com/build_seafile/server.html. Improved version checking with the https://aur.archlinux.org/cgit/aur.git/commit/?h=seafile-server&id=4d518692067e5a0c77012af840176b9e02e8a64e, so the next version>5.0.4 upgrade will be smooth. As temporary workaround , you can use "sudo pacman -Rcd ccnet" before seafile-{shared,server} upgrade.

eolianoe commented on 2016-01-14 09:40

Would it be possible to not require a version of ccnet in the PKGBUILD in order to get more smooth upgrades (see line 13 and 71).

Captain_Rage commented on 2016-01-13 00:21

Yeah, the dependencies are messed up for seafile-server 5.0.3-1.

fthiery commented on 2016-01-12 17:30

Fails to build directly for me, had to install libevhtp-seafile manually (i tried to install seafile-client, not the server).

Aur Targets (1): seafile-shared
Edit seafile-shared PKGBUILD with $EDITOR? [Y/n] n
==> Making package: seafile-server 5.0.3-1 (Tue Jan 12 18:16:22 CET 2016)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Missing dependencies:
-> libevhtp-seafile=1.2.9
==> ERROR: Could not resolve all dependencies.

Captain_Rage commented on 2016-01-11 01:18

Is it only me who gets "djblets" as a missing Python module?

bcc commented on 2016-01-07 13:05

I also get same error as @hecsa

Error: "/usr/share/seafile-server/scripts/runtime" not found

Captain_Rage commented on 2016-01-07 00:22

I also get

Jan 07 01:08:38 Centurion systemd[1]: Starting Next-generation open source cloud storage with advanced features on privacy protection and teamwork....
Jan 07 01:08:40 Centurion seafile-admin[22400]: Error: Python module "djblets" not found. Please install it first

when starting seafile-server 5.0.3-1. It was also a chore to upgrade to this version, since the dependencies for seafile-server/ccnet/seafile-client/seafile-shared seem to have gotten messed up.

hecsa commented on 2016-01-04 00:46

Tried copying /usr/share/seafile-server/scripts/seafile.sh to seafile and seahub.sh to seahub, but some errors remains:

# ./setup-seafile-mysql.sh
Checking python on this machine ...
Checking python module: setuptools ... Done.
Checking python module: python-imaging ... Done.
Checking python module: python-mysqldb ... Done.

-----------------------------------------------------------------
This script will guide you to setup your seafile server using MySQL.
Make sure you have read seafile server manual at

https://github.com/haiwen/seafile/wiki

Press ENTER to continue
-----------------------------------------------------------------


Error: "/usr/share/seafile-server/scripts/runtime" not found
# ls run*
ls: cannot access run*: No such file or directory

Thanks, and best regards,

HeCSa.

hecsa commented on 2016-01-04 00:15

Several errors when installing via yaourt, and after that, when running setup-seafile-mysql.sh:

Running yaourt:
---------------

Collecting Djblets==0.6.14
Could not find a version that satisfies the requirement Djblets==0.6.14 (from versions: 0.8, 0.8.1, 0.8.2, 0.8.3, 0.8.4, 0.8.5, 0.8.6, 0.8.7, 0.8.8, 0.8.9, 0.8.10, 0.8.11, 0.8.12, 0.8.13, 0.8.14, 0.8.15, 0.8.16, 0.8.17, 0.8.18, 0.8.19, 0.8.20, 0.8.21, 0.8.22, 0.8.23, 0.9)

...but the package gets installed.

After that:

First run of setup-seafile-mysql.sh:
------------------------------------

Checking python on this machine ...
Checking python module: setuptools ... Done.
Checking python module: python-imaging ...
python-imaging is not installed, Please install it first.

On Debian/Ubntu: apt-get install python-imaging
On CentOS/RHEL: yum install python-imaging


Error occured during setup.
Please fix possible problems and run the script again.


Then I ran:

pacman -S community/python2-pillow

...then:


Checking python on this machine ...
Checking python module: setuptools ... Done.
Checking python module: python-imaging ... Done.
Checking python module: python-mysqldb ...
python-mysqldb is not installed, Please install it first.

On Debian/Ubuntu:

sudo apt-get install python-mysqldb

On CentOS/RHEL:

sudo yum install MySQL-python


Error occured during setup.
Please fix possible problems and run the script again.

Again, I ran:

pacman -S extra/mysql-python

...then:

./setup-seafile-mysql.sh
Checking python on this machine ...
Checking python module: setuptools ... Done.
Checking python module: python-imaging ... Done.
Checking python module: python-mysqldb ... Done.

-----------------------------------------------------------------
This script will guide you to setup your seafile server using MySQL.
Make sure you have read seafile server manual at

https://github.com/haiwen/seafile/wiki

Press ENTER to continue
-----------------------------------------------------------------


Error: "/usr/share/seafile-server/scripts/seafile" not found

I assume some stuff needs to be modified:

- The dependencies check.
- Djblets!
- The .py scripts needs to point to seafile.sh, not seafile, but I'm not shure about this.
Thanks, and best regards,

HeCSa.

hillbicks commented on 2015-12-30 12:18

Upgrade from 5.0.2 to 5.0.3 is not possible, as stated before, because of the way the dependency is set uo.

Furthermore, seafile-server should not be installed when seafile-client is installed.

ERamseth commented on 2015-12-27 16:45

Line 12 of seafile-server.install needs to be changed to grab djblets properly. It should read:

pip install "git+git://github.com/djblets/djblets.git@release-0.6.14#egg=Djblets" --no-deps --allow-external Djblets --allow-unverified Djblets

The way it reads now used to work, but I think something changed on the Djblets end (maybe 0.6.14 is unsupported now? maybe seafile should change their requirements upstream)

(eventually I'll learn how to properly submit changes)

EDIT: please also add libjpeg-turbo to the dependencies. Without it, Pillow won't build with support for JPEG thumbnails.

blubbblubb commented on 2015-12-25 00:13

also got a problem with ccnet while updating the seafile packages:

==> Continue installing ccnet ? [Y/n]
==> [v]iew package contents [c]heck package with namcap
==> ---------------------------------------------------
==>

loading packages...
resolving dependencies...
looking for conflicting packages...
error: failed to prepare transaction (could not satisfy dependencies)
:: seafile-shared: requires ccnet=5.0.2


i then remove seafile completely and install it again and it works, could this be fixed if seafile-shared depends on ccnet >= X.X.X instead of ccnet = X.X.X ?

Also is there any way to install only the client like Popkornium18 asked? Im also only using the client and dont need the cli and server version

Popkornium18 commented on 2015-12-23 12:15

I think I have found the reason for the problem that Yaourt is installing the Seafile Server when you want to install the Client. seafile-client(-qt5) pulls seafile-shared as a dependency. This is a split package between seafile-shared, seafile-server, and seafile-client-cli. So if you do "yaourt -S seafile-client-qt5 --noconfirm" it automatically installs all components of this package. After the installation it tells you that seafile-server and seafile-client-cli are not needed by any package anymore and you can remove them. Could you fix that? Compiling the seafile-server on my Raspberry Pi took nearly two hours and it wasn't needed for the installation of seaf-cli (I guess).

edacval commented on 2015-12-21 13:21

@eolianoe
According to https://www.archlinux.org/pacman/PKGBUILD.5.html, `pkgbase` is optional. If not specified, the first element in the pkgname array is used.
@ERamseth
I try to figure out the 'seafdav', but will not promise that it will be soon. For me it's an unfamiliar area

eolianoe commented on 2015-12-21 12:51

@edacval: The upgrade issues may be linked to the fact that the split PKGBUILD does not contain the `pkgbase` variable

ERamseth commented on 2015-12-20 22:36

@edacval thanks for the comments and thanks for maintaining this package. I'll switch my aur helper I guess, although I dont have any problem doing it by hand, so to speak.

I still can't get webdav to work, but I havent tried that hard. I'm pretty sure seafobj (https://github.com/haiwen/seafobj) and seadav (https://github.com/haiwen/seafdav) need to be included somewhere along the way (they would typically end up in seafile-server/seahub/thirdpart... I put them there but it didn't change anything). What changes did you make to compile in webdav support? I don't mind figuring this out myelf, but if you can point me in the right direction that'd be good.

Also, a general question: is anyone using this build and a mysql/mariadb db backend? Seems like I can't use the included scripts to get it setup or converted from sqlite. Any pointers on getting that set up, aside from go through the setup scripts and mimic the actions in the right places by hand?

edacval commented on 2015-12-20 20:25

@ERamseth
1) Correct. Build one, get three :)
2) Separate seafile-shared and seafile-client-cli PKGBUIDD does not exists anymore.
3) Use AUR helper, which support split-pkgbuilds. I use yaourt/pacaur, both works perfectly.
4) Post-install configuration must be done according to Arch wiki, nothing changed
5) webdav support is compiled-in, but not tested, as I not using it

edacval commented on 2015-12-20 17:44

@a-bostaurus : upgrade ccnet

ERamseth commented on 2015-12-20 17:04

Some things I noticed so far with the new pkgbuild:

1) seafile-server is now a package group that provides seafile-server, seafile-shared, and seafile-client-cli. This means you only have to install seafile-server and it will give you all three packages

2) if you try to git-clone the old seafile-shared or seafile-client-cli packages, you will be given the 5.0.2 versions

3) packagebuilder / pb doesn't seem to play well with this setup. It goes into an infinite loop trying to install dependencies.

4) to upgrade, I uninstalled previous packages and then reinstalled the new package group. This worked ok. Note that my server directory was setup the way suggested in the Arch Linux wiki. If you do this, you will also need to update the seahub files.

5) seafdav still doesn't work

a-bostaurus commented on 2015-12-20 16:45

There is a problem, perhaps you know:
":: seafile-shared: benötigt ccnet=5.0.2, aber 5.0.3 ist installiert"
benötigt = needs

ERamseth commented on 2015-12-20 16:31

Yeah I think maybe he's trying to put them all in one PKGBUILD. Not sure.

EDIT: git clone with a manually adjusted URL gives you the 5.0.2 version

EDIT2: seems this will now provide seafile-server, seafile-shared, seafile-client-cli... im upgrading now to see if it actually installs.

Dezponia commented on 2015-12-20 16:27

When updated to 5.0.3 this package uses the "seafile-server" package build, Please change it to "seafile-shared" like it should be. Thank you.
Edit: Huh, it also seems to have randomly linked the "seafile-shared" and "seafile-server" comment boxes to each other.

edacval commented on 2015-12-20 14:42

Reworked to split-pkgbuid

edacval commented on 2015-12-20 14:42

Dependencies fixed, builds with webdav support.

ERamseth commented on 2015-12-16 05:52

the dependency on libevhtp-seafile needs to change. I don't think versions greater than 1.2.0 can work with seafile.

also, question: is this supposed to build with webdav support?

Captain_Rage commented on 2015-12-05 19:23

Hey. When upgrading to 5.0.2-1 the following error snuck inside:

<...>
Collecting django-constance[database] from git+git://github.com/haiwen/django-constance.git@bde7f7cdfd0ed1631a6817fd4cd76f37bf54fe35#egg=django-constance[database]
Cloning git://github.com/haiwen/django-constance.git (to bde7f7cdfd0ed1631a6817fd4cd76f37bf54fe35) to /tmp/pip-build-VsNBDP/django-constance
Error [Errno 2] No such file or directory while executing command git clone -q git://github.com/haiwen/django-constance.git /tmp/pip-build-VsNBDP/django-constance
Cannot find command 'git'
<...>

The package installed successfully, but later seafile-server refused to start. All that was needed was installing git and reinstalling seafile-server. :-)

<...>
Collecting django-constance[database] from git+git://github.com/haiwen/django-constance.git@bde7f7cdfd0ed1631a6817fd4cd76f37bf54fe35#egg=django-constance[database]
Cloning git://github.com/haiwen/django-constance.git (to bde7f7cdfd0ed1631a6817fd4cd76f37bf54fe35) to /tmp/pip-build-8_x0br/django-constance
Could not find a tag or branch 'bde7f7cdfd0ed1631a6817fd4cd76f37bf54fe35', assuming commit.
Collecting django-picklefield (from django-constance[database])
Downloading django_picklefield-0.3.2-py2.py3-none-any.whl
Installing collected packages: django-picklefield, django-constance
Running setup.py install for django-constance
Successfully installed django-constance-1.0.1 django-picklefield-0.3.2
<...>

I suggest adding git as a dependency to avoid this issue.

Almin commented on 2015-12-05 16:45

Attention to all upgraders to 4.4.x!

For some users, upgrading to 4.4.x seems to have broken Sync for Web-Interface and Android-Clients!

Take care upgrading!

https://github.com/haiwen/seafile/issues/1407
https://forum.seafile-server.org/t/504-error-from-nginx-1-8-suddenly-appeared-for-seafile/3462/9

Almin commented on 2015-11-11 10:19

@BunBum: the python2 package from the official [extra]/ repository is installed, otherwise I wouldn't have mentioned it.

r3ddr4gOn commented on 2015-11-10 06:38

Wouldn´t it be best to just use the virtualenv provided by the seafile packages?

[root@<domain>]# sudo -u seafile -s
[seafile@<domain>]$ echo "source /usr/lib/seafile/seafileenv/bin/activate" >> ~/.bashrc
[seafile@<domain>]$ exit
[root@<domain>]# sudo -u seafile -s
(seafileenv)[seafile@<domain>]$ <do the upgrade as usual>

BunBum commented on 2015-11-09 16:36

You have to install the python2 package (it can be installed parallel to python3) and it should work.

Almin commented on 2015-11-09 16:27

That's true, thanks.
So how de we solve the issue, as python3 is the default python interpreter on Arch Linux and everyone will run the script as I did?

Everyone will run it manually and copy-paste the secret key?

BunBum commented on 2015-11-09 15:34

You are using Python 3 (it expects parentheses for function calls like 'print'). You have to use Python 2 to run seafile.

Almin commented on 2015-11-09 15:00

Hey guys, updating got an error.
[code]

[me@mypc seafile-server]$ ./upgrade/upgrade_4.3_4.4.sh

-------------------------------------------------------------
This script would upgrade your seafile server from 4.3 to 4.4
Press [ENTER] to contiune
-------------------------------------------------------------


File "/srv/seafile/laptop/seafile-server/seahub/tools/secret_key_generator.py", line 53
print key
^
SyntaxError: Missing parentheses in call to 'print'

Updating seafile/seahub database ...

[INFO] You are using SQLite3
Done

migrating avatars ...

Done

updating /srv/seafile/laptop/seafile-server-latest symbolic link to /srv/seafile/laptop/seafile-server ...



-----------------------------------------------------------------
Upgraded your seafile server successfully.
-----------------------------------------------------------------

[/code]

Should I care about that?

simontunnat commented on 2015-10-29 16:23

Could someone please take over the seafile packages as maintainer.
I just can't find the time to maintain them.

calrama commented on 2015-09-29 12:50

I am unwilling to wait any longer, so the package is now orphaned. I advise anyone willing to pick this up to pick up the whole seafile dependency tree, as it would otherwise become tedious to maintain.

BunBum commented on 2015-09-20 06:43

@VinTeK thank you! It's working.
This should be definitely mentioned in the Arch Linux Wiki seafile section https://wiki.archlinux.org/index.php/Seafile

BunBum commented on 2015-09-20 06:43

@VinTeK thank you! It's working.
This should be definitly mentioned in the Arch Linux Wiki seafile section https://wiki.archlinux.org/index.php/Seafile

VinTeK commented on 2015-09-20 05:35

@BunBum I had the same problem and found /usr/bin/seafserv-gc solved it.

Inside your server's base directory, you'll want to run it with arguments
$ seafserv-gc -c ccnet -d seafile-data

Don't forget to do a --dry-run first.

Turtizzle commented on 2015-09-15 20:51

After fooling around a little bit, I managed to fix the issue.
Installed freetype2, linked /usr/include/freetype to /usr/include/freetype2, installed python2-pillow and tk, uninstalled pillow in the separate seafile-environment (while attempting to reinstall it, it said Requirement already satisfied).
I'm not sure what exactly of the above helped, or if all of it was required, but my Captchas started loading. Just leaving this here in case anyone has the same problem...

Turtizzle commented on 2015-09-15 19:37

Captchas (after a few failed login attempts) don't show up for me. I am required to enter one, but the image doesn't load. After further investigation, I narrowed it down to the python error "_imagingft C module is not installed". After some googling, it suggests that PIL might be compiled without freetype support, but I currently don't have the time to look further into it (and I kinda lack the understanding of that separate python environment). Eventually I'll check further, but maybe this helps someone else to save time if the same issue occurs: http://pastebin.com/raw.php?i=SU3RPWYn

calrama commented on 2015-09-05 15:38

This is the last upstream-based package update from me. Since I have received mail from one from person interested in maintaining, I will not orphan the packages just yet, but in the next couple of days.

kdop commented on 2015-09-03 02:00

I got it working on my Raspberry Pi but needed to install https://aur.archlinux.org/packages/libselinux/ to supply a missing library. It took me the better part of a day to get everything built and configured properly. I generally stuck with https://wiki.archlinux.org/index.php/Seafile until it came time to "Download seahub and extract it:" The appropriately versioned RPi variant is linked from Seafile's download page at https://github.com/haiwen/seafile-rpi/releases I then followed http://manual.seafile.com/deploy/using_mysql.html because sqlite hadn't worked for me the previous go around. After "seafile-admin setup" from the Arch wiki, it was tweaking configuration files and firewalls.

Thanks for your awesome work! Could not have done it without @calrama

BunBum commented on 2015-08-14 07:05

Thank you calrama. Unfortunately I don't get it running. Maybe @ddanier can help me out of this? I mean everbody has this problem and should clean up unused data periodically.

calrama commented on 2015-08-13 20:57

@BunBum You will at least need to copy it from the /usr/share directory to your seafile-server instance's path (where it would be in the binary distribution) and if it uses python ensure it uses the correct version of python (2). If the script has any dependencies in /usr/share, those will need to be copied, too. I don't have a seafile server on Archlinux anymore, so I can't test any of this.

BunBum commented on 2015-08-13 13:46

Hmmm ok, thank you. I will try it / do my best.

Could you please look into this forum thread as well? https://bbs.archlinux.org/viewtopic.php?id=201021 How do I run the seaf-gc.sh script?

calrama commented on 2015-08-13 13:28

@BunBum That script[1] is part of seahub, not seafile, which means I consider this an upstream issue: The seafile developers are unfortunately using the wrong shebang "#!/usr/bin/env python" instead of "!/usr/bin/env python2" pretty much everywhere. This package fixes this in all relevant contained files, but not external files. I suggest you open an upstream issue about this, since they should fix all their python-related shebangs to look for the python you require (which in this case is python2 not python, since they explicitly state they do not support python3).

[1] https://github.com/haiwen/seahub/blob/5e0d1068411a9970b8c074d1411939c2ce9d82aa/tools/secret_key_generator.py

calrama commented on 2015-08-13 13:27

@BunBum That script[1] is part of seahub, not seafile, which means I consider this an upstream issue: The seafile developers are unfortunately using the wrong shebang "#!/usr/bin/env python" instead of "!/usr/bin/env python2" pretty much everywhere. This package fixes this in all contained files, but not external files. I suggest you open an upstream issue about this, since they should fix all their python-related shebangs to look for the python you require (which in this case is python2 not python, since they explicitly state they do not support python3).

[1] https://github.com/haiwen/seahub/blob/5e0d1068411a9970b8c074d1411939c2ce9d82aa/tools/secret_key_generator.py

BunBum commented on 2015-08-11 07:00

Since the last update I can't run ./upgrade/upgrade_4.2_4.3.sh. I get a

File "/home/seafile/myserver/seafile-server/seahub/tools/secret_key_generator.py", line 53
print key
^
SyntaxError: Missing parentheses in call to 'print'.

After that I can't start the service because I get a "ImproperlyConfigured: The SECRET_KEY setting must not be empty."


I fixed line 53 manually. After that everything works.

BunBum commented on 2015-08-11 06:57

Since the last update I can't run ./upgrade/upgrade_4.2_4.3.sh. I get a

File "/home/seafile/myserver/seafile-server/seahub/tools/secret_key_generator.py", line 53
print key
^
SyntaxError: Missing parentheses in call to 'print'.

After that I can't start the service because I get a "ImproperlyConfigured: The SECRET_KEY setting must not be empty."

calrama commented on 2015-08-07 19:02

Since I no longer intend to use distributions with systemd for personal use,
I will abandon this package no earlier than 2015-09-01.
Should someone be interested in maintaining this package afterwards,
he or she can contact me in the interim to become co-maintainer
and then sole maintainer once I leave, to ensure a smooth transition.
If possible, I would like to hand over the following packages over to a single maintainer, since they comprise a dependency graph:
libevhtp-seafile, libsearpc, ccnet, seafile-shared, seafile-client, seafile-client-cli, seafile-server

vit commented on 2015-07-11 20:06

Can anyone explain how to setup with mysql? I can't do seafile-admin setup with mysql.

vit commented on 2015-07-09 17:45

Validity checks failed.
Please update.

==> Validating source files with sha256sums...
v4.2.2-server.tar.gz ... Passed
seafile-admin_virtualenv.patch ... Passed
seafile-server.install ... FAILED
seafile-server@.service ... Passed
seahub-preupgrade ... Passed
0001-Revert-server-put-pids-folder-out-of-seafile-data.patch ... Passed

calrama commented on 2015-06-29 22:50

@simonsmiley It is a relic from the past that I currently do not have the time to fully verify to be superfluous.

thelinuxguy commented on 2015-06-29 22:48

why does it conflict with django? I don't see a reason. There is nothing documented upstream

calrama commented on 2015-06-12 09:35

Initial AUR4 import at seafile version 4.2.2.

BunBum commented on 2015-06-03 08:06

Since the latest update to ccnet 1.4.2-10 I can't start seafile anymore.
Journalctl shows an "Error: Python module "python imaging library(PIL)" not found."

Almin commented on 2015-05-04 17:34

Sorry for the long response time.
@calrama: Yes, of course. I did exactly this way.

calrama commented on 2015-05-01 18:22

@Almin It worked without any issues for me, did you follow the steps mentioned here[1]. If so, this sounds like a problem for upstream.

[1] https://wiki.archlinux.org/index.php/Seafile#Upgrading

Almin commented on 2015-04-28 16:07

Hey guys, upgrading to 4.1.2, running the script, throws an error:

-------------------------------------------------------------
This script would upgrade your seafile server from 4.0 to 4.1
Press [ENTER] to contiune
-------------------------------------------------------------


Done

Updating seafile/seahub database ...

[INFO] You are using SQLite3
[INFO] updating seafile database...
Traceback (most recent call last):
File "/srv/seafile/cubietruck/seafile-server/upgrade/db_update_helper.py", line 329, in <module>
main()
File "/srv/seafile/cubietruck/seafile-server/upgrade/db_update_helper.py", line 324, in main
db_updater.update_db()
File "/srv/seafile/cubietruck/seafile-server/upgrade/db_update_helper.py", line 238, in update_db
self.update_ccnet_sql(sql_path)
File "/srv/seafile/cubietruck/seafile-server/upgrade/db_update_helper.py", line 254, in update_ccnet_sql
self.apply_sqls(self.ccnet_db.get_db(dbname), sql_path)
File "/srv/seafile/cubietruck/seafile-server/upgrade/db_update_helper.py", line 250, in apply_sqls
conn.execute(line)
sqlite3.OperationalError: duplicate column name: type

Failed to upgrade your database

minus commented on 2015-04-24 13:11

Manually updated to 4.1.2, seems to work, haven't taken a closer look though.

HalosGhost commented on 2015-04-09 17:43

Hello there! Any word on the update to 4.1.x? You've already updated the -shared which makes me think there is a problem with the server? If so, is there anything I can do to help?

All the best,

MadMe commented on 2015-03-25 20:04

@danboid A little bit more information would be helpfull... are you using ssl(https)? if yes how did you create the Certificate? How looks your configuration files?(ccnet.conf;seahub_settings.py;nginx.conf[i only used nginx... never used apache])
you have only with the original build for Raspian from the official Download the seahub.sh... So with the package from the Arch Linux you have "seafile-admin"
If you wanna start the Server manually: "seafile-admin start --fastcgi"
I also build my copy with yaourt. and yes the binaries are no option.
But i think this is the wrong place for support you should maybe start a Thread in the forum.

danboid commented on 2015-03-24 16:23

I'm having the same prob as Almin w/ v4.0.6. I can sync and upload with the desktop client and I can login to the web interface but I can't upload or download anything via the web interface. I have tried with both nginx and Apache with the same result - I get a gateway error if anything happens at all.

Two suspicious points I've noted that I can't find any reference to are that the web interface and client don't work at all when started with --fastcgi in the systemd script with both nginx and apache. Also, numerous docs make reference to starting seahub with seahub.sh but there is no such script in my installation.

I built it using yaourt under ArchARM so I expect using official binaries isn't an option. I'm also disappointed that it seems there is no way to access older versions of files using the GUI desktop client.

Thanks for your help!

MadMe commented on 2015-03-23 22:52

@Almin the config files are correct? i guess you will use ssl... Upload works over the web frontend?
in seahub_settings.py must be
FILE_SERVER_ROOT = 'https://my.domain.net:PORTNUMBER/seafhttp' (dont forget your port and the s in https)
and in ccnet/ccnet.conf there must also be the correct line:
SERVICE_URL = https://my.domain.net:PORTNUMBER

Almin commented on 2015-03-22 14:59

Hmm... sadly still doesn't work for me. It runs, it syncs desktop clients, but not mobile ones. Downloading from the web frontend also doesn't work.

MadMe commented on 2015-03-22 13:57

Ok i don't know why it worked with a new instance. but it seems like i messed up with the ssl stuff... A New ssl certificate and it works very well:) sorry for spaming :-/ And Thanx for your Help :-D
Everything works now really nice for me :-D

MadMe commented on 2015-03-22 09:10

It works with a new instance...
With my old instance the client stuck on Connecting to server...
Is there a way to debug it?the logs don't say much...

jellysheep commented on 2015-03-20 20:07

@MadMe: Syncing (up and down) works for me on linux.

My ccnet.log is as follows:
[03/20/15 21:00:07] ../common/session.c(432): socket file exists, delete it anyway
[03/20/15 21:00:07] ../common/session.c(461): Listen on /srv/seafile/ccnet/ccnet.sock for local clients
[03/20/15 21:00:07] ../common/session.c(267): Update pubinfo file
[03/20/15 21:00:07] ../common/connect-mgr.c(515): Opened port 10001 to listen for incoming peer connections
[03/20/15 21:00:08] ../common/session.c(375): Accepted a local client

MadMe commented on 2015-03-20 19:11

in the ccnet.log of the client i found this:
[03/20/15 20:05:55] ../common/processors/rcvcmd-proc.c(492): Add server a28d84vc mydomain.myfritz.net:10001
[03/20/15 20:05:55] ../common/connect-mgr.c(364): [Conn] Start outgoing connect to (null)(a28d84vc39) 85.88.88.47:10001
[03/20/15 20:06:05] ../common/connect-mgr.c(220): [Conn] peer (null)(a28d84vc39) connection fails
I think the client shouldnt see the port? a little bit strange for me. (i'm using nginx with https)

MadMe commented on 2015-03-20 19:02

Downloading works like a charm...
But syncing wont... with linux an windows...
can somebody confirm this?
Maybe i killed something in my config as i thought the download problem was there hidden...

calrama commented on 2015-03-20 13:58

@calrama: That is strange. In any case, thank you for the information, I have updated seafile-server and libevhtp-seafile appropriately, so it should work now.

jellysheep commented on 2015-03-20 13:52

I tried a few more things, and apparently the issue is caused by libevhtp 1.2.10. When using libevhtp 1.2.9 downloads work as expected (no difference if using seafile 4.0.5 or 4.0.6).

calrama commented on 2015-03-20 13:05

@jellysheep: No problem, I just wanted to clarify it. There were no changes from 4.0.5 to 4.0.6 in terms of the PKGBUILD (other than updating version and checksums) that I can remember. If you mean upstream: I am not aware of any.

jellysheep commented on 2015-03-20 13:02

@calrama: It is funny that you found my bug report. :) I reopened it as you suggested. Though sorry for blaming your starting script.
Were there any packaging/deploying changes introduced from 4.0.5 to 4.0.6?

@Varakh: Yeah, this way it works for me, too, I also wrote a systemd service for this. :) Though it does not solve the issue itself, and btw there is a huge difference between installing a binary package from 3rd party site vs. compiling it from source.

Varakh commented on 2015-03-20 12:33

I gave up on this long ago and installed seafile from the website. This did work out of the box.

Having this as a package might be easier, but there is nearly no difference when you update it manually:

- pkg upgrade = wget :-)
- stop server(s) = same thing
- execute upgrade scripts = same thing

For starting it with systemd: google provides some information on service files. Very easy to have this done manually and avoid problems regarding the predefined aur package here.

calrama commented on 2015-03-20 12:12

@jellysheep: Thanks for the information about seaf-server not responding. Unfortunately I do not know why, but I suspect there is something wrong with the way this package builds seafile (though I currently do not know what). Also, I found your github issue about this and using seafile-admin is not a faulty way to start seafile. This is the way the manual states[1] you should start self-compiled seafile server instances (not from the binary distribution). In any case, you may want to reopen that issue, I shall investigate further.


[1] http://manual.seafile.com/build_seafile/server.html

jellysheep commented on 2015-03-20 11:47

Apparently the seafile fileserver (listening on port 8082) does not respond at all. With the binary package downloadable on seafile.com this is not the case. Any ideas?

jellysheep commented on 2015-03-20 11:43

@MadMe, @calrama:
Sorry for any confusions. Apparently I misread the Seafile wiki. I downloaded the binary distribution files from seafile.com, therefore I had the scripts in the filesystem. Thank you for clarifying that.

Apart from that, I have the same problem as before, and as Varakh and MadMe have, that downloads don't start.

@calrama: nginx seems not to be the problem, as without fastcgi it does not work either.

calrama commented on 2015-03-20 11:42

The problem as far as I've been able to trace it is that for some reason nginx no longer communicates correctly with seahub in fastcgi. The error is a timeout and looks like this:
{TIMESTAMP} [error] 376#0: *939 upstream timed out (110: Connection timed out) while reading response header from upstream, client: {CLIENT_IP}, server: {SERVER_HOSTNAME}, request: "GET /repo/{REPO_ID}/files/?p=/{REQUESTED_FILE} HTTP/1.1", upstream: "fastcgi://127.0.0.1:8000", host: "{SERVER_HOSTNAME}", referrer: "https://{SERVER_HOSTNAME}/repo/{REPO_ID}/"

calrama commented on 2015-03-20 11:16

@jellysheep: I've been trying to figure this out for a while now and that does not work. Firstly, both scripts have the layout of the binary distribution hardcoded and need to be patched to work with a site-wide installation. While that is done easily enough it does not change anything regarding the ability to download files in the seahub web interface. Normal library syncing in a client works with both these two scripts and with seafile-admin, but downloading a single file in the seahub web interface works with neither.
@MadMe: They are not installed by default, because they are redundant and would also need to be patched (see my reply to jellysheep).
@vit: I've never had any admin notifications in seafile, so I cannot help you there, unfortunately.

MadMe commented on 2015-03-20 11:10

@jellysheep (btw cool name) these files aren't there for me...do you maybe have an old version of seahub? I will try to copy the files from the source when I'm back home.. maybe it will work...

jellysheep commented on 2015-03-20 08:42

@MadMe: If you installed seafile in [...]/example.org/seafile-server, first stop seafile-server@.service, then in a terminal switch to user seafile (e.g. 'sudo -u seafile -s /bin/sh') and execute the following commands:
$ [...]/example.org/seafile-server/seafile.sh start
$ [...]/example.org/seafile-server/seahub.sh start
(or seahub.sh start-fastcgi, if you want to use fastcgi).
That way seafile and downloads work fine for me.

MadMe commented on 2015-03-19 21:24

@jellysheep how can i do this? i find seafile.sh and seahub.sh only in package after makepkg... but i have no clue how to use them in the right way :-(

jellysheep commented on 2015-03-19 17:05

@MadMe: Please try to start seafile and seahub via seafile.sh and seahub.sh.
For me it did not work with the binary seafile-admin provided with this package (downloads did not start either).

MadMe commented on 2015-03-19 16:52

4.0.6-1 seems to be broken for me...
Upload works fine for me, download won't start. With the binary from 4.0.5(i guess at least so) it works fine. Now while i am writing here... i saw Varakh's Post. maybe the same problem?

vit commented on 2015-03-12 16:36

After upgrading to 4.0.6 there is still notification in admin interface about new server version 4.0.3 available. Am I the only one with this?

Varakh commented on 2015-03-04 19:47

Is download a file working for you guys? I followed the steps in the wiki and it is loading if I click on download but nothing happens.

calrama commented on 2015-03-04 14:17

@Varakh: In that case I am sorry the slightly harsh reply. Regarding the question: I do not know.

Varakh commented on 2015-03-04 11:14

@calrama: I didn't mean to be rude, sorry if it sounded like it. It is only a for each loop for every $language, isn't it?

calrama commented on 2015-03-04 10:04

@Varakh I never stated it as optional, please read again. I wrote "I don't use localisations [...]" and explained to you, that if you want this feature, you need to provide a patch, as it normal for a F(L)OSS environment.

@derintendant This has been mentioned on the relevant ArchWiki page[1] since May 2014.

[1] https://wiki.archlinux.org/index.php/Seafile

derintendant commented on 2015-03-04 09:37

Systemd no longer resolves the %h identifier in the Unit File as of Version 210 (https://bugs.archlinux.org/task/39258). Starting seafile-server via systemd thus fails.
I have now hardcoded the path to seafile in the Unit file but I dont really like this "hack".

Varakh commented on 2015-03-04 09:35

@calrama I don't think that those things are "optional". Let me explain: editing seahub_settings.py and adding LANGUAGE='...' is optional, but generating the django.mo for each language should be default because languages are built in per default. They exist. We just don't "compile them with msgfmt". It's another thing to use them in settings.py. Do you know what I mean? :-)

@BunBum Thanks, I added SEAFILE_VERSION='4.0.6' manually now. Although this is a bug. :-)

calrama commented on 2015-03-04 07:40

@Varakh I don't use localisations if it can be avoided, so if you want this functionality, you'd need to provide a tested patch to the PKGBUILD that does it.

BunBum commented on 2015-03-04 06:48

@Varakh regarding the version number: there was already a GitHub issue https://github.com/haiwen/seahub/issues/234

Varakh commented on 2015-03-03 17:47

Update worked, although I can think of some improvements:
- step in https://github.com/haiwen/seafile/wiki/Seahub-Translation (msgfmt -o django.mo django.po) for my preferred language had to be done again. Is there a chance that this can be automated?

- seahub interface is showing server version 3.0.0. Is this a bug? It is obviously not version 3.0.0. :-)

calrama commented on 2015-02-23 18:51

@TesterMcTest: Only after libevhtp has been updated for the newly required build options[1]

[1] http://manual.seafile.com/build_seafile/server.html#libevhtp

TesterMcTest commented on 2015-02-16 19:10

@calrama: Hi. Could you update the PKGBUILD to the newly released version (4.0.6)?

sflor commented on 2015-02-12 01:01

In the 'setup' section it says to run './setup-seafile.sh', but where do I actually find that file in our setup (following the wiki)? Sorry, this is kind of a dumb question, but I can't figure it out.

calrama commented on 2015-01-31 18:59

@Narigo: No, you are not. Apparently they updated the tag after release which (obviously) changed the checksum. Should be fixed now.

Narigo commented on 2015-01-30 08:42

The sha256sum of https://github.com/haiwen/seafile/archive/v4.0.5-server.tar.gz is different to what's in the PKGBUILD. Am I the only one with that problem?

Almin commented on 2015-01-08 14:32

@calrama: Thank you so much! This was exactly the problem! I thought I would be intelligent and not set up nginx, as seafile has it's own way offering the web-frontend. This is why I wanted to set up seafile first and afterwards add the nginx virtual host, knowing seafile already works.

I added that in the wiki article, but my english is not the best, which is why I invite everyone of you to edit it and make it easier to understand.

calrama commented on 2015-01-07 22:34

@Almin: How are you starting the seafile server instance? If you use the provided seafile-server@.service, it will be started with the "--fastcgi" option, in which case you will have to have a webserver in front of it (e.g. nginx). In any case, I had a look at the new official documentation over at http://manual.seafile.com/deploy/README.html and it seems they changed the way to initally setup the seafile server configuration a bit. See http://manual.seafile.com/deploy/using_sqlite.html for SQLite and http://manual.seafile.com/deploy/using_mysql.html for MySQL. I have not setup a new seafile server since before that change, so I do not know how you will have to adjust what's written in the docs to the fact that seafile is installed system-wide. I have updated the wiki to not have the "old" way of configuration anymore, but instead linked to the manual about it. If you figure out how to do it correctly, you're more than welcome to update the wiki page with it.

Almin commented on 2015-01-07 19:40

Installing and starting works fine with the instructions in the wiki.
Got an error message...:

seafile-session.c(309): Failed to open template dir /srv/seafile/laptop/seafile-data/library-template: Error opening directory '/srv/seafile/laptop/seafile-data/library-template': No such file or directory

...which I solved by just touching the file and chowning it to seafile:seafile

Now it starts and runs fine. Without strange systemctl status, without further warnings or errors in the log files.
It just and simply runs.
Well actually it doesn't. After wasting at least 12 hours and another installation on another PC I have no clue why not.
I just can't access it. If I try to enter mydomainORip:8000 in a webbrowser all it does is loading forever. It doesn't stop loading.
If I type http://myip:8082 it tells me:
If you see this page, Seafile HTTP syncing component works.

I don't know what to do and I'm sick of it. It's not as if there where any errors or warnings or something, it just runs, I can see the tasks running by using top.
It just doesn't work.

cris9288 commented on 2014-12-21 19:06

Am having some trouble starting this with systemd. It seems to start the server, but eventually times out. Here is the journalctl:

Dec 21 11:29:30 skynet seafile-admin[7002]: Seahub running on port 8000 (fastcgi)
Dec 21 11:29:30 skynet seafile-admin[7002]: Starting seahub in fastcgi mode...
Dec 21 11:29:30 skynet seafile-admin[7002]: Starting seafile-server...
Dec 21 11:29:30 skynet seafile-admin[7002]: Loading seafile config from /mnt/raid/seafile-data
Dec 21 11:29:30 skynet seafile-admin[7002]: Loading ccnet config from /srv/seafile/cbom.me/ccnet
Dec 21 11:28:03 skynet systemd[1]: seafile-server@cbom.me.service failed.
Dec 21 11:28:03 skynet systemd[1]: Unit seafile-server@cbom.me.service entered failed state.
Dec 21 11:28:03 skynet systemd[1]: Failed to start Next-generation open source cloud storage with advanced features on privacy protection and teamwork..
Dec 21 11:28:03 skynet systemd[1]: seafile-server@cbom.me.service start operation timed out. Terminating.

Here is my systemd service file:

[Unit]
Description=Next-generation open source cloud storage with advanced features on privacy protection and teamwork.
After=syslog.target network.target

[Service]
Type=forking
User=seafile
WorkingDirectory=/srv/seafile/%i
ExecStart=/usr/bin/seafile-admin start --fastcgi
ExecStop=/usr/bin/seafile-admin stop
PIDFile=/srv/seafile/%i/seafile-data/pids/seaf-server.pid

[Install]
WantedBy=multi-user.target

Strange thing is, if I change to the seafile user and start it manually with seafile-admin start --fastcgi, it starts up normally. Any help is appreciated, thanks.

calrama commented on 2014-12-03 12:48

@monochromec:

- SIGILL: Since this has not been confirmed to happen on non-arm architectures with versions >= 4.0.1 I still think this is an upstream issue and not a packaging one.
- At the last time of my updating, the latest versions released were 4.0.0 for the server and 4.0.1 for everything else.
- There should be no need for any modification to achieve that, this package has been patching seafile-admin to do exactly that for a long time now (see seafile-admin_virtualenv.patch, previously called seafile-admin.patch). The virtualenv is created and setup with django and djblets by this package pretty much exclusively for seahub, so I do not know what you actually did (since /usr/bin/seafile-admin already does that).

Regardless, versions 4.0.1(server) and 4.0.3(the rest) is out now.

monochromec commented on 2014-12-03 07:40

@calrama: not sure if this is not really a packaging issue. After spending a good bit of time on the issue, here are my conclusions / $.02:

- The SIGILL is not confined to the server package. I noticed this on the client side in seaf-daemon as well. I'll post a similar comment en the seafile-shared package entry.
- What worked for me (after trying different combinations of server versions and python environments for the web frontend): use the latest release package from github (4.0.2) and compiling these with the latest matching versions of ccnet and libsearpc for both the server and client side. Platform is an armv7h with gcc 4.9.2.
- Using the virtualenv python environment in /usr/lib/seafile from the AUR package for the seahub frontend. Simply modify the python invocation in /usr/local/bin/seafile-admin to pick up the interpreter from the virtual environment. Compared to various homebrewn environments I've tried over the last few days this virtual environment from the AUR package contains matching django and djblets version which are essential (!) for running the seahub frontend without strange python issues.

monochromec commented on 2014-12-03 07:39

@calmara: not sure if this is not really a packaging issue. After spending a good bit of time on the issue, here are my conclusions / $.02:

- The SIGILL is not confined to the server package. I noticed this on the client side in seaf-daemon as well. I'll post a similar comment en the seafile-shared package entry.
- What worked for me (after trying different combinations of server versions and python environments for the web frontend): use the latest release package from github (4.0.2) and compiling these with the latest matching versions of ccnet and libsearpc for both the server and client side. Platform is an armv7h with gcc 4.9.2.
- Using the virtualenv python environment in /usr/lib/seafile from the AUR package for the seahub frontend. Simply modify the python invocation in /usr/local/bin/seafile-admin to pick up the interpreter from the virtual environment. Compared to various homebrewn environments I've tried over the last few days this virtual environment from the AUR package contains matching django and djblets version which are essential (!) for running the seahub frontend without strange python issues.

BunBum commented on 2014-11-24 16:21

Does anyone know where I can find seaf-gc.sh mentioned here http://manual.seafile.com/maintain/seafile_gc.html ?

Armadillux commented on 2014-11-23 13:44

Did and successfull upgrade sticking to the wiki and using the minor upgrade script suggested by calrama.

Keeping an eye open for problems!

Thx calrama

calrama commented on 2014-11-16 20:24

@monochromec: Yes. If you look in the above metadata for this package, you will see the github site listed under "Upstream URL"; that is what I was referring to. At that URL you can navigate to their bug tracker (which in this case is the github issue system); the URL you shuold reach that way is the following: https://github.com/haiwen/seafile/issues

monochromec commented on 2014-11-16 20:18

@calrama: thanks for the quick reply! As I'm pretty new to the AUR: by upstream you mean the github site? (as this is an AUR package)

calrama commented on 2014-11-16 18:35

@monochromec: At first glance this does not look like a packaging issue to me, so I suggest opening a bug report upstream.

monochromec commented on 2014-11-16 18:30

Just stumbled across an issue with seaf-server: executing this with the following parameters produces a SIGILL on an armv7h architecture:

-f -c /mnt/disk/seafile/example.com/ccnet -d /mnt/disk/seafile/example.com/seafile-data -l /mnt/disk/seafile/example.com/logs/seafile.log -P /mnt/disk/seafile/example.com/seafile-data/pids/seaf-server.pid

GDB tells me:

#0 0x40561da8 in _armv7_tick () from /usr/lib/libcrypto.so.1.0.0
#1 0x4055e204 in OPENSSL_cpuid_setup () from /usr/lib/libcrypto.so.1.0.0
#2 0x40010194 in call_init.part () from /lib/ld-linux-armhf.so.3
#3 0x400102f0 in _dl_init_internal () from /lib/ld-linux-armhf.so.3
#4 0x40000c44 in _dl_start_user () from /lib/ld-linux-armhf.so.3
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Needless to say, w/o a working seaf-server instance the whole framework doesn't work (including the web frontend).

Happy to provide more information as required.

calrama commented on 2014-11-11 17:55

@Bunbum: That's because you kept it installed. You did not do "pacman -Rsunc seafile-server", right? Because if you did, it should've been removed. Pip will first try to use the normal site packages (installed through pacman) and not install if not needed. So, if you remove the pacman package after setting up the virtualenv, you will not have any simplejson, since the virtualenv depended on the pacman one. You can fix this, by removing python2-simplejson, and then simple installing seafile-server again. Alternatively, after removing python2-simplejson, do the following:
# /usr/lib/seafile/seafileenv/bin/activate
(seafilenv) # pip install simplejson
(seafilenv) # deactivate

calrama commented on 2014-11-11 17:54

@Bunbum: That's because you kept it installed. Pip will first try to use the normal site packages (installed through pacman) and not install if not needed. So, if you remove the pacman package after setting up the virtualenv, you will not have any simplejson, since the virtualenv depended on the pacman one. You can fix this, by removing python2-simplejson, and then simple installing seafile-server again. Alternatively, after removing python2-simplejson, do the following:
# /usr/lib/seafile/seafileenv/bin/activate
(seafilenv) # pip install simplejson
(seafilenv) # deactivate

BunBum commented on 2014-11-11 06:27

I followed your steps and reinstalled everything. Now it works. Thank you. Something destroyed my installation during the upgrade... hhmmm...

You should add python2-simplejson to the dependencies. After installation you get following message:

==> Packages no longer required by any installed package:
python2-simplejson

If you remove it seafile does not work anymore.

calrama commented on 2014-11-10 18:10

@BunBum: I do not know why they tagged them as a stable release, but I would believe it to be simple human error. Regardless, the update should work if you followed the normal upgrade procedure outlined on the Seafile ArchWiki page. If you still received this error that way, it might be that your virtual environment got messed up, in which case you can try the following:

# pacman -Rsunc seafile-server
# pacman -Rsunc seafile-shared
(the second line should not be necessary, but do it anyway to make certain it hase been removed)
# pacman -R python2-pillow
# pacman -R gunicorn-python2

At this point make sure that the virtual python environment for seafile has been removed, i.e. /usr/lib/seafile/ should be empty (or not exist). If necessary, remove everything in /usr/lib/seafile/.

$ yaourt -S seafile-server
(or any other AUR package wrapper, but I tried only with yaourt)

You should now have a working virtualenv. After this, do normal upgrade (but call the minor upgrade script instead of the non-existing 3.1-to-4.0 upgrade script).

By the way, you should not need to install pillow (I removed it from the dependencies explicitly), since it is being installed with pip in the virtual python environment.

calrama commented on 2014-11-10 18:08

@BunBum: I do not know why they tagged them as a stable release, but I would believe it to be simple human error. Regardless, the update should work if you followed the normal upgrade procedure outlined on the Seafile ArchWiki page. If you still received this error that way, it might be that your virtual environment got messed up, in which case you can try the following:

# pacman -Rsunc seafile-server
# pacman -Rsunc seafile-shared
(the second line should not be necessary, but do it anyway to make certain it hase been removed)

At this point make sure that the virtual python environment for seafile has been removed, i.e. /usr/lib/seafile/ should be empty (or not exist). If necessary, remove everything in /usr/lib/seafile/.

$ yaourt -S seafile-server
(or any other AUR package wrapper, but I tried only with yaourt)

You should now have a working virtualenv. After this, do normal upgrade (but call the minor upgrade script instead of the non-existing 3.1-to-4.0 upgrade script).

By the way, you should not need to install pillow (I removed it from the dependencies explicitly), since it is being installed with pip in the virtual python environment.

BunBum commented on 2014-11-10 17:56

Why do they tag a release and say it is not a release? ... :-/

After I upgradet to 4.0.0 nothing is working anymore. First I deleted gunicorn because it is not necesarry to be installed. Then I updated everything.

Then I got this error:
Error: Python module "python imaging library(PIL)" not found. Please install it first

After manually installing python2-pillow I get following:

ImportError: No module named gunicorn

After installing gunicorn-python2 (19.1.1-1) from the AUR the service does start without errors, but it does not work anymore. I cant open the seahub webinterface and so on.

calrama commented on 2014-11-10 16:06

! Important information about the 4.0.0 update !

See here: https://github.com/haiwen/seafile/issues/920

Apparently upstream created a stable tag for 4.0.0 even though it is still in testing (so I updated this package too soon). Since it seems to be working without any real problems I decided not to downgrade the seafile-packages to <4.0.0 for now. Should enough people strongly feel against this decision, I will downgrade the packages. Otherwise there will be a new package release once the stable 4.0.0 is actually released upstream.

Should you choose to update now:

- There is currently no upgrade script for 3.1 to 4.0 at upstream. I have done my update with the minor upgrade script (under the assumption that there where no database changes) and have not encountered any problems so far.
- djblets and gunicorn are no longer PKGBUILD dependencies, they are installed inside the virtual environment for seahub. This removes the need to have these two packages manually installed with pacman at fixed versions.

BunBum commented on 2014-11-10 09:14

@bsergik @calrama
3.0.0 will be shown because it is declared so in their settings.py => https://github.com/haiwen/seahub/blob/master/seahub/settings.py#L403

The guys from seafile does not synchronize everything from their internal Bitbucket repository to their public GitHub repository :-/

calrama commented on 2014-11-08 14:55

@bsergik: That would be a question for upstream, since the web interface (seahub) is not technically a part of this package - you install it either manually or by calling seahub-preupgrade, the latter of which is just the manual steps bundled together. Personally, I have the same version shown in the web interface and have not had any problems with it so far, but for a proper answer you should still go to upstream.

calrama commented on 2014-11-08 14:55

@bsergik: That would be a question for upstream, since the web interface (seahub) is not technically a part of this package - you do it either manually or by calling seahub-preupgrade, the latter of which is just the manual steps bundled together. Personally, I have the same version shown in the web interface and have not had any problems with it so far, but for a proper answer you should give go to upstream.

bsergik commented on 2014-11-08 14:38

I get Server Version: 3.0.0 shown in the Web Interface. Is it ok?

calrama commented on 2014-09-20 10:38

@axil42: See my comment from 2014-07-05 18:59. Short version: Package was taken from me (without asking) and then broken such that it could not be built (whether this is still the case I do not know, but I informed the new maintainer and did not get a positive response). You can try using it, but if you do, and get it to work, please tell me.

calrama commented on 2014-09-20 10:38

@axil42: See my comment from 2014-07-05 18:59. Short version: Package was taken from me (without asking) and then broken such that it could not be built (whether this is still the case I do not know, but I informed the new maintainer and did not get a positive response). You can try using it, but if you do, please tell me should it work.

calrama commented on 2014-09-20 10:38

axil42: See my comment from 2014-07-05 18:59. Short version: Package was taken from me (without asking) and then broken such that it could not be built (whether this is still the case I do not know, but I informed the new maintainer and did not get a positive response). You can try using it, but if you do, please tell me should it work.

axil42 commented on 2014-09-20 07:05

Hi, seems python2-djblets is now renamed to https://aur.archlinux.org/packages/python2-django-djblets/

Narigo commented on 2014-09-18 05:36

@Hinz, no idea about the webdav module, but we have 3.0.0 shown in the webinterface as well.

Hinz commented on 2014-08-27 09:01

Upgrade from 3.0.4 to 3.1.1 ran pretty smoothly. Two questions though.
- Is the webdav module included in this build or has it anybody running?
- Am I the only one who still got Server Version: 3.0.0 shown in the Webinterface?

@calrama Thanks for the packages, makes it a lot easier!
But could it be that the seafile-shared Dependency should be seafile-shared>=3.1.x? I got 3.0.4 installed and upgraded the seafile-server package to 3.1.1-2. The shared package wasn´t upgraded and the server wouldn´t start. After I upgraded the seafile-shared manually the server ran again. I think it was the same error as kiven.

Hinz commented on 2014-08-27 08:56

Upgrade from 3.0.4 to 3.1.1 ran pretty smoothly. Two questions though.
- Is the webdav module included in this build or has it anybody running?
- Am I the only one who still got Server Version: 3.0.0 shown in the Webinterface?

@calrama Thanks for the packages, makes it a lot easier!
But could it be that the seafile-shared Dependency should be seafile-shared>=3.1.x? I got 3.0.4 installed and upgraded the seafile-server package to 3.1.1-2. The shared package wasn´t upgraded and the server wouldn´t start. After I upgraded the seafile-shared manually the server ran again.

Hinz commented on 2014-08-27 08:48

Upgrade from 3.0.4 to 3.1.1 ran smoothly. Two questions though.
- Is the webdav module included in this build?
- Am I the only one who still got Server Version: 3.0.0 shown in the Webinterface?

@calrama Thanks for the packages, makes it a lot easier.

kiven commented on 2014-08-21 08:16

@calrama I had the same problme with a fresh install of seafile on my server. I did not retry on it because I reinstalled my server with CentOS 7.

calrama commented on 2014-08-18 20:41

@kiven Have you figured out your problem? I tried reproducing it in a clean machine and I was only able to do so when not using seahub-preupgrade. Have you tried doing the steps made inside seahub-preupgrade manually / had a look at the official seafile wiki? The seahub-preupgrade script does nothing more than do what is written there minus some stuff not applicable to the Archlinux seafile-server setup.

calrama commented on 2014-08-18 20:39

@cola4cube This has only happened to me when not using "makepkg" directly, i.e. using an AUR helper. Did you use makepkg or an AUR helper? If you used an AUR helper, please try using makepkg and pacman directly (e.g. after getting the package with yaourt -G seafile-server) and should you get the same error please say so; otherwise (if you already used makepkg/pacman), please tell me what the installed packages (direct dependencies of seafile-server only) were at the moment when you got that error.

@simeonfelis You probably have gunicon-python2 19.x installed. But as can be read earlier in the comments, to use seafile-server without --fastcgi, you need gunicorn-python2 of version < 19, so the dependency is valid as == 18.0. If you always use seafile-server with --fastcgi (as the example service does), then you don't need gunicon-python2 at all (as far as I know), but because both modes are mutually exclusive and either one can be the main mode of operation, this can not be an optional dependency. Furthermore, if you want gunicorn-python2 incorporated in the virtual environment, please provide a patch or a PKGBUILD I can include. The package should work the way it is if you use the standard Arch tools pacman/makepkg (no AUR helpers, I cannot speak for any issues with those), which is why I only see sense in maintaining, not enhancing at the moment. Again, however, if you can provide a working patch/PKGBUILD for this feature, I'd be more than happy to integrate it.

cola4cube commented on 2014-08-18 11:27

Yes, removing the version flag also helps 'gunicorn-python2'.

simeonfelis commented on 2014-08-18 11:23

In line depends of PKGBUILD, I replaced 'gunicorn-python2==18.0' with 'gunicorn-python2>=18.0', than the build started.

gunicorn-python2 is at version 19.x in aur. Let's face it: It very difficutl to maintain pip packages and system packages similtanously due to dependencies like that. With pip I could run pip2 gunicorn=18.0, but then the dependency would not be met for pacman.

Please include gunicorn-python2 into the virtual env (python jail?) that is already shipped with seafile.

cola4cube commented on 2014-08-18 09:33

Installation not possible.
==> Missing dependencies:
-> gunicorn-python2==18.0
==> Checking buildtime dependencies...
==> ERROR: Could not resolve all dependencies.

Guncorin is installed:

> $ pacman -Q | grep gunicorn
gunicorn-python2 18.0-0

kiven commented on 2014-08-13 14:21

@BumBum I've done it, as usual at each update

BunBum commented on 2014-08-13 12:53

@kiven I had the same error. You have to run seahub-preupgrade (see here https://wiki.archlinux.org/index.php/Seafile#Upgrading).

kiven commented on 2014-08-13 08:03

I cannot use it after upgrade to 3.1.1 :

Aug 13 10:04:47 seafile-admin[840]: self._wrapped = Settings(settings_module)
Aug 13 10:04:47 seafile-admin[840]: File "/usr/lib/seafile/seafileenv/lib/python2.7/site-packages/django/conf...init__
Aug 13 10:04:47 seafile-admin[840]: raise ImportError("Could not import settings '%s' (Is it on sys.path?): %...E, e))
Aug 13 10:04:47 seafile-admin[840]: ImportError: Could not import settings 'seahub.settings' (Is it on sys.pa...R_ROOT
Aug 13 10:04:47 seafile-admin[840]: Starting seafile-server...
Aug 13 10:04:47 seafile-admin[840]: Starting seahub in fastcgi mode...
Aug 13 10:04:47 seafile-admin[840]: Error: Failed to start seahub in fastcgi mode

calrama commented on 2014-08-12 15:13

@vit See my comment from 2014-07-05 18:59. Short version: Package was taken from me (without asking) and then broken such that it could not be built (whether this is still the case I do not know, but I informed the new maintainer and did not get a positive response). You can try using it, but if you do, please tell me should it work.

calrama commented on 2014-08-12 15:12

@vit See my comment from 2014-07-05 18:59. Short version: Package was taken from me (without asking) and then broken such that it could not be built (whether this is still the case I do not know, but I informed the new maintainer and did not get a positive response). You can try using it, but if you please tell me should it work.

vit commented on 2014-08-12 10:21

What is the difference between python2-djblets and python2-django-djblets? Why is the first one in deps, while the second one is in AUR?

isiachi commented on 2014-08-07 11:02

Missing dependency:
python2-dateutil

calrama commented on 2014-08-06 18:27

Upgrade as usual, but should you get issues about missing gunicorn-python2==18.0 despite it being installed, skip dependency check with makepkgs's/pacman's "-d" option.

calrama commented on 2014-07-11 11:36

@BunBum: Done.

@dev_arch: Good to hear. If you intent to use continue using seafile without --fastcgi in the future, you might want to open up an issue (or comment on if it already exists) at the seafile github repository about updating seafile to use gunicorn-python 19.0, so you don't have to use an older version.

dev_arch commented on 2014-07-11 11:22

@calrama: This works, full functionality again. Thank you!

BunBum commented on 2014-07-11 05:40

@calrama you should add this to the wiki ;-)

calrama commented on 2014-07-10 21:59

NOTICE: Since some of the dependencies are not currently available in this form in the AUR, here is a list of what you need to get this package running properly right now, and one possible way to obtain them:

[gunicorn-python2 == 18.0]
Package location: http://pkgbuild.com/git/aur-mirror.git/tree/gunicorn-python2?id=57609a11cc6f21064223e0957e48b9009451619b

[python2-djblets]
Package location: http://pkgbuild.com/git/aur-mirror.git/tree/python2-djblets?id=b0aaf90aeebdfe73e9a4030f47a587c99512d79b

calrama commented on 2014-07-10 21:50

@dev_arch:

I was able to reproduce the error on a clean Virtualbox VM and now I know why I never encountered it: it only happens when you start your server without --fastcgi (which I've never done before, since I use seafile behind nginx), because gunicorn is only used when starting that way.

Since the problem seemed to be with something relating to gunicorn, I tried looking into the responsible package's[1] past, which lead me to a marvelous page[2] that seems to mirror the AUR with git on a daily basis.

There I found that gunicorn-python2 was recently updated from 18.0 to 19.0[3] and inspecting this update revealed that the "gunicorn_django-python2" command was completely removed without substitution from gunicorn[4].

Apparently, seafile(-server) depends on version <=18.0 of gunicorn-python2, which is why I changed the depencency accordingly (although I made it == 18.0).
I may make the dependency on gunicorn-python2 optional when I have has time to look at it more, but for now, it stays as it is (mandatory, version 18.0).

tl;dr: It's working, see my next post for what you need.


[1] https://aur.archlinux.org/packages/gunicorn-python2/
[2] http://pkgbuild.com/git/aur-mirror.git/tree/
[3] http://pkgbuild.com/git/aur-mirror.git/log/gunicorn-python2/PKGBUILD
[4] http://pkgbuild.com/git/aur-mirror.git/commit/gunicorn-python2/PKGBUILD?id=b663f35cb02c00bb776eb82680ec1c0a736db9a8

dev_arch commented on 2014-07-10 19:05

@calrama (back from having been away a few days)
I just finished installing seafile-server 3.0.4 on a clean Arch install in VirtualBox. To my surprise this yielded the same result. I used yaourt and could try once more manually but doubt it will give any difference.
I took python2-djblets-0.8.2-1-x86_64.pkg.tar.xz and django-pipeline-1.3.24-1-any.pkg.tar.xz from the box that initially showed this problem. Could the problem lie with either of those?
It might not be just me after all. I am however quickly running out of clues now and any new idea will be gracefully accepted. :-)

calrama commented on 2014-07-06 22:52

@dev_arch: Hm, ok. Installing the 3.0.3 version of seafile-server should be as simple as getting all the relevant dependencies (libsearpc, ccnet, seafile-shared), changing all 3.0.4 to 3.0.3, calling makepkg -s with skip checksum (or change them yourself), and installing them one by one. I'm not sure whether downgrading seahub will work, but I'd suggest using the minor upgrade script. Sorry I'm not able to help more, but I do not keep any binaries cached (I use yaourt).

dev_arch commented on 2014-07-06 19:44

@calrama: No joy (I cheated with yaourt though, does that count? My evening draws to a close)

> The dependency `django-pipeline` demands version `>=1.3.23`but the most recent version is `1.2.24-1`.
This came before re-installing django-pipeline so maybe not that strange after all.

Aura has a known glitch, related to the changes in AUR, which does manifest itself on this machine (and not my pc): https://github.com/aurapm/aura/issues/246#issuecomment-48098404

I shouldn't have removed version 3.0.3 from my cache, maybe a fresh install with that works. Do you know where to find that or can you provide me with it? Soon I might be in luck with the next version, maybe with rumpelsepp's initiative.

calrama commented on 2014-07-06 18:35

@dev_arch: Damn, that's a lot of data. But more to the point: Could you try not using aura for the building, but doing it manually (i.e. download the source tarball, unpack it, run makepkg -s, and install, respective for all the dependencies, - except with djblets, of course)? Because if you installed django-pipeline with the PKGBUILD I posted, then you should have django-pipeline == 1.3.24 installed and aura's complaint makes no sense whatsoever to me.

> Installing collected packages: django
> Found existing installation: Django 1.6.5
> Not uninstalling Django at /usr/lib/python2.7/site-packages, outside environment /usr/lib/seafile/seafileenv
> Successfully installed django

Not sure about that, since my last upgrade (to 3.0.4) has been a while ago, but I think those lines aren't problematic (but don't quote me on that).

I'm sorry about not having any insight, but I simply have not encountered this problem or anything like it and if I had to take a wild guess it might have something to do with you using aura and the recent changes in AUR, but that's a real long shot.

@Elektro121: That seems to be the same issue @dev_arch ran into, so you could read his posts and my replies, but in short: I don't know why it's happening and I haven't been able to reproduce it, sorry. But if you find anything wrong with the package / how to fix it, I'll gladly add it.

dev_arch commented on 2014-07-06 18:11

@calrama
New evening, new rounds. I went for complete seafile-server re-installation. Without backup of the data though, which is not practical at nearly 1.5TB.
Eventually I tried by removing every dependency (without python itself) en re-installing from there. I have python-djblets in my package cache and build django-pipeline with the PKGBUILD you linked to on https://aur.archlinux.org/packages/python-django-pipeline/ I then created a new instance as per the wiki but regretfully the result is the same.

For completeness sake:
$ sudo aura -A seafile-server
aura >>= Determining dependencies...
aura >>= Dependency checking failed for these reasons:
The dependency `django-pipeline` demands version `>=1.3.23`but the most recent version is `1.2.24-1`.

And later when having installed django-pipeline separately during the installation of seafile-server:
Installing collected packages: django
Found existing installation: Django 1.6.5
Not uninstalling Django at /usr/lib/python2.7/site-packages, outside environment /usr/lib/seafile/seafileenv
Successfully installed django

At the moment I'm left hoping for an insight from you. Meanwhile I'll try and install on a virgin Vbox Arch.
Your efforts are much appreciated regardless!

Elektro121 commented on 2014-07-06 14:57

Problem on seafile-admin

def start_seahub_gunicorn():
argv = [
PYTHON,
'/usr/bin/gunicorn_django-python2',
'-c', conf[CONF_SEAHUB_CONF],
'-b', '0.0.0.0:%s' % conf[CONF_SEAHUB_PORT],
]

info('Starting seahub...')
env = get_seahub_env()
if run_argv(argv, cwd=conf[CONF_SEAHUB_DIR], env=env) != 0:
error('Failed to start seahub')

info('Seahub running on port %s' % conf[CONF_SEAHUB_PORT])

usage: gunicorn_django-python2 [OPTIONS] [APP_MODULE]
gunicorn_django-python2: error: No application module specified.

The syntax of the app changed, wtf Oo

Elektro121 commented on 2014-07-06 14:55

Problem on seafile-admin

def start_seahub_gunicorn():
argv = [
PYTHON,
'/usr/bin/gunicorn_django-python2',
'-c', conf[CONF_SEAHUB_CONF],
'-b', '0.0.0.0:%s' % conf[CONF_SEAHUB_PORT],
]

usage: gunicorn_django-python2 [OPTIONS] [APP_MODULE]
gunicorn_django-python2: error: No application module specified.

The syntax of the app changed, wtf Oo

Elektro121 commented on 2014-07-06 14:36

I have the same probem as dev_arch, searching for a solution ^^

calrama commented on 2014-07-05 20:16

@dev_arch: I'm sorry, but f that did not fix it have no idea why you get this error. On the other hand, I have uninstalled and reinstalled seafile (even with full pacman -Rsunc) several times without losing any data. But I would suggest that you backup the entire seafile instance folder (the /srv/seafile/example.org directory), just to be sure. Regarding reinstalling: Make sure you do not uninstall python2-djblets, as I cannot build the current replacement for it (it was renamed, see my reply to @theflyingfool).

dev_arch commented on 2014-07-05 19:21

@calrama: As far as I'm aware I have. At the same time I appear to be alone with this problem, which does make me suspect. :-)
Searching for a solution I already tried your suggestion, but then I get:
usage: gunicorn_django-python2 [OPTIONS] [APP_MODULE]
gunicorn_django-python2: error: No application module specified.

Other then new suggestions from you I'm close to uninstalling seafile and reinstalling while keeping my fingers crossed that I manage to keep accounts and data.

calrama commented on 2014-07-05 18:59

@theflyingfool: It was taken from me and renamed to "python2-django-djblets" (see https://aur.archlinux.org/pkgbase/python-django-djblets/). I forgot to update the dependency, sorry; I will not update it now, however, as I cannot build the new "python2-django-djblets", see my post in its comment section.

@dev_arch: Have you followed the upgrading section on the wikipage (https://wiki.archlinux.org/index.php/Seafile) precisely? It seems to me like somehow your packages are looking for /usr/bin/gunicorn_django-python2, when they should be looking for /usr/bin/gunicorn-python2 (which is part of gunicorn-python2, a dependence of seafile-server). I would suggest making the following symlink: "ln -s /usr/bin/gunicorn-python2 /usr/bin/gunicorn_django-python2"

dev_arch commented on 2014-07-05 18:45

After the last upgrade (3.0.3 -> 3.0.4) I haven't been able to get seahub started again. All searching and reinstalling (without completely uninstalling) have been fruitless so far. Does the error message I get when starting seafile-server give somebody a clue to what's amiss? I'm at a loss at the moment.

/usr/lib/seafile/seafileenv/bin/python2: can't open file '/usr/bin/gunicorn_django-python2': [Errno 2] No such file or directory
Error: Failed to start seahub

Thanks in advance!

theflyingfool commented on 2014-07-05 16:30

I might be missing something but tracking down the dependency python2-djblets, seems to be giving me issues.

calrama commented on 2014-06-25 17:09

@rumpelsepp: You didn't bother me at all, I just wanted to make my position clear, that's all. No need to apologise, either, criticism is a vital part of a thriving development community and should you get it to work right, you'll have been right. For me it's just that I've already put a lot of time into packaging Seafile, so I'm just happy that it works (and I don't have to use proprietary services anymore); if I came across to harsh, I apologise. In any case, give the word, if/when you have something you want me to include.

rumpelsepp commented on 2014-06-25 15:31

@calrama
I didn't want to bother you and I might have chosen the wrong words, I'm sorry! :) I will workout an improved version of the PKGBUILD(s), but this will take a while as I have to read through the docs in detail.

calrama commented on 2014-06-25 15:21

@rumpelsepp: I am aware of the Arch way, I was not debating whether it's good/conforming to the standard, but whether it's weird and "mixing things up" - imho quite a different thing. But that discussion won't lead us anywhere productive, so I'm leaving it at that, as well.
Back to the actual topic, you are welcome to post a version without virtualenv - should that be feasible - and if you can vouch that you have tested it, I will include it.

rumpelsepp commented on 2014-06-25 10:10

@calrama:
It's simple, you install a dependency somewhere on the system using a virtualenv and so it's not tracked by pacman. Either install everything in a virtualenv or provide a global package including its dependencies. Mixing things up just to fix problems never is a good idea and it does not actually follow KISS. [1]

But I will stop grumbling and will help with fixing this. :)

[1]: https://wiki.archlinux.org/index.php/The_Arch_Way

kiven commented on 2014-06-25 09:53

@calrama : Yes, I did it each time I upgrade the package (I did it only for french, but i could be nice for each language).

calrama commented on 2014-06-25 09:46

@rumpelsepp: I don't really see what's "weird" about virtualenv, but I'm always happy to reduce the dependencies, should you get seafile-server to work without it, Otherwise, I got the email notifications regarding the other packages, I will reupload them later today (whyever could they not just run a script that adds dummy .AURINFO to all the AUR packages...)

rumpelsepp commented on 2014-06-25 09:20

@calrama
I have looked at the scripts:

- the virtualenv is only used to install django < 1.6 and djangorestframwork which could eventually be fixed with the instructions from google groups
- the configure script takes PYTHON=/usr/bin/python2, this should be fine
- with a shebang-patch we could get rid of these confusing sed calls which are in the wrong function (should be prepare).
- we have to patch these shebangs:

$ grep /usr/bin/env python -r .
./tools/seafile-admin:#!/usr/bin/env python
./tests/test-transfer.py:#!/usr/bin/env python
./tests/test-share.py:#!/usr/bin/env python
./setupwin.py:#!/usr/bin/env python
./scripts/upgrade/db_update_1.3_1.4.py:#!/usr/bin/env python
./scripts/sqlite2mysql.py:#!/usr/bin/env python
./scripts/build/gen-deb-src.py:#!/usr/bin/env python
./scripts/build/build-server.py:#!/usr/bin/env python
./scripts/build/build-server-src.py:#!/usr/bin/env python
./scripts/build/build-msi.py:#!/usr/bin/env python
./scripts/build/build-deb.py:#!/usr/bin/env python
./scripts/build/build-cli.py:#!/usr/bin/env python
./app/seaf-cli:#!/usr/bin/env python

So I think it should be possible to remove this weird virtualenv hack. I will have a deeper look and create a patch later. But I think we have to test it and play around a bit, so I suggest doing this on github or something similar. :)

Furthermore I have posted comments to some seafile-server dependencies which do not have .AURINFO files. And at last I have sent a message to aur-info [1] about django-pipeline which is outdated and maybe has the wrong package name. I will adopt it or create a new package instead; I will let you know when I get news.

[1]: https://mailman.archlinux.org/pipermail/aur-general/2014-June/028966.html

calrama commented on 2014-06-25 07:56

@rumpelsepp: Archlinux "python" is Python 3. Seafile explicitly gets the "python" binary (or at least, it did at the time the virtualenv was introduced, which was not done by me, by the way, but by the previous maintainer), expects it to be Python 2, and runs its scripts with it, so the only way to get it to work was to run it in an environment where "python" corresponds to Python 2 (which is what virtualenv does) and I see nothing in your link that addresses this issue (correct me if I'm wrong, of course).

If you want to create a patch for seafile-server to run without virtualenv you're welcome to do so; should it work well, I could include it, but personally I don't consider the little benefit of not using virtualenv worth the amount of code-delving necessary to get it to work.

rumpelsepp commented on 2014-06-25 06:10

What is the purpose of this virtualenv thing in seafile-server.install? You could create a patch, see here: https://groups.google.com/d/msg/seafile/bwbcBQ5ASfE/WmVErc_cjXsJ

calrama commented on 2014-06-19 10:28

@kiven: Is that something that has to be done after each seahub upgrade? If so, I could try to include it in the seahub-preupgrade script.

kiven commented on 2014-06-19 09:25

here is a tip to translate seahub. You need to go to your seahub instance directory, and go to locale/<LANGUAGE>/LC_MESSAGES and then msgfmt -o django.mo django.po

BunBum commented on 2014-06-18 13:05

@calrama thank you. Everything works fine!

calrama commented on 2014-06-18 11:32

@BunBum: Update pushed, should work, please test.

calrama commented on 2014-06-13 14:18

@BunBum: I made that issue^^ Albeit with the wrong github account >.>

BunBum commented on 2014-06-13 14:15

Oh ok sorry. I forgot that the PKGBUILD gets a file called *-server.tar.gz. There is also already a issue about that typo: https://github.com/haiwen/seahub/issues/235
Hopefully they will fix it ;-)

calrama commented on 2014-06-13 14:08

@BunBum: And that is precisely why I wrote "once they fixed the seahub tag" and not "once they make a tag for 3.0.4". I'm not bloating up the "seahub-preupgrade" script to deal with the typo, which is likely going to be fixed, at which point I'd need to remove the handling from "seahub-preupgrade" again, anyway.

BunBum commented on 2014-06-13 12:53

Is it not this one? https://github.com/haiwen/seahub/releases/tag/v3.0.4-serve (there is only a typo in the name)

calrama commented on 2014-06-13 12:52

Will upload the updated version once they fixed the seahub tag[1].

[1] https://github.com/haiwen/seahub/tags

calrama commented on 2014-06-05 20:27

I am not familiar with WebDAV, but if you provide me with a patch that deals with everything needed from this package to get it working (and test it yourself as I'm not going to install WebDAV on my server) I'll include it.

audax commented on 2014-06-05 18:40

I found out that the module for WebDAV is separate and must also be build when seafile is built from source:
https://github.com/haiwen/seafile/issues/565

They did not yet update their docs to build the project from source to include seafdav.

calrama commented on 2014-06-05 10:06

@audax: This doesn't seem to be a packaging issue (although I'm not sure of that), in which case you better ask the developers at https://github.com/haiwen/seafile/issues. I don't use WebDAV and have no idea as to how it is integrated into Seafile. There is, however, a page on the Seafile wiki about using WebDAV with Seafile, so you might find what you're looking for there: https://github.com/haiwen/seafile/wiki/Seafile-WebDAV-Server

audax commented on 2014-06-05 09:13

Where should I put the seafdav.conf to enable WebDav? The controller does not find in conf/seafdav.conf which it at the same level as ccnet/.

RubenKelevra commented on 2014-05-27 07:29

sorry, accidentally flagged as out of date

obscure1910 commented on 2014-05-20 19:59

Hi,

Ic an not start the seafile-server as service. I followed the instructions on this page https://wiki.archlinux.org/index.php/Seafile#Installation

journalctl -xn prints out:


May 20 21:46:00 alarmcbi systemd-coredump[4371]: Process 4370 (seafile-control) dumped core.
-- Subject: Process 4370 (seafile-control) dumped core
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Documentation: man:core(5)
--
-- Process 4370 (seafile-control) crashed and dumped core.
--
-- This usually indicates a programming error in the crashing program and
-- should be reported to its vendor as a bug.
May 20 21:46:00 alarmcbi systemd[1]: seafile-server@example.org.service: control process exited, code=exited status=1

I entered: systemctl start seafile-server@example.org

Armadillux commented on 2014-05-02 14:51

Affirmative, worked like a charm! Thank you calrama!

calrama commented on 2014-05-02 09:48

@BubBum: Nice, thank you for testing. I wrote the steps down from memory^^

BunBum commented on 2014-05-02 09:32

@calrama thank you. I've tested these steps and everything worked. Great work!

Armadillux commented on 2014-05-02 08:56

@calrama: Nice work, i'll upgrade my server now and report on the results.

calrama commented on 2014-05-02 06:56

@BunBum: Done, though it might need some proof-reading.

BunBum commented on 2014-05-02 05:37

@calrama could you put this to your Wiki page https://wiki.archlinux.org/index.php/Seafile ?

Maribu commented on 2014-04-30 18:37

Excellent work! Thanks for the update instructions!

calrama commented on 2014-04-30 11:53

This package now comes with a bash script 'seahub-preupgrade', that is NOT used automatically anywhere. It exists solely to unify most steps of the procedure to upgrade seahub after a seafile upgrade. With this, the steps to upgrade seafile are now like this:
1. Stop seafile, e.g. # systemctl stop seafile-server@example.org
2. Upgrade the seafile-server package
3. Repeat for all for your seafile-server's on the target system (e.g. example.org, foo.bar, etc.):
a. Change directory to the server's 'seafile-server' subdirectory, e.g. '$ cd /srv/seafile/example.org/seafile-server'
b. Become the user the seafile server runs at (who should own all the directores and files below e.g. /srv/seafile), e.g. '$ sudo -u seafile -s'
c. Run the preupgrade script (Or do the steps by hand, see seafile's wiki for that): '$ seahub-preupgrade'
d. Run the appropriate seafile/seahub upgrade scripts from the upgrade subdirectory, i.e. '$ ./upgrade/minor-upgrade.sh' for an x.y.a to x.y.b (a < b) upgrade (minor) and '$ ./upgrade/upgrade_x.y_z.w.sh' for an x.y.a to z.w.b (x < z || y < w) upgrade (major).
4. Start seafile, e.g. # systemctl start seafile-server@example.org

Important note: I have tested this on my own server only so far, feedback would thus be welcome. Also, note that the seahub-preupgrade script has no error detection other than exiting if it's not run in a directory named 'seafile-server', so use it at your own risk.

calrama commented on 2014-04-30 11:53

This package now comes with a bash script 'seahub-preupgrade', that is NOT used automatically anywhere. It exists solely to unify most steps of the procedure to upgrade seahub after a seafile upgrade. With this, the steps to upgrade seafile are now like this:
1. Stop seafile, e.g. # systemctl stop seafile-server@example.org
2. Upgrade the seafile-server package
3. Repeat for all for your seafile-server's on the target system (e.g. example.org, foo.bar, etc.):
a. Change directory to the server's 'seafile-server' subdirectory, e.g. '$ cd /srv/seafile/example.org/seafile-server'
b. Become the user the seafile server runs at (who should own all the directores and files below e.g. /srv/seafile), e.g. '$ sudo -u seafile -s'
c. Run the preupgrade script (Or do the steps by hand, see seafile's wiki for that): '$ seahub-preupgrade'
d. Run the appropriate seafile/seahub upgrade scripts from the upgrade subdirectory, i.e. '$ ./upgrade/minor-upgrade.sh' for an x.y.a to x.y.b (a < b) upgrade (minor) and '$ ./upgrade/upgrade_x.y_z.w.sh' for an x.y.a to z.w.b (x <z || y < w) upgrade (major).
4. Start seafile, e.g. # systemctl start seafile-server@example.org

Important note: I have tested this on my own server only so far, feedback would thus be welcome. Also, note that the seahub-preupgrade script has no error detection other than exiting if it's not run in a directory named 'seafile-server', so use it at your own risk.

calrama commented on 2014-04-30 11:52

This package now comes with a bash script 'seahub-preupgrade', that is NOT used automatically anywhere. It exists solely to unify most steps of the procedure to upgrade seahub after a seafile upgrade. With this, the steps to upgrade seafile are now like this:
1. Stop seafile, e.g. # systemctl stop seafile-server@example.org
2. Upgrade the seafile-server package
3. Repeat for all for your seafile-server's on the target system (e.g. example.org, foo.bar, etc.):
a. Change directory to the server's 'seafile-server' subdirectory, e.g. '$ cd /srv/seafile/example.org/seafile-server'
b. Become the user the seafile server runs at (who should own all the directores and files below e.g. /srv/seafile), e.g. '$ sudo -u seafile -s'
c. Run the preupgrade script (Or do the steps by hand, see seafile's wiki for that): '$ seahub-preupgrade'
d. Run the appropriate seafile/seahub upgrade scripts from the upgrade subdirectory, i.e. '$ ./upgrade/minor-upgrade.sh' for an x.y.a to x.y.b (a != b) upgrade (minor) and '$ ./upgrade/upgrade_x.y_z.w.sh' for an x.y.a to z.w.b (x != z || y != w) upgrade (major).
4. Start seafile, e.g. # systemctl start seafile-server@example.org

Important note: I have tested this on my own server only so far, feedback would thus be welcome. Also, note that the seahub-preupgrade script has no error detection other than exiting if it's not run in a directory named 'seafile-server', so use it at your own risk.

calrama commented on 2014-04-30 11:51

This package now comes with a bash script 'seahub-preupgrade', that is NOT used automatically anywhere. It exists solely to unify most steps of the procedure to upgrade seahub after a seafile upgrade. With this, the steps to upgrade seafile are now like this:
1. Stop seafile, e.g. # systemctl stop seafile-server@example.org
2. Upgrade the seafile-server package
3. Repeat for all for your seafile-server's on the target system (e.g. example.org, foo.bar, etc.):
a. Change directory to the server's 'seafile-server' subdirectory, e.g. '$ cd /srv/seafile/example.org/seafile-server'
b. Become that the user the seafile server runs at (who should own all the directores and files below e.g. /srv/seafile), e.g. '$ sudo -u seafile -s'
c. Run the preupgrade script (Or do the steps by hand, see seafile's wiki for that): '$ seahub-preupgrade'
d. Run the appropriate seafile/seahub upgrade scripts from the upgrade subdirectory, i.e. '$ ./upgrade/minor-upgrade.sh' for an x.y.a to x.y.b (a != b) upgrade (minor) and '$ ./upgrade/upgrade_x.y_z.w.sh' for an x.y.a to z.w.b (x != z || y != w) upgrade (major).
4. Start seafile, e.g. # systemctl start seafile-server@example.org

Important note: I have tested this on my own server only so far, feedback would thus be welcome. Also, note that the seahub-preupgrade script has no error detection other than exiting if it's not run in a directory named 'seafile-server', so use it at your own risk.

Maribu commented on 2014-04-27 16:41

As acieroid said, your package needs gunicorn-python2 and not gunicorn. Also the "seafile-admin.patch" patch file needs to be updated: The bin path for the gunicorn-python2 package used in seafile-admin is "/usr/bin/gunicorn_django-python2", not "/usr/bin/gunicorn_django".

acieroid commented on 2014-04-27 08:31

I think you should depend on gunicorn-python2 instead of gunicorn (at least I needed to install gunicorn-python2 to get seafile-server to work).

calrama commented on 2014-04-27 08:19

If you use the --user option to systemd it is supposed to work. The workaround you describe has already been discussed here, though (and it is what I personally use, since I don't want to setup --user).

ElNick commented on 2014-04-27 08:10

systemd's %h resolution to seafile user's homedir in seafile-server@.service no longer works. Hardcoding the homedir into the file fixes problem with launching seafile's fcgi for me.

calrama commented on 2014-04-24 12:49

Forget my earlier reply (removed it). I get the same 'Page unavailable' problem. I didn't notice it before, since I don't actually use the webinterface anymore since you can do most of the stuff in the client nowadays. I'll look into it.

calrama commented on 2014-04-24 12:45

That is strange. Did you follow this update procedure?
1. Stop seafile-server
2. Update the seafile-server package
3. Download newest seahub and run the upgrade scripts
4. Try to start seafile-server
If so, you might want to remove all the related packages and rebuild and install from scratch (this shouldn't touch your libraries) in this order: libsearpc, ccnet, seafile-shared, seafile-server.
If neither helps, I don't know what could be the problem, as it works for me. But if you find something wrong in any of the PGKBUILDs that just didn't trigger in my tests, I'll try to fix it.

BunBum commented on 2014-04-24 12:36

After some re-installs, restarts, re-syncs and so on it seems to work now with the local client. Only the webinterface gives me a "Page unavailable" if I want to open a library.
Strange...

BunBum commented on 2014-04-24 11:57

Since the last update my seafile installation is not working anymore. I don't know if it was the latest seafile-shared or the latest seafile-server update. I also tried a completely fresh new installation of everything (including the latets seahub v2.2.1-server). No success.
I can open the seahub webinterface and I can login. But if I open a library I get a "Page unavailable". My local installed seafile client also tells me a "server error" but nothing more.

calrama commented on 2014-04-22 19:25

So was I, but dealing with it is a lot less work than trying to get them to follow a consistent release process and clear versioning, because it would involve getting them a build master and eliminating the seafile repo, replacing it with two new repos, one for the shared components and one for the actual server. They also need to overhaul the design of seahub, because it prevents it from being distribution packaged.

BunBum commented on 2014-04-22 19:17

Ok thank you for clarification. I'm going crazy with their versioning! ;-)

calrama commented on 2014-04-22 19:14

Please have a closer look. Server tags contain the keyword "server". All tags not containing "server" have nothing to do with the server component, but with the shared components between server and client, which the client 3.*.* release needs (and I'll update the client packages tomorrow). I specifically stated
> The 3.*.* tags are all either for testing, or client-specific
which is the case.

BunBum commented on 2014-04-22 19:11

That's not true. I can see a 3.0.2 tag. Without any testing. See here: https://github.com/haiwen/seafile/releases/tag/v3.0.2
But I don't know the difference between the 2.* branch and 3.*...

BunBum commented on 2014-04-22 19:09

That's not true. I can see a 3.0.2 tag. Without any testing. See here: https://github.com/haiwen/seafile/releases/tag/v3.0.2

calrama commented on 2014-04-22 19:07

I don't really understand the point of your question, as there's no version later than 2.2.1 officially released for the server: https://github.com/haiwen/seafile/tags
The 3.*.* tags are all either for testing, or client-specific. If there's a new version released, I'll update the package, as I've done up till now.

BunBum commented on 2014-04-22 18:37

Are there any update plans to version 3.0.*?

jprjr commented on 2014-03-19 00:14

I didn't even think to look in the wiki. Thanks!

calrama commented on 2014-03-18 21:31

jprjr: Hey, that's intentional, as there's no way to know where you want the seafile user's home directory to be (it could be /home/seafile, /srv/seafile, etc.}. See earlier discussion here and https://wiki.archlinux.org/index.php/Seafile on how to setup a Seafile server.

jprjr commented on 2014-03-18 19:42

Hi there - it looks like the systemd service file is expecting a seafile user to exist, but I don't think the package is creating the seafile user.

firecat53 commented on 2014-03-09 22:30

Reported the '%h' bug here: https://bugs.archlinux.org/task/39258

Scott

calrama commented on 2014-03-07 21:37

@gergan_penkov: I'm not overly familiar with systemd, so if you really think it's a bug, could you report it?

gergan_penkov commented on 2014-03-07 21:32

I suspect that this is a bug in systemd and probably someone should report it. In the man-page there is a note about %h - "Similar to "%U", this specifier is not available for units run by the systemd system instance, unless the configured user is the root user." But we use a valid user, probably some of the changes in the last version was overeager?

BunBum commented on 2014-03-06 11:38

I am not experienced enough but why should they remove the %h variable? Is it really deleted or is it only renamed to %home or something?

calrama commented on 2014-03-06 10:41

Thanks for reporting the problem, I haven't updated my server to 210, yet, so I hadn't run into it. Is either of you two aware of any fix / workaround, that I could include in the package's service, because replacing %h with the correct directory is something only the end-user can do?

gergan_penkov commented on 2014-03-06 10:19

I can confirm, that it does not work with 210-2.

The %h is not correctly resolved and that's why the service could not start. If I replace the %h with the correct directory, seafile starts and works. Probably connected with http://cgit.freedesktop.org/systemd/systemd/commit/?id=487060c2394b7703e59650ef332053645ffae2a3 But I don't see any sense in the error message as %h should be absolute path.

BunBum commented on 2014-03-05 17:26

With the latest systemd update to version 210-2 the service does not start anymore. The status of the service indicates a "Error: "seafile-server/" not found in current directory". With the previous version of systemd everything worked fine.

BunBum commented on 2014-02-21 07:16

Ok thank you. I will have a look at the GitHub issue.

calrama commented on 2014-02-20 19:13

No problem, and I am also a bit sad about that, though more annoyed than sad. Anyway, you can always monitor or post to the issue I linked, that is where I post when I notice there's a new binary release without corresponding sources.

BunBum commented on 2014-02-20 18:26

Ah ok ok I understand. I thought the download link was a source tarball. That explains a lot. Thank you for clarifying. Big sorry!
So I (we) have to wait for a source releas from the seafile crew... I am sad that the Seafile developers are not accurate with their source code.

calrama commented on 2014-02-20 17:56

> so you would have to change it in your PKGBUILD
As I already explained, your new download link is a binary blob, not a source tarball!? This is not a binary package (it's seafile-server, not seafile-server-bin), so that blob by itself, without any accompanying sources gives me nothing I can actually use - it's neither a new download URL (for sources I can use), nor a changelog (for sources I can use) relevant to this package (yet!). I do not wish to - once again - repeat the discussion as to what constitutes a source release, because that's up to the Seafile developers, *not* me. Regarding this, please refer to this issue where you will find the last statement from the Seafile developers on this subject I know of:
https://github.com/haiwen/seafile/issues/406
As a short rule of thumb: Flagging out-of-date should afaik only be done, if there's a new version available to which the package in question can be updated. That is not the case, as - by the Seafile developers own rules - there is no released source relating to that binary blob.

BunBum commented on 2014-02-20 15:50

My question was only because in the PKGBUILD file you download the sources from GitHub. The new download link here (http://seafile.com/en/download/) points to https://bitbucket.org/haiwen/seafile/downloads/seafile-server_2.1.5_i386.tar.gz so you would have to change it in your PKGBUILD.
So I have a new download URL and a changelog (https://seacloud.cc/group/3/wiki/server-changelog/) for a new version. This is not enough for a new release? Only a GitHub tag is relevant to flag this package as out dated?

calrama commented on 2014-02-20 15:13

Please don't take this the wrong way, but that's a question for the Seafile developers (open up a github issue there?), not for the Archlinux package maintainer. I am not involved in the Seafile project other than packaging it and reporting issues, so I have no more knowledge / influence on their internal decision making / future decisions. However, based on their bitbucket repository (which I found based on your question) https://bitbucket.org/haiwen/seafile, which contains no source and only binary downloads, I'd hazard a guess to "no, they aren't moving", but please take that with a grain of salt.
Also, please read the previous comments for the whole story, but the short version is, that Seafile developers tend to forget to tag their releases, so the packages are not out of date until they do so.

BunBum commented on 2014-02-20 14:07

https://seacloud.cc/group/3/wiki/server-changelog/ and http://seafile.com/en/download/ indicates that version 2.1.5 is out now. But the downloadlink points to bitbucket. Are they moving away from GitHub?

BunBum commented on 2014-02-14 23:45

Please add "armv7h". I've tested it and it worked nicely.

calrama commented on 2014-01-28 10:35

It doesn't necessarily go into /srv. Mine for example goes into /home/seafile/. Any script made for that purpose would either place further restrictions on how you can setup your server, or become more complex for any restriction it doesn't make. In order to do it properly, you'd have to write a fairly complex script that handles both first installations as well as upgrades, because if you only do the first installation, you'll give be inconsistent. The truth - as I see it - is that you could write such a thing in probably a day (at most two), while the gain would be on average (my guess on how long it takes me) 1-2 minutes for the user (for each installation/update).
The main reasons I haven't done that so far are that on the one hand I'd need to invest time to workaround a problematic design of Seafile - it's something they should fix in upstream imho and on the other hand that you're the first you has asked this. Everyone else (including me) didn't seem to have any problem with seahub not being installed automatically. While I can't speak of anyone else, but to me Arch is still a distrubtion where a level of fiddling is to be expected. However, if there really is a significant demand for such a thing (and it's not just you) I could look into adding it as time permits.

diensthunds commented on 2014-01-28 05:57

@calrama fair enough, is there not some way to include a post install script to finish off the installation of seahub? Since it is going into /srv/ anyways?
I didn't notice the -testing for 2.1.4 I was just looking at the version on the download page.

calrama commented on 2014-01-28 04:07

Great >.> I wrote a very long explanation and then pressed F5. Sorry, it'll keep it short this time:
It isn't included, because it can't be installed system-wide. Every seahub folder can only be used with exactly one seafile server while the binaries produces by this package can be used by as many instances of seafile as you want (no binary blob duplication). As far as I am aware, that's an explicit design decision on their part, which makes it impossible for us to package seahub (as pacman install packages system-wide).
Regarding the update: Yes and Nope, upstream version is technically still 2.1.3. 2.1.4 is the testing version (as indicated by the "-testing" suffix). The seafile developers tend to push binaries before sources.

diensthunds commented on 2014-01-28 01:47

Latest upstream version has bumped up to 2.1.4

diensthunds commented on 2014-01-27 21:12

The first comment wasn't worded the way I wanted to get the info across.
I didn't install seahub as I still don't understand why it wasn't included in the package, if you do the download from the actual website everything is included and you can set up from there.
I don't mind fidling and even had to do that from the official web sites download.
I've read through the wiki link you provided and it still seams that you have to do both download the official package to use as a setup and the aur package just to install the binaries. This seems sort of redundant.

calrama commented on 2014-01-27 10:03

Apparently I was wrong about the missing work-in-progess marking. I've added a new page "Seafile" to the ArchWik. It currently contains the minimal information you should require to setup seafile-server successfully: https://wiki.archlinux.org/index.php/Seafile

calrama commented on 2014-01-27 09:46

Apparently I was wrong about the missing work-in-progess marking. I'll post a link to the soon-to-be-online wiki page here.

calrama commented on 2014-01-27 07:50

@diensthund: Also, you seem to have deleted your first post (which requires information needed to understand your second one correctly), so I'll keep the response to that short:
The instructions from the seafile-wiki do work if you simply omit the parts that don't apply (and change some of the paths to where this package installs to). It's not overly hard (this is Archlinux, not Ubuntu, so a certain level of manual fiddling and tweaking shold be expected), but I understand that a wiki page entry towards that end would help. But as I said before, the ArchWiki does not have an option (that I could find) to mark a new page as (work-in-progress), so I need to have the entire page in tip-top shape before posting it there in the first place. Here is a (very) early prototype, that contains ALL the commands necessary to setup seafile server on Arch:
http://pastebin.com/raw.php?i=yk0g1QHW

calrama commented on 2014-01-27 07:36

@diensthunds: Have you followed the sseafile setup guidelines? Because it sounds to me like you did not install seahub, so I'll repost my second-to-last post here again, as it contains all the info you should need:
You essentially follow the seafile guide from this point onwards to setup seafile (leaving out the parts that don't apply):
https://github.com/haiwen/seafile/wiki/Build%20and%20Deploy%20Seafile%20Server%20from%20source#prepare-the-directory-layout
You won't have/setup the "src" subdirectory as everything but seahub was installed at system-level. To get the latest seahub version you look at the git tags here
https://github.com/haiwen/seahub/tags
and select the one matching with package's version, e.g. right now "v2.1.3-server" and download it, set it up in the directory layout described in the first link, and finally do the "seafile-admin setup" stuff. When upgrading, you follow this:
https://github.com/haiwen/seafile/wiki/Build%20and%20Deploy%20Seafile%20Server%20from%20source#upgrade-the-seafile-server
Also, the upgrade scripts are installed by this package under "/usr/share/seafile-server/upgrade", so use that instead of "seafile-{version}/scripts/upgrade" in the cp -rf line when upgrading.

diensthunds commented on 2014-01-27 03:41

seafile-admin setup gives Error: "seafile-server/seahub/" not found. Please download seahub first.
systemctl start seafile gives Failed to issue method call: unit seafile.service failed to load: No such file or directory

I'm stuck now not being able to get seafile to run or even setup.

diensthunds commented on 2014-01-27 03:33

I'm a bit confused as to how to get things set up and running once the packages are installed.
Following the wiki at the seafile website doesn't work as that requires you to set up the directory structure and enter into directories that don't exist from this package installation.
There also isn't any other instruction as to how to get the service running using systemctl.

calrama commented on 2014-01-27 02:03

I have the seafile-server working on x86_64 Arch exactly with these PKGBUILDs here. Regarding updating, if you haven't already, you could look at the links from my last post. The proper procedure is in short:
1) Stop the seafile server
2) Update seafile-server package
3) Update seahub (manually)
4) Run upgrade scripts (manually, they get put into /usr/share/seafile-server/upgrade)
5) Attempt to start the seafile server again
I do not know why you needed to install the captcha module, because I have had no problems so far with this version (that includes the seafile-server package and the manually setup seahub). Did you perhaps change any options (e.g. activate a feature) that would require it?

Also, that log dosen't look complete to me (I can't see any actual error, just the middle of the trace), so I can't help you there. If you're using x86 or x86_64, my best guess would be that there's something not quite right with your nginx config for seahub; I can't comment on what might be wrong for ARM, but there were users who confirmed that it works like this there.

I'm sorry I can' be of much more help here, but you might want to open an issue with the seafile developers (here: https://github.com/haiwen/seafile/issues?state=open). If you to find some problem with the PKGBUILD I'd be happy to include a fix, but as it stands right now, I can't reproduce your problems.

Narigo commented on 2014-01-27 01:40

When upgrading this package, I had trouble restarting it, due to some seahub error. `seafile-admin setup` and `systemctl start seafile` both gave me an `ImportError: No module named captcha`.

I tried installing a captcha module by executing `pip2 install django-recaptcha`, which let me start the seafile server again. It looks like the regular seafile server works again.

But trying to open seahub now yields an "Unhandled Exception" page ("An unhandled exception was thrown by the application.", no more info) in the browser and `seahub.error.log` shows this: http://pastebin.com/LZV8fn2j

Maybe there are some new dependencies I'm missing some dependencies? It worked before the upgrade (from 2.0 to 2.1) so maybe there were a few new things introduced with seahub 2.1 and I'm missing some required modules?

Any pointers highly appreciated!

sirkitbreaker commented on 2014-01-19 20:52

@calrama: Thanks for the help and the swift reply, much appreciated

calrama commented on 2014-01-19 20:27

You essentially follow the seafile guide from this point onwards to setup seafile (leaving out the parts that don't apply):
https://github.com/haiwen/seafile/wiki/Build%20and%20Deploy%20Seafile%20Server%20from%20source#prepare-the-directory-layout
You won't have/setup the "src" subdirectory as everything but seahub was installed at system-level. To get the latest seahub version you look at the git tags here
https://github.com/haiwen/seahub/tags
and select the one matching with package's version, e.g. right now "v2.1.3-server" and download it, set it up in the directory layout described in the first link, and finally do the "seafile-admin setup" stuff. When upgrading, you follow this:
https://github.com/haiwen/seafile/wiki/Build%20and%20Deploy%20Seafile%20Server%20from%20source#upgrade-the-seafile-server
Also, the upgrade scripts are installed by this package under "/usr/share/seafile-server/upgrade", so use that instead of "seafile-{version}/scripts/upgrade" in the cp -rf line when upgrading.

calrama commented on 2014-01-19 20:25

You essentially follow the seafile guide from this point onwards to setup seafile (leaving out the parts that don't apply):
https://github.com/haiwen/seafile/wiki/Build%20and%20Deploy%20Seafile%20Server%20from%20source#prepare-the-directory-layout
You won't have/setup the "src" subdirectory as everything but seahub was installed at system-level. To get the latest seahub version you look at the git tags here
https://github.com/haiwen/seahub/tags
and select the one matching with package's version, e.g. right now "v2.1.3-server" and download it, set it up in the directory layout described in the first link, and finally do the "seafile-admin setup" stuff. When upgrading, you follow this:
https://github.com/haiwen/seafile/wiki/Build%20and%20Deploy%20Seafile%20Server%20from%20source#upgrade-the-seafile-server

sirkitbreaker commented on 2014-01-19 20:07

The package contents say that seahub is not included, do I just download the current latest seahub from the seafile website?

BunBum commented on 2014-01-10 14:43

python2-imaging dependency should be replaced with python2-pillow

calrama commented on 2013-12-30 22:35

@wabi: Strange, I was sure I set it to one month, my mistake. I'm considering creating a page for seafile (the paste was the first prototype for the server part) on the ArchWiki, but it's not quite up to the standard of the usual pages there and there's no feature (I could find) that allows me to create a "beta" page for reviewing there, so I have to work on it offline, essentially. Once that is done I'll post the (hopefully) up-to-snuff version and make a link to it in a comment here (and possibly make the post-install script print the link).

wabi commented on 2013-12-30 11:26

@calrama: could you include the pastebin contents in the package (as a README). It has been automatically removed and I think others could benefit from it. Thanks.

calrama commented on 2013-12-22 17:44

@wabi: I could not reproduce your error, just to confirm, you did the setup similar to this? http://pastebin.com/raw.php?i=5CDQGCq9

calrama commented on 2013-12-20 16:16

I don't know, but it should be possible. You'll have to ask the devs at the seafile repository about that.
I'll look into the setup problem this weekend and see if I can reproduce it (as in, the package build is faulty and needs fixing).

wabi commented on 2013-12-19 14:53

Tried to setup a new seafile server with this package.
I'm runing "seafile-admin setup" within /srv/seafile as user seafile (who's home is /src/seafile). I can create the config files sucessfully but initializing the database fails:

Now initializing seahub database, please wait...

/usr/lib/seafile/seafileenv/bin/python2: can't open file 'manage.py': [Errno 2] No such file or directory
Error: Seahub syncdb failed

Is there any way to create the database config manually and a sql-dump to preload the DB?

kevincox commented on 2013-11-20 22:31

I wouldn't call that unusual, I see it all the time.

useradd --home /srv/seafile/ seafile
# or if the user already exists.
usermod --home /srv/seafile seafile

Note that neither of those create the directory.

Although personally, I like to give every service their own place in `/home/`. I think it keeps things tidier IMHO.

calrama commented on 2013-11-20 22:09

Well, you could make /srv/seafile be the home directory for the seafile user. It's unusual, but iirc not impossible.

peacememories commented on 2013-11-20 20:46

gotta ask though. what would be the correct way to run the server in /srv/seafile with your systemd script?

peacememories commented on 2013-11-20 20:35

Seems like an elegant solution.
Thanks for the quick response.

calrama commented on 2013-11-20 18:27

I've added the systemd service I've been using:
The username is fixed to "seafile" (so if you want to use a different one, you have to change it in the service file), but the directory is set by the instance name. This means, that e.g.

systemctl start seafile-server@example.org

will try to start a seafile server located in the directory "/home/seafile/example.org/" as the user "seafile".
I have decided against creating a user in the install script (seafile-server.install), as there is no reason to add it for people who want to run it under their normal user, or have any other - more complex - setup of users and different seafile-servers on a single machine.
Sadly I could not find a way to use the instance name to carry both the username AND a directory under that username, because systemd failed to start any services where the .service file contained stuff like USER=$(sed ...) that would be necessary to split the instance name.

peacememories commented on 2013-11-20 17:34

First of all, thanks for taking over the package, it works great.
I'd like to suggest including a service file into the package though.
I'm using this at the moment: http://pastebin.com/rrn70Rtx

Of course the user would have to be added as well.

calrama commented on 2013-11-09 00:34

@ddanier: Thanks for your work, I'll try to take good care of it!

ddanier commented on 2013-11-08 12:40

@calrama: Feel free to adopt this package. Thanks!

calrama commented on 2013-11-08 12:28

Updated PKGBUILD which I've verified to work a least on my own server: http://pastebin.com/raw.php?i=wJX1Pd2L
I'd be willing to adopt this package if you want (it's been out-of-date for a while).

Changes include:

- Switch to using the tagges git tarballs
- Include upgrade scripts in the package (under /usr/share/seafile-server/scripts/upgrade
- Make the package depend on seafile-shared, so seafile-client + seafile-client-cli / seafile-server don't conflict

calrama commented on 2013-11-08 12:26

Updates PKGBUILD which I've verified to work a least on my own server: http://pastebin.com/raw.php?i=wJX1Pd2L
I'd be willing to adopt this package if you want (it's been out-of-date for a while).

ddanier commented on 2013-10-29 12:54

@mbroemme: I'll still wait for the official release. There are currently multiple 2.0.x binary versions available, even multiple server versions. I don't want to put up an PKGBUILD for an old, probably unstable version. Besides ccnet probably needs to be updated first, so we have to wait for this package anyways. Again: seafile has a really bad release policy. I'm sorry to keep you waiting, but I'm not convinced rushing things will bring this package forward. Please see the discussion om the seafile-client package for further details on this issue. The same questions were asked there.

mbroemme commented on 2013-10-29 02:16

@ddanier: You can safely use https://github.com/haiwen/seafile/archive/server-2.0.tar.gz as it is freezed after tagging and no more commits will go into it.

ddanier commented on 2013-10-28 10:22

@mplx: No, as the branches don't help much (there is active development going on on there). Tags would work, but there's no 2.0 server version either. Seafile really has a bad release policy. There are different version numbers for each platform, too. We just have to wait until the source package is ready.

mplx commented on 2013-10-28 10:08

The files on Google Code are also lacking latest source versions in 1.8 tree, up to 1.8.5, so maybe it's an option to take the source from github directly? https://github.com/haiwen/seafile/tree/2.0

ddanier commented on 2013-10-28 08:21

@mplx: Sure, when the source download is ready. Currently only binary files are released. (https://code.google.com/p/seafile/downloads/list)

mplx commented on 2013-10-26 10:17

@ddanier, do you intend to update the package to seafile 2.0.1? thank you :)

Alomsimoy commented on 2013-10-23 20:36

I've got a problem compiling it: /usr/bin/ld: cannot find -levhtp
Anybody can help me?

ddanier commented on 2013-10-01 20:18

Hope this new version fixes many problems. Took me some time to figure out how to do this the right way. I also updated the package to upgrade the virtualenv, so Django 1.5 gets installed without the need to completely reinstall seafile-server.

kevincox commented on 2013-08-29 12:37

I was a little confused. It was actually using gcc. However the error is that libpthread was not being linked in. Adding LDFLAGS=-lpthread to the configure command fixes this.

Anonymous comment on 2013-08-28 12:32

thanks, the seafile-package in the aur has a patch to fix this error, i used that and it worked

kevincox commented on 2013-08-27 19:00

You need to edit the build scripts. I haven't looked into it enough to tell what exactly needs to be done.

Anonymous comment on 2013-08-27 14:02

sorry, that about exceeds my knowledge of compiling and linking.
Could you please be more specific?

kevincox commented on 2013-08-27 13:54

@hachel

Just change the excutable. gcc will take object files on the command line and link them using it's liker and its settings.

Anonymous comment on 2013-08-27 13:52

@kevincox
how would I use gcc for linking instead of ld?

kevincox commented on 2013-08-26 22:55

The download file hasn't moved, however the old version 404's. Changing pkgver to 1.8.1 fixes this. (Of course the checksum has to be updated too).

However, there is a build error in this new version.

Making all in tools
make[2]: Entering directory `/tmp/yaourt-tmp-kevincox/aur-seafile-server/src/seafile-1.8.1/tools'
/bin/sh ../libtool --tag=CC --mode=link gcc -march=i686 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -Wl,-O1,--sort-common,--as-needed,-z,relro -o seaf-server-init seaf_server_init-seaf-server-init.o seaf_server_init-seaf-db.o -lglib-2.0 -lzdb
libtool: link: gcc -march=i686 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z -Wl,relro -o seaf-server-init seaf_server_init-seaf-server-init.o seaf_server_init-seaf-db.o -lglib-2.0 -lzdb
/usr/bin/ld: seaf_server_init-seaf-db.o: undefined reference to symbol 'pthread_setspecific@@GLIBC_2.0'
/usr/bin/ld: note: 'pthread_setspecific@@GLIBC_2.0' is defined in DSO /usr/lib/libpthread.so.0 so try adding it to the linker command line
/usr/lib/libpthread.so.0: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
make[2]: *** [seaf-server-init] Error 1
make[2]: Leaving directory `/tmp/yaourt-tmp-kevincox/aur-seafile-server/src/seafile-1.8.1/tools'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/yaourt-tmp-kevincox/aur-seafile-server/src/seafile-1.8.1'
make: *** [all] Error 2

The error appears to be that the package is being compiled with gcc but linked with ld. Generally you need to link with the compiler's linker (use gcc and it will call the right linker with the right options).

I doubt this is a packaging error and if you confirm I don't mind reporting it upstream.

(I'm make sure I subscribe this time)

kevincox commented on 2013-08-26 22:40

@ddanier, yes, I have tested it and have been using it for a while.

untitaker commented on 2013-08-18 18:15

Seafile is now at GitHub. Package doesn't compile.

ddanier commented on 2013-07-04 09:23

@kevincox: Have you tested this, does it work?

kevincox commented on 2013-07-04 01:12

Adding "armv6h" to the "arch" variable allows for use on arm devices such as the raspberry pi.