Package Details: seafile-client 5.1.1-1

Git Clone URL: https://aur.archlinux.org/seafile-client.git (read-only)
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
Conflicts: seafile-client-qt5
Provides: seafile-client-qt5
Submitter: Localizator
Maintainer: edacval (eolianoe)
Last Packager: edacval
Votes: 97
Popularity: 4.378038
First Submitted: 2012-12-10 17:34
Last Updated: 2016-05-05 16:25

Latest Comments

eolianoe commented on 2016-05-08 20:24

@PsiTrax: please read carefully the dependency list. This package only depends on 'seafile-shared' which is part of the split package 'seafile-server'. This split package builds 'seafile-shared', 'seafile-client-cli' and 'seafile-server' but you have to install only 'seafile-shared' to get 'seafile-client' working.

PsiTrax commented on 2016-05-08 20:17

Still pulling the server ??? ;(

lins05 commented on 2016-04-05 09:08

Hi, I'm Shuai Lin from the seafile team. I'm here to notify the maintainer of this AUR that we're going to remove Qt 4 support in seafile-client soon (most likely before we release seafile client 5.1.0) since it has become a maintenance burden of the code base.

tuxayo commented on 2016-03-19 15:03

Is there something that prevents updating the client to 5.0.6?

muon commented on 2016-02-09 19:47

For what it's worth, the upgrade worked fine for me by simply
* removing older versions of seafile-client and seafile-shared
* building/upgrading ccnet (to 5.0.5-1)
* building/upgrading seafile-shared from the split package (to 5.0.5-1)
* building/upgrading this package (to 5.0.4-1).
Now, all seems to be running fine.

a-bostaurus commented on 2016-02-06 14:29

I got four arch-computer with seafile, and in the meantime no one is working relating to seafile. What I get are informations that there is an error ... It is more than annoying ...

rami commented on 2016-01-31 12:58

To me, it worked after I installed current seafile-shared manually. The dependency statement seafile-shared>=4.3.0 seems to be wrong.

nicolauz commented on 2016-01-15 12:25

The whole aur package is broken/annoying!
Not that I can't fix the issue .. it's that there is an issue.
A simple yaour -Suya should update all my aur packages .. it does, except seafile because either the dep on ccnet is "=" (instead of >=), or because seafile-[shared|server]'s pkg-split is broken

Popkornium18 commented on 2016-01-14 12:15

How can I upgrade the seafile-client package without reinstalling it. When I try to upgrade it it fails, because seafile-shared needs ccnet-5.0.3.

mjianr commented on 2016-01-07 20:25

Seems like there's a big misunderstood here about "seafile-shared" package. As it's made with split-pkgbuild, it outputs client-cli, server and shared packages (so that you won't compile all, 2 hours each on raspberry pi). AUR helpers like yaourt may try to install all of them, so, if someone struggling, make seafile-shared first and install needed packages with pacman -U manually or either use appropriate arguments (NOT --noconfirm!).

I hope I made this clearer.

Popkornium18 commented on 2016-01-07 19:35

The installation process of the Seafile client STILL pulls the Seafile server and the Seafile CLI client as a dependency... Why? This is so pointless... Could you PLEASE tell us if this is intentional, and if so, why it is necessery? If it is not intended please fix it. It's kind of annoying.

snack commented on 2015-12-21 11:44

It seems that the sync issue with new libraries can be bypassed by moving all the files in a temporary folder and then moving them back to the original folder. Seafile detects new files in the library folder and the synchronizes them correctly.

snack commented on 2015-12-15 15:36

Is anyone using the client with an old server (the one at my institute is 2.1.4) and experiencing no sync for new libraries? If I create a new library to sync a local folder already containing some files then no sync is performed: no file is uploaded to the server. The seafile.log file shows:

[12/15/15 16:35:22] sync-mgr.c(660): Repo 'Documents' sync state transition from 'synchronized' to 'committing'.
[12/15/15 16:35:23] sync-mgr.c(660): Repo 'Documents' sync state transition from 'committing' to 'initializing'.

But if I add a new file to the local folder or touch one of the existing ones then that file is synced and uploaded.

snack commented on 2015-12-14 08:56

Compiling with Qt5 support as suggested by edacval partially fixes the problem. xembedsniproxy does not crash anymore and the Saefile icon is not displayed in the system tray but rather in the Status & Notifications panel, which is fine for me. The only problem is that the application window cannot be restored by clicking on the Seafile icon, and also the right click does nothing.

edacval commented on 2015-12-13 13:30

You can try to rebuild with QT5:
change PKGBUILD 19 line to "cmake -DUSE_QT5=on -DBUILD_SHIBBOLETH_SUPPORT=ON -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr ."

eolianoe commented on 2015-12-13 12:54

Does a switch to Qt5 may change something to the problem? By the way the change to Qt5 can be a good thing as Qt4 will reach its end of life

xarinatan commented on 2015-12-13 00:35

Seeing the same issue as @Snack on a completely fresh setup (KDE 5.5), not sure what to do to resolve the issue though.

snack commented on 2015-12-11 11:01

Since the update to Plasma 5.5 the tray icon is disappeared. I have been able to track down the issue being seafile-applet making xembedsniproxy crash, as reported here:

https://bbs.archlinux.org/viewtopic.php?pid=1585237#p1585237

Is anyone having a similar issue?

fsf commented on 2015-12-08 14:54

Thank you very much!

edacval commented on 2015-11-10 13:27

Done.

fsf commented on 2015-11-06 12:01

Please Add -DBUILD_SHIBBOLETH_SUPPORT=ON to the build options and
change md5sum to SHA256sum, thx

hopimet commented on 2015-11-04 21:41

Thank you for updating this package. It works fine.

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.

Dezponia commented on 2015-10-01 16:11

Thanks for updating the package and taking on the maintainer role. So far the new client seems to work fine on my systems, syncing up and down without issues. In the case you don't want to maintain the client and its dependencies I'm willing to take it on.


Client 4.4.0 is clearly marked as Beta on https://www.seafile.com/en/download/

Server 4.4.1 is also clearly marked as Beta. A good test here to see which is the latest stable is that the Seafile client will not show the "New stable version x.x.x is out" window unless its a new stable. That's why 4.3.4 is not asking to upgrade to 4.4.0 right now, 4.4.0 not considered stable by upstream.

More info about how Seafile handles stable versions can be found here: https://seacloud.cc/group/3/wiki/client-changelog/
Specifically: "For desktop clients, we maintain two versions, one stable version and one master version. Master version will come with major modifications that may cause syncing issues."

Master is not recommended for regular users but should be considered testing. And since Seafile handles peoples data I think its better to be careful (the 4.3.0-4.3.3 sync disaster shows this).

Lastly I would also like to chime in and support the switch to use SHA256 over MD5.

Dezponia commented on 2015-10-01 15:59

Thanks for updating the package and taking on the maintainer role. So far the new client seems to work fine on my systems, syncing up and down without issues.


Client 4.4.0 is clearly marked as Beta on https://www.seafile.com/en/download/

Server 4.4.1 is also clearly marked as Beta. A good test here to see which is the latest stable is that the Seafile client will not show the "New stable version x.x.x is out" window unless its a new stable. That's why 4.3.4 is not asking to upgrade to 4.0 right now, 4.4.0 not considered stable by upstream.

More info about how Seafile handles stable versions can be found here: https://seacloud.cc/group/3/wiki/client-changelog/
Specifically: "For desktop clients, we maintain two versions, one stable version and one master version. Master version will come with major modifications that may cause syncing issues."

Master is not recommended for regular users but should be considered testing. And since Seafile handles peoples data I think its better to be careful (the 4.3.0-4.3.3 sync disaster shows this).

Lastly I would also like to chime in and support the switch to use SHA256 over MD5.

Dezponia commented on 2015-10-01 15:57

Thanks for updating the package and taking on the maintainer role. So far the new client seems to work fine on my systems, syncing up and down without issues.


Client 4.0 is clearly marked as Beta on https://www.seafile.com/en/download/

Server 4.4.1 is also clearly marked as Beta. A good test here is that the Seafile client will not show the "New stable version x.x.x is out" window unless its a new stable, that's why 4.3.4 is not asking to upgrade to 4.0 right now.

More info about how Seafile handles stable versions can be found here: https://seacloud.cc/group/3/wiki/client-changelog/
Specifically: "For desktop clients, we maintain two versions, one stable version and one master version. Master version will come with major modifications that may cause syncing issues."

Master is not recommended for regular users but should be considered testing. And since Seafile handles peoples data I think its better to be careful (the 4.3.0-4.3.3 sync disaster shows this).

Lastly I would also like to chime in and support the switch to use SHA256 over MD5.

fsf commented on 2015-10-01 15:20

4.4 is out on all clients as stable, server still beta:

Seafile Client for Linux
Runs on Ubuntu 12.04 or above
4.3.4 64bit
4.3.4 32bit
4.4.0 64bit
4.4.0 32bit

And please use sha256sum and NOT md5, thx

fsf commented on 2015-10-01 15:20

4.4 is out on all clients as stable, server still beta:

Seafile Client for Linux
Runs on Ubuntu 12.04 or above
4.3.4 64bit
4.3.4 32bit
4.4.0 64bit
4.4.0 32bit

cybertron commented on 2015-10-01 13:15

still not work for me, so can't download anything

simontunnat commented on 2015-10-01 12:26

If someone else wanted to take care of the packages im happily willing to give up my ownership. I just saw that there was no maintainer at the time.

simontunnat commented on 2015-10-01 12:24

Version 4.3.4 seems to be the last stable version.
On the official homepage there is no 4.4 client and the server version 4.4 is marked as "beta".
(https://www.seafile.com/en/download/)

fsf commented on 2015-10-01 09:50

i wanted to commit 4.4 but, now theres just apeared another maintainer...
So, @simontunnat - would you mind to bump the version to 4.4 ?

calrama commented on 2015-09-29 12:49

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.

Dezponia commented on 2015-09-26 22:47

Status update on new maintainer?

nebulon commented on 2015-09-16 08:30

Any updates on the ownership change? Thanks.

cybertron commented on 2015-09-05 20:19

Thanks a lot!

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.

cybertron commented on 2015-09-04 06:34

it's gettin older and older :/

maxi_jac commented on 2015-08-21 17:43

My synchronisation issue was related to SSL cert and seafile silently falling back to its own protocol on previous server versions. All works for me now.

taggaara commented on 2015-08-19 13:26

@a-bostaurus
Please check my commet @ 2015-08-11 06:00, you can search it in this page.

a-bostaurus commented on 2015-08-19 11:06

After the last update to version 4.3.1-1 there are some problems with syncing. If you have worked with a file and saved it the seafile client says: Uploading is not possible or did not work. (Hochladen der Datei fehlgeschlagen). I tested it on 4 Computers with Arch Linux und found everywhere the same problem. Downgrading could help but I am not able to do this.

a-bostaurus commented on 2015-08-19 11:05

After the last update to version 4.3.1-1 there are some problems with syncing. If you have worked with a file and saved it the seafile client says: Uploading is not possible or did not work. (Hochladen der Datei fehlgeschlagen). I tested it on 4 Computers with Arch Linux und found everywhere the same problem. Upgrading could help but I am not able to do this.

Dezponia commented on 2015-08-19 10:42

@maxi_jac
4.3.2 just got released which fixes even more syncing issues with the 4.3.x branch. Perhaps you've run into one of these issues?

taggaara commented on 2015-08-15 04:17

@calrama You have maintained this pkg for more than 2years. Really Thanks!
I've never heard Funtoo before because I moved my working environment from Windows to Archlinux only 1 year ago. There are lots of things I need to learn in Linux.
Since I don't have enough knowledge to maintain this package, I fell so sorry.

maxi_jac commented on 2015-08-14 16:18

Thanks calrama.
At least, now the window/systray works.
But I still have problems with synchronisation. I'll investigate.

calrama commented on 2015-08-13 13:18

@Dezponia Cool, unfortunately my last Archlinux box is headless, so the maximum testing for this I can still do is build verification.
@taggaara Should work with the update to 4.3.1 and the downgrade to QT4. Also, since I may not have stressed this enough, I WILL drop all my AUR packages sometime after 2015-08-31, maybe as early as 2015-09-01. <OT> I have been moving away from Archlinux to Funtoo for quite a while now and except for one box used to keep maintaining here, I no longer have any Archlinux boxes. I am glad that Archlinux existed when I moved away from Ubuntu in '09, as it allowed me to sharpen my Linux-fu so to speak, but I do not agree with several of the decisions regarding Archlinux' future made by its core developers - including, but not limited to the adoption of systemd - and it was/is time for me to move to something that satisfies my requirements and I simply do not have the time (and quite frankly the motivation) to keep maintaining something that I have no use for (which I btw have been doing for about half a year now as thanks for what Archlinux has enabled me to do in the past).</OT>

calrama commented on 2015-08-13 13:16

@Dezponia Cool, unfortunately my last Archlinux box is headless, so the maximum testing for this I can still do is build verification.
@taggaara Should work with the update to 4.3.1 and the downgrade to QT4. Also, since I may not have stressed this enough, I WILL drop all my AUR packages sometime after 2015-08-31, maybe as early as 2015-09-01. <OT> I have been moving away from Archlinux to Funtoo for quite a while now and except for one box used to keep maintaining here, I no longer have any Archlinux boxes. I am glad that Archlinux existed when I moved away from Ubuntu in '09, as it allowed me to sharpen my Linux-fu so to speak, but I do not agree with several of the decisions regarding Archlinux' future made by its core developers - including, but not limited to the adoption of systemd - and it was/is time for me to move to something that satisfies my requirements and I simply do not have the time quite frankly the motivation to keep maintaining something that I have no use for (which I btw have been doing for about half a year now as thanks for what Archlinux has enabled me to do in the past).</OT>

Dezponia commented on 2015-08-13 13:02

Thanks for the update to version 4.3.1. I can confirm the system menu tray now works as intended again on Qt4. As I have not experienced any sync bugs myself (I did not trigger the "empty folder" bug) someone else will have to verify that part is solved.

Dezponia commented on 2015-08-12 08:37

The sync bug is probably related to version 4.3.0, it was fixed in 4.3.1 that just got released.

The system tray menu bug is likely a problem with the Qt5 branch from what I've found. If the maintainer could do two set of builds, one with Qt4 and one with Qt5 and test that would be nice. For the moment most users probably want a fully working Qt4 client over a sort-of working Qt5 one.

maxi_jac commented on 2015-08-11 15:42

@taggaara
Thx, we need now to know if this is KDE/Plasma related or not. Does someone have it working and with what DE if you do ?
And/or need to know if it is a packaging issue.

Not much time to investigate this right now :/

taggaara commented on 2015-08-11 06:07

And if @calrama give up maintain of this package, maybe I will stay v4.1.6 for long time...

taggaara commented on 2015-08-11 06:00

Hei~ maxi_jac, I updated to 4.3.0-1 either, and my plasma systray cann't show right click menu, when I re-run the seafile-applet the seafile client GUI show but it cannot sync anything.
I downgrade all pkg to 4.2.4 with AUR pkg: "seafile-client seafile-shared seafile-client-cli ccnet", but still the same thing.

In the end I have to downgrade, back to 4.1.6 which version I used with no problem . I have to get PKGBUILD file from AUR GIT History Mirror:
http://pkgbuild.com/git/aur-mirror.git/
http://pkgbuild.com/git/aur-mirror.git/log/seafile-client
http://pkgbuild.com/git/aur-mirror.git/log/seafile-client-cli
http://pkgbuild.com/git/aur-mirror.git/log/seafile-shared
http://pkgbuild.com/git/aur-mirror.git/log/ccnet
# I download this whole commit history file(122MB), because I cannot find the indepence package with every seafile pkg.
http://pkgbuild.com/git/aur-mirror.git/snapshot/aur-mirror-087de4535ed8d4fd3e08deac214b3ffb6b7d0607.tar.xz

maxi_jac commented on 2015-08-08 12:19

Do you guys still have a working systray icon ?
Using KDE/Plasma I used to have it working but now, I can see it registered in my plasma systray when developing it, but I cannot interact with it, no left/right click does a thing.
In console output it does not give any error and says it successfully registered to KStatusNotifierWatcher.
I do have sni-qt.

Any idea ?

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

tes5884 commented on 2015-08-05 21:25

Version 4.3 was released

calrama commented on 2015-06-12 09:34

Initial AUR4 import at seafile version 4.2.4.

cirk2 commented on 2015-06-05 10:21

@guiguid: you also need qt5-tools, else the cmake fails to find Qt5LinguistTools

guiguid commented on 2015-05-27 19:46

for build with QT5 :
-depends=('seafile-shared>=4.1.6' 'qt4' 'qtwebkit')
+depends=('seafile-shared>=4.1.6' 'qt5-base' 'qt5-webkit')

-cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr .
+cmake -DUSE_QT5=on -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr .

jcelerier commented on 2015-04-12 14:21

Would it be possible to switch from Qt4 to Qt5 ?

timsn commented on 2015-03-27 07:22

4.1.3 was released

4.1.3 (2015/03/23)
[fix] Fix unable to sync bug (permission denial) if the Windows system user name contains space like "test 123" introduced in v4.1.2
[win] Update version of OpenSSL to 1.0.2a

4.1.2 (2015/03/19) (deprecated)
Add logout/login support (need server 4.1.0+)
fix proxy password disappearance after restarting issue
mask proxy password in the setting dialog
[Fix] fix unexpected disconnection with proxy servers
[Fix] fix a conflicting case when we have read-only sharing repository to a group
update translations
support darkmode (OS X)
and other minor fixes

chilledheart commented on 2015-03-04 16:31

Hi all,
From version 4.1.0, it seems seafile-client have add support for qt5.
I think you can enable this by pass -DUSE_QT5=on to cmake.

And if you have a hidpi screen (or more than one), you can try something
like setting environment variable QT_DEVICE_PIXEL_RATIO=auto (or 2)
before starting seafile-client.

Feel free to email me if you have any issues with it.

arnieswap commented on 2015-01-22 22:24

==> Building and installing package
==> ERROR: options array contains unknown option ''
==> ERROR: Makepkg was unable to build libsearpc.
==> Restart building libsearpc ? [y/N]

Chocobozzz commented on 2015-01-22 12:27

Seafile-client 4.0.7 released :)

calrama commented on 2014-12-26 19:50

@blubbblubb: 1) The package had already been flagged out-of-date 2) The checksums are generated semi-automatically by invoking updpkgsums (which downloads all necessary sources and updates the relevant checksum lines in the PKGBUILD, provided they are at the end of the file), which belongs to pacman and can thus be assumed to be always installed.

