Package Details: spideroak-one 7.5.0-1

Git Clone URL: https://aur.archlinux.org/spideroak-one.git (read-only, click to copy)
Package Base: spideroak-one
Description: Secure file backup, sync and sharing client. This provides the client for SpiderOakONE.
Upstream URL: https://spideroak.com/
Keywords: backup
Licenses: custom
Conflicts: spideroak, spideroak-beta
Provides: spideroak
Replaces: spideroak
Submitter: coolpyrofreak
Maintainer: mxfm
Last Packager: coolpyrofreak
Votes: 269
Popularity: 0.31
First Submitted: 2015-07-18 19:17 (UTC)
Last Updated: 2019-02-15 03:12 (UTC)

Latest Comments

mxfm commented on 2021-03-13 06:38 (UTC)

@coolpyrofreak OK, I have adopted the package.

coolpyrofreak commented on 2021-03-12 15:11 (UTC)

@mxfm It's pretty straightforward. I tried to clean up the PKGBUILD when I took this over a while back, so I think it's easy to maintain.

mxfm commented on 2021-03-11 16:36 (UTC)

@coolpyrofreak perhaps I can maintain this package (I continue to use their service). Are there some packaging caveats?

coolpyrofreak commented on 2021-03-11 03:39 (UTC)

Hi all. I'm disowning this package because I've decided not to use the service anymore. Despite no new updates in a long time, the service and the application are both still supported upstream.

mxfm commented on 2019-01-05 18:43 (UTC)

@coolpyrofreak Well, this situation is indeed strange, I thought it was a new version.

I see links to other packages (rpm, windows, osx) were also rolled back to 7.3.0.1. It seems there is some bug in new version, but hope they will resolve somehow soon.

Even if they return 7.4 back, the sha256sum will likely be changed, so PKGBUILD will require adjustment anyway.

coolpyrofreak commented on 2019-01-05 17:38 (UTC)

@dummys @mxfm It appears that the upstream download link has been rolled back to 7.3.0.1, but there's nothing about it on the vendor's website. I'll keep working to confirm the rollback before I change the PKGBUILD.

mxfm commented on 2019-01-05 16:56 (UTC) (edited on 2019-01-05 16:57 (UTC) by mxfm)

@dummys Yes, it is out of date.

dummys commented on 2019-01-05 16:22 (UTC) (edited on 2019-01-05 16:24 (UTC) by dummys)

deb has the wrong checksum:

==> Validating source files with sha256sums... SpiderOakONE_7.4.0_1_amd64.deb ... FAILED terms.txt ... Passed ==> ERROR: One or more files did not pass the validity check!

The url: https://spideroak.com/release/spideroak/deb_x64 is pointing to 7.0.3.1

stratus_ss commented on 2018-12-01 23:54 (UTC)

SpiderOak 7.4.0.1 is out. The new sha256sum appears to be 1a606320742ac3d020d4d0180abaf03cfb75574c83f18b4f09e7eb026213a5a9 SpiderOakONE_7.4.0_1_amd64.deb

Would you kindly update the PKGBUILD

ReLaxLex commented on 2018-11-12 13:29 (UTC)

@coolpyrofreak: thank you for the quick response. Although SpiderOak team has specific reasons to set it. The Arch linux kernel maintainers have decided to set a much higher value (524288) by default (max memory use for this is around 512MB). Because this limit is not set per process but for all processes running under the same (user) account you hit this limit much faster. Like I did while I was playing with powerline and tmux, which broke in quite surprising ways. ;)

coolpyrofreak commented on 2018-11-12 00:29 (UTC)

@ReLaxLex: looks like this value was a deliberate design choice by the SpiderOak team to force people to be more selective when choosing the directories to back up. Since this doesn't impact the package installation or the program's function on Arch, I'm going to leave the PKGBUILD as is, and recommend you contact the development team directly regarding this issue.

More info here: https://spideroak.support/hc/en-us/articles/115005633546-inotify

ReLaxLex commented on 2018-11-11 20:51 (UTC)

Please also remove /etc/sysctl.d/30-spideroakone.conf, the value set for fs.inotify.max_user_watches (65536) is much lower than the default value (524288) set in the Arch linux kernel. Also checked this with the latest archlinux iso, archlinux-2018.11.01-x86_64.iso, were 'fs.inotify.max_user_watches = 524288'.

coolpyrofreak commented on 2018-09-13 02:34 (UTC)

Upstream support for 32-bit on Linux has ended, so I'm removing it from the PKGBUILD. The article below has more information, and download links to the last 32-bit versions.

https://spideroak.support/hc/en-us/articles/360007065152-32-Bit-Support-on-Linux

sadid commented on 2018-09-12 05:48 (UTC) (edited on 2018-09-12 05:50 (UTC) by sadid)

I think the sha256 hash should be updated:

==> Validating source files with sha256sums...

terms.txt ... Passed

==> Validating source_x86_64 files with sha256sums...

SpiderOakONE_7.2.0_1_amd64.deb ... FAILED

==> ERROR: One or more files did not pass the validity check!

Error downloading sources: spideroak-one

rek769 commented on 2018-06-23 03:19 (UTC)

Install went great on Artix-OpenRC...currently uploading my backup set.Thank you for your work in maintaining this package.

coolpyrofreak commented on 2018-06-16 19:02 (UTC)

7.2.0 for Linux has been fixed and released. Full information on SpiderOak's release notes at https://spideroak.com/articles/one-groups-backup-7-2-0-release-notes-june-11-2018/.

As always, please let me know if you have issues with this PKGBUILD. Thanks!

coolpyrofreak commented on 2018-06-12 23:45 (UTC) (edited on 2018-06-12 23:45 (UTC) by coolpyrofreak)

Looks like upstream is having issues:

"Note: Today we discovered an error in the way our Linux builds of SpiderOak One were released. This is in the process of being fixed but in the meantime we will be serving v. 7.1.0. Once the issue is resolved we will add new checksums to this page. SpiderOak Groups installers are unaffected."

