Package Details: btsync 2.3.7-1

Git Clone URL: https://aur.archlinux.org/btsync.git (read-only)
Package Base: btsync
Description: BitTorrent Sync - automatically sync files via secure, distributed technology
Upstream URL: https://www.getsync.com
Licenses: custom:btsync
Conflicts: btsync-1.4
Submitter: ava1ar
Maintainer: ava1ar
Last Packager: ava1ar
Votes: 292
Popularity: 4.432169
First Submitted: 2013-09-17 03:06
Last Updated: 2016-05-08 04:09

Dependencies (0)

Required by (3)

Sources (5)

Latest Comments

BunBum commented on 2016-05-15 13:48

@broken.pipe I wrote a lot of emails with the sync support team and in the end they suggested that I should try the armhf binary from the link that I posted. Unfortunately you can't find the binary on the sync website. I suggested to update their website for that. I'm curious when / if they update it.

After all I don't understand which Arch update broke the previous binary that worked for me in the last couple of months.

zifnab commented on 2016-05-15 08:55

summary attempt:
- armv5 devices: should ALL work with "non hf" version (which is the one provided by ava1ar in package 2.3.7-1) as none of these devices does have "hf" support
- armv6 devices: only the raspberry pi 1 is supported by arch linux arm, which is a "hf" enabled device: for now, this should be the ONLY (yet widespread) device NOT working (because the hf binary seem to be compiled with armv7 as a min. requirement)
- armv7 devices (ALL are "hf" devices) and up (armv8, etc...): all should work with the alternate "hf" binary (link provided by BunBum)

anyway: it doesn't seem we are "addressing" the true root cause here, as rpi1 device used to work with all versions (tested from 2.3.1 to 2.3.6). now all (2.3.1 to 2.3.7) stopped working: so another updated package would be the true culprit here.
still, it is better for hf devices to go with the hf binary!

ava1ar commented on 2016-05-15 04:49

I use btsync only on one ARM device (which is old Marvell Kirkwood ARMv5) and have no problem with latest version. Let's summarize what we have now with ARM versions and decide what should we do with the package.

zifnab commented on 2016-05-14 21:01

thx BunBum.
- worked for armv7h (cubox-i4pro here)
- still doesn't work for armv6h (raspberry pi 1)

broken.pipe commented on 2016-05-14 10:11

@BunBum: It's probably built with a newer toolchain, this is why it stopped working under archlinux after the glibc upgrade. How did you figured it out? Thanks!

BunBum commented on 2016-05-14 07:19

I've got it! You have to download the binary from here: https://download-cdn.getsync.com/2.3.7/linux-armhf/BitTorrent-Sync_armhf.tar.gz
Then it should work on armv7 machines. I don't know if it's working on armv6. Would it be possible to update the PKGBUILD for that?

broken.pipe commented on 2016-05-10 06:49

I noticed this error on armv7h and armv6h. Take a look at my list of updated packages (http://pastebin.com/bEtPKuZc). One of them caused the failure.

Maybe this kind of error: https://forum.getsync.com/topic/42057-230-segmenation-fault-on-raspberry-pi-with-openelec/

Lulzon commented on 2016-05-09 18:52

@ava1ar I installed this on a freshly formatted raspberry pi and it occured.

Edit: I realized this comment is pointless - yesterday was a long day. You meant that maybe downgrading from 2.3.7 wasn't successful due to some cache.

BunBum commented on 2016-05-09 18:15

I believe that something was updated on the Arch Linux ARM architecture. A segmentation fault indicates that there went something wrong while allocating memory.

On my desktop machine everything works as expected, it only happens on my ARM machine (Odroid U3). So some update of the linux kernel / gcc / something else broke the btsync binary compatibility.

Note: I *believe* that's the reason but maybe I am wrong with this theory.

ava1ar commented on 2016-05-09 17:50

@BunBum did you try to clean the cache folder (or what is the name of it for btsync). Broken old version make me think that this is related to configuration/cache.

All comments