blubbblubb commented on 2014-12-26 18:54

4.0.5 released

change package version to 4.0.5 and use this sha sum: b2ab5251450b33a3a425d9a8a4fa17a17e7cad33691339784f0861416bd48186

calrama commented on 2014-12-03 12:54

@monochromec: See my reply at the URL you linked from 2014-12-03 12:48.

monochromec commented on 2014-12-03 07:43

Noticed an SIGILL issue on an armv7h on both the server and client side. Comment on the server page contains a workaround (https://aur.archlinux.org/packages/seafile-server).

Rook commented on 2014-12-01 16:14

4.0.2 has been released (2014/11/29) :

[fix] Fix bugs in syncing with HTTP protocol

IsSuE commented on 2014-11-18 17:26

4.0.1 was just released, fixes the previous segfault aswell

shimi commented on 2014-11-18 15:40

@Perry3D that works, thanks.

Perry3D commented on 2014-11-18 14:11

@shimi: I got the same error. After recompiling seafile-shared and seafile-client it works.

shimi commented on 2014-11-17 17:28

I'm getting this error when trying to run the applet, any ideas?

(seafile-applet:9929): GLib-GObject-CRITICAL **: g_type_instance_get_private: assertion 'instance != NULL && instance->g_class != NULL' failed
fish: Job 1, “seafile-applet ” terminated by signal SIGSEGV (Address boundary error)

calrama commented on 2014-11-12 16:13

@gnumdk: It was properly released as stable: https://github.com/haiwen/seafile-client/tags
By the upstream developers' own convention, stable released have no additional suffix and beta released have the "-testing" suffix. While one upstream developer did afterwards say that 4.0 is still in beta, they have not yet removed the stable tag for it, so upstream (as a whole) has two contradictory statements (if it truly is purely a beta release, they should have renamed the stable tag after noticing the wrong naming - even if this introduces a temporary hassle for people who already pulled the changes). The statement I chose to follow is the release of a properly versioned, stable tarball by their own convention.

calrama commented on 2014-11-12 16:12

@gnumdk: It was properly released as stable: https://github.com/haiwen/seafile-client/tags
By the upstream developer's own convention, stable released have no additional suffix and beta released have the "-testing" suffix. While one upstream developer did afterwards say that 4.0 is still in beta, they have not yet removed the stable tag for it, so upstream (as a whole) has two contradictory statements (if it truly is purely a beta release, they should have renamed the stable tag after noticing the wrong naming - even if this introduces a temporary hassle for people who already pulled the changes). The statement I chose to follow is the release of a properly versioned, stable tarball by their own convention.

gnumdk commented on 2014-11-12 14:51

Seafile 4 is a beta version!

calrama commented on 2014-10-31 00:09

@alinmear: If the package has been flagged out of date, then I have been notified of it. If the package remains flagged (that is, I don't unflag it because of an invalid flagging) I will update it when I have the necessary time to test it. Please wait with reminders about it until the end of the following weekend, since it is quite possible that I cannot make the necessary time on the weekdays. I have now - as an exception - updated the packages without testing them to accomodate you this time.

alinmear commented on 2014-10-30 12:23

@calrama. Please update the pkgver=3.1.8!

we also need to update the seafile-shared!

i uploaded the updated PKGBUILDs as GIST:
https://gist.github.com/anonymous/50a36bbdfec30cc83c13

calrama commented on 2014-10-04 10:07

@jpambrun: The perspective to be used here is a source-based (not binary based !) non-beta build script for a FLOSS (or at least a seemingly so) development project (seafile client), in which stable releases have been marked by providing source archive files for long enough for that to have become the de facto standard (both in FLOSS generally and in seafile specifically). Marking this package as out-of-date - if there is no stable release archive newer than the currently used one - is incorrect, since it cannot be updated without such an archive without becomimg broken. With that being said, the devs from seafile "forget" to do this on a regular basis - on average every third release or so (estimation based on memory) - and when reminded it can appear anywhere between a couple of minutes to a couple of weeks later, but with no shown intention of fixing their imho problematic release procedure. You might want to create a github issue there about the missing tag if you wish, or alternatively create a seafile-client-beta package and use their testing tags (which are pretty much always there the way you expect). For references to my claims you can look hat this packages comment history. It will support the pattern.

jpambrun commented on 2014-10-04 01:26

@calrama: "incorrectly" is a question of perspective; the release was announced on their twitter account on sept 27 and binaries are available for all platforms on their web site since then. They obviously just forgot to create another git tag.

calrama commented on 2014-10-03 21:24

@jpambrun: There is no issue that I know of with the "Flag as out-of-date" action, you flagged it out of date incorrectly, so I unflagged it. As of my writing this, the latest stable tag is v3.1.6: https://github.com/haiwen/seafile-client/tags

jpambrun commented on 2014-10-03 14:26

There seems to be an issue with the "Flag as out-of-date" action so I'm writing this comment. I have sync issue and I hope this update will fix my problems.

3.1.7 (2014/09/28)
- [fix] Fix another not sync problem when adding a big file (>100M) and several other files.

Chocobozzz commented on 2014-08-18 12:46

Oh, sorry the same than jbgi.

But I don't undestand why they don't precise it's testing here http://www.seafile.com/en/download/

Anyway, thanks for your work and your rapidity calrama.

jbgi commented on 2014-08-14 11:54

sorry false "out-of-date" flagging. only "v3.1.5-testing" was really released.

simontunnat commented on 2014-08-11 15:15

I agree with malachay. Had the same problem and it worked after I added "qtwebkit" to the dependencies.

malachay commented on 2014-08-07 19:58

Hi calrama,

I have a fresh arch install on my laptop with nearly nothing installed. While installing seafile-client I got this error:

CMake Error at /usr/share/cmake-3.0/Modules/FindPackageHandleStandardArgs.cmake:136 (message):
Could NOT find Qt4 (missing: QT_QTWEBKIT_INCLUDE_DIR QT_QTWEBKIT_LIBRARY)
(found version "4.8.6")

After installing qtwebkit, the client was built. You shoul add qtwebkit to the dependencies :)

Regards,
malachay


calrama commented on 2014-07-16 10:04

Dear Ondřej,

thank you for informing me about this issue.
As you said, in the AUR we are technically only distributing "Descriptions on how
to build Seafile", not Seafile itself, so as far as I understand the GPL, we're fine.
Should someone, however, contact me about merging any of these packages into the main
repositories (which would imply distribution of automatically built binaries),
I shall point them to this problem (should it not be fixed by then).
One question, though, as I'm not really clear on that point: The GPL violations
seem to be in the seafile repository, do they also automatically propagate to
anything that includes them (like the seafile-client repository)?
I ask because you posted this here and not at one of the other seafile-* packages.

Cheers,
Moritz

oerdnj commented on 2014-07-14 08:34

Dear maintainer,

the seafile is violation GPL[1] and the resulting work
cannot be legally distributed. I am not sure if that
also applies to ArchLinux since you are not distributing
binary packages, but you should be at least aware of the
issue.

Cheers,
Ondrej

1. https://github.com/haiwen/seafile/issues/666

cedricziel commented on 2014-04-27 08:37

The sha256 sum differs from the archive.

allspark commented on 2014-03-15 01:26

yes, tested it with -j 9

calrama commented on 2014-03-14 23:34

Have you explicitly tested it with more jobs, otherwise that could simply be because makepkg.conf has one job by default?

allspark commented on 2014-03-14 22:13

please remove the '-j1'. it builds fine without

calrama commented on 2014-01-20 23:16

pacman -Qo /usr/share/applications/seafile.desktop
/usr/share/applications/seafile.desktop is owned by seafile-shared 2.1.1-4
The .desktop file resides in the "seafile" repo, not in the "seafile-client" repo, so it goes into seafile-shared ATM, but it is there (since seafile-client depends on seafile-shared).

haagch commented on 2014-01-20 22:51

Works fine, but a .desktop file in /usr/share/apps would be helpful for having it in the menus.

calrama commented on 2014-01-14 12:27

Before unflagging this, please wait for a response to this: https://github.com/haiwen/seafile/issues/406#issuecomment-32260305

calrama commented on 2013-11-09 09:58

Because of a serious bug in the client, I was asked not to provide version 2.0.7 here[1]. For the time being I'll thus use 2.0.6 here.

[1] https://github.com/haiwen/seafile/issues/406#issuecomment-28117454

calrama commented on 2013-11-05 21:31

The cli client resides in the "seafile" repository and is not part of the new client, which is why it doesn't belong here anymore. There's now a seperate package for it called "seafile-client-cli"; give it a try and please report any problems you find (don't have enough time right now to do an in-depth test).

calrama commented on 2013-11-05 20:56

The cli client resides in the "seafile" repository and is not part of the new client. I'll upload a seperate package for it in a bit.

monksy commented on 2013-11-05 20:22

What happened to the seaf-cli client? All I see is the seafile-daemon and the applet. I can't use the applet with a headless box.

kevincox commented on 2013-11-04 21:34

Sorry, I don't know how I managed it but the order in which I built them allowed the new seafile-client to build but couldn't link. Rebuilding seafile-shared then seafile-client fixed it.

Cheers.

kevincox commented on 2013-11-04 21:26

That's good to have the new Qt applet (the web one kinda sucked TBH) however I get the following error when starting seafile-applet.

$ seafile-applet
seafile-applet: error while loading shared libraries: libseafile.so.0: cannot open shared object file: No such file or directory

calrama commented on 2013-10-30 20:38

This package has now been changed to use the new Qt-based seafile-client, as the old one is going to be dropped soon (see the discussion on this issue: https://github.com/haiwen/seafile/issues/406).
However, the new client in the seafile-client repository depends on some of the shared core components of seafile, which were previously part of this package; these have been moved out to the seafile-shared package, as they aren't really part of the actual client.

calrama commented on 2013-08-20 09:31

Thanks for the info, you might simply want to flag out-of-date next time (I've done it this time), though, as that produces less comments (which people have to look through if for some reason the package doesn't work for them).

Once ccnet is updated to use 1.8.0 I'll update this.

calrama commented on 2013-08-20 09:30

Thanks for the info, you might simply want to flag out-of-date next time, though, as that produces less comments (which people have to look through if for some reason the package doesn't work for them).

Once ccnet is updated to use 1.8.0 I'll update this.

Anonymous comment on 2013-08-20 04:39

Version 1.8.0 is out. I've updated the PKGBUILD here:

http://pastebin.com/7x67pFQj

I stripped out the sha sums out of pure laziness, sorry about that.

calrama commented on 2013-08-04 12:06

> Why don't you use the source-releases from https://github.com/haiwen/seafile/releases
> They provide a "zip" Download-Link for each tagged release.

(1) Because the ccnet package doesn't do it and seafile-client depends on it
(2) Because haiwen's tagging is arbitrary and not done in the usual clear way (i.e. only the version number, no extras).

> The current package builds, but the web-interface of seafile has a python-error when you click any link in it:

I cannot reproduce that error on any of my machines (x86_64 VirtualBox VM, x86_64 Native, i686 Native). The package builds on all of them and I can use all settings / click all links in the web-interface of seafile-client, as well as download / synchronize my libraries with my private server running the seafile server (from the AUR package seafile).

Sorry, but I don't know how to help you here.

Anonymous comment on 2013-08-04 10:01

(sorry for the many edits, i thought it would work now, but it doesn't)

The current package builds, but the web-interface of seafile has a python-error when you click any link in it:

Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/web/wsgiserver/__init__.py", line 1245, in communicate
req.respond()
[...]
File "/usr/lib/python2.7/site-packages/web/httpserver.py", line 319, in log
print >> outfile, utils.safestr(msg)
IOError: [Errno 5] Input/output error

Anonymous comment on 2013-08-04 09:53

Why don't you use the source-releases from https://github.com/haiwen/seafile/releases
They provide a "zip" Download-Link for each tagged release.

calrama commented on 2013-07-08 12:42

Until now, I've written emails, but I'll write it here once for reference:

1) Seafile gets (at the moment) released here: https://code.google.com/p/seafile/downloads/list
2) Binaries for Seafile are currently released before source tarballs
3) There's no point in flagging seafile-client out-of-date *until* these source tarballs become available, even if new binaries have been released because without the source tarballs, this package cannot be built.

Example: At the moment of me writing this comment the latest released source tarball is version 1.7.1 (as is this package), while the latest released binaries are 1.7.3 (they were released two days prior). I cannot update seafile-client to 1.7.3 until
i) the source tarball for 1.7.3 gets released (which usually takes a couple of days)
ii) the ccnet package gets updated, as usually both get changes that make compiling the client without the exact proper ccnet version not possible.

