elfo

What I said does not invalidate your point... Users can, and should, contact devs with bug reports. All I'm saying is users should also be allowed to revert to a previous version if the latest has a bug that prevents correct use of the application (or some important part of the application) while the latest version is being fixed. I'm sure you agree that users, that gracefully test your software and report bugs, should not be without the use of said software while the bugs (they previously reported) are being squashed. Just because software is "beta" quality, users should not have to suffer needlessly.

You already answered your own question... Just to be clear, a packager needs: a hard link to the source code or pre-built binaries from upstreama way to build the package for a specific distroa place to put the package so others can access it This way, a webpage can be created that provides the packages as follows: bittorrent sync version 1.4.83 <slackbuild script link> <upstream binaries tarball 32bit link> - <slackware package link> <upstream binaries tarball 64bit link> - <slackware64 package link> bittorrent sync version 1.4.82 <slackbuild script link> <upstream binaries tarball 32bit link> - <slackware package link> <upstream binaries tarball 64bit link> - <slackware64 package link> bittorrent sync version 1.4.75 <slackbuild script link> <upstream binaries tarball 32bit link> - <slackware package link> <upstream binaries tarball 64bit link> - <slackware64 package link> etc, etc, etc... Providing packages for all versions (not just the latest) helps people test things and if they find a particular version to be buggy they can always downgrade to a working version, or keep testing the buggy one. We are willing to provide all of this ourselves but, as things stand now, we have to do it manually. It would help A LOT if you guys help us automate the creation of packages for specific distros as it will mean that your program will reach more people.

@RomanZ I think it would be far more elegant to get the version right away with something like curl "http://syncapp.bittorrent.com/latest/" | grep "Sync version" | sed 's/\(<h3>\|<\/h3>\)//g' | cut -d " " -f 3...than hammering your webserver 15 to 20 times hoping to get a hit instead of a "file not found". It would be greatly appreciated, by all package builders, if you help us make the process of building the bittorrent sync package for our distros fully automated

That is unfortunate, as there is no easy way to automatically find the version number of the latest build. Maybe a fix would be to have a "syncapp.bittorrent.com/latest/" that would be linked to whatever version happened to be the latest on syncapp.bittorrent.com The idea is to place a script on an hourly cron job to check your server for a change in the latest version number. If version changes, download tarball and rebuild slackware package.

Hello guys, I'm scraping the version number from the download webpage... I hope it is in sync with syncapp.bittorrent.com Here is my (beta quality) slackbuild: #!/bin/sh# Slackware build script for btsync## Copyright 2014 Elfo <jmfl {at} sapo [dot] pt># All rights reserved.## Redistribution and use of this script, with or without modification, is# permitted provided that the following conditions are met:## 1. Redistributions of this script must retain the above copyright# notice, this list of conditions and the following disclaimer.## THIS SOFTWARE IS PROVIDED BY THE AUTHOR ''AS IS'' AND ANY EXPRESS OR IMPLIED# WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF# MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO# EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,# PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;# OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,# WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR# OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF# ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.PRGNAM=btsyncBUILD=${BUILD:-1}TAG=${TAG:-_elfo}if [ -z "$ARCH" ]; then case "$( uname -m )" in i?86) ARCH=i386 ;; arm*) ARCH=arm ;; *) ARCH=$( uname -m ) ;; esacfiCWD=$(pwd)TMP=${TMP:-/tmp}PKG=$TMP/package-$PRGNAMOUTPUT=${OUTPUT:-/tmp}# this is here because x64 does not conform with the output of uname -mif [ "$ARCH" = "x86_64" ]; then BTARCH="x64"else BTARCH=$ARCHfiset -eVERSION=$(curl http://www.bittorrent.com/sync/download | grep "linux-$BTARCH" | grep -o '<span>.*</span>' | sed 's/\(<span>\|<\/span>\)//g')wget syncapp.bittorrent.com/$VERSION/btsync_$BTARCH-$VERSION.tar.gzrm -rf $PKGmkdir -p $TMP $PKG $OUTPUTcd $TMPrm -rf $PRGNAM-$VERSIONmkdir -p $TMP/$PRGNAM-$VERSIONcd $PRGNAM-$VERSIONtar xvf $CWD/btsync_$BTARCH-$VERSION.tar.gzchown -R root:root .find -L . \ \( -perm 777 -o -perm 775 -o -perm 750 -o -perm 711 -o -perm 555 -o -perm 511 \) \ -exec chmod 755 {} \; -o \ \( -perm 666 -o -perm 664 -o -perm 600 -o -perm 444 -o -perm 440 -o -perm 400 \) \ -exec chmod 644 {} \;mkdir -p $PKG/usr/bin/ $PKG/usr/doc/$PRGNAM-$VERSION $PKG/installcp -a LICENSE.TXT $CWD/README\ $PKG/usr/doc/install -m 0755 btsync $PKG/usr/bin/btsynccat $CWD/$PRGNAM.SlackBuild > $PKG/usr/doc/$PRGNAM-$VERSION/$PRGNAM.SlackBuildcat $CWD/slack-desc > $PKG/install/slack-desccd $PKG/sbin/makepkg -l y -c n $OUTPUT/$PRGNAM-$VERSION-$ARCH-$BUILD$TAG.${PKGTYPE:-tgz}

I have the same problem. The version must be specified in the build script. A repository for making all versions available would be greatly appreciated. The alternative, as fearedbliss said, would be to host the tar ball ourselves.

Hello RomanZ, Thank you for your reply and please excuse my lateness in viewing it (I was on a much deserved vacation). I wish to submit a slackbuild to our community driven site slackbuilds.org For those unfamiliar with slackware: a slackbuild is a script that builds a well formed slackware package by compiling source code and packaging the resulting binaries in the appropriate folders or by simply packaging the supplied binaries in case of closed source software (think of NVIDIA drivers and the like). Please note that slackbuilds.org only hosts slackbuild scripts, not binary packages. There are, of course, some rules to follow but the one that applies to this case is: "a link to the download location for the specific version must be supplied". Unfortunately, btsync download location for a specific version is not easily available. Another option is to make a slackbuild that does not comply with the official rules and host it on my own, but it would be nice to have an easier way to identify the version number. I *could* extract the tar ball, then execute "btsync --help" and parse the version number from the output, but would rather parse some "README.TXT" file if you would be kind enough to include it in the tar ball. This file should contain the version number for the binary any warnings that you see fit to display (like the license link), as well as a change log (again, optional). What do you think?

Hi all, I would like to package btsync for use with my favorite linux distro (slackware), but I don't know if I'm allowed to do it or not. The LICENSE.TXT file included in the tar ball just has a link to a "terms of use" website that states that we are not allowed to copy or distribute "the software"... so that would be a no... yet, that site is so general purpose that I'm not sure if it applies to btsync specifically or not. Sure, I could write a script that downloads the tar ball, extracts it, forms a slackware package with it and installs it, but that would be silly. I'd rather have a slackware package that I could maintain and distribute to the community. It would be great to have an "official" answer Thanks