Package Details: seafile-client 9.0.11-1

Git Clone URL: https://aur.archlinux.org/seafile-client.git (read-only, click to copy)
Package Base: seafile-client
Description: GUI client for synchronizing your local files with seafile server
Upstream URL: https://github.com/haiwen/seafile-client
Licenses: Apache
Submitter: Localizator
Maintainer: Joffrey
Last Packager: Joffrey
Votes: 168
Popularity: 0.000000
First Submitted: 2012-12-10 17:34 (UTC)
Last Updated: 2024-11-14 17:07 (UTC)

Pinned Comments

Joffrey commented on 2021-05-30 20:06 (UTC) (edited on 2021-05-30 20:11 (UTC) by Joffrey)

Please, when you have compilation or execution errors, recompile each component without using an AUR helper before reporting an issue.

Latest Comments

« First ‹ Previous 1 .. 19 20 21 22 23 24 25 26 27 28 29 .. 44 Next › Last »

ToK commented on 2017-04-26 15:26 (UTC)

I just tried on a fresh Antergos system (before this I uses plain Arch) with the same result...

snack commented on 2017-04-26 15:24 (UTC)

@eolianoe: maybe not building in a clean chroot might be the problem? If so, it's strange since I always updated with yaourt with no problems up to now. Did you try building in a standard environment? I will try the chroot as soon as I have time.

eolianoe commented on 2017-04-26 15:00 (UTC)

@ToK, @snack: I've just rebuild the seafile packages in a clean and up-to-date chroot and I'm not seeing any segfault on two different computers. You may have some special configuration which may break something

ToK commented on 2017-04-26 14:09 (UTC)

I also got a segfault in seaf-daemon: Apr 26 15:56:39 clodsahamp kernel: pool[3981]: segfault at 100 ip 0000000000000100 sp 00007f74f25b3208 error 14 in seaf-daemon[400000+99000] Apr 26 15:56:39 clodsahamp systemd[1]: Started Process Core Dump (PID 3982/UID 0). Apr 26 15:56:39 clodsahamp systemd-coredump[3983]: Process 3978 (seaf-daemon) of user 1000 dumped core. Stack trace of thread 3981: #0 0x0000000000000100 n/a (n/a) And i got a segfault in seafile-applet: Apr 26 15:56:57 clodsahamp kernel: seafile-applet[3711]: segfault at 8 ip 00007f5ebb601b51 sp 00007fff1a3b8010 error 4 in libQt5Widgets.so.5.8.0[7f5ebb46b000+628000] Apr 26 15:56:57 clodsahamp systemd[1]: Started Process Core Dump (PID 4136/UID 0). Apr 26 15:56:57 clodsahamp systemd-coredump[4137]: Process 3711 (seafile-applet) of user 1000 dumped core. Stack trace of thread 3711: #0 0x00007f5ebb601b51 _ZNK7QWidget14ensurePolishedEv (libQt5Widgets.so.5) #1 0x00007f5ebb602ae9 _ZN7QWidget10showNormalEv (libQt5Widgets.so.5) #2 0x00000000004effd9 _ZN10MainWindow10showWindowEv (seafile-applet) #3 0x0000000000492139 _ZN13SeafileApplet10warningBoxERK7QStringP7QWidget (seafile-applet) #4 0x00000000004921c1 _ZN13SeafileApplet12errorAndExitERK7QString (seafile-applet) #5 0x00000000004a4c57 _ZN13DaemonManager20checkSeafDaemonReadyEv (seafile-applet) #6 0x00007f5eba907d79 _ZN11QMetaObject8activateEP7QObjectiiPPv (libQt5Core.so.5) #7 0x00007f5eba914dc8 _ZN6QTimer10timerEventEP11QTimerEvent (libQt5Core.so.5) #8 0x00007f5eba908b93 _ZN7QObject5eventEP6QEvent (libQt5Core.so.5) #9 0x00007f5ebb5be34c _ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent (libQt5Widgets.so.5) #10 0x00007f5ebb5c5b61 _ZN12QApplication6notifyEP7QObjectP6QEvent (libQt5Widgets.so.5) #11 0x00007f5eba8dc470 _ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent (libQt5Core.so.5) #12 0x00007f5eba92fcee _ZN14QTimerInfoList14activateTimersEv (libQt5Core.so.5) #13 0x00007f5eba930579 n/a (libQt5Core.so.5) #14 0x00007f5ec23c17b7 g_main_context_dispatch (libglib-2.0.so.0) #15 0x00007f5ec23c1a20 n/a (libglib-2.0.so.0) #16 0x00007f5ec23c1acc g_main_context_iteration (libglib-2.0.so.0) #17 0x00007f5eba93107f _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5) #18 0x00007f5eba8da8ca _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5) #19 0x00007f5eba8e2e14 _ZN16QCoreApplication4execEv (libQt5Core.so.5) #20 0x000000000048e6ff main (seafile-applet) #21 0x00007f5eb9d31511 __libc_start_main (libc.so.6) #22 0x000000000048edca _start (seafile-applet) Stack trace of thread 3805: #0 0x00007f5eb9df367d poll (libc.so.6) #1 0x00007f5ec23c19b6 n/a (libglib-2.0.so.0) #2 0x00007f5ec23c1acc g_main_context_iteration (libglib-2.0.so.0) #3 0x00007f5eba93107f _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5) #4 0x00007f5eba8da8ca _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5) #5 0x00007f5eba6fca73 _ZN7QThread4execEv (libQt5Core.so.5) #6 0x00007f5ec1a79125 n/a (libQt5DBus.so.5) #7 0x00007f5eba7016d8 n/a (libQt5Core.so.5) #8 0x00007f5ec36cb2e7 start_thread (libpthread.so.0) #9 0x00007f5eb9dfd54f __clone (libc.so.6) Stack trace of thread 3756: #0 0x00007f5eb9df367d poll (libc.so.6) #1 0x00007f5eace5d8e0 n/a (libxcb.so.1) #2 0x00007f5eace5f679 xcb_wait_for_event (libxcb.so.1) #3 0x00007f5ea4d8a239 n/a (libQt5XcbQpa.so.5) #4 0x00007f5eba7016d8 n/a (libQt5Core.so.5) #5 0x00007f5ec36cb2e7 start_thread (libpthread.so.0) #6 0x00007f5eb9dfd54f __clone (libc.so.6) Stack trace of thread 3761: #0 0x00007f5eb9df367d poll (libc.so.6) #1 0x00007f5ec23c19b6 n/a (libglib-2.0.so.0) #2 0x00007f5ec23c1acc g_main_context_iteration (libglib-2.0.so.0) #3 0x00007f5ec23c1b11 n/a (libglib-2.0.so.0) #4 0x00007f5ec23e9295 n/a (libglib-2.0.so.0) #5 0x00007f5ec36cb2e7 start_thread (libpthread.so.0) #6 0x00007f5eb9dfd54f __clone (libc.so.6) Stack trace of thread 3762: #0 0x00007f5eb9df367d poll (libc.so.6) #1 0x00007f5ec23c19b6 n/a (libglib-2.0.so.0) #2 0x00007f5ec23c1d42 g_main_loop_run (libglib-2.0.so.0) #3 0x00007f5eb8eafff6 n/a (libgio-2.0.so.0) #4 0x00007f5ec23e9295 n/a (libglib-2.0.so.0) #5 0x00007f5ec36cb2e7 start_thread (libpthread.so.0) #6 0x00007f5eb9dfd54f __clone (libc.so.6) Stack trace of thread 3779: #0 0x00007f5ec36d1ca6 pthread_cond_timedwait@@GLIBC_2.3.2 (libpthread.so.0) #1 0x00007f5e93d72e44 n/a (libGLX_nvidia.so.0) #2 0x00007f5e92a90394 n/a (libnvidia-glcore.so.378.13) #3 0x00007f5e93d7212c n/a (libGLX_nvidia.so.0) #4 0x00007f5ec36cb2e7 start_thread (libpthread.so.0) #5 0x00007f5eb9dfd54f __clone (libc.so.6) I removed every packet concerning seafile-applet like snack did. And I remove ~/.ccnet and ~/Seafile/.seafile I tried it in gnome and in plasma with a fresh user. Noting changed I could access the server by clicking in the "main window" of seafile applet. But syncing doesn't work. I also have a Mac with seafile-client 6.0.4 which works fine. So it could not be may Server, i think (running armbian on a cubietruck).