It is sensbile to flag seafile-client out of date as soon as you notice i) and I'll push the new PKGBUILD when notice ii) (and have the time)

calrama commented on 2013-06-24 12:24

Thanks for flagging out of date, but please don't flag out of date AND comment about it unless the comment has important info, as it sends two mails about the same issue with the same amount of information in them.

calrama commented on 2013-06-24 12:17

Thanks for flagging out of date, but please don't flag out of date AND comment about it unless the comment has important info, as it sends two mails about the same issue with the same amount of information in them.

pi3r1k commented on 2013-06-24 10:57

Seafile 1.7.1
https://seafile.googlecode.com/files/seafile-1.7.1.tar.gz
md5sum 7c1f2f0c7ae6fe913b610e413fd8bb85
sha256sum 8bce8f727deebc71c04a0e1b6ad3d9d39a6454858128a0e75e1903d59fabef79

oliver_aur commented on 2013-06-22 12:58

thanks. Looks good now

calrama commented on 2013-06-21 22:32

Technically, that shouldn't happen, because the python binary gets explicitly set to python2 when configuring (see the ./configure line in the PKGBUILD), so I'd say that this is a bug in upstream; I've included a patch to take care of that for now.

oliver_aur commented on 2013-06-21 22:14

The first line of /usr/bin/seaf-cli needs to be updated in order to successfully run