(posted on the release notes for v7.2.0 https://spideroak.com/articles/one-groups-backup-7-2-0-release-notes-june-11-2018/)

This means the current version for Linux is 7.1.0. I will update when 7.2.0 is released.

hotdog789 commented on 2018-05-29 03:30 (UTC)

Thank you. The install went smoothly.

Freso commented on 2018-02-02 16:54 (UTC)

I get a checksum mismatch on spideroakone_7.0.0_amd64.deb.

coolpyrofreak commented on 2018-01-12 17:09 (UTC)

@Olorin I updated the PKGBUILD to the current version back on 29 Dec.

Olorin commented on 2018-01-12 12:42 (UTC)

Just FYI there is a big new update to SpiderOakONE that just came out when you have time to update the PKGBUILD!: https://spideroak.com/articles/introducing-spideroak-one-version-7-0/

infinitezero commented on 2017-11-21 19:01 (UTC) (edited on 2017-11-21 20:01 (UTC) by infinitezero)

Looks like Spideroak broke a few weeks back. It will start, but no backup. Here is the error I get when running it from term: Traceback (most recent call last): File "<string>", line 6, in <module> File "__main__.py", line 128, in <module> File "__main__SpiderOakONE__.py", line 183, in <module> File "__main__SpiderOakONE__.py", line 168, in main File "oak/Oak.py", line 19, in <module> File "Pandora/library/policy_selection.py", line 14, in <module> File "Pandora/UserConfig.py", line 20, in <module> File "Pandora/system_queue/fix_win_root_path.py", line 12, in <module> File "Pandora/Network/__init__.py", line 44, in <module> File "Pandora/Network/UplinkService.py", line 10, in <module> File "Pandora/Network/ServerSession.py", line 17, in <module> File "Pandora/Network/ServerSessionBase.py", line 12, in <module> File "Pandora/ssl/__init__.py", line 3, in <module> File "OpenSSL/__init__.py", line 40, in <module> ImportError: cannot import name crypto

znmeb commented on 2017-11-19 23:27 (UTC)

It looks like SpiderOak one is now available as a generic Linux tarball - https://spideroak.com/release/spideroak/slack_tar_x86 and https://spideroak.com/release/spideroak/slack_tar_x64.

coolpyrofreak commented on 2017-11-19 22:56 (UTC)

@ectoplasm - I just maintain the PKGBUILD. I'm sorry that SpiderOak's support was less than helpful, but I'm not going to be much help either. SpiderOakONE does have a CLI-only option. Just run with the --headless flag. You can see all the CLI references here: https://support.spideroak.com/hc/en-us/articles/115001891343-Command-Line-Reference

ectospasm commented on 2017-11-18 17:16 (UTC)

@coolpyrofreak I have tried moving my .config/SpiderOakONE out of the way (as my original post stated), with *precisely* the same behavior: nothing happens, no warnings or error messages displayed, even with the --verbose option. I contacted SpiderOakONE, their support is practically worthless. The only suggestion they gave to me was try an older version. I've tried 6.3 and 6.0.1 to no avail, they use libraries which are no longer current and I'm not interested (yet) in installing old libraries. I'm at my wits end. I think if they had a command-line only option, it would work much better. I wonder if this has to do with ~/.config/SpiderOakONE being mounted on my NAS over NFS. Syncing takes a LOT of local storage space and my 256G SSD fills up quite quickly.

coolpyrofreak commented on 2017-07-31 01:19 (UTC)

@ectospasm - I receive the same error when I start from the command line, but it doesn't keep the SpiderOakONE client from running. I imagine your problem is something else. I'd suggest deleting your ~/.config/SpiderOakONE folder, then running the config wizard again. If you continue to have problems, you should contact SpiderOak Support.

ectospasm commented on 2017-07-31 00:58 (UTC)

Ever since this update was released, SpiderOakONE doesn't launch for me. It simply prints out the following warning if I launch it from a terminal shell, then a long, long pause before exiting with a zero status: "sni-qt/22935" WARN 20:42:56.607 void StatusNotifierItemFactory::connectToSnw() Invalid interface to SNW_SERVICE I figured some incompatibility between my ~/.config/SpiderOakONE and this new version, so I moved it out of the way. SpiderOakONE still gives the same behavior, only the splash screen shows for several minutes, while the terminal output is precisely the same.

coolpyrofreak commented on 2017-07-29 01:25 (UTC) (edited on 2017-07-29 01:25 (UTC) by coolpyrofreak)

Apologies for the delay. Apparently this update has been out for a while, but I didn't know until now. Update is very minor: they finally fixed the libz error by upgrading the included libz file. I've also had to create a new email, so I've updated my address in the PKGBUILD if any of you need it. EDIT: forgot to mention that since SpiderOak updated their provided libz package, I've removed the ugly hack I previously had in the PKGBUILD.

ProfessorKaos64 commented on 2017-07-29 01:01 (UTC)

Checksum fails.

cb474 commented on 2017-06-10 01:00 (UTC)

@blacktav Yeah, I blame gtk3.

blacktav commented on 2017-06-09 18:46 (UTC)

@cb474 indeed. The command-line "error" I was getting seems to be fairly innocuous - according to SpiderOak The real problem is more likely related to system instability as you suggest - not soon after, my keyboard was killed and my xfce effectively died, with both staying dead even after reboots, removing and reinstalling all xfce bins & config. Xfce remains non-functional for one particular user. However, lxde & even kde appear to be fine, SpiderOak GUI runs OK & even my keyboard works again. Go figure

cb474 commented on 2017-06-07 22:15 (UTC)

@blacktav I was having a similar problem where the gui would not come up most of the time, if I clicked on the SpiderOak icon in my notification area. Sometimes it seemed like if I quit Spideroak and ran it again from a terminal then it would work. But it was very inconsistent. For me it seemed to start when there were a bunch of updates to the Mate desktop, completing the shift to GTK3. (Curiously I never had the problem on a separate LMDE system running the Mate desktop.) Then after a while it fixed itself, which I assumed had to do with some further update. So I wonder if it's your system and not SpiderOak? Sorry, I know that's not super helpful, but I thought the extra information might be worth sharing.

coolpyrofreak commented on 2017-06-07 13:35 (UTC) (edited on 2017-06-07 13:35 (UTC) by coolpyrofreak)

@blacktav This looks like an upstream issue to me. I found a page that might help: https://spideroak.com/faq/i-keep-getting-a-message-saying-the-backend-worker-process-has-exited-what-does-that-mean If that doesn't work, you'll need to contact the SpiderOak's support team yourself, but keep in mind that they don't officially support Arch.

blacktav commented on 2017-06-07 09:29 (UTC)

Command line error & log file at https://pastebin.com/AKDSvU1E Spideroak seems to start spider with an icon in notification bar; when the spider finishes an alert pops-up saying "Backend process has quit"

coolpyrofreak commented on 2017-06-06 22:56 (UTC)

@blacktav try running it from the command line and paste the output. Use a pastebin service if possible.

blacktav commented on 2017-06-06 22:22 (UTC)

Hey, nice one on the new release but unfortunately I cannot get the GUI to come up; I am guessing this is related to the libz issue. Linking to the current version (1.2.11) doesn't seem to work for me. Has anyone figured a workaround or do I need to downgrade?

coolpyrofreak commented on 2017-06-06 00:54 (UTC)

New PKGBUILD. However, libz error is still not fixed, so the link remains.

cb474 commented on 2017-06-06 00:22 (UTC)

6.3.0 is available now on the SpiderOak site.

cfr42 commented on 2017-06-05 22:18 (UTC)

Details of bugs: https://spideroak.com/articles/security-update-for-spideroak-groups--one-bugs-reported--resolved. They don't usually email about updates that I remember, so they do seem to think these fixes matter.

JohnRobson commented on 2017-06-05 21:52 (UTC)

Recently we investigated and resolved three bugs reported by security researchers at Aarhus University (Denmark) in April 2017. The bugs were found in SpiderOak Groups and SpiderOak ONE (version 6.1.5). While these were all real bugs, they were unintended behavior that we are happy to report as resolved. A new version of SpiderOak ONE has been issued which addresses these bugs, version 6.3.0. Please consider this release a security upgrade and install it on your devices as soon as possible. Downloads are available at https://spideroak.com/opendownload/

znmeb commented on 2017-05-16 01:19 (UTC)

I did have some issues on a machine I hadn't used in a few weeks but not sure whether it was 6.2.0 or 6.1.9. The symptom was that the application was showing "Disconnected" and it was on both Windows and Ubuntu on a dual-boot. I had to delete the SpiderOak profiles and re-connect. It's more likely an issue with not having used the machine than a version problem ;-)

coolpyrofreak commented on 2017-05-16 00:33 (UTC)

From SpiderOak's tech support: "Shortly after releasing version 6.2.0 a small number of users experienced sync issues. Our developers found the issue and created a fix, but it will not be available until version 6.3.0 which will be released in the coming weeks. We decided that in the meantime it would be best to roll back to version 6.1.9 so no further users would experience the sync bug." I'll roll the PKGBUILD back to 6.1.9 tonight, but I'll leave the downgrading decision up to you.

coolpyrofreak commented on 2017-05-13 20:26 (UTC)

Looks like the Linux versions have been rolled back to v6.1.9 from the vendor's download page. I'm trying to confirm with their support team, but I'll wait to hear back from the vendor before I change the PKGBUILD.

dudedudedude commented on 2017-05-13 12:57 (UTC)

Couldn't install, there is a checksum failure again.

znmeb commented on 2017-05-05 01:36 (UTC)

Looks good - just did a clean install and I'm happily syncing!!

coolpyrofreak commented on 2017-05-05 01:12 (UTC)

So here's v6.2.0. As previously reported, the libz error still exists. I'll leave the simlink in the PKGBUILD until this is fixed upstream.

coolpyrofreak commented on 2017-05-04 20:53 (UTC)

I'll build the new version today or tomorrow. I would've pushed out sooner, but have just been too busy.

znmeb commented on 2017-05-04 19:16 (UTC)

I just hacked an install via 'alien' and 'archalien' on the latest .deb, 6.2.0. It looks like the bug noted by @zero456 still exists and the symlink workaround still fixes it.

znmeb commented on 2017-05-04 07:26 (UTC) (edited on 2017-05-04 19:16 (UTC) by znmeb)

Is the 64-bit .deb corrupted? yaourt is erroring on a checksum failure ==> Building and installing package ==> Making package: spideroak-one 6.1.9-1 (Thu May 4 00:25:21 PDT 2017) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Found terms.txt -> Downloading spideroakone_6.1.9_amd64.deb... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 25.6M 100 25.6M 0 0 7854k 0 0:00:03 0:00:03 --:--:-- 7854k ==> Validating source files with sha256sums... terms.txt ... Passed ==> Validating source_x86_64 files with sha256sums... spideroakone_6.1.9_amd64.deb ... FAILED ==> ERROR: One or more files did not pass the validity check! ==> ERROR: Makepkg was unable to build spideroak-one. ==> Restart building spideroak-one ? [y/N] ==> -------------------------------------- ==>

flash872 commented on 2017-04-01 18:07 (UTC)

I have been in touch with support at SpiderOakONE. They are now aware of this and I am told that their packaging engineer is taking action on it.

coolpyrofreak commented on 2017-04-01 17:02 (UTC)

