https://forums.whonix.org/t/torbirdy-replacement/8782

We're not using KDE anymore and sdwdate-gui is enabled by default.

This was done. If not, please create specific tickets where it isn't done.

Onionshare is in Buster.
https://packages.debian.org/buster/onionshare

https://github.com/Whonix/uwt/commit/907f8e1ee93a0ec47febecce3e86266c681764fa

Yes, please.

I see. So without these variables set, ricochet tries to to start its
own Tor client?

Yes exactly !

Tibo (Tibo):

Tibo added a comment.

Any idea why that is required?

Yes, ricochet is looking if a control port is defined in the config file or in
the environment.
If a control port is defined, ricochet will not launch tor and will directly
connect to the control host.

Any idea why that is required?

In T444#15959, @Tibo wrote:

The only thing missing is to set environment variable TOR_CONTROL_PORT=9151 and TOR_CONTROL_HOST="127.0.0.1".
That's all :).

This ticket is in status "needs review". Meaning, implementation is
done, but should be tested in next build.

This status is confusing and for ticket changes we'll be using
testing-in-next-build-required as status.

This ticket is in status "needs review". Meaning, implementation is

done, but should be tested in next build.

So the only remaining work here before you started working on this
ticket was:
Do the instructions in the wiki work as is? If yes, the ticket is done.

Tibo (Tibo):

Tibo added a comment.

I think I misunderstood something.

I think I misunderstood something.
I thought that the goal was to not use EXTERNAL_OPEN_ALL=true and just open one port on the workstation firewall.

Tibo (Tibo):

Tibo added a comment.

Oh, my bad...

Probably a manual config is required because otherwise
localListenAddress is set to localhost.

Manual config is not how it is supposed to work. It worked before

Yes exactly, and also to set the localListenPort.

Oh, my bad...

Tibo (Tibo):

Tibo added a comment.

So here are all the steps to make ricochet working :

Open Ricochet and close it (it will create all the config files and folders).
Then edit : *$HOME/.local/share/Ricochet/ricochet.anondist-orig/ricochet.json* :

{

"identity": {
    "dataDirectory": "data-0",
    "localListenAddress": "10.152.152.11",
    "localListenPort": 12345
},
"tor": {
    "controlAddress": "127.0.0.1",
    "controlPort": 9151,
    "socksAddress": "127.0.0.1",
    "socksPort": 9050
},
"ui": {
    "combinedChatWindow": true,
    "language": "",
    "notificationVolume": 0.75
}

}

So here are all the steps to make ricochet working :

I got Ricochet properly working.
I had some troubles with onion-grater which filtered commands needed by Ricochet.
Even with the config file provided in example :
https://github.com/Whonix/onion-grater/blob/master/usr/share/onion-grater-merger/examples/40_ricochet.yml

Tested in VirtualBox and Qubes-Whonix using 13-14 upgraded templates.
Confirmed ships with dirmsgr and /etc/thunderbird/pref/30_whonix.js and /etc/skel/.gnupg/dirmngr.conf as per spec.

I mean, how do you build the deb package?

There's no build commands, LookNFeel packages are just directory structures that can be packaged as compressed archives and get put into the right paths to be picked up by the system.

What command do you use to build https://github.com/netrunner-artwork/artwork-lnf-netrunner-core?

Yep, you can name your own LnF package anything. You could also patch/extend the default one in packaging if you prefer.

Thanks @hein! We don't have to use org.kde.netrunner-core.desktop in path name? Can be anything?

Hi folks,

@matvey90 It does not work yet.

https://github.com/Whonix/sdwdate-gui/pull/1

It's also not on the workstation.

Wait. I don't see this package on GW.

We shouldn't disable it through qdbus - because that won't persist across reboots. It only disables it for a session, in memory. qdbus isn't great since we want to disable it using a package / by dropping a config snippet into the right place.

Forum said:

I don't know for sure, so I did a little bit of perusing of the dbus API, I dug up "qdbus org.kde.kde /modules/kdeconnect [start|stop]" which looks like it should start/stop the kdeconnect module (service?).

JasonJAyalaP (Jason J. Ayala P.):

My mistake. I asked on the kde forums:

https://forum.kde.org/viewtopic.php?f=66&t=140535

My mistake. I asked on the kde forums:

Kdeconnect package is installed by default? I just did a fresh image of developers-14 plus upgrade, and I don't see kdeconnect installed or kdeconnectd running.

• ServiceTypes=Plasma/LayoutTemplate
• https://github.com/OpenMandrivaAssociation/distro-plasma-config
• https://github.com/OpenMandrivaAssociation/distro-plasma-config/blob/master/distro-plasma-config.spec
• https://github.com/OpenMandrivaAssociation/distro-plasma-config/blob/master/org.kde.plasma.desktop-layout.js
• https://github.com/netrunner-core/netrunner-core-plasma5-panels/blob/master/usr/share/default-settings/plasma5-profile/plasma/layout-templates/org.kde.plasma.desktop.defaultPanel/contents/layout.js

This was done. Commit link?

tor-controlport-filter has been renamed to onion-grater by upstream Tails.

Asked about how to set the environment variables and got some answers:
https://lists.freedesktop.org/archives/systemd-devel/2017-February/038365.html

A systemd --user instance knows nothing about the systemd --system instance. I.e. a systemd --user instance cannot reference After=some-system.service. Source:

Great work by @joysn1980 with the initial implementation.

That worked. Somewhat. Now I need to figure out if there is a sane way to sort out the environment variables.

As per

In T424#12408, @Patrick wrote:

I haven't figured out yet how to cleanly (or uncleanly) enable systemd user services using Debian packaging. sudo -u user systemctl --user enable mytest will probably not work (apt-get somehow does not like sudo -u user anymore since Debian stretch), and that would not be a clean solution either.

One step closer.

In T598#12266, @Patrick wrote:

I'll check in the next developers-only build.

In T598#12298, @Patrick wrote:

That worked in Debian jessie based Whonix. Currently broken in Debian stretch based Whonix. Apparently the KDEDIRS variable was abolished and hopefully replaced by something else. Still TODO to figure that out and fix.

Thanks for reporting!

Just an update.

I'll check in the next developers-only build.

I do not see the issue in my case. I have latest sni-qt installed and the sdwdate icon is also visible.

Not easy. Need to wait for reply from TPO.

sdwdate-gui generally works, but after installing the sni-qt package, sdwdate-gui is invisible.

TODO:
Need to check if this is solved once I have a new image working.

In T598#12098, @joysn1980 wrote:

I see the same issue (repeated right click , restart ) is present even in the older version. Can you verify that once?