Arch Linux User Repository

SpiderOak 6.0 is out, and this is a pretty major upgrade. Besides a new UI, new features, and bug fixes, SpiderOak has changed the name of this product (and the name of the binary) to SpiderOakONE to differentiate it from their Groups and Enterprise products. I'm changing the name of the package to spideroak-one to keep in line with this convention, and will merge the existing package to it. Groups or Enterprise would have to be a separate PKGBUILD, with the source obtained from SpiderOak directly. For both of those, some signup and interaction with the SpiderOak sales team is necessary before you can get the install file. In a minor change, I've changed the install file to the .deb file in order to clean up the PKGBUILD. It should build the same without any issues. I've also removed the CLI link from the install file and replaced it with the link to the release notes. Please let me know if you have questions. My email is in the PKGBUILD. Thanks!

@infinitezero Still sounds like an upstream issue to me. Either SpiderOak needs to rebuild the RPM source, or you need to recompile the PKGBUILD. I don't intend to be rude, but I don't really want to re-write the PKGBUILD for the .deb source just because one user is having an issue.

I did, see part of their response below. "The errors I was seeing were indicating that the process which scans your file system was crashing. There are differences in the libraries used by the rpm vs deb builds which caused the directory watcher to crash."

@infinitezero: Sounds to me like an upstream issue. You really should contact the developers: https://spideroak.com/help/

Makes me wonder if this is a marriage issue between the .rpm and Gnome 3.

I have a fix for the issue. The variable that is different, is the package used to create the AUR version, it is from the .rpm, not the .deb. Make sure you have uninstalled the previous SpiderOak install from the AUR. 01. Install deb2targz: $ pacaur -Syu deb2targz 02. Download current .deb from SpiderOak: 03. Convert: $ deb2targz spideroak_5.2.0_amd64.deb 04. Decompress: $ tar -xzvf spideroak_5.2.0_amd64.tar.gz 05. Copy the following newly created directories (etc, usr, opt) as follows: $ sudo cp -r etc/ / $ sudo cp -r usr/ / $ sudo cp -r opt/ / 06. Start SpiderOak and set it to, "Launch SpiderOak at OS Startup" $ SpiderOak ## Is case sensitive. 07. Reboot Now SpiderOak will automatically scan for changes like it should.

I have noticed over the last 5 months or so SpiderOak does not automatically (or if you set a time) scan the directories for changed files and upload them. I have not seen this issue with other distros running SpiderOak (for example Debian 7 & 8 and Ubuntu 14.04.2), only Arch, is there a fix for it? I have seen the same symptom on two different fresh Arch installs, and two different (fresh) installs of SpiderOak, include the most current 5.2.0. If I make a change a to file, or add a new file, SpiderOak does not detect it (not scanning for changes) unless I manual tell it to scan, or kill it and then restart it. I have even set it to backup every 5 minutes and it still does not scan for changes. All distros running gnome-shell. There is at least one other user experiencing the same issue. https://bbs.archlinux.org/viewtopic.php?pid=1529938#p1529938

I've decided that I'm not going to include SpiderOak's PGP signature in this PKGBUILD. My reasons are too numerous to list here, but suffice it to say that I don't think it's appropriate. Feel free to contact me directly (email's in the PKGBUILD) if you want to discuss further. I still want to improve the PKGBUILD wherever I can, so I've changed from sha1sum to sha256sum. I think this will allow users to better verify the integrity of the RPM.

@coolpyfreak I got a response from SpiderOak explaining what's going on with the GPG keys. Apparently with the .deb files, it's not the package itself that is signed. Apt (in Debian distros) using a sha1sum to verify the file and the sha1sum is signed with GPG. So that's what apt checks, if one uses the spideroak apt repository and apt to update spideroak. With the rpm files it is the .rpm package itself that is signed. And then rpm checks the package. However spideroak failed to update the signature, found in the blog post that you link to below. They said they are going to correct that, but have not yet. But I was sent the new signature as an attachment in an email. I'm not really sure how this signature can be used in Arch to verify the .rpm package, if one is not using rpm to do this. I sent an email asking if there's a way to verify the .rpm with gpg itself. Perhaps you know more than I do about how to do this (I'm getting a little beyond my cursory gpg knowledge). I guess I can't attach the .rpm signature I was sent here, but I could just copy and paste the text of it into a comment, if you want. But then you'd be getting it from me, rather than directly from SpiderOak's website, which kind of breaks the chain of trust. So perhaps it's better to wait until the SpiderOak website is updated. That's the latest info I have.

@coolpyrofreak Yes the key for the .deb packages is newer and has not expired yet. But as far as I can tell the actual .deb downloads for Spideroak have not been signed with GPG. I'm still waiting to hear back from SpiderOak about this. I got an intial response form someone who did not have an answer, but said he would check with other people.