I'm really tempted to add that fix to the PKGBUILD, since I don't think an update is on the schedule anytime soon. I'll look at it later today or tomorrow.

zero456 commented on 2017-04-01 00:41 (UTC) (edited on 2017-04-01 00:44 (UTC) by zero456)

@yochaigal @iegubkin - I can confirm that the issue is indeed caused by the latest version of libpng-1.6.29. After a bit of investigating, it seems it is actually due to SpiderOak shipping and using it's own version of libz located in its' install directory - /opt/SpiderOakONE/lib/ Backing up and then symlinking to Arch's built-in libz fixes the issue with the new version of libpng: # mv /opt/SpiderOakONE/lib/libz.so.1 /opt/SpiderOakONE/lib/libz.so.1.bak # ln -s /usr/lib/libz.so.1 /opt/SpiderOakONE/lib Hope this helps!

yochaigal commented on 2017-03-29 22:23 (UTC) (edited on 2017-03-29 23:15 (UTC) by yochaigal)

I'm having the same issue as @iegubkin had earlier: Traceback (most recent call last): File "<string>", line 6, in <module> File "__main__.py", line 128, in <module> File "__main__SpiderOakONE__.py", line 183, in <module> File "__main__SpiderOakONE__.py", line 168, in main File "oak/Oak.py", line 21, in <module> File "PyQt4/QtGui.py", line 26, in <module> File "PyQt4/QtGui.py", line 17, in _bbfreeze_import_dynamic_module ImportError: /opt/SpiderOakONE/lib/libz.so.1: version `ZLIB_1.2.9' not found (required by /usr/lib/libpng16.so.16) Downgrading libpng with: pacman -U /var/cache/pacman/pkg/libpng-1.6.28-1-x86_64.pkg.tar.xz Resolves the issue for now.

nesk_aur commented on 2017-01-10 19:31 (UTC)

This is a problem when upgrading to harfbuzz 1.4.1 and still using Infinality fonts. See details here on how to migrate back to freetype2 https://gist.github.com/cryzed/e002e7057435f02cc7894b9e748c5671 It worked for me.

coolpyrofreak commented on 2017-01-10 15:31 (UTC)

@iegubkin - All I can tell you is that I can't reproduce your error. harfbuzz isn't a dependency, so it sounds like an upstream problem to me. You should contact SpiderOak support directly. https://spideroak.com/support

iegubkin commented on 2017-01-10 00:21 (UTC) (edited on 2017-01-10 03:21 (UTC) by iegubkin)

I'm confused. I re-installed the package and it gives the same error. $ wget -c https://aur.archlinux.org/cgit/aur.git/snapshot/spideroak-one.tar.gz $ tar -xvzf spideroak-one.tar.gz $ cd spideroak-one $ makepkg -s # pacman -U *.pkg.tar.xz Is this what you meant by "you might want to try re-running makepkg with a fresh git clone"? Thanks

coolpyrofreak commented on 2017-01-08 03:25 (UTC) (edited on 2017-01-08 04:17 (UTC) by coolpyrofreak)

@iegubkin - I'll try to figure this out tomorrow. It's entirely possible we'll need an upstream fix, though. EDIT - Just rebuilt the package with updated harfbuzz package, and it seems to be working fine. It executes from CLI without any errors, so you might want to try re-running makepkg with a fresh git clone.

iegubkin commented on 2017-01-08 03:12 (UTC)

The recent update of harfbuzz 1.3.4-1 to 1.4.1-1 seems to have killed spideroak-one. It crashes with: >> SpiderOakONE Traceback (most recent call last): File "<string>", line 6, in <module> File "__main__.py", line 128, in <module> File "__main__SpiderOakONE__.py", line 183, in <module> File "__main__SpiderOakONE__.py", line 168, in main File "oak/Oak.py", line 21, in <module> File "PyQt4/QtGui.py", line 26, in <module> File "PyQt4/QtGui.py", line 17, in _bbfreeze_import_dynamic_module ImportError: /usr/lib/libharfbuzz.so.0: undefined symbol: FT_Get_Var_Blend_Coordinates Similar to bug with Zim Desktop: https://bbs.archlinux.org/viewtopic.php?id=221648 "needs to be rebuilt against the new harfbuzz lib" downgrading back to 1.3.4-1 fixes the problem.

coolpyrofreak commented on 2016-06-03 01:34 (UTC)

I'm thinking about renaming this package to spideroakone (removing the hyphen) so that the package name is the same as SpiderOak's naming conventions. While it's not a big change, I wanted to advertise it before I made any changes. I'd appreciate any comments or thoughts anyone might have on this. Thanks!

scachemaille commented on 2016-04-25 21:52 (UTC) (edited on 2016-04-25 21:54 (UTC) by scachemaille)

A new version is out. The download link point to newer version 6.1.4 so the sha256sums is not valid anymore.

coolpyrofreak commented on 2016-03-11 23:56 (UTC)

@cfr42 - Sorry, I just have a habit of always using the -v flag with tar. I removed it from the PKGBUILD, so you should see a much cleaner build now.

cfr42 commented on 2016-03-11 22:24 (UTC)

Great to see the update - thanks for this. May I make the quite minor suggestion that the change to the package build which makes untarring the package verbose be undone when you next update? As far as I know, PKGBUILDs do not normally do this and I can't, to be honest, see the point. If there is a point, I think maybe adding a message explaining what users should look for in the output would be useful as it really isn't clear to me *why* I'm being given all this information, which makepkg does not provide for any other packages I've built! And apologies if this suggestion is off-base in some way. I realise you made the change for a reason, even if I cannot currently appreciate that reason.

lockheed commented on 2016-03-10 09:36 (UTC) (edited on 2016-03-10 09:43 (UTC) by lockheed)

==> Validating source files with sha256sums... terms.txt ... Passed ==> Validating source_x86_64 files with sha256sums... spideroakone_6.1.2_amd64.deb ... FAILED ==> ERROR: One or more files did not pass the validity check It's probably because the scripts downloads newer version 6.1.3

cfr42 commented on 2016-02-06 00:41 (UTC)

No worries - seems happy enough to build now ;).

coolpyrofreak commented on 2016-02-06 00:05 (UTC)

I finally fixed it, and I feel kinda dumb. I updated the terms to be SpiderOak's service agreement (the same one that everyone sees when they sign up for the service). I discovered that the ones that were previously in this package were just the terms of service for SpiderOak's website, which don't really apply here. However, when I did the git add, I forgot to include the new terms.txt file, so that's why the hash failed. But, it's all fixed now (I hope) and it should build properly now. Sorry again for the inconvenience.

cfr42 commented on 2016-02-05 20:29 (UTC)

I don't think terms.txt changed from 6.1 to 6.1.2, so the sums should be the same, I believe. (At least, when I diff'ed them, diff exited with 0 status, so I assume they're the same.)

coolpyrofreak commented on 2016-02-05 15:17 (UTC)

@chem.tand - Thanks for the info. I'll update the PKGBUILD tonight when I get home from work.

noplomplom commented on 2016-02-05 12:06 (UTC)

The sha256sum for the terms.txt file is not correct, it should be '4819c8d923ab19e552e877b87adf1d45aca6adcb5dffcb238d7819501e6e6737'.

coolpyrofreak commented on 2016-02-05 05:18 (UTC)

Yes, I know about the errors. The sha256sum is correct as far as I can tell :-/ and the PKGBUILD should still be successful if you do out locally. I'll look into it tomorrow and will hopefully have an update. Sorry for the inconvenience.

cfr42 commented on 2016-02-05 04:37 (UTC)

==> Validating source files with sha256sums... terms.txt ... FAILED ==> ERROR: One or more files did not pass the validity check!

vendion commented on 2016-02-05 03:53 (UTC)

The checksum for terms.txt is wrong.

coolpyrofreak commented on 2016-02-05 02:54 (UTC)

I've updated the package to v6.1.2, and made some additional changes to the PKGBUILD as suggested by @andreyv. As always, please let me know if anything should be fixed or could be improved. Thanks!

andreyv commented on 2016-01-03 21:14 (UTC)