The generic installed version (#!/usr/bin/env python) gives me the following:
$ seaf-cli status
File "/sbin/seaf-cli", line 105
print "%s not found in PATH. Have you installed seafile?" % prog
^
SyntaxError: invalid syntax

If I modify it to be #!/usr/bin/env python2 it works

$ seaf-cli status
# Name Status Progress

# Name Status
conf_files synchronized


Is there some fancy way I'm missing that enables the correct version of python to be selected without modifying the packaged file?

calrama commented on 2013-03-07 11:33

I will (as in can only when) update this when ccnet has been updated.

calrama commented on 2013-02-27 16:38

Hm, you're right, though I don't know why I had intltool installed (and thus not notice this). I never installed it explicitly and there was no package installed that depends on it... Anyway, it's in the dependencies now, thank you.

xeross commented on 2013-02-27 14:15

./configure: line 13399: intltool-update: command not found
checking for intltool >= 0.35.0... found
configure: error: Your intltool is too old. You need intltool 0.35.0 or later.
==> ERROR: A failure occurred in build().
Aborting...
==> ERROR: Makepkg was unable to build .

Needs a builddep on extra/intltool?

calrama commented on 2013-02-26 13:34

Sorry about that, it was in the dependencies before, I must've accidentally deleted it when adopting it to build from source. It's done now.

mbunkus commented on 2013-02-26 13:30

Another issue occurs when I want to start seafile-applet:

Load config from /home/mosu/.ccnet
Traceback (most recent call last):
File "main.py", line 75, in <module>
default_filters=['decode.utf8'])
File "/usr/lib/python2.7/site-packages/web/contrib/template.py", line 107, in __init__
from mako.lookup import TemplateLookup
ImportError: No module named mako.lookup


