sdwdate and sdwdate-gui development thread

sdwdate-gui (non-Qubes)

  • exit menu entry missing
  • left click does no longer show popup?
  • starts with Unexpected error: <class 'NameError'> but otherwise working
sdwdate-gui
+ set -e
+ command -v kdesudo
/usr/bin/kdesudo
+ command -v /usr/lib/sdwdate-gui/sdwdate-gui
/usr/lib/sdwdate-gui/sdwdate-gui
+ id sdwdate-gui
uid=122(sdwdate-gui) gid=129(sdwdate-gui) groups=129(sdwdate-gui)
+ kdesudo -u sdwdate-gui /usr/lib/sdwdate-gui/sdwdate-gui
kdesudo(10672) KDESu::KDESuPrivate::KCookie::getXCookie: No X authentication info set for display  ":0" 

Unexpected error: <class 'NameError'>

I see if caller == 'tor': and elif caller == 'sdwdate': but where caller gets set? Can’t find any caller =?

I was hoping to introduce this in Whonix as soon as possible but due to missing dom0 policy files it will be postponed 10-14 days I expect until it reaches Whonix stable-proposed-updates.

Until then we can’t start sdwdate-gui-qubes by default since the dom0 qrexec prompt would confuse too many users.

I was wrong. Already available from Qubes testers repository. As a side effect. Due to add Qubes-Whonix tags on domain-load rather than VM creation time to avoid missing tags for users that upgraded · Issue #4094 · QubesOS/qubes-issues · GitHub Marek made an upgrade. Can be tracked here when it enters Qubes stable repository.

Merged into master. Excellent work!

It’s now in Whonix testers repository.

Testers welcome! //cc @nurmagoz

1 Like

Merged your commits.

Testing in Whonix-Gateway (VirtualBox).

The line if self.tor_status == 'running': is not necessary, but does it make sense to restart sdwdate when tor is stopped? Any how, minor.

Yes. ⚓ T534 make sdwdate-gui Qubes friendly (sdwdate-gui-qubes)

sdwdate-gui (non-Qubes)

  • exit menu entry missing
    That is on purpose. It was left for testing or debugging. The question is, once sdwdate-gui is thoroughly debugged, do we still want it? It is just commented.in the code.

  • left click does no longer show popup?
    It does, on the second left click, or randomly on the first one, for an obscure reason seemingly created in KDE5, one among other annoying issues.

  • starts with Unexpected error: <class 'NameError'> but otherwise working
    I could not reproduce this one.

The call is done in lines 186 and 215. update_tip('_caller_') runs show_message('_caller_'), which then runs run_popup('_caller_'), under conditions.

This code could be simplified, but I remember trying a couple of times, without much success.

1 Like

Yes.

Yes.

I’d like to say that when installing sdwdate with --no-install-recommends (I don’t like the KDE dependencies) the python3.stem module doesn’t get installed and borks everything. Maybe that should be a required package?

Where did you install it?

troubadour:

The line if self.tor_status == 'running': is not necessary, but does it make sense to restart sdwdate when tor is stopped?

Yes, makes sense because sdwdate would wait (even forever) for Tor to
restart and the log and status symbols would reflect that.

By the way, does the Tor status (disabled) always overrule sdwdate
status? (Should be.)

Debian Stretch via CLI. I seem to remember having the same problem on Jessie, but it’s been awhile.

1 Like

Agreed.

A remark: if tor-control-panel is installed, the Tor status symbol has precedence on the sdwdate status symbol. It was the logic for the condition, assuming tor-control-panel is installed by default.

1 Like

Do you have anon-shared-helper-scripts installed?

python3-stem is a dependency of anon-shared-helper-scripts.

If /usr/lib/anon-shared-helper-scripts/te_pe_tb_check exists and is executable it calls it which then uses python stem.

usr/bin/sdwdate:        prerequisite_status = subprocess.Popen(prerequisite_path, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
usr/bin/sdwdate:    prerequisite_path = '/usr/lib/anon-shared-helper-scripts/te_pe_tb_check'
usr/bin/sdwdate:    if os.access(prerequisite_path, os.X_OK):

sdwdate purposely did not depend on anon-shared-helper-scripts. sdwdate prerequisite_check() is optional.

/usr/lib/anon-shared-helper-scripts/te_pe_tb_check

  • tor_enabled_check
  • pkg_manager_running_check
  • tor_bootstrap_check

Maybe we should do that by default, i.e. make sdwdate depend on anon-shared-helper-scripts?

1 Like

Both added for now but open for arguments.

Yes, installing anon-shared-helper-scripts will get the package installed. I’m actually reporting this issue from memory, sorry if I’m not very helpful on this one.

It seems to me that sdwdate won’t work without anon-shared-helper-scripts so yes, I think so. I’m new to this type of thing, though, so practically anyone else would be in a better position to say.

sdwdate-gui dom0 qrexec policy should be sorted.

sdwdate-gui left click action does nothing in Whonix KDE.

@nurmagoz does sdwdate-gui left click do something in Whonix XFCE?

in xfce its opens the sdw-date list
in KDE (testing version) its also working.

Left click and right click action is the same?

right click has no action whether in KDE or xfce.

1 Like