Hello, I have some suggestions to improve this package: - Instead of "if CARCH == ..." source_x86_64 and source_i686 can be used (https://wiki.archlinux.org/index.php/PKGBUILD#source) - The etc/ directory in the package is not needed (it only contains /etc/apt/sources.list.d/spideroakone.list) - desktop-file-utils should be in depends because it is called in the install script - There is a namcap warning amongst others: spideroak-one E: Missing custom license directory (usr/share/licenses/spideroak-one) It looks like terms.txt should be installed as LICENSE, but isn't.

gumper commented on 2015-09-08 16:55 (UTC)

I contacted their support about the issue. Let's see what they have to say.

coolpyrofreak commented on 2015-09-08 13:56 (UTC)

@gumper - I still believe it's an upstream issue. I've experienced the same thing, but I haven't remembered to contact the vendor about it. Their support page is at https://spideroak.com/support.

gumper commented on 2015-09-08 13:17 (UTC)

I'm currently seeing the same issue that Infinitezero had, when I have the backup frequency set to "automatic", SpiderOak will not find any changes. I have to set the frequency to one of the time selections in order for it to find the changes. His fix was to create the package using the deb file from Spideroak, but the current PKGBUILD is already doing that. Any suggestions on how to correct this issue?

k2s commented on 2015-08-19 23:36 (UTC)

new version 6.0.1 here https://spideroak.com/resources/release-notes

k2s commented on 2015-08-19 23:36 (UTC)

had to update for x86_64: 7baa2573756ce174fbdff882be21de2306580de12d31cf760b706da72efdb711

cb474 commented on 2015-07-28 17:48 (UTC)

Thanks coolpyrofreak. Seems to have updated fine. Though I am not a fan of the new interface.

coolpyrofreak commented on 2015-07-19 01:43 (UTC)

@cb474 - I set the PKGBUILD for this to conflict with the original spideroak package, so pacman should prompt you to remove spideroak before installing spideroak-one. Based on my experience, it should be a seamless transition and you shouldn't lose anything, but YMMV.

cb474 commented on 2015-07-19 01:02 (UTC)

So when I install this will it automatically replace 5.2 from old AUR? Do I have to uninstall 5.2 first? Am I going to lose my settings and have to set up SpiderOak all over again? Thanks for any details on that. And thanks for maintaining and upgrading the package.

coolpyrofreak commented on 2015-07-18 19:21 (UTC)

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!

coolpyrofreak commented on 2015-05-21 22:33 (UTC)

@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.

infinitezero commented on 2015-05-20 17:51 (UTC)

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."

coolpyrofreak commented on 2015-05-18 23:16 (UTC)

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

infinitezero commented on 2015-05-18 21:07 (UTC)

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

infinitezero commented on 2015-05-18 21:03 (UTC)

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.

infinitezero commented on 2015-05-18 20:15 (UTC)

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

coolpyrofreak commented on 2015-03-14 18:56 (UTC)

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.

cb474 commented on 2015-03-12 00:27 (UTC)

@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.

cb474 commented on 2015-03-09 22:56 (UTC)

@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.

nesk_aur commented on 2015-03-08 06:28 (UTC)

@cb474 They updated the key for .deb packages just 1 year ago, can you check please? https://blog.spideroak.com/20130920145427-ubuntudebian-apt-repository-gpg-key-update

cb474 commented on 2015-03-08 00:29 (UTC)

@coolpyrofreak That blog post that you link to is six years old. The GPG key in that post expired four years ago. It's even more out of date that the GPG key for the .deb files. In any case, it also does not appear in the PKGBUILD for this AUR version of of SpiderOak that the download is being verified with GPG (the sha1sum check does not accomplish the same thing). As I said, as far as I can tell, there are no GPG keys for SpiderOak anymore. I'm emailing them and waiting for a response. In the meantime, in principle, it seems there is no way to know that this install of SpiderOak has not been compromised. If it was something else, I might not be as concerned. But if one is going out of one's way to use the sort of zero knowledge encryption that SpiderOak provides, it really kind of defeats the purpose not to verify the package with GPG.

coolpyrofreak commented on 2015-03-07 05:06 (UTC)

@cb474 - They sign the RPMs used for this PKGBUILD. Read here: https://blog.spideroak.com/20090219070000-hello-fedora

cb474 commented on 2015-03-07 02:08 (UTC)

Isn't it a problem that there are no GPG signatures for this package? SpiderOak used to provide them, at least for the .deb package, but everything about this on their website seems to be out of date now. Without GPG signatures there's no way to verify that the package downloaded from the SpiderOak site is the real package. I love SpiderOak, but it kind of undermines the point of encryption like this.

coolpyrofreak commented on 2015-03-05 01:19 (UTC)

Updated to 5.1.10.

commented on 2015-03-03 22:39 (UTC)

According to Spideroak's website, the most recent version is 5.1.10 and the version in the AUR fails to build properly.

coolpyrofreak commented on 2015-01-29 00:16 (UTC)

@ddreamer - Looks like an upstream bug to me. You can email them at support@spideroak.com.

ddreamer commented on 2015-01-28 13:11 (UTC)

Failed to show trayicon in the updated Archlinux system with cinnamon 2.4.6-1.

cfr42 commented on 2014-08-23 20:55 (UTC)

Thanks for the info re. the downgrade, by the way. I'd actually already got those links from the forums when I reported the bug.

cfr42 commented on 2014-08-23 20:52 (UTC)

You need the / on the end of the law enforcement policy link else you get a 404 error. (Privacy one works fine.)

coolpyrofreak commented on 2014-08-23 13:07 (UTC)

Updated to 5.1.8. Also added links to SpiderOak's privacy and law enforcement policies to the spideroak.install file. Thanks!

coolpyrofreak commented on 2014-07-10 00:26 (UTC)

Updated! 5.1.6 is now stable, and syncing should be fixed now.

coolpyrofreak commented on 2014-07-08 23:50 (UTC)

SpiderOak says syncing is fixed in the 5.1.6 beta. I probably won't update this PKGBUILD until it is officially released. Go to https://spideroak.com/getbuild?beta=yes to get the beta.

coolpyrofreak commented on 2014-07-07 21:49 (UTC)

2014-07-07 21:48 So the most recent version does break device syncing, and downgrading to 5.1.3 DOES fix it. However, since the most current official version of SpiderOak is 5.1.5, I'm not going to downgrade the PKGBUILD. If you want the links to the previous version, try these. The PKGBUILD should work just fine if you replace the source URI and sha1sum appropriately. i686: https://ricketyshack.spideroak.com/getbuild?brand=spideroak&platform=fedora&arch=i386&buildnum=385 x86_64: https://ricketyshack.spideroak.com/getbuild?brand=spideroak&platform=fedora&arch=x86_64&buildnum=428

coolpyrofreak commented on 2014-07-05 16:29 (UTC)

@cfr42 A lot of people, including me, are having the same issue. Seems like the only solution for now is to downgrade. See the forum thread at http://tinyurl.com/qxqv3hb

cfr42 commented on 2014-07-03 01:22 (UTC)

Is anybody having trouble with the 5.1.5 version? It works great on Fedora but on Arch I'm having trouble. (Fedora's is also upstream whereas Arch is this package in case that matters.) Specifically, my Arch machine never syncs changes *from* the cloud. (Not sure but seems to sync *to* the cloud OK.) Even if I restart the application, restart the machine, repair/vacuum/rebuild-reference-database. Nothing. No joy. It isn't even seeing the sub-directories it needs to scan. Downgrade to 5.1.3 and it works again. But obviously this isn't great given the update fixes a security vulnerability and the whole point of using SpiderOak is, well, security...

coolpyrofreak commented on 2014-07-02 00:45 (UTC)

Updated. Current version is 5.1.5.

theru commented on 2014-07-01 19:37 (UTC)

https://blog.spideroak.com/20140701135413-new-openssl-vulnerabilities-new-spideroak-client

becatlibra commented on 2014-05-16 14:54 (UTC)

@btorb If it is not in ~/.SpiderOak then it is located in ~/.config/SpiderOak

btorb commented on 2014-05-16 01:12 (UTC)

Probably not the best place to ask but where does SpiderOak store the data? Normally you have a ~/.SpiderOak but I really cannot find it. Thanks, Ben

coolpyrofreak commented on 2014-04-25 15:41 (UTC)

@PaulE Thanks for the notice. I just downloaded the tarball, and the PKGBUILD still builds and works just fine as it is. I don't see a need to update it if the download link and the sha1sum still work.

fantab commented on 2014-04-19 07:14 (UTC)

@coolpyrofreak: Thanks for taking over and maintaining spideroak @ AUR.

ava1ar commented on 2014-04-12 04:31 (UTC)

Thanks, @coolpyrofreak!

coolpyrofreak commented on 2014-04-12 04:29 (UTC)

I'll take it.

ava1ar commented on 2014-04-12 04:05 (UTC)

I am not using SpiderOak anymore, please pick up the package.

thanil commented on 2014-03-29 00:04 (UTC)

This package has a missing dependency for desktop-file-utils Otherwise INSTALL outputs: /tmp/alpm_aM6aAV/.INSTALL: line 2: update-desktop-database: command not found

ava1ar commented on 2014-02-21 16:33 (UTC)

