Feature Request: PPA?

@Nutomic It would be possible by building with golang-go, I think.

I’ll look at the F-Droid build procedure. Perhaps I can use it.

@calmh I changed both (syncthing.org -> syncthing.net and github.com/calmh/syncthing -> github.com/syncthing/syncthing).

I just wanted to say Thank you.!

Are you going to be keeping that ppa up to date? Last build there is 8 weeks ago.

I created a .deb package: [WIP] Syncthing Ubuntu Installer

Advantage is that Syncthing updates itself automatically, so once it is installed, no update of the package is necessary anymore.

PPA is a great idea. Is there a way to connect it to automated builds?

Audrius, is there an automated build setup like Jenkins or something? Maybe we can have Jenkins recombine the codebase and write the .deb package, but only whenever a commit on master is tagged with ‘release’ or something like that.

Then someone else can populate the PPA from the Syncthing github automated build using cron. That’d way the PPA would never go out of date, and wouldn’t need any maintenence.

It seems to be a complicated setup since Syncthing updates itself automatically anyway. Once again, I made a .deb package which:

  • downloads the latest version of Syncthing
  • lauches Syncthing automatically at startup for a given list of users

Since ST updates itself, there is no need to do anything afterwards on client side to keep it up-to-date.

Oh nice bliz, I missed that comment. . . Well done. Should we put this in a PPA or do more tesing first?

Yeah builds are done by a Jenkins server.

Yes, I’m going to.

I’m sorry for those 8 weeks - I’ve been busy wih school.

But I uploaded v0.10.26 just now.

Wait, what?!

How is Syncthing going to ujpdate itself when put into a package?

For this you either have to:

  • put it outside of system folders (packages shouldn’t write to /home - they’re going to be installed system-wide)
  • open up the file so that it can be edited by users (which isn’t recommended - if user can change it and another runs it, what happens? There’s a security risk involved.)
  • or run Syncthing as root (Hello? Running a network as root?!)

I’m very interested in how this could be done.

But after all: You’re circumventing the package manager. (You aren’t Steam!)

What sense does building a package make, if it isn’t installed system-wide and isn’t auto-upgradeable through the package manager?

That’s really a good idea. Thanks.

I haven’t tried to automate this because the build process or the resulting file names or the file names of the documentation changed multiple times. This is normal for v0.*.

But I could try to automate it. Ant let it send an e-mail to me if something breaks.

You can compile syncthing with automatic upgrades disabled.

I think, I’ve done it. I run go run build.go -no-upgrade clean build. That should do the trick, shouldn’t it?

My package only contains an init script, then downloads ST automatically. The ST executable is not included directly in the package. So far, the executable is installed in /usr/local/syncthing-startup, which is open to all users. I did it for sake of simplicity, but that would not be a big deal to create a copy of the executable for each user… Not very nice, but safe.

Security risk? Yeah, actually not more than using an executable from a random PPA. Circumventing the package manager? Yeah, I don’t care. The user has a copy of ST which is official and up-to-date, and I don’t have to spend time on packaging. Everybody is happy.

bilz I think that’s fine . Many ppas work just like that – install globally to /usr/local. Well done.