snack commented on 2017-04-26 13:42 (UTC)

@eolianoe: I just did a full rebuild of the stack: libsearpc ccnet-server ccnet seafile seafile-client in this order using yaourt, without touching any PKGBUILD. Nothing changed, seaf-daemon keeps crashing. @carlos @ToK: do you see the same segfault of seaf-daemon in journalctl?

eolianoe commented on 2017-04-26 12:31 (UTC)

@snack: I'm not seeing all theses errors... Could you try to rebuild all the seafile related packages in the proper order to get everything linked properly?

snack commented on 2017-04-26 12:17 (UTC) (edited on 2017-04-26 12:24 (UTC) by snack)

I noticed that when starting the client the seaf-daemon crashes. From journald: apr 26 14:09:59 elric kernel: pool[23823]: segfault at 100 ip 0000000000000100 sp 00007fdf8a3fe208 error 14 in seaf-daemon[400000+99000] apr 26 14:09:59 elric systemd[1]: Started Process Core Dump (PID 23826/UID 0). -- Subject: Unit systemd-coredump@9-23826-0.service has finished start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit systemd-coredump@9-23826-0.service has finished starting up. -- -- The start-up result is done. apr 26 14:10:00 elric systemd-coredump[23827]: Process 23820 (seaf-daemon) of user 10085 dumped core. Stack trace of thread 23823: #0 0x0000000000000100 n/a (n/a) -- Subject: Process 23820 (seaf-daemon) dumped core -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Documentation: man:core(5) -- -- Process 23820 (seaf-daemon) crashed and dumped core. -- -- This usually indicates a programming error in the crashing program and -- should be reported to its vendor as a bug. After manually restarting seaf-daemon from command line after the client I am able again to sync with remote. Unfortunately the crash happens again when the client is stopped and restarted. It seems that the client launches the daemon in a way that makes it crash, while launching it from the command line without any argument works.

snack commented on 2017-04-26 12:06 (UTC)

@eolianoe: the server is maintained by the IT department of my institute, it has not been updated in a while and it worked fine up to this morning. Is client 6.0.4 known to break compatibility with old servers? Or maybe the OpenSSL mayhem broke something? I see that seafile-applet still links libssl.so.1.0.0 so I guess that it should not be the root of the problem, but who knows...

eolianoe commented on 2017-04-26 11:32 (UTC)

@snack, @ToK: the seafile client is working fine on my setup (using a server maintained by a third-party). Maybe the problem is linked to your server rather than the client

carlos commented on 2017-04-26 11:31 (UTC)

Same problem here: ``` [26.04.2017 13:28:01][RPC] failed to start rpc server: 511 Unknown service. [26.04.2017 13:28:01][RPC] failed to start rpc server: 511 Unknown service. [26.04.2017 13:28:01]failed to get repo list: Transport Error ```