Actually, 5.1.3 released yesterday for Linux. Updated.

coolpyrofreak commented on 2014-02-21 13:06 (UTC)

Version 5.1.2 was released yesterday.

lockheed commented on 2014-02-21 12:58 (UTC)

It no longer compiles. I think the checksum changed.

coolpyrofreak commented on 2013-12-19 03:06 (UTC)

Current version is 5.1.1.

runical commented on 2013-10-28 16:10 (UTC)

All right, for some reason the download for debia based systems is named 5.0.4 while the rest is still 5.0.3. Version 5.0.4 is nowhere to be found except there. Sorry for the trouble.

runical commented on 2013-10-28 16:00 (UTC)

Version 5.0.4 is out.

cb474 commented on 2013-08-20 20:54 (UTC)

Thanks SS4, worked for me. Looks like you only changed the sha1sum for x86_64, though, and not i386, for anyone who wants i386.

SS4 commented on 2013-08-20 14:03 (UTC)

I've changed the version with their SH1SUMs and pkgver. PKGBUILD below # Contributor: Alessio Sergi <asergi at archlinux dot us> # Contributor: Limao Luo <luolimao@gmail.com> # Maintainer: ava1ar (mail(dot)avatar(at)gmail(dot)com) pkgname=spideroak _PkgName=SpiderOak pkgver=5.0.3 pkgrel=1 pkgdesc="Secure file backup, sync and sharing client" arch=('i686' 'x86_64') url="https://spideroak.com/" license=('custom') depends=() provides=(${pkgname}) conflicts=(${pkgname}-beta) options=('!strip') install=${pkgname}.install source=(terms.txt) sha1sums=('f287fdbad966ac9ae4951a1932e9be7e82112728') if [ "$CARCH" == x86_64 ]; then source+=("${pkgname}_${pkgver}_x86_64.rpm::https://spideroak.com/directdownload?platform=fedora&arch=x86_64") sha1sums+=('fdec54db96d749179221e1e8a8e96293ffc9045c') elif [ "$CARCH" == i686 ]; then source+=("${pkgname}_${pkgver}_i386.rpm::https://spideroak.com/directdownload?platform=fedora&arch=i386") sha1sums+=('e0b7c380e598f0478d3ccf85838a007ed2314631') fi package() { # install config file install -Dm644 ${srcdir}/etc/dbus-1/system.d/${_PkgName}.dbus.conf ${pkgdir}/etc/dbus-1/system.d/${pkgname}.dbus.conf # install app in /opt install -dm755 ${pkgdir}/opt/ cp -r ${srcdir}/opt/* ${pkgdir}/opt/ # install start script file install -Dm755 ${srcdir}/usr/bin/${_PkgName} ${pkgdir}/usr/bin/${_PkgName} # install desktop and pixmap files install -Dm644 ${srcdir}/usr/share/applications/${_PkgName}.desktop ${pkgdir}/usr/share/applications/${_PkgName}.desktop install -Dm644 ${srcdir}/usr/share/pixmaps/${_PkgName}.png ${pkgdir}/usr/share/pixmaps/${_PkgName}.png # fix desktop file sed -i \ -e "/Encoding=UTF-8/d" \ -e "/^Name=/s: Backup::" \ -e "/^Comment=/s:${_PkgName} ::" \ -e "/^Categories=/s:${_PkgName};::" \ -e "/^Icon=/s:=.*$:=${_PkgName}:" \ -e "/^Exec=/s:=.*$:=${_PkgName}:" \ ${pkgdir}/usr/share/applications/${_PkgName}.desktop # install man page install -Dm644 ${srcdir}/usr/share/man/man1/${_PkgName}.1.gz ${pkgdir}/usr/share/man/man1/${_PkgName}.1.gz # install custom license file install -Dm644 terms.txt ${pkgdir}/usr/share/licenses/${pkgname}/terms.txt }

commented on 2013-08-12 01:48 (UTC)

SO support have stated that version 5.0.3 is out - fixes an issue where you cannot create a new sync.

ava1ar commented on 2013-06-23 05:14 (UTC)

Updated, looks like 5.0.2 is out.

commented on 2013-06-23 05:04 (UTC)

RPM does'n pass validation: [atom@bridgelinux ~]$ pacaur -S spideroak :: Package(s) spideroak not found in repositories, trying AUR... :: resolving dependencies... warning: config file /etc/pacman.conf, line 19: directive 'SyncFirst' in section 'options' not recognized. :: looking for inter-conflicts... AUR Packages (1): spideroak-5.0.1-1 :: Proceed with installation? [Y/n] y :: View spideroak PKGBUILD? [Y/n] n :: View spideroak .install script? [Y/n] n :: Building spideroak package... ==> Making package: spideroak 5.0.1-1 (Sun Jun 23 08:42:15 UTC 2013) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Downloading spideroak_5.0.1_x86_64.rpm... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 21.8M 100 21.8M 0 0 549k 0 0:00:40 0:00:40 --:--:-- 749k -> Found terms.txt ==> Validating source files with sha1sums... spideroak_5.0.1_x86_64.rpm ... FAILED terms.txt ... Passed ==> ERROR: One or more files did not pass the validity check! :: spideroak cleaned

cb474 commented on 2013-06-17 03:43 (UTC)

This is trivial, but I just installed Spideroak and the hive folder doesn't have the icon that goes with it (as I had in a Debian install). I just looks like a regular folder icon. Any way to get the hive icon? I kind of like it.

ava1ar commented on 2013-04-26 03:33 (UTC)

5.0.1 just out! This was fast :) Updated to 5.0.1

sberghel commented on 2013-04-26 03:25 (UTC)

New update doesn't pass validation: [sberghel@desktop spideroak]$ makepkg -s ==> Making package: spideroak 5.0-1 (Thu Apr 25 20:23:54 PDT 2013) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Downloading spideroak_5.0_x86_64.rpm... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 21.8M 100 21.8M 0 0 2454k 0 0:00:09 0:00:09 --:--:-- 3163k -> Found terms.txt ==> Validating source files with sha1sums... spideroak_5.0_x86_64.rpm ... FAILED terms.txt ... Passed ==> ERROR: One or more files did not pass the validity check!

ava1ar commented on 2013-04-26 00:41 (UTC)

Updated

ethail commented on 2013-04-25 07:44 (UTC)

Spideroak 5.0 released :D

ava1ar commented on 2013-04-12 18:53 (UTC)

Cleaned PKGBUILD, removed bundled dependencies.

goetzc commented on 2013-04-12 16:18 (UTC)

Why is now libpng12 as a dependency? If you look at the package (in /opt), spideroak provides all the needed dependencies, including libpng12, qt, krb5, etc. The SpiderOak.menu file doesn't seem to be needed.

Red_Squirrel commented on 2013-04-12 13:17 (UTC)

Same here (double Internet category) using XFCE. For now I fixed it by deleting the line relative to "# install xdg menu" from the PKGBUILD

commented on 2013-04-12 10:20 (UTC)

With the last update (4.8.4-3) the menu has a second "Internet" category. My locale is German using Xfce. http://imageshack.us/scaled/landing/259/bildschirmfoto120420131.png

ava1ar commented on 2013-03-02 04:21 (UTC)

qt=>qt4

tredaelli commented on 2013-03-01 11:17 (UTC)

You need to change qt dep to qt4

coolpyrofreak commented on 2013-01-19 18:50 (UTC)

Current version is 4.8.4.

commented on 2013-01-19 17:07 (UTC)

Hello, installation on x86 fails; checksum isn't correct: ==> Retrieving Sources... -> Downloading spideroak_4.8.3_x86_64.rpm... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 19.5M 100 19.5M 0 0 1960k 0 0:00:10 0:00:10 --:--:-- 3104k -> Found terms.txt ==> Validating source files with sha1sums... spideroak_4.8.3_x86_64.rpm ... FAILED terms.txt ... Passed ==> ERROR: One or more files did not pass the validity check! ==> ERROR: Makepkg was unable to build spideroak. ==> Restart building spideroak ? [y/N] ==> ---------------------------------- ==>

gesh commented on 2012-12-11 20:34 (UTC)

A couple of comments re: the PKGBUILD: - Why are you using the RPM package when you have a nice tarball available at https://spideroak.com/directdownload?platform=slackware&arch=i386 which is much easier to use? - It would be helpful to link to this post-install: https://spideroak.com/faq/questions/1017/ - Why don't you install the manpage and copyright notice provided by the package? - You don't seem to be copying etc/xdg/* - The occurrences of install could be simplified to just copying the slackware tarball in its entirety. Other than that, thanks for packaging this - its extremely useful.

ava1ar commented on 2012-12-07 04:00 (UTC)

