Bugfixes only. mv suffices. 26 December 2011: 4.2.9913 (General Release) * Fix a refresh bug on the view page. * Fix an issue with non-English characters in passwords. 21 December 2011: 4.2.9912 (Beta Release) * Fix a bug where two devices may both think they're the first device to be added to an account. * Fix a bug preventing selection of Windows "Favorites" on basic view when containing folders with non-English names. * Fix a couple of bugs causing version building to go more slowly than it should for large files. 15 December 2011: 4.2.9909 (General Release) * Fixed a problem with some large filetypes that could lead SpiderOak to falsely conclude the file had been modified during backup. * Fixed a bug in the basic view causing category selection to be incorrect if any of the default categories appeared in Windows Favorites. Reproducible: Always
Jeroen Roovers <jer@gentoo.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|naota@gentoo.org | AssignedTo|bug-wranglers@gentoo.org |naota@gentoo.org That is actually wrong. I am the maintainer, naota is just proxy.
Okay, I've updated the ebuild in a way which tries to take into consideration all the issues regarding this package and this bump. Its on my overlay and I'll put it on the tree in a few days if there are no objections. http://git.overlays.gentoo.org/gitweb/?p=dev/blueness.git;a=blob;f=app-backup/spideroak-bin/spideroak-bin-4.2.9913.ebuild;h=d18e44b471134a0696dcfd3c759a9fc29473d48a;hb=449e6dd9706c003f1b6f41c5974981b603f2e018 Let me know if there are any problems. I'll comment in each dependant bug why I did what I did.
Where did the deps on Qt go? Why are you using all bundled libs? At least libstdc++.so had an actuall issue, because it was too old and thus incompatible with my system library, causing loading problems. Can you at least make that depend on IUSE=+all-bundled, if you think it has to be? Why do you rm so many files, e.g. after unpacking and after installation? I find installing "somedir" into / a bit uncommon, compared to installing "somedir/*" into /somedir. +1 on the patch vs. the invocation of sed I used previously. I am not sure about the cp thing... Seems like it could accidentally install anything and gives up a lot of control over the contents of the package... But your point regarding permissions and future changes is valid, too...
(In reply to comment #3) > Where did the deps on Qt go? > > Why are you using all bundled libs? At least libstdc++.so had an actuall issue, > because it was too old and thus incompatible with my system library, causing > loading problems. > Can you at least make that depend on IUSE=+all-bundled, if you think it has to > be? Its bad both ways. If we package the entire bundle, then the appropriately versioned libraries are there, but there's bloat. If we depend on the system libraries then we may force an up or downgrade on some library(ies) on an entire system just for this one package. Luckily some are slotted like dev-libs/openssl:0.9.8, but on most current gentoo boxes this would pull in openssl-0.9.8 just for spideroak-bin. The same is true for example in depending on python 2.7 which = SpiderOak/py. I'd be interested in the problem with libstdc++. Was there a bug # for that? I'm going to ask what the common wisdom is in such cases. > > Why do you rm so many files, e.g. after unpacking and after installation? rm -rf etc/apt <- debian only and should be removed rm -rf usr <- I just checked and this can now be removed. It was a leftover from something else. > I find installing "somedir" into / a bit uncommon, compared to installing > "somedir/*" into /somedir. Both work. > > +1 on the patch vs. the invocation of sed I used previously. > > > I am not sure about the cp thing... Seems like it could accidentally install > anything and gives up a lot of control over the contents of the package... But > your point regarding permissions and future changes is valid, too...
(In reply to comment #4) > (In reply to comment #3) > I'd be interested in the problem with libstdc++. Was there a bug # for that? http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-backup/spideroak-bin/spideroak-bin-4.2.9907.ebuild?view=markup#l67 No bugreport that I know of. Possible reason for requiring that symbol: Not all libs or plugins are bundled and something pulled in a library that was linked against a newer libstdc++ > > Why do you rm so many files, e.g. after unpacking and after installation? > > rm -rf etc/apt <- debian only and should be removed I mean: Why don't you install the necessary files explicitly, instead of removing the unnecessary? Is similar in nature to the cp thing though.
(In reply to comment #4) > (In reply to comment #3) > > > > Why are you using all bundled libs? We've worked with few Linux distributions, so I'll share what we've learned along the way. In general, it works to use the existing system libraries and reduce bundled libraries only in the case that the distribution maintainers are willing to work closely with SpiderOak and keep the package updated frequently. We've found this an unreasonable expectation of how package maintainers spend their time :). For example, in the last 6 months, we've shipped 2 critical bugfixes that were actually fixes to QT (related to UI stalls on interacting with various types of network volumes.) There's another on the way that requires an upgrade to Qt 4.8. So unless someone is willing to give it regular care, we recommend bundling.
(In reply to comment #6) > So unless someone is willing to give it regular care, we recommend bundling. Gentoo is generally pretty up-to-date with its system libraries. For maintaining this package it would be helpful if we knew which libraries you deem necessary for bug free operations. Is there such a list, or could you provide one? Then I (or blueness) could update the dependencies of our Gentoo ebuild regularly, to keep up with your bugfixes, etc.
(In reply to comment #6) > (In reply to comment #4) > > (In reply to comment #3) > > > > > > Why are you using all bundled libs? > > For example, in the last 6 months, we've shipped 2 critical bugfixes that were > actually fixes to QT (related to UI stalls on interacting with various types of > network volumes.) There's another on the way that requires an upgrade to Qt > 4.8. > > So unless someone is willing to give it regular care, we recommend bundling. This was my gut feeling. You also bring up a good point that we really can't track issues as you guys can. @Dennis, its not just a matter of Gentoo's libraries being up to date, or more specifically matching library versions. We don't know what modifications spider oak made to those libraries. This isn't like situations where some open source package ships its own version of a library's source code and we already have that library on the tree. There we can patch both and have control when we build. Here we don't know what's in the libraries that Spider Oak is shipping when we throw them away. I'm going with bundling.
Okay I added USE="system-libs". USE="-system-libs" will install the fully bundled package as upstream distributes it, while USE="system-libs" strips out the following bundled libs with the substitutions shown: # libcrypto.so.0.$SSL_SLOT => dev-libs/openssl:$SSL_SLOT # libssl.so.$SSL_SLOT => dev-libs/openssl:$SSL_SLOT # libcurl.so* => net-misc/curl # libexpat.so* => dev-libs/expat # libgcc_s.so* => >=sys-devel/gcc-4 # libstdc++.so* => >=sys-devel/gcc-4 # libpcre.so* => dev-libs/libpcre # libpng12* => media-libs/libpng:1.2 # libQt*.so* => x11-libs/qt-core x11-libs/qt-gui # libsqlite3.so* => dev-db/sqlite:3 # libssh2.so* => net-libs/libssh2 # libz.so* => sys-libs/zlib # # pycurl.so pyexpat.so => dev-python/pycurl # # usr/lib/SpiderOak/py => dev-lang/python:2.7 Here SSL_SLOT=0.9.8. The ebuild is at http://git.overlays.gentoo.org/gitweb/?p=dev/blueness.git;a=blob;f=app-backup/spideroak-bin/spideroak-bin-4.2.9913.ebuild;h=129f2ef39d594781c741cda261aa9cec1c86032d;hb=b6399d0aae7b47694453c62ca4f55a0dc08b135a I'll put it up in a week or so if there are no objections.
(In reply to comment #9) > I'll put it up in a week or so if there are no objections. No objections. Just for the docs: pyexpat is python:2.7
(In reply to comment #10) > (In reply to comment #9) > > I'll put it up in a week or so if there are no objections. > No objections. > > Just for the docs: pyexpat is python:2.7 Okay added to the tree.
