Arch Linux User Repository

@bionade24, I see, it made sense to me in a -git package to have the sums as SKIP as the HEAD always change but as you said this is not really a valid attack vector here as we are using the official company Git repository as our source. This kind of precaution makes sense inside pre-compiled packages in the main arch repository but isn't really required here. I will update the package one last time to skip checksum verification. Thanks for the suggestion and explanation.

@orax Imho when you use a git tag as source you can 'SKIP' the pkg checksum, as git guarantees the integrity (that's what the -git pkgs in AUR do). In the linked xz PKGBUILD they either do it to prevent malicious attackers from force-pushing or because the git repo still uses SHA1 which one can compute collisions for with loads of gpus. I think neither 2 things are reasonable attack vectors for seadrive-gui, as it's much less popular than xz, maintained by a company and not some overworked guy in his free time. So when I proposed this, it did indeed solve the issue cause by Seafile force-pushing tags.

@bionade24 Thank you very much for those infos. Let me try to see what I can do. The issue here is more that they force-push the tag than the tarball itself (which as you said is generated by Github, this is not something the owner can manually updates).

On the other hand, I completely agree with you that it removes a potential attack vector to use the git repo directly, so I will be updating it to use that.

This will not fix the issue permanently tho as I said and I will still need to update the sources checksums regularly if they do indeed force-push over the tag.

In the end its a pretty ok tradeoff in my opinion as it forces me to check that everything do indeed still works even if it can be frustrating to see a broken build file sometimes.

@jbrouhard, as already stated by bionade, your build environment might be compromised. I just reran a build inside a completely clean container with just base-dev and the stated dependencies in this package and everything built fine.

@orax Since Seafile likes to update tags afterwards, I think it'd be smart to use the git tag as source instead of the tarball that Github creates to the tag. The source line for this looks like this:

source=("${pkgname}-v${pkgver}::git+${url}.git#tag="v${pkgver}")

The git tag method also prevents the Jia Tan manually uploaded release tarballs attack vector and is nowadays also used by official Arch maintainers: https://gitlab.archlinux.org/archlinux/packaging/packages/xz/-/blob/main/PKGBUILD?ref_type=heads

@jbrouhard: You gave yourself the answer to your problem:

on my work laptop no problem but on my desktop, where i have some ffmpeg-based items like OBS Studio and others

You have an unclean build environment. The appropriate way to build Arch pkgs is to build them in a clean chroot.

Have a weird problem: I can update this on my work laptop no problem but on my desktop, where i have some ffmpeg-based items like OBS Studio and others, seadrive-gui fails to build failing on the below:

Note: yes, libxml2 and libeavformat are both already installed in the system and were before updating I'm a little confused at why i'm hitting this?

[100%] Building CXX object CMakeFiles/seadrive-gui.dir/qrc_QtAwesome.cpp.o
[100%] Linking CXX executable seadrive-gui
/usr/bin/ld: warning: libxml2.so.2, needed by /usr/lib/libavformat.so.61, not found (try using -rpath or -rpath-link)
/usr/bin/ld: /usr/lib/libavformat.so.61: undefined reference to `xmlCopyNode@LIBXML2_2.4.30'
/usr/bin/ld: /usr/lib/libavformat.so.61: undefined reference to `xmlNodeGetContent@LIBXML2_2.4.30'
/usr/bin/ld: /usr/lib/libavformat.so.61: undefined reference to `xmlGetNoNsProp@LIBXML2_2.5.2'
/usr/bin/ld: /usr/lib/libavformat.so.61: undefined reference to `xmlGetProp@LIBXML2_2.4.30'
/usr/bin/ld: /usr/lib/libavformat.so.61: undefined reference to `xmlCheckVersion@LIBXML2_2.4.30'
/usr/bin/ld: /usr/lib/libavformat.so.61: undefined reference to `xmlCleanupParser@LIBXML2_2.4.30'
/usr/bin/ld: /usr/lib/libavformat.so.61: undefined reference to `xmlFree@LIBXML2_2.4.30'
/usr/bin/ld: /usr/lib/libavformat.so.61: undefined reference to `xmlDocGetRootElement@LIBXML2_2.4.30'
/usr/bin/ld: /usr/lib/libavformat.so.61: undefined reference to `xmlCharStrdup@LIBXML2_2.4.30'
/usr/bin/ld: /usr/lib/libavformat.so.61: undefined reference to `xmlFreeDoc@LIBXML2_2.4.30'
/usr/bin/ld: /usr/lib/libavformat.so.61: undefined reference to `xmlFirstElementChild@LIBXML2_2.7.3'
/usr/bin/ld: /usr/lib/libavformat.so.61: undefined reference to `xmlReadMemory@LIBXML2_2.6.0'
/usr/bin/ld: /usr/lib/libavformat.so.61: undefined reference to `xmlNewNode@LIBXML2_2.4.30'
/usr/bin/ld: /usr/lib/libavformat.so.61: undefined reference to `xmlStrcmp@LIBXML2_2.4.30'
/usr/bin/ld: /usr/lib/libavformat.so.61: undefined reference to `xmlStrdup@LIBXML2_2.4.30'
/usr/bin/ld: /usr/lib/libavformat.so.61: undefined reference to `xmlNodeListGetString@LIBXML2_2.4.30'
/usr/bin/ld: /usr/lib/libavformat.so.61: undefined reference to `xmlFreeNode@LIBXML2_2.4.30'
/usr/bin/ld: /usr/lib/libavformat.so.61: undefined reference to `xmlNextElementSibling@LIBXML2_2.7.3'
/usr/bin/ld: /usr/lib/libavformat.so.61: undefined reference to `xmlNodeSetContent@LIBXML2_2.4.30'
/usr/bin/ld: /usr/lib/libavformat.so.61: undefined reference to `xmlChildElementCount@LIBXML2_2.7.3'
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/seadrive-gui.dir/build.make:2039: seadrive-gui] Error 1
make[1]: *** [CMakeFiles/Makefile2:1169: CMakeFiles/seadrive-gui.dir/all] Error 2
make: *** [Makefile:136: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...
 -> error making: seadrive-gui-exit status 4

@river_wunsch my bad, I had a local copy of the source tar and the guys at Seafile seems to have force pushed over the tag after its original release (as they love to do).

Just cleanup everything and re-ran updpkgsums, everything should be good in 3.0.12-2.

@orax Thanks for your hard work! Unfortunately, it seems that sha256 needs an update.

@lprobsth I have been facing the same issue for a couple of days. This seems to be related to the update of the seadrive-daemon package that has now finally reached v3 which I needed to update this one.

I was just able to do the update and everything seems to be back to working. There was a weird period where the latest version of both seadrive-daemon and seadrive-gui couldn't be built for Linux due to some weirdness in Seafile's codebase. This has now been fixed with v3.0.12.

I apologize for not being able to fix this earlier. I have been tracking issues and PR for quite some time now and was finally able to push a fix.

Hope this fixes the issue for all person affected.

SeaDrive has completely stopped working for me for no known reason. The $home/SeaDrive directory just is unreadable when the seadrive gui application is started. I can't access the directory with any tools - I'm even unable to delete the directory with "sudo rm SeaDrive". I'm not able to identify the reason: logs show nothing particularly related to the problem, I have reverted the kernel, deleted the seadrive root folder, reinstalled seadrive, fsck'ed the partition, ... I'm wondering if this is related to using an outdated version of seadrive?

In case anyone has the same issue, it seems like there's some compatibility issue between this package and curl 8.10.0.

Even freshly re-compiled, I could not push any data in any library, seadrive logged PUT errors like this one every time:

[09/14/24 18:19:00] http-tx-mgr.c(752): libcurl failed to PUT https://not.my.true.domain.com/seafhttp/repo/8ea86777-a6b8-43d7-9982-b82c1068079e/commit/HEAD/?head=dc12500ae0be2231f802e1578ce4ed74a24365d8: Stream error in the HTTP/2 framing layer.

Downgrading to curl to 8.9.1 (as well as lib32-curl & libcurl-gnutls to be safe, but I assume curl would have been enough) solves the issue.

Given the lack of support for linux over the past months, though, I think I'm just going to switch back to the regular seafile client.