Updated.

commented on 2012-12-06 21:11 (UTC)

The sha1sum fails for the package fetched from spideroak. Also, there is a newer version available. ps. Thanks for packaging this.

coolpyrofreak commented on 2012-11-09 01:41 (UTC)

The correct version should actually be 4.7.9948.

cfr42 commented on 2012-09-21 00:17 (UTC)

Well I started off with just SpiderOak --headless --verbose and it didn't do much. I figure this is because it had nothing to do. So I ran: SpiderOak --headless --verbose --backup <dir> for a couple of directories and this seemed to go OK. It's very slow but it seemed to finish. To check this, I tried: SpiderOak --headless --verbose --fulllist I got: Status: Waiting for initial updates from server and it sat there. To try to get a sense of how long, I cancelled it and reran it under time. It has now been sitting there for over 90 minutes. Have I misunderstood what this command should do? I expected it to just give me a list of the stuff backed up... I guess this is because it doesn't like to be asked for --headless with --fulllist. I thought --headless just told it not to spawn the GUI. Anyway, I'll try the GUI again in a bit. I'm not sure why it is quite so slow. My connection is reasonable so it isn't that.

liganic commented on 2012-09-20 21:17 (UTC)

Guys, please. This is not the place for those discussions. Please open a thread in the forum. These comments are meant for direct feedback to the package maintainer.

cfr42 commented on 2012-09-20 21:15 (UTC)

Thanks for responding. Sorry. I should have specified that I emailed spideroak's support - not Arch. I'll try with the headless version. Given that spideroak has a dependency on qt, it would be surprising if it worked with gnome etc. but not kde, wouldn't it? Unless the database became almost instantly corrupted, that's an unlikely explanation as I'd only just started to use it. The resource usage I mentioned was definitely *not* within a normal range. It only happened after I rebooted but it went truly insane. It pushed my temperatures as high as I've ever seen them - higher than when I'm using all cores flat out to generate a fractal, for example. Much higher than when I back up my entire drive to external disk. Since it had no reason to actually be doing anything at all (except checking nothing had changed to the few things I'd assigned to back up), I can't believe it behaves this way for other people else nobody would be able to use it. I have openssl installed already.

cemsbr commented on 2012-09-20 18:02 (UTC)

@cfr42, try to debug running it on cli: "SpiderOak --headless --verbose". Maybe the database is corrupted and you need to rebuild it. If everything is ok, the problem may be KDE compatibility, because there's no problem in my Gnome.

commented on 2012-09-20 09:42 (UTC)

@cfr42 SpiderOak isn't supported on Arch so email will, understandably, not get you very far. Try running it headless and see what happens. You will find that hdd and cpu go up as it works naturally. I don't use KDE but LXDE so I can't help with that. Also try a different pkgbuild below to see if you have better luck. Perhaps using a version of SpiderOak that might run on KDE could help. Nobody seems to agree on the dependencies for this so try adding openssl if you don't have that already.

cfr42 commented on 2012-09-20 01:59 (UTC)

I tried this out and found that various aspects of the GUI just did nothing (e.g. buttons having no effect; links to help etc. not working including for the forums which makes it impossible to use them to research the problem without giving my password over the web...). On reboot, my laptop went insane. Temperatures way up, cpu going crazy. Quitting the application didn't kill all the bits but helped. Killing the rest instantly started bringing things under control. (I then uninstalled and rebooted just to be certain.) Since I can't access the forums without giving my password over the web (which I'd rather not) and since email support has so far yielded nothing, I just wondered if this was a known issue or if there's a work around. I'm using x86_64 with KDE; everything from standard repos (no testing) except a handful of things from AUR.

ava1ar commented on 2012-08-26 13:59 (UTC)

Hi, @dkaylor Sorry, it was my mistake. I used PKKBUILD by @liolomau without proper verification of it. Will try to avoid of such things in future.

dkaylor commented on 2012-08-26 08:15 (UTC)

@ava1ar: You didn't answer my question, but obviously removed [ "$CARCH" = 'x86_64' ] && depends+=(gcc-libs-multilib) from the PKGBUILD and bumped the pkgrel You need to point that out to anyone who may have gone ahead with the update from -1 to -2 on x86_64 and replaced gcc-libs with gcc-libs-multilib unnecessarily in the process. And you really should explain why you thought that was necessary, since this package has no build() function at all. If it was just a simple mistake, just admit to that and move on, no big deal, it happens to maintainers all the time.

dkaylor commented on 2012-08-25 03:20 (UTC)

Why is [ "$CARCH" = 'x86_64' ] && depends+=(gcc-libs-multilib) needed? I commented it out just to see what would happen, package installed successfully and is currently working just fine.

ava1ar commented on 2012-08-24 03:32 (UTC)

No difference at this moment, but there are two separate channels for stable and beta versions and they are usually different.

commented on 2012-08-24 03:29 (UTC)

if both the -expetimental and this package have the same ver...what is the difference??

ava1ar commented on 2012-08-24 01:19 (UTC)

updated

ava1ar commented on 2012-08-23 19:34 (UTC)

Hi, luolimao I just adopted PKGBUILD and did not do any serious changes there :) Thanks for the update, I will incorporate them into PKGBUILD shortly.

luolimao commented on 2012-08-23 13:40 (UTC)

Some of the commands in the PKGBUILD were also out of order, so I fixed that as well.

luolimao commented on 2012-08-23 13:40 (UTC)

The way that you used the install command is... interesting. A lot of the commands themselves were redundant; I have posted a PKGBUILD with the redundancies removed here: https://gist.github.com/3436610 The page also has a slightly cleaned-up install file.

ava1ar commented on 2012-07-04 15:45 (UTC)

Great!

0112358 commented on 2012-07-04 15:43 (UTC)

Well, I manually purged all application files and reinstalled this package, and it is now working again. Not sure what the deal was before. Thanks anyway!

ava1ar commented on 2012-07-04 15:34 (UTC)

$ ldd /usr/bin/SpiderOak => not a dynamic executable is OK, since it is launch script. Why actually you trying to execute it using sudo - it should be executed as a normal user. Can you post output of ls -la /usr/bin/SpiderOak command here.

0112358 commented on 2012-07-04 15:31 (UTC)

Update seems to have broken this package for me. $ sudo /usr/bin/SpiderOak => /usr/bin/SpiderOak: /usr/bin/SpiderOak: cannot execute binary file $ ldd /usr/bin/SpiderOak => not a dynamic executable Where can I find the last version? I no longer have it on system.

ava1ar commented on 2012-07-03 01:01 (UTC)

PKGBUILD was slightly updated, switched to rpm version for Fedora. Please let me know, if anything is wrong with this updated package. Thanks!

ava1ar commented on 2012-07-03 00:07 (UTC)

Adopting this

coolpyrofreak commented on 2012-06-14 03:05 (UTC)

Current version is 4.6.9945.

lockheed commented on 2012-05-24 17:21 (UTC)

I had to stop using SpiderOak because it's gone mad. It was scanning empty folders, or folders with just few txt files, for hours, with 100% cpu usage. And when it finished, after an hour it started all over again. WTF?

commented on 2012-05-24 16:09 (UTC)

There is a bug where launching external URLs won't work with the current build script. The problem is because SpiderOak temporarily removes /usr/lib/SpiderOak from LD_LIBRARY_PATH when trying to launch the URL. Since this PKGBUILD installs in /opt/SpiderOak, the preload isn't properly cleared and the OS'es Qt isn't used for the launcher operation. There are two workaround for this. The easiest is to run /opt/SpiderOak/SpiderOak directly instead of from the startup script (/usr/bin/SpiderOak). This may run into some problems though with some Qt plugins. The other workaround is to have PKGBUILD install in /usr/lib/SpiderOak, and to have the startup script set LD_LIBRARY_PATH accordingly. We are aware of this issue at SpiderOak and hope to come up with a fix for this in a future release. :-)

commented on 2012-05-24 16:04 (UTC)

@lockheed, killing SpiderOak with the killall command should be safe. If you expect to do this regularly though, I would recommend that you investigate if --batchmode would be better suited for you.

lockheed commented on 2012-04-30 10:06 (UTC)

If I run spideroak --headless and then kill it with 'killall SpiderOak', is there a chance it may break the installation, or is it the safe way to terminate the process? If not, then what other way is there?

cb474 commented on 2012-02-11 01:09 (UTC)

Is there a reason why every time SpiderOak is updated the spelling in the name of the shell script that launches it switches from "/usr/bin/spideroak" to "/usr/bin/SpiderOak" and then back again? With the capitals, without the capitals, with the capitals. With just about every update I have to go in and change the menu commands and startup commands that launch spideroak, because the shell script spelling keeps changing. Not a big deal, but it is a bit odd and consistently inconsistent.

