Preliminary work for Seafile 10.0 #122
Comments
|
Thank you for maintaining this here. |
|
I simply upgraded the golang version for my raspberrypi (bullseye) with this tutorial https://www.e-tinkers.com/2019/06/better-way-to-install-golang-go-on-raspberry-pi/ I was then able to build seafile 10.0.1 with the build.sh script. I had to remove the line in build.sh where golang is installed via apt. I used the same requirements as for v9.0.9. for seafdav and the ones ChatDeBlofeld mentioned for seahub (https://github.com/haiwen/seahub/blob/master/requirements.txt) I second lanmarc77's suggestion to use a docker based build environment. |
|
I was able to build seafile 10.0.1, golang is not a problem as you can install and activate every version with gvm. |
Where do you get that internal server error? I got an error starting seahub when using the v9.0.9 requirements to build. But after using the ones mentioned above my installation works flawless so far. |
|
Seahub starts without error, but web interface shows internal error. Used same requirements as above. And stopping seahub shows "failed to stop seahub", but it is stopped.....Maybe some problem with some requirement or somewhat. |
|
@nihilistaX Try to set @lanmarc77 I won't work on such an integration but yes it certainly works. Universal binaries will be harder though since the server depends on libc (see below), I don't even know if it possible to static link it... However, I built a fileserver on buster (which has oldest versions of dependencies) which should work fine on later versions. $ ldd fileserver
linux-vdso.so.1 (0x0000007f8b365000)
libresolv.so.2 => /lib/aarch64-linux-gnu/libresolv.so.2 (0x0000007f8b30e000)
libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000007f8b2fa000)
libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000007f8b2c9000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007f8b154000)
/lib/ld-linux-aarch64.so.1 (0x0000007f8b335000)I've added support for notification server (ChatDeBlofeld@23acec9), which is written in go too 🙃. Pretty ugly, backward compatibility is broken (but it was already the case when the go fileserver was added and it seemed ok at the time) and I patch the |
|
@ChatDeBlofeld thanks for your work! I wrote the maintainers to merge your PR (but don't know, if they actually do). Also if you feel ready you can start a PR for v10. I also wrote you a message on LinkedIn. |
|
PR was merged, thanks! I will start a PR for 10.0.1, maybe should we write down somewhere the minimal go requirements to build the server? |
|
Hi @lanmarc77 @Duke690 @nihilistaX Static linking libc in go happened to be very easy, so I set up an experimental docker pipeline to cross-compile seafile from amd64. You'll find some compiled packages for seafile 10 here. If some of you want to test them it would be very helpful! |
|
Hi @ChatDeBlofeld , @Gustl22 I would like to add automated tests of these builds to get rid of the human more or less completely for the testing process. And how about renaming seafile-rpi into seafile-arm? |
|
Small Update, went down the rabbit hole kinda... I am now using the newest Go version 1.20.4 which is downloaded and installed inside the build container during creation. This allows compiling also for older distributions directly in the container type it is meant to run later. I am currently compiling only with the requirement that come with the original repos. Are there any reasons beside maybe historical ones that there are version specific requirements which you apply ahead? It did compile without them, also for tests I did with 9.0.9 and 8.0.7. I released 10.0.1 for all major distributions for everyone who wants to test: https://github.com/lanmarc77/seafile-arm/releases No tests have been conducted so far. |
|
Wow @ChatDeBlofeld @lanmarc77 that looks very promising, if you feel comfortable, you can start a Merge Request, if you want, or even start it as Draft, if you don't feel ready to merge yet ;D |
|
Hi @Gustl22 , I am unsure before I could implement automated tests. |
|
Hi, tested bullseye aarch64 and armv7l builds, as upgrade and as fresh install, but seahub won't start. |
Solved for me in Ubuntu by installing python3-django-appconf |
|
@nihilistaX , yes I already detected missing dependencies in the packaging and adjusted the new build scripts. |
|
@ChatDeBlofeld, @Gustl22 In addition to downloading the newest go instead of using the distribution one now also the newest rust is downloaded and installed. This allows compiling of the newest python cryptography library as well so that we can get more or less CVE free libraries even on older distros. |
Will test that maybe tomorrow.... Edit: Now seahub starts. No time for more testing, but seems to work. |
|
@nihilistaX , thank you for your time. Meanwhile I updated all other packages and hope for anyone who can check and report back https://github.com/lanmarc77/seafile-arm/releases |
|
@lanmarc77 |
|
I was able to update my own system from version 9 using bullseye armv7 and everything I use works without issues. |
|
Hi @lanmarc77, that's a great work! Here some thoughts, you may find something informative.
Most of the time when something doesn't work it is due to missing dependencies, other cases are probably too hard to forecast and don't worth the effort. Then I think just checking if it launches is enough.
In this case you don't need to link statically the go parts but it probably doesn't hurt. I've deliberately avoided to install Go packages because I target RISCV too and the packages don't exist, but that's my business. :)
Just warning, but maintaining a per-distro pipeline can be cumbersome, qemu and docker are sometimes...capricious. For example I can't build for focal targeting arm/v7 because of this. Just ran a build for jammy and got some TLS handshake errors, didn't dig further. It can be tiring. As you have seen, I'm not often implied. That's why I tried to make a "universal" package based on buster to reduce maintenance. It implies to ship less python dependencies though (mostly every that are not pure python) but nothing not written in the manual. In a way, I find it very convenient because building a wheel for cryptography is the most painful thing I've experienced in this project, with weird stupid bugs arising from time to time (and I didn't even know there were CVE on top of that).
Not sure, but requirements used to be regularly broken. Since version 10 most versions are pinned, so it should be better. |
|
Hi @ChatDeBlofeld, |
Indeed, but the work should be done for us by the devs, as this is the way they ship the amd64 packages. The manual specifies a bunch of prerequisites which work for us too. But I agree this is less convenient for the users.
Probably. These issues should intersect with ones from amd64 users though, then the trade-off looks ok to me.
Wouldn't this slope eventually lead us to some containerization tool like docker? :D Not that I wouldn't like it, for me it is the best way to deploy such an application, but not sure it's the goal here (or it is?). Anyway, there is pros and cons in both case... |
|
Indeed, we finally would end up with docker. I just checked, there seems to be no armv7 version though. Yet... My next steps are cleanup and documentation of how the build process works and then stay with my fork and wait for the next update to see how much this works with new releases. Ideally no intervention is needed. Even more ideal would be if the original project checks the build process and uses the tests before actually making a new release. I will try to reach out to them after cleanup and documentation. Thank you for your input. |
|
After some time using this builds on 2 machines i see that seafdav seems not to work. Checked seafdav port but thats not opened. |
|
This is caused by #113 Forgot it when saying upstream requirements used to be broken, they still are... |
|
Hi, |
|
First short test on armv7l and aarch64: Seems to work now. Couldnt get inside subfolders first but maybe thats maybe cache issue. With /seafdav/subfolder its works. After manually typing that all fine for now. |
|
Thank you all @ChatDeBlofeld @lanmarc77 @nihilistaX . Sorry that I stood out of the conversation. As I'm not using the cloud on arm anymore on a regular basis, I'm not familiar with the current development of seafile, and also I cannot put too much time into it. If you come up with a working solution, I'm happy to review any Merge Requests and then we can push the active development with further volunteers. Thank you! |
|
Hi @Gustl22 , I just updated my fork https://github.com/lanmarc77/seafile-arm with what I think is good enough for now. Locally everything builds and tests. Online only Buster and Focal arm/v7 do not build. In buster there is a mysterious SSL certificate error, in focal a cmake error that seems to connect to a kernel issue with readdir. As the Github pipeline uses an older Ubuntu I guess we just need to wait until they update. |
|
@lanmarc77 wow that looks like you put a lot of work into the project. Would you mind open a Pull request to better review the changes? I also thought about making a whole new repo like |
|
@lanmarc77 the maintainers suggested to rename the repo after finishing the pipeline. If you're still interested, you can open a PR ;) |
|
@Gustl22 , I am unsure how you mean this. I already opened a PR against this repo. And what do you mean by finished exactly? |
|
@lanmarc77 I think you opened a Pull request to @ChatDeBlofeld and not to haiwen : https://github.com/ChatDeBlofeld/seafile-rpi/pulls |
|
@Gustl22 ah indeed, as ChatDeBlofeld did the static compiling part, I just created a PR for this repo |
Hi folks,
I've started the work to build Seafile 10. Compilation dependencies were straightforward to update (see ChatDeBlofeld/seafile-rpi@321057d) but python packages have been completely reworked upstream and I don't know how to merge them with the custom requirements we have here (which still have pending changes #120)
What I can tell so far:
By disabling the go fileserver when needed, I was able to build something usable for:
Tested features (22.04 only):
The text was updated successfully, but these errors were encountered: