Seafile Server 8.0.5 for Raspberry Pi is ready! 29.05.2021

You can get it from the Seafile download section.

:pushpin: Please remember:

  • Don’t forget to stop Seafile Server before the upgrade (i.e: service seafile-server stop or, another example: service seahub stop && service seafile stop)
  • Don’t forget to change the directory rights of Seafile after unpacking it (i.e: chown -R seafile:nogroup seafile-server-8.0.5 or, another example: sudo chown -R seafile:seafile seafile-server-8.0.5 )
  • Don’t forget to apply the upgrade script/s according your start release && with the properly user which in normal case should be seafile (i.e change to seafile user: su seafile -s /bin/bash or, another example: sudo su seafile)

Recommendations and clarifications

  • Download the properly rpi version for your OS. There are: Debian Stretch, Buster or Ubuntu Bionic, Focal. These were compiled against his own native libraries inside linux containers.

  • Users who need to chose Debian Stretch, they must install Python3.6+ to run seafile. The native Python 3.5 is not enough. You can choose to download and compile Python3.6.13 by yourself or use pyenv to do it automatically. Here the suggestions on the forum and common pitfails while using pyenv.

:eyes: We are still searching built volunteers for ARM Architecture (armv6, armv7, arm64v8). Let us a message in Seafile Forum

You can check Seafile release table to find the lifetime of each release and current supported OS.

Seafile Server ChangeLog here

Once again, thanks to the developers and Seafile Community.

have fun :blush:

4 Likes

Even though I don’t have an ARM server any more I appreciate your work for the community. :muscle: :+1:

thank you!

the announcement is tagged arm64, armv7, arm, but there’s currently no arm64 binaries, right?

@m.eik completely right, actually they are just binaries for arm32v7.

ok, i’m trying to compile from source using the build3.sh script on a machine running bionic, where python 2.7 is still the default (but 3.6 also installed). the configure scripts detect python 2.7 (except when python3 is run directly in the script, that is). do i have to adjust the script or the build environment to build against 3.6 instead?

I use lxc containers, where I already adapted the environment using pyenv (in such cases where the default einvironment is 2.7). I warmly recommend you to use pyenv for build Seafile. Use this build3.sh.

i get an access denied error with the link.

@m.eik sorry, I can imagine why. Here in pastebin: Seafile Server build script for ARM - Pastebin.com

thanks for hinting me to pyenv, that did the trick!

also thanks for the updated script. i have done some adjustments to it to accept options, i.e. so that i don’t always have to repeat the installation of dependencies each time it runs. it can also run the builds step by step so for debugging it is perhaps easier to spot where something goes wrong. let me know if you’re interested :wink:

1 Like

Yeah,sure. I would appreciate if you could merge these switches to the repo. Every improvement ist very welcomed.

great, i’ve issued a pull request.

could you explain toi me why VERSION_CCNET and VERSION_SEAFILE are fixed to 6.0.1?

1 Like

That’s a verry long story behind these both fixed variables and you can find many infos in Github commits, Seafile Forum and Release ChangeLog.

VERSION_CCNET=6.0.1 # ccnet has not consistent version (see configure.ac)
VERSION_SEAFILE=6.0.1 # ebenda for seafile

VERSION_CCNET is not being used anymore since the CCNET component was inserted in Seafile Server component, but the python script, which is still the created by Seafile Devs, needs the variable to built the binaries.

VERSION SEAFILE that variable is not really the one which we use to download the tag version and ist just used in the build process, because the SEAFILE_VERSION variable passed for the ‘build-server.py’ script needs to be the same as the CCNET_VERSION. Why? because a the beginning, many years ago, the tags for ccnet-server were properly tagged in GitHub but later, that was not the case. Therefore the configure.ac file was not updated anymore (stopped at 6.0.1) and we have to cheat the build-server.py script.

Summary: The passed version to the built-server.py are fake, but the binaries containing the packages are the one for $VERSION_TAG.

We pull the properly tags ($VERSION_TAG) for seafile-server with these commands here:

  if [ -d "seafile-server" ]; then
    cd seafile-server
    (set -x; make clean && make distclean)
    (set -x; git fetch origin --tags)
    (set -x; git reset --hard origin/master)
  else
    (set -x; git clone https://github.com/haiwen/seafile-server.git)
    cd seafile-server
  fi
  (set -x; git reset --hard $VERSION_TAG)
  (set -x; ./autogen.sh)
  (set -x; ./configure --with-mysql=$MYSQL_CONFIG_PATH)
  (set -x; make dist)

and here for ccnet-server:

if [ -d "ccnet-server" ]; then
    cd ccnet-server
    (set -x; make clean && make distclean)
    (set -x; git fetch origin --tags)
    (set -x; git reset --hard origin/master)
  else
    (set -x; git clone https://github.com/haiwen/ccnet-server.git)
    cd ccnet-server
  fi
  (set -x; git reset --hard $VERSION_TAG)
  (set -x; ./autogen.sh)
  (set -x; ./configure --with-mysql=$MYSQL_CONFIG_PATH)
  (set -x; make dist)

But again, for ccnet-server, there is no need anymore to do anything and the functionality is now integrated on the seafile-server component since release 8.0.0. The result is that the community ARM package carries a useless ccnet package inside. This is because we still use the old built-server.py script from Seafile developers, which is still inside of the seafile-server code, here:

python3 $SCRIPTPATH/$BUILDFOLDER/seafile-server/scripts/build/build-server.py

@daniel.pan is there a chance, that the community gets a new built-server.py for build the seafile rpi releases without the ccnet-server component? That’s will be great.

LGTM, but I have to compile at least one time to examine the logs. Thanks A LOT!

We will check the issue soon.

thanks for the comprehensive explanaition!

ok, the script could safely be stripped of the -c and -s arguments, then. no one will ever use them.

i’m glad if it helps. i use bash scripts so often that i’ve actually written a script that writes a new script for me from templates. they usually also generate a config file with all variables used when the script is run for the first time, but that didn’t seem to be very useful here.

I liked it. The built went fine. Already merged --both PR. Additionally, I made a small change for ccnet-server, since the tag v8.0.5 doesn’t exist on ccnet-server branch, avoiding the fatal error:

Resolving deltas: 100% (541/541), done.
+ git reset --hard v8.0.5-server
fatal: ambiguous argument 'v8.0.5-server': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
+ ./autogen.sh

i see. did i accidently change the logic, or was that already happening in the original script?

looks to me like ${VERSION_TAG} needs to be replaced with a fixed variable to always be v7.1.5. did you push your fix to the git repo yet?

He already did. And the logic was inherited from the previous versions. :slightly_smiling_face:
Anyway, just want to say thanks, your improvements will be useful to me.

Of course a big up to @jobenvil too for your constant work on this project, it’s really appreciated.
I see you’re still lacking of volunteers, sadly I won’t become one of them. But if there’s some milestone to provide Docker images et passing through this hell of different dependencies, distributions, platforms, …, I’m in. I already build mine anyway.

1 Like

Not your fault. The issue started to happening since last version 8.0.3. It was no impact at all, since it was pulled the master branch, just the tag was not found.

Good catch and yes, the issue was fixed with this commit.