coolpyrofreak commented on 2012-02-07 01:07 (UTC)

4.3.9917 was released on 6 Feb.

Pyromaniac commented on 2011-12-16 07:14 (UTC)

Looks like md5sum for x86_64 is 'f9acc503ad326bc000f42844a951529b' now.

cb474 commented on 2011-12-13 00:30 (UTC)

@funkmuscle I just updated and it worked fine.

funkmuscle commented on 2011-12-12 23:13 (UTC)

is something wrong with the server?? every time I try to update, it freezes at 7% of the download...

commented on 2011-11-05 20:11 (UTC)

It worked perfectly - Thankyou NobodySpecial & thankyou al3hex, much appreciated.

NobodySpecial commented on 2011-11-05 02:30 (UTC)

b1ackcr0w - this PKGBUILD will install a 32 bit client for you, try it.

commented on 2011-11-04 23:38 (UTC)

Hi, Is a 32bit client available please? Thanks

leafonsword commented on 2011-10-31 14:31 (UTC)

完美替换dropbox

al3hex commented on 2011-10-26 10:28 (UTC)

Fixed (another) typo. Thanks.

cb474 commented on 2011-10-26 03:47 (UTC)

The command to launch spideroak seems to have switched back from /usr/bin/SpiderOak to /usr/bin/spideroak, without the capitals. So I think the PKGBUILD may be needed to be changed again to reflect this (I don't know really how this works). I had to edit my Gnome startup setting and Gnome menus commands again, to get rid of the capitals for the new spideroak version to launch.

al3hex commented on 2011-10-25 21:30 (UTC)

Fixed typo. Thanks.

juantascon commented on 2011-10-25 18:20 (UTC)

for i686 the line should be md5sums[0]="xxxx" without spaces thanks

ethail commented on 2011-10-18 09:48 (UTC)

SpiderOak (app) complains about new version and 9860 seems to be out

cb474 commented on 2011-09-30 05:25 (UTC)

@tpavlic thanks, that worked for getting the extra free space.

tpavlic commented on 2011-09-28 03:22 (UTC)

Maintainer -- please add "exec" to the SpiderOak line in /usr/bin/SpiderOak Patched PKGBUILD here: http://pastebin.com/zcGT2wfZ That is, change: echo '/usr/share/spideroak/lib/SpiderOak "$@"' >> "${USRBINFILE}" to echo 'exec /usr/share/spideroak/lib/SpiderOak "$@"' >> "${USRBINFILE}" Otherwise an unneeded bash process sticks around while SpiderOak is running. @cb474 -- IIRC, you can still use the "worldbackupday" to convert your 2GB to 5GB. Go to "Account" and then "Get More Space" and then "Change" and then you can put in the promocode there.

polslinux commented on 2011-09-19 17:21 (UTC)

9850 is out!

cb474 commented on 2011-09-15 21:20 (UTC)

@ebrodeur. didn't seem tacky to me. i would have liked to have gotten the 6Gb instead of 2Gb, if i weren't already signed up. i assume MartinZ gets something for the referral, but that doesn't bother me.

commented on 2011-09-15 12:54 (UTC)

@MartinZ extremely tacky way to get some free space.

mzecher commented on 2011-09-15 02:06 (UTC)

Thanks a lot for the package. For the new users how don't know, you may register with a referral link (this is mine: https://spideroak.com/download/referral/dd6b3051b5f1f10a5674d694f22dd3e8) and the Promo Code "worldbackupday" to begin with 6GB instead of the regular 2GB.

polslinux commented on 2011-09-10 08:23 (UTC)

9849 is out!

dserban commented on 2011-08-25 10:53 (UTC)

@sschober, try the Fedora-based version of this PKGBUILD: http://pastebin.com/raw.php?i=6FH2JzCr Let me know if this one is also segfaulting for you.

sschober commented on 2011-08-25 09:37 (UTC)

segfaults for me, when clicking on the backup->advanced button :/ See the full stacktrace here: https://gist.github.com/1170277

dserban commented on 2011-06-28 10:43 (UTC)

@mond, my observations: 1) Hardcoding the revision number into the PKGBUILD almost by definition guarantees that at some point the build process is going to retrieve out-of-date software from upstream. We wouldn't do that with *-git / *-svn / *-bzr packages, and so we won't do that with SpiderOak either. Upstream is essentially a version control system that has been enhanced to spit out a .deb file on demand, and IMO the PKGBUILD must reflect the VCS nature of upstream. 2) Replacing static libraries with their Arch-native equivalents is technically infeasible in SpiderOak's case because the SpiderOak binary incorporates the entirety of some version of Python. What you are suggesting would be possible were SpiderOak open-source and with python2 as a dependency. 3) I have added the .install file.

commented on 2011-06-27 21:16 (UTC)

Hi, I think I made this PKGBUILD a lot more standard conform and removed more Debian/Ubuntu stuff. http://dl.dropbox.com/u/1715256/spideroak-9823-1.src.tar.xz Also what do you think about replacing most of the static libraries with the packages from extra/community?

cb474 commented on 2011-06-23 17:21 (UTC)

Thanks.

dserban commented on 2011-06-23 09:21 (UTC)

@cb474: My bad. Fixed.

cb474 commented on 2011-06-23 08:03 (UTC)

I'm not sure if this problem is caused by the PKGBUILD, but I noticed that when spideroak is installed, the shell script that launches it is called "spideroak," instead of "SpiderOak" as it used to be, with the capitals. There's a line in the PKGBUILD that seems to assign this name: "USRBINFILE="${pkgdir}"/usr/bin/spideroak". This causes a problem (at least in Gnome) if you set spideroak to launch at login, from the spideroak preferences. Spideroak automatically creates an entry in the Gnome Startup Applications, where it expects to launch spideroak with the command "/usr/bin/SpiderOak" with the capital "S" and "O". So the launch fails. Should the line in the PKGBUILD read "USRBINFILE="${pkgdir}"/usr/bin/SpiderOak" in order to work properly with the way spideroak is internally configured? Thanks.

dserban commented on 2011-06-22 10:04 (UTC)

PKGBUILD updated. @mond, interesting observation re: specific revision. Is there a sure-fire method of using wget to automatically discover the latest minor version and revision? It would be interesting if there was such a method because I could then dynamically set the value of the pkgver variable during the build process.

commented on 2011-06-22 06:54 (UTC)

The beta is over. Also you can get a specific with "?revision=9810"

cb474 commented on 2011-06-18 20:28 (UTC)

Thanks dserban. And thanks for adopting the other spideroak package as well.

dserban commented on 2011-06-18 09:25 (UTC)

@cb474: In order to get the beta version (the 4.x.xxxx series) you have to append the string "beta=yes" at the end of the download link. That's how upstream distinguishes the beta channel from the stable channel. What I had noticed about the other SpiderOak PKGBUILD here on AUR (called spideroak-latest) is that it said "Beta versions included" in the description, but it didn't feature the "beta=yes" HTTP GET parameter in the structure of the download link, hence the confusion. I have adopted spideroak-latest and fixed that slip-up. Please note, however, that SpiderOak's beta channel is only available in 32-bit. @coolpyrofreak @cb474: I agree as far as major version numbers are concerned (3series vs. 4series) especially now that I own the PKGBUILDs for both channels (stable and beta), but I disagree as far as minor version numbers.

coolpyrofreak commented on 2011-06-17 23:53 (UTC)

