6.2.5 seahub 500 ISE and ImportError

Since Slackware is very different from raspbian, you have to compile your own version or it won’t work. The ARM version isn’t for generic and so you could use rasbian directly, in a LXC container (Seems that they’re very good supported by Slackware) or compile it yourself.
Why do you want to use Slackware? Any purposes?

That’s why I was mentioning that I’m on Debian, and that my folder structure would be different than yours. Out of all the OS’s I’ve run Seafile on, Debian is the most stable, followed closely by Ubuntu, which is based on Debian.

I’ll try to backtrace through the code to see what it is that is passed to that function. According to the error, the service it is requesting in the req_str does not exist, which is passed from another program. I just have to find out what function/program is sending that request and see if I can narrow it down some. Unfortunately, I’m out of time before my next appointment, so I’ll have to dig into it later.

The ARM version of SeaFile isn’t for generic Linux.

Although I’m somewhat familiar with Slackware, I’ve never used it. Is it a generic Linux type? Are you saying that he should use the generic version of Seafile on Slackware, or that he should compile it himself? If the latter is the case, which one should he try to build? Just asking for my own education and knowledge.

https://en.wikipedia.org/wiki/Slackware
It very Unix-like and has it’s own init process. I think this is the problem, there are some not right linked dependencies or something else. So if he want to use Slackware he should compile it himself.
Even if the ARM package is made with make dist it’s still for raspbian and will just work with similar Linux distributions, not with all the distributions who will work with the x86/amd64 version of SeaFile.

That makes sense. I looked at some of the code and something is being passed to python that it doesn’t like, so that is a likely culprit.

Yeah, that’s right, you have to compile most software yourself unless a 3rd party offers a prebuild binary (ie. latest firefox). But of course I tried using the “Server for generic Linux” from the download page before building, but this utilizes SELinux which isn’t available. I think the “Server for Raspberry Pi” doesn’t, but I didn’t try. My workflow is: test building on an x64 system, if that works try it on the pi.

Since this thread has some nice instructions so my next step will be building 6.2.5 with these. I home I can find some time to do it before the weekend. I’ll report back with any clue that may give.

Speaking of time, I really appreciate all the effort and time you guys are putting into this :slight_smile:

2 Likes

If you have compiling issues, always ask maybe we can help, even if we’re bot on Slackware, but if they are really complicated, I’ll run a VM and will try it.

Diversity is always important for Linux. If everyone runs Ubunutu or Red Hat, you could use directly Windoof.

I totally advise to try Slackware anyway, but be careful, it’s highly addictive :wink:

Back to topic:
I’ve rebuilt using @TCB13’s instructions. It works! :man_dancing: Both on the pi and on x86_x64. Unluckily I still don’t have a clue why it didn’t in the first place.

TODO:
upgrading on 6.3.x due to django EOL
post info here
:heart: the instructions

1 Like

Becuase of the framework’s init systems and run/execution directories.

E.g., Debian mounts /run with the -- noexec option and seafile for rpi is compiled to run it elsewhere. But Slackware needs the link setted under the /run directory. The versions aren’t compatible to Slackware.

@dennis you are talking about this instructions: Compilation ARM64 - DONE

1 Like

Seems they’re good for every Linux and every architecture.

1 Like

Yes, this one. It’s linked in my previous post, so I didn’t link it again. Good job, thank you very much :slight_smile:

As bionade24 says, it should work for every linux. Maybe it should be moved to the tutorials section.

1 Like

Now made.

@dennis @bionade24 have you noticed any RAM issues with the web interface? I’m using this on a device where I can only afford to spare 150MB of RAM to Seafile and the WebUI is so so slow.

Yes, it’s even so slow with 16GB RAM on amd64. They rewrote seahub in React.js and now it has performance problems on any platform, Of course, maybe the new interface doesn’t work smooth with 150MB RAM, but when they release a pro version, they’ve fixed the performance issues and we will get CE 6.3.2.

1 Like

I didn’t notice the webui being slow, but that doesn’t necessarily mean it isn’t slow :slight_smile:

Building and upgrading to 6.3.1 went pretty smooth. Only exception: the build script (seafile-server/scripts/build/build-server.py) asks for flup which isn’t listed in seahub’s requirements.txt. I didn’t try to remove the check, but I think flup was required for fastcgi.

It’s slow for SeaFile, slower than 6.2.5