Package Details: btsync 2.3.8-1

Git Clone URL: https://aur.archlinux.org/btsync.git (read-only)
Package Base: btsync
Description: BitTorrent Sync (Resilio) - 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: 303
Popularity: 5.863326
First Submitted: 2013-09-17 03:06
Last Updated: 2016-06-24 23:09

Dependencies (0)

Required by (3)

Sources (5)

Latest Comments

albert748 commented on 2016-09-21 14:06

I've tested that to syncable between windows and arch, UMask = 0002 flag shall be added to btsync.service. otherwise the file modified from windows will not be writable from arch if use the default 0022 umask.

if you have time, please add this flag to btsync.servie.

BunBum commented on 2016-09-13 14:43

BitTorrent Sync was renamed to Resilio Sync. Updates (like the newest one 2.4) will only happen for Resilio Sync. BitTorrent Sync will not be updated anymore: https://blog.resilio.com/resilio-sync-2-4/

Will there be a new AUR package for rslsync?

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

@mad_cow:
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 https://archlinuxarm.org/forum/viewtopic.php?f=60&t=10260&sid=8fa41b6eb4e2a5165148e70652010d59&start=10
(these instructions are for RPI 1)

1) downgrade glibc;
sudo pacman -U http://fraggod.net/static/mirror/packages/archlinuxarm/armv7h/glibc-2.23-1-armv7h.pkg.tar.xz
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/libthread_db.so.1".

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/libthread_db.so.1" 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)

All comments