@Narigo: No, you are not. Apparently they updated the tag after release which (obviously) changed the checksum. Should be fixed now.
Search Criteria
Package Details: seafile 9.0.11-1
Package Actions
| Git Clone URL: | https://aur.archlinux.org/seafile.git (read-only, click to copy) |
|---|---|
| Package Base: | seafile |
| Description: | An online file storage and collaboration tool |
| Upstream URL: | https://github.com/haiwen/seafile |
| Licenses: | GPL2 |
| Conflicts: | seafile-server |
| Provides: | seafile-client-cli |
| Submitter: | eolianoe |
| Maintainer: | Joffrey |
| Last Packager: | Joffrey |
| Votes: | 111 |
| Popularity: | 0.000000 |
| First Submitted: | 2016-08-11 16:38 (UTC) |
| Last Updated: | 2024-11-14 17:06 (UTC) |
Dependencies (8)
- fuse (fuse2)
- libevent (libevent-gitAUR)
- libsearpcAUR
- libwebsockets
- python-future
- sqlite (sqlite-fossilAUR)
- intltool (make)
- vala (vala-gitAUR) (make)
Required by (2)
Sources (2)
<deleted-account> commented on 2015-01-31 18:59 (UTC)
Narigo commented on 2015-01-30 08:42 (UTC)
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 (UTC)
@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.
<deleted-account> commented on 2015-01-07 22:34 (UTC)
@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 (UTC)
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 (UTC)
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.
<deleted-account> commented on 2014-12-03 12:48 (UTC)
@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 (UTC)
@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.
Pinned Comments