Arch Linux User Repository

@johnwallaby Thanks for your report, python-future has been removed from dependencies. It's an old requierement.

hi @Joffrey, first of, thx for maintaining the package! I have a question though. The package has a dependency on python-future (https://aur.archlinux.org/packages/python-future) which does not build against the current python version. As it is not really clear for me why this is needed and replacing the dependency with python itself seems to work fine, would it be a possibility to modify the PKGBUILD in this way?

@mehrad, no please install the base-devel package as advised on the aur page on the wiki: https://wiki.archlinux.org/title/Arch_User_Repository#Getting_started

I believe the automake and autoconf should both be added as compile time dependencies.

@bionade24 The strange thing is that the library has been created a couple of months ago, and everything worked up to this morning, with a manual sync operation performed every day. So if "two months ago" is recent enough to make it a "new, actually secure library" and thus without password then probably there never were entries in RepoPasswd, and still everything worked. If this is true then the lack of entries in RepoPasswd is not the cause of the problem.

I'll open the issue on GitHub.

Edit: https://github.com/haiwen/seafile/issues/2662

@snack: No, there shouldn't be one for the new, actually secure library types, like I already said in the last sentence.

It can only crash if something (e.g. a file attribute) of in the library folder changes, otherwise the repo is the same & no sync update is triggered.

I think you should open an issue on GH for this.

Well. the library is just a backup of one local folder. I will simply remove and re-create it, and see if this fixes the problem. Still I don't understand why it worked until yesterday and then today it stopped working, since there was no seafile update in the middle.

Edit: actually there's no entry in the RepoPasswd table of repo.db. Could this be the problem? If yes, I really don't understand why it vanished since this morning.

@snack You're right, I should have looked closer. From a quick look at the code, encrypted libaries on the latest version shouldn't store the password locally, only the derived key. Do you maybe have a very old encrypted library. Anyway, if you want to investigate further, you can start at add_task_common(), your passwd arg has already is 0 there. Maybe you can also check if you have any password still stored in repo.db. I don't, even though I have encrypted libraries.

As I guessed by looking at the gdb trace below, the issue is with the passwd argument of seafile_decrypt_repo_enc_key being NULL. Indeed, line 239 of common/seafile-crypt.c is:

seafile_derive_key (passwd, strlen(passwd), enc_version, repo_salt, key, iv);

and after installing the glibc-debug package (debuginfod didn't work) the gdb trace shows:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:76
76              VPCMPEQ (%rdi), %ymm0, %ymm1

So I think that the segfault comes from the call to strlen(passwd) with passwd being NULL.

@snack You need to install & activate https://wiki.archlinux.org/title/Debuginfod to get debug symbols for the libraries that seafile-daemon uses. Then you can try run the same coredumpctl cmd again, but this time there should be proper function names instead of ()