Everyone can become a volunteer, sorry if i explicitely did not mention. There is a lot of room for improvements and you can help building the ARM Versions for armv7 or armv8 (x64). The tricky point is the seahub dependencies issue, like you already are aware. The impediments of python3 are so far as i can appreciate, already fixed.
Oh, sorry for the misunderstanding, my broken English is always quite an issue.
My point is I don’t want to volunteer for building native packages, but if this project plans to provide Docker images in the future (like the regular releases do), I will be glad to help setting it up and maintaining.
Here you’re intriguing me, any ideas to start working on?
@jobenvil The build script has been updated. You can give it a check: remove ccnet by SkywalkerSpace · Pull Request #84 · haiwen/seafile-rpi · GitHub
Thank you and works perfect!
Now the requirements.txt file is linked to the general master branch, not to a tagged version. This should not be an issue for us, since we built always the latest, but better will be to ammend the requirements.txt before to tag the release.
See requirements.txt from tagged v8.0.5-server versus master branch.
If we built right v8.0.5 will work, but older tags 8.0.4, 8.0.3 and 8.0.1 will probably not, since the requirements.txt link always point to master branch and is not aware of tagging. A version aware requirements.txt coul be indicated easly:
https://raw.githubusercontent.com/haiwen/seahub/${VERSION_TAG}/requirements.txt
This solution implies to update the requirement.txt file before to tag seahub, which is easily forgotten.
@Barolo sorry for the late reply: Indeed was an exaggeration.
I just remembered an old issue:
The community script is producing following folder python${NATIVE_PYTHON_VERSION_FROM_OS}
If for example we have the assumption ${NATIVE_PYTHON_VERSION_FROM_OS} = 3.8
It results the creation of the folder python3.8 under /sefile/lib like as:
seafile-server-latest/seafile/lib/python3.8
This lead to a critical error after starting seahub service:
Starting seahub at port 8000 ...
Traceback (most recent call last):
File "/media/sda/seafile/seafile-server-8.0.0/check_init_admin.py", line 19, in <module>
from seaserv import ccnet_api
ModuleNotFoundError: No module named 'seaserv'
Since the python version 3.6 is hardcoded on seafile (python folder version must be to 3.6) , we have to make a “mv python3.8 python3.6” to have /seafile/lib/python3.6
That issue is still open. I can imagine several ways to accomplish that but none is really elegant.
If they are rpi (armv*) related, we you could ask to devs to get a docker corner for rpi later, but meanwhile could be allocated under same GitHub - haiwen/seafile-rpi: Seafile server package for Raspberry Pi.. You can create a folder there containing a README.txt, etc.
@jobenvil The requirements.txt depends on the corresponding version now: fix requirements by tag by SkywalkerSpace · Pull Request #85 · haiwen/seafile-rpi · GitHub
1 Like
Fixed it with a symlink on my side…not more elegant…
# Fix import not found when running seafile
RUN ln -s python3.7 seafile-server-$VERSION/seafile/lib/python3.6
Ok great! I have some improvements to do but I’ll surely work on this way, will take some weeks though. I’ll take contact when I think I have something worthy to be added.
Dears,
I just try to build seafile server v8.0.5 using build3.sh with this commit (github_com / haiwen / seafile-rpi / commit / c5f733782c3144c52395fa1dfc5b29d4d863c3da) in Ubuntu Server 20.04.2 LTS (Focal Fossa) for aarch64 GNU/Linux. In the build process I’ve noticed the following message error:
Any idea/guide/fix/patch to correct the error message and the correct architecture arm64/aarch64?
Thanks in advance for your kindly answer/support!
Sorry for the format of the link to the last commit, I got a message telling me that I can’t include links in my post…(weird!).
Also, the following picture shows the wrong architecture built:
Thanks again for your kindly support.
Since the tagged version 8.0.5 doesn’t have the properly requirements.txt file, you should use this:
Use this:
./build3.sh -D -A -h https://raw.githubusercontent.com/jobenvil/rpi-build-seafile/main/seahub_requirements_v8.0.5.txt
I see you installed django-webpack_loader==1.1.0 from v8.0.5 but you need danjgo-webpack_loader==0.7.0
@plche This was happening erliaer. Don’t worry, the recognition for arm x64 bits is not properly matched (aarch64). If you insert a elseif loop inside the patch (build-server.py.patch) containing or modify the if statement, it will work
if 'aarch64' in platform.machine():
arch = platform.machine()@Barolo With the version from today (02.07.2021), you don’t need anyomore to do that.
1 Like
Dear @jobenvil,
Thanks for your support. I did what you suggested, but the error continued. However, I’ve found the solution, basically installing the package with: sudo apt-get install python3-testresources fixes it.
Dear @jobenvil,
Thanks a lot for this suggestion, it actually works well. In case someone else is having this same issue, what I finally did was modify the already downloaded build-server.py.patch like this:
Now is identifying properly:
---------------------------------------------
The build is successful. Output is: /home/ubuntu/built-seafile-server-pkgs/seafile-server-8.0.5-focal-aarch64.tar.gz
---------------------------------------------
[INFO] remove builddir before exit
-> BUILD COMPLETED.
Now that is built correctly, could you please suggest me a properly deploy method/guide ?
Thanks in advance!
Works like a charm. Nice work thank you, one hack removed!
1 Like
Very interesting. For me it is completely new that in v8.0.5 we must install sudo apt-get install python3-testresources. In fact,no one has raised such thirdpart until now. Are you totally sure? From your screenshot, I observe that you installed django-webpack_loader==1.1.0:
But the recommended version is django-webpack_loader==0.7.0. See in GitHub:
When I was testing last month , I discovered the issue. Meanwhile it is possible that django-webpack_loader==1.1.0 works if you install after that the thirdpart component that you mentioned earlier. If this is true (django-webpack_loader==1.1.0 && python3-testresources together fixes the issue) and your v8.0.5 release is working properly, you can suggest the devs to update dependencies accordingly. But please double check.
@plche great, would you mind to submit a PR here? If not, I can submit it for you. Thanks!
By the way, which device do you use, Raspberry Pi 4?
Sure, here is the section for mysql.. This is the official manual. I recommend you in case of questions, to search in the forum and if you cannot find it, to rise here your questions. Another unofficial source of knowledge is here:
Started by a member, who looks like is not activer anymore @danilo ??
Later, there are other guides, like the offered by a german active user @christophdb :
Dear @jobenvil,
I did issue the command as you suggested, but as I did over the previous built it seems to have no cleaned at all, checking the directory contents of haiwen-build:
I see that your requirements version was taken into account anyway, I can’t check locally the contents of it, because the script at the end removes it.
I will try to built it again and double check as you suggested. Will do it after I test the built is working fine, so will get back to you soon.
@plche yes, you are right, actually the thirdpart directory is not cleaned at all, so you will have both versions installed and just one will be used. We couldn’t remove the requirements.txt file and check for if at the beginnning of the thirdpart module and delete the content of thirdpart, so always start with a clean directory. Since there is the switch “-D” for dependencies and thirdpart modules, this will be ok in case you don’t want to reinstall them. The normal case should be now clean and install with new requirements.txt file.