Installing "python2-mako" helps, so please add it to the dependencies.

calrama commented on 2013-02-26 12:36

No problem. Anyway, I'd suggest putting this flag into your /etc/makepkg.conf (https://www.archlinux.org/pacman/makepkg.conf.5.html).

This way it will get used by makepkg automatically *unless* the make call in the PKGBUILD specifically states -j1, to which I've now just updated this packages PKGBUILD. In essence:
(1) Move -j3 to /etc/makepkg.conf into the line "#MAKEFLAGS=" and uncomment it.
(2) Try building with the package release I just uploaded

mbunkus commented on 2013-02-26 12:26

Yes, I do. I have "export MAKEFLAGS="-j 3"" in my shell startup files. I've temporarily removed it and re-built seafile-client. It works now. Thanks for the fast response.

calrama commented on 2013-02-26 12:24

The same error occurs on ccnet when building with more than one job, so do you use more than one job? If so, try changing make to make -j1 in the PKGBUILD.

calrama commented on 2013-02-26 12:23

The same error occurs on ccnet when building with more than one job, so do you use more than one job?

calrama commented on 2013-02-26 12:22

The same error occurs on ccnet when building with more than one job, so do you use more than one job?

mbunkus commented on 2013-02-26 12:21

And sorry for flagging out of date, I confused client with server version numbers. Still, the error does happen.

