Seafile Server 8.0.3 for Raspberry Pi is ready! 13.02.2021

@jobenvil In the seahub_settings.py I have inserted below as mentioned in the manual, to get the “Shared from other server” enabled.

Enable OCM

ENABLE_OCM = True
OCM_PROVIDER_ID = ‘71687320-6219-47af-82f3-32012707a5ad’ # the unique id of this server
OCM_REMOTE_SERVERS = [
{

Is the ID random, or unique generated somewhere? I’m not sure were it has to come from.

I’m a fan of the software and its opportunities and how it is developing :ok_hand: :+1:

I was not able to get the 8.0.3 version compiled by my self up and running last week, but I think I missed some actions to get it working, I guess it is simple things I missed, but I hadn’t got the time :slight_smile:

I did

apt-get install libmysqlclient-dev

sudo pip3 install -U future mysqlclient

as indicated in Upgrade notes for 8.0.x - Seafile admin manual

but I still have the same problem

@Howmann I was not aware of such integration. I don’t have any idea how to debug it. You should open a new issue to catch more attention.

You have to be very careful with the user flags in pip3 install and double check that your seafile user is able to use the moduls. Check with pip3 list as a root and later as Seafile user to compare the seafile dependencies.

Which distro? Which Seafile Package? Wich Python Version is being used by Seafile?

According to this [RESOLVED] Seahub does not start after upgrade from 7.1.5 to 8.0.3, i could update my 7.1.5 version to 8.0.3 :slight_smile:

I did this :
apt install libmariadbclient-dev
and all is right.

1 Like

@fafar Thanks for posting your efforts, that’s help for others. You are right, this should be on the installation guide (x64). There is just the mention to libmysqlclient-dev not to libmariadbclient-dev but many users have mariadb. That’s also true, that those users should recognice his database type and choose accordingly. @N_Zilio maybe is your issue?

I had the same issue, and as using a mariadb docker container this solved the issue on my side :slightly_smiling_face:

Indeed, that did the trick! Thanks again for the help, it’s very much appreciated.

@xiez any chance to reflect both databases in the docs/manual?

IMO, if the update notes state: Debian 10, then these notes should suggest to use the mariadb dev libraries and not otherwise. I say this just observing the fact that mariadb has substituted mysql long time ago in Debian mainline.

It is true that one could “figure it out” that the note is inprecise. In fact that is precisely what I did when I first posted the problem and then I myself marked it as resolved and posted my explanation… However, I think that if one has to figure that some note or documentation is misplaced then I think we are defeating the purpose of the notes being something helpful. :smiley:

2 Likes

I’m using myself mariadb. The issue is that the manual is not wrote exclusively for Debian 10 an therefore should be avoided just to write indications only for mariadb.

Anyway, I didn’t wrote the manual myself :laughing:

Do you still need volunteers?
I have installed seafile in odroid n2 (arm 64) ubuntu 18.04

Thanks for asking, actually you have to talk to @Gustl22 , he is building the x64 versions.

Dear supporters,

@Tjelfe, @mehlkopf, @squirrel, @Termi2, @fakuivan, @Cisco, @Howmann, @Bernie_O, @langhaarschneider

I need volunteers to test the new Seafile Server v8.0.5 for ARMv7 (32bits)? It is buid for Ubuntu Focal . (earlier versions like Xenia and Bionic may not probably work!!).

The version v8.0.5 runs fine since a couple of hours and It was compiled with the flag --ldap, but since I’m not using LDAP, it’s difficult to say.

Thanks my dear friends :green_heart:

I would not complain if someone else wanted to take over this task. I made a description, how to build for the different Debian versions. If you have problems, don’t mind to write a PN.
If you are finished, you can send me the files to test and forward them to @jobenvil for the release :slight_smile:

Hello,

at first my setup:
Debian 10 (64bit) Docker container on my 64 Bit Raspi OS / Raspberry Pi 4:
No ReverseProxy, just direct communication to the container port

the following did work for me:

  • successfully run the build3 script inside debian 10 container
  • successfully run the script /home/seafile/seafile-server-8.0.3/setup-seafile-mysql.sh
  • successfully started seafile.sh and seahub.sh
  • sucessfully accessed the login page at http://192.168.180.111:8000

But after login, I get error 500.
The logs are showing something like “asset = assets[‘assets’][chunk]”. After my research, I could not find anything useful, to solve this issue.

Any idea what I may did wrong?

Heres, the full seahub.log

2021-06-06 20:21:21,314 [ERROR] django.request:228 log_response Internal Server Error: /
Traceback (most recent call last):
  File "/home/seafile/seafile-server-8.0.3/seahub/thirdpart/django/core/handlers/exception.py", line 34, in inner
    response = get_response(request)
  File "/home/seafile/seafile-server-8.0.3/seahub/thirdpart/django/core/handlers/base.py", line 115, in _get_response
    response = self.process_exception_by_middleware(e, request)
  File "/home/seafile/seafile-server-8.0.3/seahub/thirdpart/django/core/handlers/base.py", line 113, in _get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/home/seafile/seafile-server-8.0.3/seahub/seahub/auth/decorators.py", line 27, in _wrapped_view
    return view_func(request, *args, **kwargs)
  File "/home/seafile/seafile-server-8.0.3/seahub/seahub/views/__init__.py", line 1214, in react_fake_view
    'enable_share_to_department': settings.ENABLE_SHARE_TO_DEPARTMENT,
  File "/home/seafile/seafile-server-8.0.3/seahub/thirdpart/django/shortcuts.py", line 36, in render
    content = loader.render_to_string(template_name, context, request, using=using)
  File "/home/seafile/seafile-server-8.0.3/seahub/thirdpart/django/template/loader.py", line 62, in render_to_string
    return template.render(context, request)
  File "/home/seafile/seafile-server-8.0.3/seahub/thirdpart/django/template/backends/django.py", line 61, in render
    return self.template.render(context)
  File "/home/seafile/seafile-server-8.0.3/seahub/thirdpart/django/template/base.py", line 171, in render
    return self._render(context)
  File "/home/seafile/seafile-server-8.0.3/seahub/thirdpart/django/template/base.py", line 163, in _render
    return self.nodelist.render(context)
  File "/home/seafile/seafile-server-8.0.3/seahub/thirdpart/django/template/base.py", line 937, in render
    bit = node.render_annotated(context)
  File "/home/seafile/seafile-server-8.0.3/seahub/thirdpart/django/template/base.py", line 904, in render_annotated
    return self.render(context)
  File "/home/seafile/seafile-server-8.0.3/seahub/thirdpart/django/template/loader_tags.py", line 150, in render
    return compiled_parent._render(context)
  File "/home/seafile/seafile-server-8.0.3/seahub/thirdpart/django/template/base.py", line 163, in _render
    return self.nodelist.render(context)
  File "/home/seafile/seafile-server-8.0.3/seahub/thirdpart/django/template/base.py", line 937, in render
    bit = node.render_annotated(context)
  File "/home/seafile/seafile-server-8.0.3/seahub/thirdpart/django/template/base.py", line 904, in render_annotated
    return self.render(context)
  File "/home/seafile/seafile-server-8.0.3/seahub/thirdpart/django/template/library.py", line 192, in render
    output = self.func(*resolved_args, **resolved_kwargs)
  File "/home/seafile/seafile-server-8.0.3/seahub/thirdpart/webpack_loader/templatetags/webpack_loader.py", line 12, in render_bundle
    tags = utils.get_as_tags(bundle_name, extension=extension, config=config, attrs=attrs)
  File "/home/seafile/seafile-server-8.0.3/seahub/thirdpart/webpack_loader/utils.py", line 62, in get_as_tags
    bundle = _get_bundle(bundle_name, extension, config)
  File "/home/seafile/seafile-server-8.0.3/seahub/thirdpart/webpack_loader/utils.py", line 40, in _get_bundle
    bundle = get_loader(config).get_bundle(bundle_name)
  File "/home/seafile/seafile-server-8.0.3/seahub/thirdpart/webpack_loader/loader.py", line 90, in get_bundle
    asset = assets['assets'][chunk]
KeyError: 'assets'

atm use this slightly modified version, Explanation is here. You will recognice your error at the bottom. I had the same issue with wrong requirements.txt file.

Thanks jobenvil! Your solution did the trick!

I was just wondering that the build3.sh script you mentioned is hostet at different locations…, github, pastebin. I assume that github is the official repo?

Legit! it’s difficult to understand without previous knowledge. The build3.sh script which is hosted on seafile rpi repo is maintained by the community, me included. With almost each new released Seafile x64 version we face similar problems while compiling, mainly that the requirements.txt file from the x64 repo differs from the one which is served to download here. We compile using the one from the official x64 repo and it fails seahub to start. Either by not listed thirdpart modules, either by the version level constriction is outdated or not accurate, etc, If you compare, for example the requirements.txt from official repo, tag v8.0.5 are these

Django==2.2.14
future
captcha
django-statici18n
django-webpack_loader
gunicorn
mysqlclient
django-picklefield==2.1.1
openpyxl
qrcode
django-formtools
django-simple-captcha
djangorestframework==3.11.1
python-dateutil
requests
pillow
pyjwt==2.1.*
pycryptodome
requests_oauthlib:

If you use this requirements.txt file, seahub will not be able to start. You should morever use these requirements.txt file, with django-webpack_loader==0.7.0:

Django~=2.2.17
future
captcha
django-statici18n
django-post_office~=3.3.0
django-webpack_loader==0.7.0
gunicorn
mysqlclient
django-picklefield~=2.1.1
openpyxl
qrcode
django-formtools
django-simple-captcha
djangorestframework~=3.12.2
python-dateutil
requests
pillow
pyjwt==2.1.*
pycryptodome
requests_oauthlib

from here, the repo which I use for testing and you got with pastebin.

After a succesfully built version, the binaries are shared in Github and the community gives the feedback. After a positive feedback --release is able to start and functionalities are tested, I update the script to point to the requirements.txt file which did the trick. If the official one did the trick, is much better and we point the script to that file, but not always is the case. Since I’m not able to modify the official requirements.txt file in Seahub repo, I’m obliged to create my own requirements.txt file on my repo and to refer to that file.

Finally, it means, that the build3.sh script that you got by pastebin, will most probably become the new “official” build3.sh one under the seafile-rpi repo --after merging, but sadly, this just will work with the last tagged version v8.0.5 and not anymore with 8.0.3 or earlier versions since the requirements.txt is statically linked and there is no if, else, elif statement to choose for the tag version.

26 #PYTHON_REQUIREMENTS_URL_SEAHUB=https://raw.githubusercontent.com/haiwen/seahub/master/requirements.txt  # official requirements.txt file
27 PYTHON_REQUIREMENTS_URL_SEAHUB=https://raw.githubusercontent.com/jobenvil/rpi-build-seafile/main/seahub_requirements_v8.0.3.txt # Only for build the 8.0.3 version
28 PYTHON_REQUIREMENTS_URL_SEAFDAV=https://raw.githubusercontent.com/haiwen/seafdav/master/requirements.txt