As usual, a couple of lintian warnings.
There must be a way around “new-package-should-close-itp-bug”. I won’t file a bug in Debian, or add “Close #123456”.
Tried to override “zero-byte-file-in-doc-directory” without luck.
There must be a way around "new-package-should-close-itp-bug". I won't file a bug in Debian, or add "Close #123456".
No need. It will go away with the next version number. Just bump the version number. When the second changelog entry exists, it won't complain about this anymore.
Handy shortcut.
make deb-chl-bumpup
Tried to override "zero-byte-file-in-doc-directory" without luck.
No need to override. It’s because changelog.upstream is still empty. deb-chl-bumpup will also fix this.
export DEBFULLNAME="Full Name"
export DEBEMAIL=your@emai.net
make deb-chl-bumpup
(You could set this environment variables more comfortably in a location of your choice to make those permanent.)
(deb-chl-bumpup is just automating and imho simplifying usage of debchange.)
Package name. After your mail to Whonix-devel and the name naturally used in TimeSync: Whonix ™ Time Synchronization Mechanism, I think sdwdate-tray is more descriptive than sdwdate-gui, which sounds too general. I propose to rename the package sdwdate-tray.
Not sure. How likely is it that sdwdate-tray turns into a full gui? Especially the left click action could show a comprehensive overview of all states of the various checks.
Checking if sdwdate is running. It looks sort of awkward, asking the user to stop and restart the program once/if the problem is fixed. Could make a loop checking sdwdate, but that would require a separate thread in sdwdate-gui. Still far from ideal.
I was thinking of writing a separate program that checks sdwdate before launching sdwdate-gui. It could popup a GUI in case of failure. Same for bootclockrandomization, but non blocking.
[sdwdate-gui would then live by its name, becoming a mere monitor (hence the name below) . Good in the perspective of “standard” distributions.]
Using “Time Synchronization Monitor” in the tool tip text. Does it sound right for the gui name in desktop applications?
Let’s try to go real simple. sdwdate-daemon provides all the information, sdwdate-gui shows them in a usable way.
I guess the babysitting daemons way won’t work. Sdwdate shouldn’t crash. If it crashes, we should fix the bug. But in normal operation there should never be the case that it’ stopped without having the user intent that. To more we try to add any error handling code for such situations with loops and what not, the more we are creating the issue we want to fix. Does that make sense?
I mean, how often does this situation happen? systemd also supports restarting the service if it crashed for unrelated reasons. sd_notify, remember that [unrelated] discussion on the tracker. (⚓ T274 control-port-filter-proxy sd_notify support)
A loop sounds awkward indeed. Then you need to keep polling the file system. Best would be to get notified by inotifywait as soon as sdwdate creates any files that sdwdate-gui can use for output. Plus once sdwdate-gui starts, check the folder for existing files. (Because inotifywait won’t cover already existing files at time of startup.) If sdwdate does not run, i.e. if it hasn’t created any files, just say so. You could indeed advice the user to run “sudo service sdwdate restart” in such situations (or to use the right click action for that).
Maybe if sdwdate has not provided any status files yet, run “sudo service sdwdate status” once? Add the output of that to the tooltip? Then no loop. Just rely on inotifywait to notify about newly creates status files.
If it was any useful, this could also work the other way around. systemd unit files support stuff like ExecStartPre/Post, ExecStopPre/Post. This could be used to send some signal to sdwdate-gui. But I don’t think we need that for now. Just useful to know.
I guess the babysitting daemons way won't work. Sdwdate shouldn't crash. If it crashes, we should fix the bug. But in normal operation there should never be the case that it' stopped without having the user intent that. To more we try to add any error handling code for such situations with loops and what not, the more we are creating the issue we want to fix. Does that make sense?
Yes, we could easily shoot our own foot.
But because we have to make some sdwdate check when the GUI is loaded , I implemented it (roughly) as suggested in your post.
check if status file exists.
if not, ask the user to try restarting sdwdate. If the icon is still red, report the bug. sdwdate-gui watch the folder (something equivalent to “inotifywait -e create path”). If the status file is created, it starts watching it.
That should be safe, and no sdwdate-gui exit-restart is required.
orange icon only if fetching remotes not finished after boot, green in normal cycles.
modified the logic in the main loop so that the success file is written even if set_new_time is false
inform sdwdate-gui if sdwdate was stopped by the user.
separate status and message in sdwdate_loop.
different sleep times, retry on error.
At this stage, the latter is done only for “No values returned from url_to_unixtime”. The reason is that it happens randomly, without apparent cause, when running sdwdate at short intervals (less than a minute). It’s back to normal on the next cycle. In normal conditions, the probability that this happens is very low, but swdate would stop and the icon stay red for the duration of the next sleeping period.
It might have to do with my internet connection, but I suspect the problem lies with gevent timeout. If you could test it for a few hours with a short sleep time and read the log, that would help clarifying.
The sleeping time is adjustable after an error occurs too, which let us retry at will.
Next would be:
what to do on left click action (probably display the tool-tip text, or an expanded version)?
Could this informing also be as lightweight as watching status files change?
- what to do on left click action (probably display the tool-tip text, or an expanded version)?
For start perhaps just the same message as the tool-tip.
- do we re-implement restart fresh in the menu?
- anything else in the menu?
Maybe like this... [Only development comments.] The "-----" should symbol dividing lines. (Just have a look at a few existing systray icons. Many are using these deciding lines as a stylistic feature.)
“View status.” (same as left click)
“Open sdwdate’s log.”
“Restart sdwdate - Gradually adjust the time.” [“normal restart”]
“Restart sdwdate - Clock jump.” [“restart fresh”]
“Stop sdwdate.”
“Exit.”
But this are all with question marks. We could use help with comments on usability.
Maybe “View status.” and “Open sdwdate’s log.” could be combined. So “Open sdwdate’s log.” would be a click to expand button or simpler just starting it in an editor. I guess the latter is simpler, better and sufficient.
Should have mentioned, most of the changes are in sdwdate.
My mistake.
Can we make the passive tooltip text (mouse hover over) copyable? Only if not too much effort.
When you keep your mouse on that tooltip, the tooltip won’t change until you move your mouse away and there again. Is this something that could be made more dynamic?
Non fatal / crashing error. Got this while running from cli. (Not by autostart.)
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/sdwdate_gui/sdwdate_gui.py", line 70, in status_changed
status = pickle.load(f)
File "/usr/lib/python2.7/pickle.py", line 1378, in load
return Unpickler(file).load()
File "/usr/lib/python2.7/pickle.py", line 858, in load
dispatch[key](self)
File "/usr/lib/python2.7/pickle.py", line 880, in load_eof
raise EOFError
EOFError
with open(self.status_path, 'rb') as f:
Do you think this should be put within exception handling? Perhaps there could be race conditions while sdwdate-gui tries to read the file while sdwdate-daemon just rewrote it so the read would fail?