@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.
@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:
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?
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:
/home
- they’re going to be installed system-wide)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.