According to the Arch Packaging Standards (https://wiki.archlinux.org/index.php/Arch_Packaging_Standards): Package versions should be the same as the version released by the author. Versions can include letters if need be (eg, nmap's version is 2.54BETA32). Version tags may not include hyphens! Letters, numbers, and periods only. According to that, this package violates that standard. Please add the version numbers back to the PKGBUILD. If you include the beta, you need to make sure that the version number includes 'beta' somewhere.

cb474 commented on 2011-06-17 23:48 (UTC)

Would it be possible to include the version number in the name of the package, as was done with the other AUR SpiderOak package that has been disowned (http://aur.archlinux.org/packages.php?ID=47096)? I do find this a bit confusing. Right now it says the package was upgrade on June 16, but when I installed it, SpiderOak shows I'm running 3.7.9810, which is the older version, not the recent June 15, 4.0.9823 update. Or are you not including betas in this PKGBUILD? Thanks if this can be simplified/clarified.

commented on 2011-06-17 03:30 (UTC)

@dserban, thank you for your hard work and bring this package into shape. Would you like me to delete my now irrelevant comments?

coolpyrofreak commented on 2011-06-16 19:02 (UTC)

That sounds a lot more complicated than it needs to be. Just because upstream doesn't put version numbers in the download files doesn't mean we can't have them in the PKGBUILD. The version numbers are all on the Release Notes page here: https://spideroak.com/release_notes

dserban commented on 2011-06-16 18:10 (UTC)

Package release 2 incorporates a mechanism to allow us to signal to each other when there is a new release. When the md5sum of the downloaded file changes, the first one of us to build SpiderOak will get this output message: "Please raise the out-of-date flag for this package: http://aur.archlinux.org/packages.php?ID=24401" This is necessary because upstream has chosen not to include the version number into the structure of the download link. When you flag the package out-of date, I will recompute the md5 sums, increment the pkgrel by one and resubmit the package. I think this is the best we can do - help each other if upstream won't help us.

commented on 2011-06-16 17:16 (UTC)

Are you updating this package without updating the REL inside PKGBUILD? I notice the last update is fairly recent but if you don't increase that number, it won't register for us that we need to update.

coolpyrofreak commented on 2011-06-16 17:04 (UTC)

This package really should have the version numbers on there. The Linux client doesn't auto-update like others, so just putting "latest" as the version number means that the package won't update unless one manually checks.

coolpyrofreak commented on 2011-06-08 20:42 (UTC)

The only thing you can really do is email SpiderOak customer support, like I did, and let them know you want a tar.gz tarball for installation on distros that don't use RPMs or .debs. For now, the .deb works fine for installation. Thanks for maintaining it!

commented on 2011-06-08 16:30 (UTC)

ahh yes, I should have seen that with the slackware packages.

coolpyrofreak commented on 2011-06-08 05:03 (UTC)

The Slackware package won't work because it's only available for 32-bit.

commented on 2011-06-08 05:00 (UTC)

Another thought, it looks like you didn't update rel version, so that even though the md5's are correct, nobody will be notified a fix is out. This may be intentional though.

commented on 2011-06-08 04:59 (UTC)

1) dbus is still an optional dep vs an actual dep because the CLI does not need it. 2) they have released a 'slackware' build recently, that amounts out to a .tar.gz that could simply be cp'd from src -> pkg. This would be a cleaner way to install this app as it is more platform agnostic then debian.

notizblock commented on 2011-05-08 07:44 (UTC)

updated & disowned since i don't use spideroak regularly.

commented on 2011-05-07 19:01 (UTC)

Also, technically dbus is an optional package because this client can run perfectly well in CLI(headless) mode without it.

commented on 2011-05-07 19:00 (UTC)

==> Validating source files with md5sums... spideroak_3.7.9801_x86_64.deb ... FAILED LICENSE ... Passed ==> ERROR: One or more files did not pass the validity check! [ebrodeur@hobbes.ujami.net] [~/spideroak]% makepkg -g ==> Retrieving Sources... -> Found spideroak_3.7.9801_x86_64.deb -> Found LICENSE ==> Generating checksums for source files... md5sums=('27f20650ace00db96886e49c33b6e0b7' '53d58e8dd9d8e5fb23919f655b164e90') fix it or disown it so I can:)

sfabius commented on 2011-03-27 15:29 (UTC)

For some reason I didn't get the 'out of date' emails I usually get. I'm happy to have another maintainer and I don't know if it's good to have more than one. In any case, I am disowning so someone else can take this up.

iosonofabio commented on 2011-03-19 21:29 (UTC)

sfabius, are you still mantaining the package? Could you update the PKGBUILD to the last version please?

cb474 commented on 2011-03-15 08:56 (UTC)

I'm getting did not pass the validity check error. I tried Xenkth suggestions for changing the pkgver line and the two md5 values, but still get the error.

commented on 2011-03-04 18:15 (UTC)

I've created a new package here on AUR called "spideroak-latest" with the intent to provide updates even when beta versions are released. http://aur.archlinux.org/packages.php?ID=47096

commented on 2011-02-24 07:41 (UTC)

Could some one give me the PKGBUILD file for the 3.7.9766 version that just got released? Thanks :)

joschi commented on 2011-02-13 18:07 (UTC)

Current PKGBUILD file for spideroak 3.6.9740 (for the lazy like me): http://aur.pastebin.com/0FVYqSKy

mr_hangman commented on 2011-01-05 16:31 (UTC)

Thanks for the workaround, Xenkth!

commented on 2011-01-02 01:18 (UTC)

I got an error that the md5sum of the latest downloaded version is wrong. Try the following if you have a similar error: Edit PKGBUILD that it fits the package which is available under the download url inside of it. >> Delete the whole parameter of "pkgver" and write "9740" instead of "3.6.9700". >> Change both md5 values to f8ac349f89abe18e77dd1c8365f2603e (32bit) and b40effb23486c2226cfe740e4f08d802 (64bit).

commented on 2010-12-23 10:41 (UTC)

New version released last night: v3.7.9739 If trying to run this on a 64bit installation then you will need to enable the Multilib repository and install lib32-glib2 if you haven't already. You can enable the Multilib repository from your pacman.conf file.

commented on 2010-12-03 21:40 (UTC)

no license, but there is a service agreement: https://spideroak.com/service_agreement

notizblock commented on 2010-11-26 20:07 (UTC)

anyone found a license, that can be included in the PKGBUILD?

notizblock commented on 2010-11-26 20:06 (UTC)

a lot of improvement is still needed: http://aur.pastebin.com/bw53ideY

commented on 2010-11-22 20:13 (UTC)

Thanks a lot for telling ignorant people like me :) works perfectly!

commented on 2010-10-23 17:24 (UTC)

Changing line 4 to: pkgver=3.6.9713 (just changing the version number) and the first MD5 checksum to 27540104a3650951140b3e18cfdb368c makes the package installable.

ava1ar commented on 2010-10-10 19:37 (UTC)

3.7.9713 is out...

commented on 2010-10-07 13:37 (UTC)

new version is out: 3.7.9710 I updated the PKGBUILD and did some minor changes like deleting the /etc/apt/ folder and switching to lucid rather than karmic new PKGBUILD is here: http://pastebin.com/sGqj3CM4

ava1ar commented on 2010-08-19 15:13 (UTC)

Looks like 3.7 is a correct version now - at least I have VERSION:3.7.9700 on the tom of the main window after installing latest build.

sfabius commented on 2010-08-10 22:57 (UTC)

I do track them there, but the new ones up until now have been beta and the files not available. I'm not obsessive, however, and only check every few days. If anyone wants to be more on top of it I'm happy to give this up; I just did because the last maintainer was giving it up. I'll fix the dependency syntax.

ava1ar commented on 2010-07-31 08:12 (UTC)

You can track stable/beta versions for spideraok here: https://spideroak.com/release_notes Also, please replace 'qt if you want to run the GUI' with 'qt: if you want to run the GUI' - colon should be placed between optdep package name and its description.

sfabius commented on 2010-07-30 17:09 (UTC)

BTW, the release notes page says 3.7.9692 is latest, but 3.6.9680 is the latest they have for sources. I assume the '7' is a typo.

sfabius commented on 2010-07-30 16:57 (UTC)

Sorry for the delay -- vacation! I've changed the versioning as suggested by Xavion. Nirev, where is the offending line?

smahs commented on 2010-07-16 22:51 (UTC)

This is the modified pkgbuild for version 9680, latest at this time. http://pastebin.com/rPaHeqha

commented on 2010-06-20 07:37 (UTC)

Edit the PKGBUILD file, changing pkgver to 9667 and changing the first md5sums(for 32 bit system) to 'b784ed8f79e5ef3ea5463e40d1c9956b', so the latest spideroak package will be used. It works for my laptop.

nirev commented on 2010-05-18 17:07 (UTC)

Couldn't "/etc/apt/sources.list.d/spideroak.com.sources.list" be removed from the package?

sfabius commented on 2010-05-15 12:51 (UTC)

I'll make Xavion's changes later, as simple as they would be. Not much time this morning, and it seems unusable without an upgrade.

Xavion commented on 2010-05-15 10:45 (UTC)

It's mandatory that everyone updates to v3.6.9658, or the application will apparently cease to operate. Incidentally, I recommend that you prepend v3.6 to the 'pkgver' variable and use another in the archive filename.

duckdalbe commented on 2010-05-12 11:39 (UTC)

Checksums still/again don't match. I'm getting these for the x86_64-package: sha1sums=('5b34e2f45d4ea2bb7ea7e29cecd12b63bc33aded') md5sums=('58bd9271ac6fc9260aa14cad4166dc4a')

sfabius commented on 2010-04-18 13:19 (UTC)

Updated -- should work now! Sorry it took a few days.

master commented on 2010-04-13 13:54 (UTC)

md5sum doesn't match the package.