Package Details: seafile 9.0.13-1

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: 110
Popularity: 0.000000
First Submitted: 2016-08-11 16:38 (UTC)
Last Updated: 2025-04-04 12:14 (UTC)

Pinned Comments

Latest Comments

« First ‹ Previous 1 .. 25 26 27 28 29 30 31 32 33 34 35 .. 47 Next › Last »

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

BunBum commented on 2014-11-24 16:21 (UTC)

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 (UTC)

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

<deleted-account> commented on 2014-11-16 20:24 (UTC)

@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 (UTC)

@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)

<deleted-account> commented on 2014-11-16 18:35 (UTC)

@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 (UTC)

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.

<deleted-account> commented on 2014-11-11 17:55 (UTC)

@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

« First ‹ Previous 1 .. 25 26 27 28 29 30 31 32 33 34 35 .. 47 Next › Last »