tuxpoldo

Debian And Ubuntu Legacy Desktop Unofficial Packages For Bittorrent Sync

Recommended Posts

Updated all packages to 1.1.30 - All Debian builds are now online. Unfortunately todays there is high load on launchpad and so Ubuntu builds will be probably available in about 10 hours (launchpad shows 6-10 hours for all builds). I'm sorry, but I can't change this :-(

Changelog:


btsync (1.1.30-1~sid) sid; urgency=low

* New upstream release

-- Leo Moll <leo.moll@yeasoft.com> Wed, 10 Jul 2013 00:31:45 +0200

Share this post


Link to post
Share on other sites

Updated all packages to 1.1.33 - All Debian builds are now online. Unfortunately today again there is high load on launchpad and so Ubuntu builds will be probably available in about 8 hours (launchpad shows 4-8 hours for all builds). I'm sorry, but again I can't change this :-(

Changelog:


btsync (1.1.33-1~sid) sid; urgency=low

* New upstream release

-- Leo Moll <leo.moll@yeasoft.com> Thu, 11 Jul 2013 22:10:09 +0200

Share this post


Link to post
Share on other sites

Updated all packages to 1.1.40 - All Debian builds are going online. As usual, Ubuntu builds will be probably available in 30-60 Minutes.

Changelog:


btsync (1.1.40-1~sid) sid; urgency=low

* New upstream release

-- Leo Moll <leo.moll@yeasoft.com> Mon, 15 Jul 2013 16:13:43 +0200

Share this post


Link to post
Share on other sites

Woould it be possible to get generic .src rpm's so that we could try the linux desktop client on Opensuse or Fedora OS? the server client is woefully lacking in information in comparison

Share this post


Link to post
Share on other sites

Updated all packages to 1.1.42 - All Debian builds are now online. As usual, Ubuntu builds will be probably available in 1-2 hours.

Changelog:


btsync (1.1.42-1~sid) sid; urgency=low

* New upstream release

-- Leo Moll <leo.moll@yeasoft.com> Tue, 16 Jul 2013 17:45:08 +0200

Share this post


Link to post
Share on other sites

what new in the 1.1.42-2?

Nothing relevant for the desktop version. The changes affected only the daemon init scripts for the server version. The only reason, there is a new package also for the desktop version is that both versions are built with a common procedure.

You will always find the changelog in

/usr/share/doc/btsync-user/changelog.Debian.gz

Every package installs documentation (at least changelogs) in

/usr/share/doc/<package name>

Share this post


Link to post
Share on other sites

Updated all packages to 1.1.48 - All Debian and Ubuntu (!) builds are now online.

Changelog:


btsync (1.1.48-1~sid) sid; urgency=low

* New upstream release

-- Leo Moll <leo.moll@yeasoft.com> Tue, 23 Jul 2013 22:51:39 +0200

Share this post


Link to post
Share on other sites

I have a problem with the desktop package. A few weeks ago I installed the desktop package for ubuntu, as instructed in the first post here. Now the update manager program says there is an update available but will not install it because the package is untrusted.

How do I solve this problem?

Share this post


Link to post
Share on other sites

...

Now the update manager program says there is an update available but will not install it because the package is untrusted.

...

This is a real strange problem. Usually it means, that the package is coming from a source, that provides no signed packages or the package signature is unknown in the system. Basically this is not possible, since the procedure of adding a PPA automatically downloads the signer key and inserts it into the systems's keyring.

Perhaps for some reason, the keyring was updated and all foreign keys were removed. I would suggest to try the following procedure:


sudo gpg --keyserver pgp.mit.edu --recv-keys 6BF18B15
sudo gpg --armor --export 6BF18B15 | sudo apt-key add -

sudo apt-get update
sudo apt-get upgrade

This will re-add the signer key manually. Please let me know, if this is working for you.

Share this post


Link to post
Share on other sites

@tuxpoldo: after upgrading both my server running Debian and my Macbook (both to version 1.4.8 of btsync) syncing just stopped. Restarting btsync on both machines didn't help.

My Macbook lists the server in the devices tab and shows there is data to be uploaded but simply doesn't start.

Does your btsync package write a log file somewhere? Any other suggestion?

P.S. The macbook and my Windows PC (also using btsync 1.4.8) are still happily syncing.

Share this post


Link to post
Share on other sites

This is a real strange problem. Usually it means, that the package is coming from a source, that provides no signed packages or the package signature is unknown in the system. Basically this is not possible, since the procedure of adding a PPA automatically downloads the signer key and inserts it into the systems's keyring.

Perhaps for some reason, the keyring was updated and all foreign keys were removed. I would suggest to try the following procedure:


sudo gpg --keyserver pgp.mit.edu --recv-keys 6BF18B15
sudo gpg --armor --export 6BF18B15 | sudo apt-key add -

sudo apt-get update
sudo apt-get upgrade

This will re-add the signer key manually. Please let me know, if this is working for you.

After the apt-get update command the following warning is returned:

W: GPG error: http://ppa.launchpad.net precise Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY D6D9510DD294A752

I have accepted the "untrusted" install of version .48 earlier so I'll wait until the next update.

Share this post


Link to post
Share on other sites

After the apt-get update command the following warning is returned:

W: GPG error: http://ppa.launchpad.net precise Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY D6D9510DD294A752

I have accepted the "untrusted" install of version .48 earlier so I'll wait until the next update.

Interesting. It seems that your system has lost the PPA key. In this case my suggestion was wrong. You must re-add the PPA signer key:


sudo gpg --keyserver pgp.mit.edu --recv-keys D6D9510DD294A752
sudo gpg --armor --export D6D9510DD294A752 | sudo apt-key add -

I have no idea why this happened on your system, but I noticed that in the last weeks there were a lot of updates to the system keyring - I suppose due to some security issues. Perhaps one of this updates killed the external keys...

Share this post


Link to post
Share on other sites

using ~/btsync.conf it seems to ignore the device name I configured...

You must reboot your machine after creating the file in order to make the changes active.

Share this post


Link to post
Share on other sites

Thanks for the packages. Will make rolling this out on other machines much easier for everyone! One comment, would you consider making the config and local btsync cache locations XDG based for the desktop package? ie ~/.config/ instead of ~/

Thanks again!

Share this post


Link to post
Share on other sites

You must reboot your machine after creating the file in order to make the changes active.

I have (I just rebooted again to be sure), it still shows the default name, which is ($HOSTNAME - $USERNAME). I don't want my first name getting shown to people on large syncs, so this is a problem.

The other parts of the config file seem to be used, ie: listening port, but the "device_name" is ignored, using the ~/.btsync.conf info instead.

Share this post


Link to post
Share on other sites

Updated all packages to 1.1.69 - All Debian and Ubuntu builds are online.

Changelog:


btsync (1.1.69-1~sid) sid; urgency=low

* New upstream release
- Fixed: Additional error message on startup

-- Leo Moll <leo.moll@yeasoft.com> Tue, 13 Aug 2013 00:41:27 +0200

Share this post


Link to post
Share on other sites

I have (I just rebooted again to be sure), it still shows the default name, which is ($HOSTNAME - $USERNAME). I don't want my first name getting shown to people on large syncs, so this is a problem.

The other parts of the config file seem to be used, ie: listening port, but the "device_name" is ignored, using the ~/.btsync.conf info instead.

I'm really puzzled about that. I have tested it on my own machine and I verified that it shows the name I have written into my specific configuration file /home/leo/btsync.conf :



//!/usr/lib/btsync-user/btsync-agent --config
//
// configuration for the btsync agent running in the
// user environment
{
"device_name" : "Leopoldo's Ubuntu Machine",
"pid_file" : "/home/leo/.btsync.pid",
"storage_path" : "/home/leo/.btsync",
"listening_port" : 0,
"check_for_updates" : false,
"use_upnp" : true,
"download_limit" : 0,
"upload_limit" : 0,
"webui" :
{
"listen" : "127.0.0.1:9999"
}
}

...and on the other machines, I saw appearing "Leopoldo's Ubuntu Machine" in the list of hosts... Are you really sure, you are using the latest version of the package?

Share this post


Link to post
Share on other sites

The other parts of the config file seem to be used, ie: listening port, but the "device_name" is ignored, using the ~/.btsync.conf info instead.

p.S.: Please post me here the contents of your file /usr/lib/btsync-user/btsync-starter

Share this post


Link to post
Share on other sites

$dpkg --list | grep btsync

ii btsync-user 1.1.69-1~raring amd64 Private network P2P file synchronisation daemon(s)

----

$ cat /usr/lib/btsync-user/btsync-starter

#!/bin/sh

# compute user specific directories

DESTDIR=${HOME}

DATADIR=${DESTDIR}/.btsync

CFGFILE=${DESTDIR}/.btsync.conf

PIDFILE=${DESTDIR}/.btsync.pid

USRFILE=${DESTDIR}/btsync.conf

DEVNAME="$(hostname) - $(whoami)"

# "sedify" replacemnt data

XDATADIR="$(echo ${DATADIR} | sed -e "s/\\//\\\\\//g")"

XPIDFILE="$(echo ${PIDFILE} | sed -e "s/\\//\\\\\//g")"

XDEVNAME="$(echo ${DEVNAME} | sed -e "s/\\//\\\\\//g")"

if pgrep -x btsync-agent -U $(id -u) > /dev/null; then

echo btsync-agent already running

exit 0

else

# move to user's home directory

cd ~

sed \

-e "s/DATADIR/${XDATADIR}/g" \

-e "s/PIDFILE/${XPIDFILE}/g" \

-e "s/DEVNAME/${XDEVNAME}/g" \

> ${CFGFILE} < /etc/btsync-user/btsync-user.conf

if [ -f "${USRFILE}" ]; then

/usr/lib/btsync-user/btsync-agent --config ${USRFILE}

else

mkdir -p ${DATADIR}

/usr/lib/btsync-user/btsync-agent --config ${CFGFILE}

fi

fi

------

$cat ~/btsync.conf

//!/usr/lib/btsync-user/btsync-agent --config

//

// configuration for the btsync agent running in the

// user environment

{

"device_name" : "computername",

"pid_file" : "/home/username/.btsync.pid",

"storage_path" : "/home/username/.btsync",

"listening_port" : 10090,

"check_for_updates" : false,

"use_upnp" : false,

"download_limit" : 0,

"upload_limit" : 0,

"webui" :

{

"listen" : "0.0.0.0:9999"

}

}

------------

$cat ~/.btsync.conf

//!/usr/lib/btsync-user/btsync-agent --config

//

// configuration for the btsync agent running in the

// user environment

{

"device_name" : "computername - username",

"pid_file" : "/home/username/.btsync.pid",

"storage_path" : "/home/username/.btsync",

"listening_port" : 0,

"check_for_updates" : false,

"use_upnp" : true,

"download_limit" : 0,

"upload_limit" : 0,

"webui" :

{

"listen" : "127.0.0.1:9999"

}

}

----------

So, again, it picks up my listen port from ~/btsync.conf but it seems to be taking my device name from ~/.btsync.conf. I have played around a bit and cannot get it to change this behaviour.

Share this post


Link to post
Share on other sites

...

$dpkg --list | grep btsync

ii btsync-user 1.1.69-1~raring amd64 Private network P2P file synchronisation daemon(s)

...

So, again, it picks up my listen port from ~/btsync.conf but it seems to be taking my device name from ~/.btsync.conf. I have played around a bit and cannot get it to change this behaviour.

OK. It is totally evident, that you HAVE the latest version and that btsync was started with your personally tuned configuration file. Since btsync never opens more than one configuration file, I have the suspicion, that for some strange reason, the original value was stored into the internal database of btsync. I must admit, that I have tested all of this with a freshly installed btsync without any active folder shares.

I would suggest to start from scratch: stop btsync (use this command: /usr/lib/btsync-user/btsync-stopper ) and than delete or rename the btsync storage_path (in your installation: /home/username/.btsync ). Afterwards restart btsync ( /usr/lib/btsync-user/btsync-starter ) and than redefined the folder shares on the web ui.

Share this post


Link to post
Share on other sites

OK. It is totally evident, that you HAVE the latest version and that btsync was started with your personally tuned configuration file. Since btsync never opens more than one configuration file, I have the suspicion, that for some strange reason, the original value was stored into the internal database of btsync. I must admit, that I have tested all of this with a freshly installed btsync without any active folder shares.

I would suggest to start from scratch: stop btsync (use this command: /usr/lib/btsync-user/btsync-stopper ) and than delete or rename the btsync storage_path (in your installation: /home/username/.btsync ). Afterwards restart btsync ( /usr/lib/btsync-user/btsync-starter ) and than redefined the folder shares on the web ui.

That did it. This is a problem with using a binary settings file, makes it pretty hard to troubleshoot. Thanks for your hard work (flattrd)!

Share this post


Link to post
Share on other sites

Updated all packages to 1.1.70 - All Debian and Ubuntu builds are online.

Changelog:


btsync (1.1.70-1~sid) sid; urgency=low

* New upstream release

-- Leo Moll <leo.moll@yeasoft.com> Thu, 15 Aug 2013 10:44:11 +0200

Share this post


Link to post
Share on other sites

Hi,

thanks a lot for your packages, I know it is some work to be a package maintainer.

Your packages run very well for me but I have some problems with the updates. Sometimes I wonder why one of my machines is not running btsync anymore and I discover that the agent has been stopped by an update, I guess you do a killall of some sort in the update script. It would be great if you could start btsync again after the update.

I guess this is a problem as the btsync-user agent runs with user privileges but the update is a root process. You might be able to solve this by running the agent in an endless loop as long as there is a running state file. If there is an updating state file in a global location, the loop will sleep for some time and then check again. This way, your update script could just create this updating state file and kill all agents. Afterwards that state file could be removed and the agents will automatically start again the new version.

If you want, I can send you a patch for this.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.