How to get source for 3.8

Asked by hokasch

Forgive me for being too dump to use Launchpad, but could you give me a hint on how to get a source tarball url for 3.8 out of it? I could just check out the trunk branch, but would prefer a release tarball à la
"https://launchpad.net/~nilarimogard/+archive/webupd8/+files/dropbox-share_0.2.4.2.orig.tar.gz".
Thanks...

Question information

Language:
English Edit question
Status:
Solved
For:
Dropbox Share Edit question
Assignee:
No assignee Edit question
Solved by:
hokasch
Solved:
Last query:
Last reply:
Revision history for this message
Alin Andrei (nilarimogard) said :
#1
Revision history for this message
hokasch (hokasch) said :
#2

Thanks!
AUR package updated ;)
http://aur.archlinux.org/packages.php?ID=43926

Revision history for this message
Alin Andrei (nilarimogard) said :
#3

Great! You missed a dependency (I've also wrote about it in the bug you submitted): sqlite3 - required to get the exact Dropbox path for the new Dropbox (>= 0.8 I believe).

Revision history for this message
hokasch (hokasch) said :
#4

Ok... odd, I figured from the "if -e host.db" it was the other way round, since I have dropbox 1.010 and a host.db file in .dropbox.
Sqlite is on 3.7.4 here, so maybe that host.db does not belong there anymore and is breaking the path routine.

There is a lot of importent stuff in my dropox atm, will need to free some space to back it up first before moving host.db....

Revision history for this message
Alin Andrei (nilarimogard) said :
#5

"host.db" is a plain text file for older Dropbox versions and it no longer exists in new Dropbox versions. "config.db" is an sqlite file available in some old Dropbox version and in the latest Dropbox.

Keep both checks as in my original file or else it will not work for all Dropbox versions...

Revision history for this message
hokasch (hokasch) said :
#6

As said above, host.db still exists in the latest dropbox version, and your first check (without sqlite) resolves the folder just fine. I was about to remove host.db from my actual dropbox folder, to force your script into the sqlite check.

All moot anyway, since the problem was with the public url, not the local folder. I did not realize dropbox cli tools are packaged separately from the daemon here. Doh.