Documentation: https://www.qubes-os.org/doc/split-gpg/

[Achim Patzner]

Hi!

Would whoever is currently doing the maintenance on the web pages add a
hint for Evolution users that the "legal" method of changing the path
to the external tool doing the PGP work requires modifying

the key "camel-gpg-binary" in org.gnome.evolution-data-server as in

gsettings set org.gnome.evolution-data-server camel-gpg-binary
'/usr/bin/qubes-gpg-client-wrapper'

This seems to be quite hard to find in Google if you don't know what to
look for; I've been asked this three times in two weeks now...


Achim

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

In case anyone reading this is not aware, the documentation is a
community effort, and everyone is welcome to contribute. (That's how
things like this get updated!) So, if you'd like to get involved with
the project, this is a great way to do it. You can read more about how
to submit documentation changes here:

https://www.qubes-os.org/doc/doc-guidelines/

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlw9YUwACgkQ203TvDlQ
MDAO6A/+MEbhp+LVnMm1BJqW+BlFRDa+XsQFo7bjCXeKOtjHaXmhoxtWF8tgRE6/
HkwJllh3b82eE9DPeKqcaVFxa2BaIPmTMqUqU/ezmsQ4/hvyjqsBP64hbR4ZBDMC
8H1sGUIpYWv/iuAHUYwytztdug/wNp2iRBmCkjUymZ7nWVP+cexleJvh46jIWiWx
aZoT+kMw/NID0VyIgX2N9uGJ8VQwdS544WfSvoFYGqiUg9gH7/KJJm0nI1u5/auQ
GJYB4W+oAG3QeWAIgT3tK/FytQwBShyJIycQP6H8oRQwMQXYJBOqd2iuEQqyJCUF
JP4gZK71/WlDsdNQeWdPGYNp2TA6k29KWShLVojJcgXZTG9lyrQke4JccXHADrfE
ql0wCZ3s3bqDjiInRcYZBP2egn64YrvnmCc5zj9gMrCYijtEUvSOohle9fLdK9Jp
hCBzJVqk9p1jWIyk/FR5USCDe2XAdCTmTVnVXIvuYL/U9Ze9TKm37OpccEDoRjWX
NNz+6WOhXIUgX8RNfsIYzr4YY25U9E8ColoZ9Nsllr0Psa4DjeIHMeJdb+xUhZ16
aTltCsAP/8/SdPpMjDhGBDz+5sonhDm/6Jx533m/NsyFCcPU6qq/Xt0/RuNxK8iH
vauZ3d1c98x9cvS9edKWImO92U5sFXxVsh5deaWRUowAVGCeXco=
=ToQd
-----END PGP SIGNATURE-----

[Achim Patzner]

On 20190114 at 22:28 -0600 Andrew David Wong wrote:

We're getting to a point that is bringing up quite painful memories of
decades past...

> In case anyone reading this is not aware, the documentation is a
> community effort, and everyone is welcome to contribute. (That's how
> things like this get updated!) So, if you'd like to get involved with
> the project, this is a great way to do it. You can read more about
> how
> to submit documentation changes here:
>
> https://www.qubes-os.org/doc/doc-guidelines

Second sentence of the second paragraph:

"If you notice a problem with the documentation or some way it can be
improved, please report it!"

And to quote the "How to Contribute" below:

"If you’re already familiar with GitHub or wish to work from the
command line, you can skip the rest of this section.
All you need to do to contribute is to fork and clone the qubes-doc
repo, make your changes, then submit a pull request.)"

1) Not doing anything that needs git I'm staying with CVS since 1995
for my own projects and do not want to deal with git.

2) git (or any other descendant of CVS) is hardly the right tool to do
documentation in a community setting just like a hammer is the adequate
tool for everything.

The effect can be easily seen here: Important information is not
updated (a lot of the pages are still referring to 3.2 only; just
remember my last remark about bind-dirs in the 4.0 fedora-templates)
and a lot of knowledge that would be easy to collect in a MediaWiki
with its low hurdles regarding access to editing tools is just getting
lost (see the messages about getting NICs in Lenovo P-series to work
(or installing Qubes there); several people solved the problem and
nobody documented it -- I certainly won't if it means wrangling with a
versioning system and vi instead of adequate tools). Reading qubes-
users and the Reddit discussions contain a lot beginner-level stuff
that should be recorded somewhere but if that means using git I would
assume 99.9% of those who could do it just giving up.

I remember similar discussions in the FreeBSD and NetBSD projects a few
decades ago. Their hard stance on availability and participation in
documentation projects ("use our tools or die" instead of "let's see if
we find something that works for all") was (besides the UCB vs AT&T
copyright disputes that halted development for more than a year) one of
the things that made lots of people move to Linux.


Achim

[unman]

You dont need to know anything about git.
Just create an account on GitHub, and start editing those pages. (The
link to do this is on the LHS of each page.)
The doc-guidelines page that you quoted from contains detailed
guidelines on how to edit the page *without* using git (or vi) at all. I
cant believe it would be beyond you. If not you, who?