Package Details: btsync 2.3.8-1

Git Clone URL: (read-only)
Package Base: btsync
Description: BitTorrent Sync (Resilio) - automatically sync files via secure, distributed technology
Upstream URL:
Licenses: custom:btsync
Conflicts: btsync-1.4
Submitter: ava1ar
Maintainer: ava1ar
Last Packager: ava1ar
Votes: 300
Popularity: 5.381540
First Submitted: 2013-09-17 03:06
Last Updated: 2016-06-24 23:09

Dependencies (0)

Required by (3)

Sources (5)

Latest Comments

ava1ar commented on 2016-06-24 23:11

Sorry for the delay - just updated the package to 2.3.8.
As for now, I changed the binary for armv7 arch to hf version, keeping other unchanged. Please check how it works and let me know if other updated are needed.

zifnab commented on 2016-06-21 08:59

u got me a bit wrong mate.
optimal for u, is not the RPi1 workaround, but the armv7h (hf) workaround (because currently, u are missing out on performance optimizations. I do own a cubox-ipro 4 too, just like you):

- hf devices >= armv7 (basically, ANYTHING >= armv7): they can update to latest glibc, and overwrite their btsync binary with the hf version (can now be found on official btsync website)
- non hf devices, AND hf devices <= armv6 (so basically, rpi1 and all armv5 boards): stick with glibc-2.23-1 for now (you can find how to downgrade in other posts here), and go with the btsync 2.3.7-1 package from ava1ar (which refers only to non hf for now)
(I have to say, I don't have any armv5 board, so for them, I don't have confirmation for the glibc part of the workaround...)
I am sure ava1ar will update his PKGBUILD for hf and non hf btsync binary builds for >= 2.3.7-2 (if/when it comes out).

mad_cow commented on 2016-06-21 07:19

for Cubox i4 pro; i followed instructions adapted from
(these instructions are for RPI 1)

1) downgrade glibc;
sudo pacman -U
2) reinstalled btsync

bim9262 commented on 2016-06-05 15:04

(gdb) r --config .config/btsync/btsync.conf
Starting program: /usr/bin/btsync --config .config/btsync/btsync.conf
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/".

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()

I'm no expert, but looking at the gdb output it looks like it fails on loading host libthread_db library "/usr/lib/" and then fails to go any further... It doesn't look like it's executed any of the application if it is dying at 0x00000000.

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:
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?

All comments