SpiderOak is a online backup service that uses the so called "SuperCloud" system and several encryption layers to produce a "zero knowledge" secure backups. The client is so far released only as closed source, but the devs are considering a FOSS license and the open source release is supposed to happen rather soon-ish. Until then I wrote a binary ebuild for people to use.
Created attachment 188606 [details] First working SpiderOak binary ebuild The biggest quirk that bothers me is that the SRC_URI does not include the package version, but I've already asked the SpiderOak devs for a suggested solution. The ebuild is written by using the Debian Etch packages for x86 and AMD64.
would the slackware download be easier? its just a .tgz
(In reply to comment #2) > would the slackware download be easier? its just a .tgz > Bah, slackware doesn't have any x86_64 port. Well, I'm looking at your ebuild tonight. Could use some QA improvement. Since this report is from April, I must ask: You still do use this service, correct? I think you blog about it still.
The problem is that my Gentoo/only laptop died and am temporarily borrowing from time to time my dad's WinXP laptop. That's why I haven't done much here. The saddest part though is that my laptop died just a few hours after I updated the ebuild and tested it. I can pull it from the backups and post it here if you'd like, but it wasn't tested much yet. It works though.
Created attachment 199258 [details] Working binary ebuild I've updated it to the newer version and cleaned up the ebuild a bit as well. It worked[1] for me, but it'd be great if someone else could have a look. [1] I couldn't test the ebuild thoroughly, because ironically just after I got it to work and backed up my system with it, my laptop died (hardware failure, completely irrelevant to the app) and has remained dead since. I'll test it when I get a new laptop to install Gentoo on it again.
version 9200 is out... ebuild works for me (just renamed), thx
Doesn't work for me, though: >$ SpiderOak >Traceback (most recent call last): > File "<string>", line 6, in <module> > File "__main__.py", line 105, in <module> > File "__main__SpiderOak__.py", line 16, in <module> > File "oak/Oak.py", line 12, in <module> > File "Pandora/library/preferences.py", line 6, in <module> >ImportError: No module named louie I tried installing dev-python/louie, but that did not change anything. Any ideas ?
(In reply to comment #7) > I tried installing dev-python/louie, but that did not change anything. > Any ideas ? The problem is that all the deps are already included in the tarball and the binary wants them where it would expect them to be. These included deps have appended versions in their directories, so their names often change. This in turn means that with each version of SpiderOak coming out (until they release it as open source), a rewrite of the ebuild is needed. The biggest problem with this is that because SpiderOak don't offer (yet) versioned downloads, the ebuild just takes the latest stable and it often happens that the old ebuild does not work for the new tarball. In short: because of how upstream works so far, the ebuild is effectively a SVN/*-9999.ebuild of a binary package with dependencies included. So, until I get a new Gentoo box (see comment #4) to maintain a up-to-date SVN ebuild or upstream starts offering versioned downloads, this ebuild is not usable, unless you want to edit it yourself every time.
(In reply to comment #8) > In short: because of how upstream works so far, the ebuild is effectively a > SVN/*-9999.ebuild of a binary package with dependencies included. I see. My ebuild-know-how is very limited. I'll see what I can do (if I can, that is.)
(In reply to comment #9) > I see. My ebuild-know-how is very limited. I'll see what I can do (if I can, > that is.) As long as it's a binary ebuild, editing it is pretty simple, but tedious. Download the package in the SRC_URI and uncompress it and compare it to what the ebuild I wrote says ...you'll figure it out pretty soon what's to be done and how ;) I'd do it myself, but obviously without any Gentoo box (or at least my own box, period), my hands are pretty tied.
Created attachment 207422 [details] non-versioned, binary Modified the ebuild, hope I didn't make it "worse"... renamed to -9999 for obvious reasons. Works on my machine.
Hi, someone can add me back to CC if they ever release a source tarball. I don't really want to mess with a binary here. I hope you can understand. Thanks.
Just installed using the -9999 ebuild. I had to manually download the tarball and recalculate the manifest (since it had changed). Then I got errors like "Incompatible version of Qt" or something like that and I used a little trick I've used before with VirtualBox (which also bundles Qt libraries with it). I moved the libQt*.so* to some backup location and made symlinks from /usr/lib/qt/libQtCore.so.4 to /usr/lib/SpiderOak for all of the bundles Qt libs. Runs just fine so far.
Created attachment 209577 [details] non-versioned, binary ebuild Sorry, should have thought of that... The new ebuild fetches the file before unpacking... which works around the Manifest error and also is more fitting for a -9999 ebuild (as it will always fetch the file...) but acually this makes the ebuild worse. I am unsure what to do about the qt-problems.. It seems we need the sources real bad....
versioned download is possible, at least for win and deb packages. there is also a new version available...
Created attachment 218287 [details] spideroak-bin-9629.ebuild using versioned download, 32/64 bit version using debian lenny pkgs
Good to know. Your eBuild works fine btw (amd64). But shoudn't the name be "spideroak-bin-3.6.9629.ebuild" ?
Created attachment 218405 [details] spideroak-bin-3.6.9629.ebuild @nils: you're right, full version number is needed for version bumps. attached is a new ebuild which use full version in name but minor for downloading.
all ebuilds, including mine (which is actually only a modified copy of one posted here) put SpiderOak in /usr. Is this the right way or should it go to /opt as most (or even all) precompiled binaries?
Comment on attachment 209577 [details] non-versioned, binary ebuild Obsoleted by new (versioned) ebuild.
Your'e right Martin, /opt is the way to go IMHO.
Created attachment 218517 [details] spideroak-bin-3.6.9629-r1.ebuild installs now into /opt/SpiderOak/, +qt-static useflag added (rm qt libs and symlink them from /usr/lib/qt4/*), cleaned up RDEPS according to deb control file
Get this error when clicking on Edit Email address on the account page. Using qt-static flag. kfmclient: /opt/SpiderOak/lib/SpiderOak/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by /usr/lib64/libkdecore.so.5)
(In reply to comment #23) > Get this error when clicking on Edit Email address on the account page. Using > qt-static flag. > > kfmclient: /opt/SpiderOak/lib/SpiderOak/libstdc++.so.6: version > `GLIBCXX_3.4.11' not found (required by /usr/lib64/libkdecore.so.5) > removed the libstdc++.so.6 from the /opt/SpiderOak/lib/SpiderOak and linked to /usr/lib64/gcc/x86_64-pc-linux-gnu/4.4.2/libstdc++.so.6 and it works now.
Created attachment 218939 [details] spideroak-bin-3.6.9629-r2.ebuild removed shipped libstdc++.so.6, should find the one from gcc, no symlik required, added >=gcc-4 dep
Versioned tarball is available on: http://apt.spideroak.com/unsupported_slack/ They're not committing themselves to keep any number of past versions there though. I asked SpiderOak to include an amd64 version there as well and bumped about its source being open while I was at it :P
Created attachment 228873 [details] spideroak-bin-3.6.9643.ebuild Version bump to 3.6.9643, new ebuild attached, also fixed path to executable in .desktop file. there are still more (python) libs to unbundle optionally
Created attachment 231581 [details] new 3.6.9658.ebuild unmodified version bump to 3.6.9658.
Created attachment 231619 [details] spideroak-bin-3.6.9658.ebuild Version bump to 3.6.9658, new ebuild attached, not tested yet by myself, there are still more (python) libs to unbundle optionally. From an email from SpiderOak regarding this upgrade: We are writing this evening to inform you of a mandatory update to the SpiderOak application. This update will need to be performed before SpiderOak can continue operation.
I should first check the bug before posting the same... ;)
Comment on attachment 231581 [details] new 3.6.9658.ebuild Martin, since our two ebuilds are exactly the same I'll obsolete mine.
Comment on attachment 199258 [details] Working binary ebuild I think I can obsolete my now as well. BTW, the current ebuild works for me as well.
Created attachment 237479 [details] unmodified bump to 3.6.9680
I think, in the lastest ebuild spideroak-bin-3.6.9680.ebuild, the USEFLAG line: !qt-static? ( x11-libs/qt-gui:4[dbus] )" should be qt-static? ( x11-libs/qt-gui:4[dbus] )"
(In reply to comment #34) > I think, in the lastest ebuild spideroak-bin-3.6.9680.ebuild, > the USEFLAG line: > !qt-static? ( x11-libs/qt-gui:4[dbus] )" > should be > qt-static? ( x11-libs/qt-gui:4[dbus] )" well the usage of the useflag is correct but the name is not, it should be qt-bundled. then with !qt-bundled, qt-gui needs to be installed.
Created attachment 240495 [details] changed USE flag from qt-static to qt-bundled also make remove qt-bundled as default
Created attachment 241487 [details] headless support added I've added 2 new useflag: 'dbus' and 'headless' I've noticed the binary works well on my server without any qt nor X lib installed... clearly one must run SpiderOak with '--headless' option, so I sed the binary wrapper to force it PS: I'm trying to debundle libs but spideroak uses some libs we don't have in portage anymore... aaarrggg damn closed-source!!
Created attachment 243437 [details] spideroak-bin-3.6.9700 based on http://bugs.gentoo.org/attachment.cgi?id=241487&action=view by Laurento Frittella (mrfree)
FYI: '7 October 2010: 3.7.9713 (General Release) * Fix a rare sync bug when deleting folders, handling error messages when some items couldn't be removed * Fix for a UI bug that could sometimes allow the "Next" button to be pushed twice during the device Reinstall sequence * Give more information to the user when making the Setup choince for Reinstall vs. New Device 5 October 2010: 3.7.9710 (General Release) * Make it possible for SpiderOak clients to auto-recover from time-travel situations * Greatly reduce memory requirements during new device setup or existing device reinstall, for accounts that have many millions of data blocks (very few do.) * Ability to make SpiderOak client look more like the native OS: Enable this by setting the environmental variable SPIDEROAK_UI_STYLE to "Native". This also provides a workaround for a QT bug that prevented tooltips from appearing in Ubuntu. This is likely to become the default in the future. * Correction for a rare Windows directory watcher bug that could sometimes cause the watcher to never exit. This only happened on file systems with nearly constant activity, such that the watcher would never become idle. Now the watcher checks occasionally for the parent process's existence even when busy. This will correct an occasional "Backend Worker Exit" on startup problem experienced by a few users. * A few general improvements to memory usage and performance'
(In reply to comment #39) > '7 October 2010: 3.7.9713 (General Release) can be found in my overlay http://bitbucket.org/bearsh/bearshoverlay/src/bd27347c2eb6/app-backup/spideroak-bin/spideroak-bin-3.6.9713.ebuild
Re Comment 40: Thanks, but I'd rather get it from Gentoo. :)
Created attachment 258220 [details] version bump to 3.6.9740
Created attachment 267113 [details] A fixed "live" ebuild that will fetch the latest revision. Fixed a couple of things like: *SRC_URI not depending on revision. *RESTRICT for mirror and strip. *Fixed the sed operations which didn't change correctly the paths in files. *Corrected the icon path. Now is it possible to disable digesting of the src files and force fetching all the time? Or comparing the filename from the resolved link with the file in the distdir directory and taking a decision based on that? Anyway, thanks to all the people who worked on the ebuilds! ;)
(In reply to comment #43) Philipp, thx for you ebuild! I merged it with my latest version and did a version bump (personally I prefer versioned ebuilds...) it can also be found in my overlay mentioned in an earlier comment
Created attachment 268031 [details] spideroak-bin 3.6.9781 version bump, mark earlier ebuild as obsolete
(In reply to comment #44) > (In reply to comment #43) > Philipp, thx for you ebuild! > I merged it with my latest version and did a version bump (personally I prefer > versioned ebuilds...) > it can also be found in my overlay mentioned in an earlier comment Looks much nicer after the depend clean-up now :) Alright, we will just have to bump the version manually then I guess.
Created attachment 271199 [details] Version bump to 3.7.9801 New Version 3.7.9801 of Spideroak. I had to change the download URL to the Ubuntu Lucid package because the debian lenny one does not seem to be available. We could leave it to the Ubuntu mirror I think since it usually gets the best treatment :P
(In reply to comment #47) Using Philipp Richter's ebuild, I get the following error when trying to run SpiderOak: $ /opt/bin/SpiderOak Traceback (most recent call last): File "<string>", line 6, in <module> File "__main__.py", line 131, in <module> File "__main__SpiderOak__.py", line 68, in <module> File "__main__SpiderOak__.py", line 63, in main File "oak/Oak.py", line 17, in <module> File "PyQt4/QtCore.py", line 14, in <module> ImportError: /opt/SpiderOak/lib/SpiderOak/PyQt4.QtCore.so: undefined symbol: _ZN13QElapsedTimer11isMonotonicEv $ c++filt _ZN13QElapsedTimer11isMonotonicEv QElapsedTimer::isMonotonic() Running pyqt4 version 4.8.1.
(In reply to comment #48) > (In reply to comment #47) > Using Philipp Richter's ebuild, I get the following error when trying to run > SpiderOak: > > > $ /opt/bin/SpiderOak > Traceback (most recent call last): > File "<string>", line 6, in <module> > File "__main__.py", line 131, in <module> > File "__main__SpiderOak__.py", line 68, in <module> > File "__main__SpiderOak__.py", line 63, in main > File "oak/Oak.py", line 17, in <module> > File "PyQt4/QtCore.py", line 14, in <module> > ImportError: /opt/SpiderOak/lib/SpiderOak/PyQt4.QtCore.so: undefined symbol: > _ZN13QElapsedTimer11isMonotonicEv > > $ c++filt _ZN13QElapsedTimer11isMonotonicEv > QElapsedTimer::isMonotonic() > > Running pyqt4 version 4.8.1. Hi, did you try to install with qt-bundled use flag enabled? Try to run $ python-updater as root, make sure you are using python 2.* as active version although I'm not positive it will do much since the package uses its own library. You shouldn't need dev-python/PyQt4 to install SpiderOak. Also post your 'emerge --info' output and your SpiderOak use flags. Qt, python versions could be useful too. Make sure your system is up to date and run 'revdep-rebuild' to make sure there are no broken dependencies.
Created attachment 272377 [details] Version Bump to 3.7.9810 Release Notes: 5 May 2011: 3.7.9810 (General Release) - Fixes a bug that sometimes prevents generation of a single-file-sharing URL. - Enable the next button in the new user setup sequence when the activation code was autodetected. Manifest: DIST spideroak-bin-3.7.9810_amd64.deb 24027514 RMD160 74323b1f543a9bcd2e97ab5aca432cb86cef1d31 SHA1 53d2d0793ec74c0411ca7c2b01fbbbeccabe310c SHA256 5c15da208ebfcfe06877c2a916eefeb0e1262fc6f2e454d47693d5ec464a0647 DIST spideroak-bin-3.7.9810_x86.deb 23458332 RMD160 3ceb4ee9632e0674dff012c15cd23137e0349589 SHA1 e5fee0296fb31052643cdf679123f02248dee04a SHA256 4289ce818baa7b64403a9801db2571de5e2f33f6a5ffa0afe266f20de51e7015
Could this go into Sunrise?
Created attachment 276227 [details, diff] Patch to improve paths in spideroak-bin-3.7.9810.ebuild I suggest that this patch be applied to the proposed spideroak-bin-3.7.9810.ebuild ebuild; rather than putting things into /opt/SpiderOak/lib/SpiderOak, this just puts everything into /opt/SpiderOak (aside from the binary, which remains in /opt/bin). Also, I second the suggestion of moving this to Sunrise.
Used the ebuild from Philipp and the patch from Randall, but then bumped the version to 4.0.9823 (latest as of 21 June 2011 -- see https://spideroak.com/release_notes), and everything is working great. Definitely seems like a good candidate for Sunrise to me.
Created attachment 278611 [details, diff] patch 3.7.9810 -> 4.0.9823 (incl path improvements) Attached patch bumps from 3.7.9810 to 4.0.9823, and improves the ebuild by removing useless code, simplifying the sed commands, setting the sourcedir properly (the original $S didn't work for me) and bump to EAPI 4.
What is up with the URL of this bug? http://eradicus.blogsome.com/2009/10/18/vrms-virtual-richard-m-stallman does not really seem to have any relation at all to SpiderOak.
(In reply to comment #54) > Created attachment 278611 [details, diff] > patch 3.7.9810 -> 4.0.9823 (incl path improvements) > > Attached patch bumps from 3.7.9810 to 4.0.9823, and improves the ebuild by > removing useless code, simplifying the sed commands, setting the sourcedir > properly (the original $S didn't work for me) and bump to EAPI 4. I think, you should include the following in your patch: @@ -32,7 +32,7 @@ x11-libs/libX11 x11-libs/libXext x11-libs/libXrender - !qt-bundled? ( x11-libs/qt-gui:4[dbus] ) + !qt-bundled? ( x11-libs/qt-gui:4[accessibility,dbus] ) )" DEPEND="${RDEPEND}" Otherwise, SpiderOak fails to load with SpiderOak Traceback (most recent call last): File "<string>", line 6, in <module> File "__main__.py", line 128, in <module> File "__main__SpiderOak__.py", line 112, in <module> File "__main__SpiderOak__.py", line 107, in main File "oak/Oak.py", line 20, in <module> File "PyQt4/QtGui.py", line 14, in <module> ImportError: /opt/SpiderOak/PyQt4.QtGui.so: undefined symbol: _ZNK7QWidget14accessibleNameEv
Created attachment 278699 [details, diff] patch 3.7.9810 -> 4.0.9823 (incl. path impr., accessibility) (In reply to comment #56) > I think, you should include the following in your patch: Thanks for the hint!
It might also be good to einfo links to the following FAQ entries when the headless use flag is supplied: https://spideroak.com/faq/questions/62/how_do_i_install_spideroak_on_a_headless_linux_server/ https://spideroak.com/faq/questions/67/how_can_i_use_spideroak_from_the_commandline/ It's not exactly obvious how to make everything work 100% headless without reading those.
I'm thinking to add this package to betagarden (or portage main repository) Is there anyone considering to become a proxy maintainer here? http://overlays.gentoo.org/proj/sunrise/wiki/ProxyMaintainer
(In reply to comment #59) > I'm thinking to add this package to betagarden (or portage main repository) > Is there anyone considering to become a proxy maintainer here? I would proxy-maintain for Sunrise, if that would be another option you offer.
(In reply to comment #60) > (In reply to comment #59) > > I'm thinking to add this package to betagarden (or portage main repository) > > Is there anyone considering to become a proxy maintainer here? > I would proxy-maintain for Sunrise, if that would be another option you offer. I don't think there is proxy-maintain system on sunrise, because users can commit to the repo directory. Also I have permission to commit Portage and Betagarden, but not for Sunrise. So it can't.
Created attachment 279753 [details] app-backup/spideroak-bin-4.0.9830 (In reply to comment #58) > It might also be good to einfo links to the following FAQ entries when the > headless use flag is supplied: Thanks for the suggestion! Included in the update to 9830. (In reply to comment #61) > I don't think there is proxy-maintain system on sunrise, because users can > commit to the repo directory. Also I have permission to commit Portage and > Betagarden, but not for Sunrise. So it can't. Ok, then feel free to proxy maintain for betagarden. :)
Version 4.1.9842 was released. A simple rename of the ebuild suffices. @naota: There seem to be no bugs reported to the ebuild. Can you move it to Gentoo's main tree and continue to proxy-maintain it there?
(In reply to comment #63) > Version 4.1.9842 was released. A simple rename of the ebuild suffices. > > @naota: There seem to be no bugs reported to the ebuild. Can you move it to > Gentoo's main tree and continue to proxy-maintain it there? Thanks. I've moved it to main tree. If there's no problem, I'll close this bug in a week.
(In reply to comment #64) > Thanks. I've moved it to main tree. Credit belongs to you, for generously offering to proxy-maintain. Thanks a lot!
Closing since it have been moved to the tree.