mbunkus commented on 2013-02-26 12:18

This package does currently not build due to an error during compilation:

In file included from ../common/rpc-service.c:39:0:
../../lib/searpc-marshal.h:1027:13: error: redefinition of ‘register_marshals’
../../lib/searpc-marshal.h:816:13: note: previous definition of ‘register_marshals’ was here
../../lib/searpc-marshal.h:816:13: warning: ‘register_marshals’ defined but not used [-Wunused-function]

calrama commented on 2013-02-23 17:07

Adopted this package, it will now be build from source to avoid python2/python3 problems.

calrama commented on 2013-02-23 15:58

Please make this compile from source, because the precompiled binaries expect python to be python2 instead of python3, which means this will not work with python3 installed, as the connection between applet and server is a python script that won't start, breaking the entire client. To change this the PYTHON variable needs to be set to /usr/bin/python2 at ./configure time.

I have a working PKGBUILD that also builds upon the already available ccnet and libsearpc packages:

http://pastebin.com/raw.php?i=UkMiPZYw

calrama commented on 2013-02-23 15:55

Please make this compile from source, because the precompiled binaries expect python to be python2 instead of python3, which means this will not work with python3 installed, as the connection between applet and server is a python script that won't start, breaking the entire client. To change this the PYTHON variable needs to be set to /usr/bin/python2 at ./configure time.

I have a working PKGBUILD that also builds upon the already available ccnet and libsearpc packages:

http://pastebin.com/raw.php?i=LLYYShCs

calrama commented on 2013-02-23 15:55

Please make this compile from source, because the precompiled binaries expect python to be python3 instead of python2, which means this will not work with python3 installed, as the connection between applet and server is a python script that won't start, breaking the entire client. To change this the PYTHON variable needs to be set to /usr/bin/python2 at ./configure time.

I have a working PKGBUILD that also builds upon the already available ccnet and libsearpc packages:

http://pastebin.com/raw.php?i=LLYYShCs

mbunkus commented on 2012-12-29 19:47

If Python 3 is installed in addition to Python 2.7 then the ccnet-web.sh will start the wrong Python executable. /usr/bin/ccnet-web.sh simply calls "python ..." which is a symlink in /usr/bin to the actual Python version. For me this was /usr/bin/python3, resulting in various syntax errors and, after having manually fixed those, in "module XYZ not found".

So please fix ccnet-web.sh to call "python2.7 ..." instead of simply "python ...".