Well, I may be little unfair to DEBs, because only packaging system I can compare with is pacman with its dead-simple PKGBUILDs. Your description of RPM is pretty scary, but I can at lest give it a try…
[quote=“BJay, post:20, topic:709”] “why would I want to quit it?” [/quote]Actually, should syncthing daemon die instead of restarting, Syncthing GTK would hang on that window. But user can close it even without button, or quit using notification icon anyway.
Just as two worthwhile pointers:
To actually create a “Ubuntu compliant” DEB (since the Software Center will complain about “inferior quality” when your handcrafted DEB doesn’t contain the MD5SUMS file in “DEBIAN”) simply fetch one from the Ubuntu repo (packages.ubuntu.com) and do a (filling in a example below)…
sudo dpkg --extract syncthing-gtk_0.5-1_all.deb syncthing-gtk_0.5-1_all sudo dpkg --control syncthing-gtk_0.5-1_all.deb syncthing-gtk_0.5-1_all/DEBIAN
Yes, you do issue the commands as “root”. You can then examine how the project directory has to be laid out and what has to be in “DEBIAN” (“control” file, “md5sums” file, pre/post install script if necessary and so on) and use that as a “template” to create your own
To roll it back up into a DEB (i.e. you put in a new compile and did the required alterations - remember, in the root context because it gets installed into the global filesystem structure) it’s just
sudo dpkg --build syncthing-gtk_0.6-1_all syncthing-gtk_0.6-1_all.deb
Compared to the packages in Arch it’s only a wee bit trickier to create a fully compliant DEB by hand (the actual work are the files inside “DEBIAN”).
As for RPM… start by trying to understand the “rpmbuild” man page (http://www.rpm.org/max-rpm-snapshot/rpmbuild.8.html) and go from there. I don’t think you will find it particularly insightful or straightforward to understand.
Just an idea, but how about creating packages using Alien? Using it, I can create Arch package and then convert it to DEB and RPM without messing with all that dpkg and rpmbuild stuff. Generated DEB installs on Ubuntu without any problems, but I don’t have mean to test it on OpenSuse right now.
syncthing-gtk_0.5-2_all.deb (467.6 KB) syncthing-gtk-0.5-2.noarch.rpm (425.9 KB)
Well, just because you asked about the idea I gave it a try (using Andrew’s DEBs as they are “Debian standard compliant”) … and the result is, as expected, inferior…
While alien can convert a DEB to an RPM it’s missing one crucial thing … it does NOT convert the required dependencies.
For example, Andrew’s DEB correctly list…
Depends: python (>= 2.7), python (<< 2.8), python:any (>= 2.7.1-0ubuntu2), python-gobject | python-gi, python-dateutil, libappindicator3-1, libgtk-3-0, gir1.2-gtk-3.0, gir1.2-glib-2.0, gir1.2-appindicator3-0.1, python-notify
Recommends: python-pyinotify
The alien converted RPM has NONE of the “Requires” (=“Depends” in the DEB control file) or “Recommends” included, and I guess I don’t need to add that all the other “Metainfo” within the various files in “INFO” is also totally wonky.
You can of course install the converted RPM, but don’t expect it to start at all as it won’t find required dependencies unless you already have them installed by pure chance and coincident.
In conclusion: your “hacky” solution to use alien to cross-convert packages for $distro is not really a good idea.
I also looked into the RPM you provided above, and it’s as borked as my “alien conversion trial run”.
EDIT: Another “oddity”…
So I tried to “smartass” the system and do as you recommended on your github page: I extracted the .tar.gz, moved it into ~/.local/share (I wouldn’t need it “globally” installed because the syncthing binary is just in my ~/bin) and fired up syncthing-gtk.py (in a terminal). It complained about missing “datetime” so I installed python-datetime and it started up (and works). The odditiy however is … when I put the .desktop file into ~/.local/share/applications (yes, I corrected the Exec= and Icon= lines prior to copying the .desktop file over) it shows in the application list but it won’t start (also not by creating a syncthing-gtk symlink to syncthing-gtk.py) … it silently fails (no error message in any system log or “xsession” log file). Starting it manually through the terminal works.
Before you think I’m totally nuts: this actually worked with XnViewMP (not available as an RPM in the openSUSE repos because it’s just “free for personal use” but no “Opensource”, so the SUSE guys refuse to include it due to not being licensed under a free license). I downloaded the amd64 binary tar.gz, put it into ~/.local/share/XnViewMP, copied over the .desktop file after editing it and installed libpng12 because it depends on that specific version of the library. Starts and works flawlessly when I click its icon.
I know it’s far from ideal and I have no intention replacing Andrew’s DEBs (I’m really thankfull to him for doing them), but it would be nice way for doing RPMs. I can probably add missing fields using script
Your “smartass” solution should work, but you need to change working directory before running syncthing-gtk.py. It uses relative paths to glade files and icons (in contrast to installed syncthing-gtk launcher that has hardcoded /usr/share/ and windows launcher that reads path from registry)
So you need either chage Exec= line in .desktop file to something like cd ~/.local/share/no_idea_where && ./syncthing-gtk.py or modify paths at before-last line in syncthing-gtk.py
kozec, after a lot of messing about I managed to get a first RPM going, though there are a few draw-backs…
Now …
I whipped the stuff I did into a file on copy.com
The file contains the readily built x86_64 RPM for openSUSE 13.2 as well as as .sh file to run the build (having run “sudo zypper install rpm-build” prior to launching the script is a must) along with the required spec file - it’s meant for version 0.5 ONLY! Also, if you compare the “Requires” to the “Depends” of Andrew’s DEB please know that the “gir1.2*” libraries do NOT exist in openSUSE, but that doesn’t seem to keep syncthing-gtk from working. Also, the fancy tar extracting and tar creating I do in the build script is necessary … the -gui in the directory name of the tarball doesn’t really go very well with the -gtk project name, that’s why I need to extract to rename the directory to wrap it up into a new tarball … otherwise the build would bomb (yet again).
If you, kozec, or someone knows how to fix the OBS problem up (it’s complaining about the icon resource in the .desktop file) so it can be built on the OBS I’m more than willing to maintain a repo - for now I had enough of the RPM idiocy. If the exact error message the OBS throws needs to be known I happily provide a log.
I am sorry to interrupt your discussion.
@kozec : You mention that you now support inotify.
I think it was not supported by syncthing yet and I am also telling people so. eq: #989. Should I rather tell people to use your syncthing-gui?
I still suffers from the same issues which were big enough that it is still not part of the normal syncthing. Which is the default kernel limits on OS X/BSD only allowing to watch 256 files/directories at one time: http://git-annex.branchable.com/bugs/Issue_on_OSX_with_some_system_limits/
@BJay Thanks, I should still have OBS account somewhere, so I’ll check that error. Having OBS to do all packaging work would be nice.
@bigbear2nd It’s exactly as @AudriusButkevicius says, inotify works, but only within it’s own limits. It’s possible to increase limit and it is possible to enable inotify only for repositories where it matters, but it’s still limited thing.
But I’m not aware of any better way to do filesystem monitoring, so it’s probably as good as it can get.
[quote=“BJay, post:26, topic:709”] It does NOT build on the openSUSE Build Service (OBS). [/quote]I have to admit, it was exactly as bad as you described it. But not impossible. Here are working RMPs in OBS.
Problem is syncthing dependency. Althought there apparently is syncthing package in OpenSUSE, it’s probably not part of default repo and package installer will not find it. Is there any way how to reference syncthing package, or user will always have to install that dependency manually?
The syncthing package on the OBS is a user project; see openSUSE package for Syncthing as an example.
However, depending on “syncthing” is actually an option for your consideration:
if you want to depend on a 3rd party packaged RPM you can go that route and hope that the package is updated in a somewhat timely manner whenever a new version is released.
You could use the “first run” wizard to put the binary into /usr/bin yourself if you find a way to put the file there with elevated rights (only root can write to /usr/bin, so you would need to find a way to elevate for binary install/update). The syncthing binary doesn’t require anything extra; everything is statically linked into it (a very good practice in this case).
You could go the “per user” route. In this case it would be best to find a suitable place for dropping the binary to (i.e. check if $HOME/bin exists … if yes, drop it there - if not, create the directory and drop it there … that way you at least follow a somewhat official way to have a binary in the user directory “sorted out and properly placed”) and have it launched it through your UI (either when the user starts it up or when it loads upon logging in to the session because its set to autostart).
I would run with either the 2nd or 3rd option if I would be you. Why? Well…
The “syncthing” package is actually meant for “daemonized startup on boot”. This means: A user using the package will most likely not have any use for your UI and instead use the web UI because it is either running on a server server where there’s no X11 or on a totally headless system. “Joe Average” will most likely use it in his user context anyway, so dropping the binary into the user directory is a safe bet in this scenario.
I think there’s also a way to declare a “Conflicts” in a RPM spec file if you want to “clash” on purpose with the “synthing” package - to avoid having a system-launched instance and your user instance at the same time.
Anyhow, great to see you resolved the problem that prevented the OBS packaging going through. Will add your OBS project as a repo to my system. In the meantime I actually found out that SUSE is hiding the documentation on openbuiidservice.org (the link on the build.opensuse.org site isn’t really obvious nor does it stand out that one can find the documentation there - structuring and organizing things isn’t a particular strength of the SUSE lot).
EDIT: Added your OBS home project as a repo and installed it (I “broke” the dependency with syncthing because I already had the binary in $HOME/bin and the config.json was already all set from my packaging attempt).
One thing to note that you should point out: When adding your home project as a repo (the “zypper” way) it will not be auto-refreshed by default. If you publish an update it therefore won’t reach the user. To receive updates as you publish them one needs to run…
sudo zypper modifyrepo -r <repo url>
…once, after adding the repo, to enable “auto-refresh” and stay up-to-date.
I ended up going by route #3. Existing ST packages are already out of date and unless there is same way how to let OBS to build packages automatically, I’m not going to keep and update additional…
But Syncthing-GTK can connect to daemonized instance (instance started by rc script) or just launch /usr/bin/sycnthing installed from package, so there is no need to make it conflicting. Also, downloading binaries to ~/bin is probably best solution on OpenSUSE, but completely crazy idea in general 
It’s not as whacked of an idea as you may think it is.
While the $HOME/bin directory is not exactly defined in the LSB standard (which no one follows really anyway), it’s a well accepted solution to put “user binaries”, only runable by the corresponding user, into the home directory for quite a while now. EDIT: Of course only for as long as the binary/script can make due with user privileges and not require elevated rights to run. /EDIT
In openSUSE there’s actually a empty bin directory sitting in the user home by default, in Ubuntu/Debian (and derivates thereof) it’s not there by default but the bashrc (global one in /etc and the dot file in the user home) contains a check to add it to the path if it exists.
The LSB compliant way would be, of course, to properly base files under /usr or /usr/local (though /usr/local became somewhat unpopular) or /usr/sbin (daemon binaries for example), though that would leave you again with the problem of having to spawn a child process with elevated rights to put/update a file at that filesystem locations.
While it may look kinda weird to place a binary in $HOME/bin it’s not “against guidelines”; and let me tell you that I have a ton of shell/python/perl scripts as well as real binaries sitting in my bin directory.
The only valid complaint might be that it’s “unusual” or “not best practice”, but then show me a Linux desktop system (meaning: used in the same likes as a Windows box) where there are really several users logged in at once. The default internal syncthing UI at 127.0.0.1 would then become a problem (clashing for local IP:Port) when launched concurrently from several user accounts on the very same machine, unless syncthing has a “sanity check” to spread out on the ports on 127.0.0.1 automatically (i.e. first instance at 8080, second one on 8081 and so on - haven’t checked if there’s a handler in syncthing to resolve that on-the-fly); that’s when a daemonized launch in the likes of “for $user in $launch_for_users” would be the way to go so you can pre-define the config for each daemon process).
If someone complains refer them to me - I’ll handle it. 
[quote=“BJay, post:33, topic:709”]
The default internal syncthing UI at 127.0.0.1 would then become a problem (clashing for local IP:Port) when launched concurrently from several user accounts on the very same machine, unless syncthing has a “sanity check” to spread out on the ports on 127.0.0.1 automatically (i.e. first instance at 8080, second one on 8081 and so on - haven’t checked if there’s a handler in syncthing to resolve that on-the-fly); that’s when a daemonized launch in the likes of “for $user in $launch_for_users” would be the way to go so you can pre-define the config for each daemon process).
[/quote]Actually, 1st run wizard in ST-GTK checks for this and sets HTTP to first unused port >= 8080, so there shouldn’t be any clash even in multiuser or multiuser+systemwide daemon environment. But it’s true that I can’t remember seeing machine running multiple desktop sessions in this century 
For a change of pace, bugreport for the Windows version (0.5.1)…
Bug: On Windows 7 and Windows 8, using the native Windows decorations, the Syncthing-GTK window is always placed on top/left of the screen and slightly out of the screen. Doesn’t happen when using the internal window decoration, in that case the windows is pixel-perfect aligned with the top/left of the screen (that’s what I tend to use to “unify” the look between Linux and Windows).
Repropduce: Just restore the Syncthing GTK window from the tray icon.
Bug: “Anon Data Collection” doesn’t stick on Windows. The checkmark remains checked at all times. Unchecking and restarting Syncthing GTK shows it checked again.
Reproduce: Try to uncheck the anonymous data submit option and either go back into the pref screen or restart and go back into the pref screen … will show as checked.
Bug: For whatever reason I can’t figure out the “repo” (left side) and “host” (top/right where there’s also the status of the annouce server shown) section within the main windows is always collapsed. On Linux, the repo and the host are always expanded.
Reproduce: Just open the Syncthing GTK window and all “panes” inside the window should be collapsed.
Bug: Shortcut (in the “Start Menu”) is created with the wrong icon resource path. Syncthing GTK installs into “C:\Program Files (x86)” on 64-Bit Windows Editions. The path to the icon resource in the shortcut reads “%ProgramFiles%\SyncthingGTK\icons\st-logo-128.ico” (that would be the case for a x64 program) where it should actually be “%ProgramFiles(x86)%\SyncthingGTK\icons\st-logo-128.ico”. I think that’s the installers fault - it needs to differentiate between 32-Bit and 64-Bit OS versions.
Reproduce: Right-click the Syncthing GTK shortcut -> Properties -> Change Icon. Throws an error message about the .ico not being found due to wrong path.
There is an issue tracker on github
Let’s keep the forum tidy.
Feel free to delete the posts bothering you. That being said … I don’t have a Github account so the option to post to the issue tracker is kinda outta reach - I’m running in-house Git servers, so “then go and create an account” is also out of question as I have no use for “cloud source repos”.
Lots of people who don’t push code have GitHub accounts, for the purpose of filing bugs or otherwise. You don’t have to, for sure, but it’s the common way to make a note of a problem and make sure it’s not forgotten.
I don’t think Audrius is particularly worried about polluting the forum, so there’ll be no deleting of posts. But a bug report in the middle of a forum thread does run the risk of being missed or forgotten, now matter how well everyone intends otherwise.
And if nothing else it’s annoying to push a commit to solve “post #35 in that forum thread #709 on discourse from last year” instead of “fixes #1234”.
Thank you for reporting. I created the bug reports for you on github:
Oh god, man is afk for 3 days and this happens O.o
Asking on github will not work, I guess, so @BJay, can you please check if window position gets saved to registry? It should be stored in User/Software/Syncthing GTK/window_position_0 and window_position_1 every time when window disappears (and reused when window gets mapped back). Only problem I can imagine in this is some sort of crazy multi-monitor configuration where window position gets to negative values…
And question #2, I’m not sure what do you mean by this:
All boxes should be collapsed when app starts…