[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [CONTRIBUTE] [DONATE]

Long Wiki Edits Thread

A post was merged into an existing topic: apt-key Deprecation / Apt 2.2 changes

Could you review Difference between revisions of "Passwords" - Whonix please? @HulaHoop

1 Like

I had to look up what a kibibyte is. I learn something everyday.

1 Like

Updated chapter Install the Signal Desktop Client.

The Notable Changes in a release announcement are based on git commit log. A recommend practice for git commit messages is:

“Use the imperative mood.”

For example:

This then gets rewritten in (Difference between revisions of "Whonix Stable Release" - Whonix) on Whonix Stable Release - Whonix to:

Which might be more appropriate for the wiki. Should I ignore that git commit messages best practices part and try change my habits to use “descriptive mood” instead of “imperative mood”?

I am wondering if some effort on @torjunkie’s side for maintaining Whonix Stable Release - Whonix could be lowered.

Maybe Notable Changes could be left out in release announcements by me.

  1. To avoid duplication.
  2. Notable Changes would then be auto generated in mediawiki markup instead of markdown makeup (forums). I could post them in the wiki instead. (Maybe with a comment if still in testing and not actually stable yet or wiki pending moderation as long as not in stable yet.)

Then there would be no need to copy/paste (and duplicate) them from forums to wiki. And fixes on top of my writeups would still be very much welcome.

Also if it seems useful… Feel free to edit my forum posts with the usual very much appreciated enhancements that are happening in the wiki all the time all over the place. :slight_smile:

Other suggestions to simplify the changelog writing process?

To be honest, I hadn’t thought about it too much - I just preferred that phrasing. Happy to go either way.

It would be good if you can edit the stable release notes going forward, and just reference it in your forum post. Saves a lot of time. Then I’ll just do any finer edits later on.

1 Like

This will be done that way from now. I’ve adjusted the changelog auto generator to use your chosen format. Example:

grub-live:

  • Fixed grub-live (initramfs-tools version).

([archive] link is added by a mediawiki extension.)

Any idea how/where to document this?

//cc @adw

Thanks.

As some dipshit keeps editing the “Contact” wiki page with spam, suggest you lock that page to contributors only.

Nobody should really be adding things there anyhow except for a few select people.

1 Like

Done.

I don’t understand why this was removed:

A rule of thumb is to select Y or I for packages coming from {{project_name}}, and N for packages coming from other distributions. Otherwise settings affecting anonymity, privacy and security might be lost.

Users will inevitably come across this issue and won’t know whether to a) accept (Y or I), b) select N (possibly losing anonymity etc benefits in the process) or c) flip a coin. :wink:

If it doesn’t belong on that page, then where? Or are you saying this is no longer an issue?

No longer an issue.

A rule of thumb is to select Y or I for packages coming from {{project_name}}, and N for packages coming from other distributions.

No longer an issue.

This:

A rule of thumb is to select Y or I for packages coming from {{project_name}},

vs this:

and N for packages coming from other distributions.

Is no longer valid.

There is no more “coming from other distributions”. Since use of config-package-dev, Whonix can “steal” ownership if config files coming from “other distributions” (Debian “mostly” [except third party repo added by user]).

So recommended is I (install) in any case. Except the user has customized something the things get difficult. Then it’s up to user to merge this. One strategy would be to install and then re-add customization if still relevant. Or not do it and then check what Whonix changed and backport these if worth it (not worth it for trivial updates such as copyright year updates).

Maybe the latter two paragraphs are worth documenting? That would belong to Operating System Software and Updates - Whonix?

“coming from other distributions” was from times in cases where Whonix was modifying config files owned by other packages when config-package-dev didn’t exist (or wasn’t used). So many releases ago that I’d have hard time to point out the release. :wink:

Now that we tried hard and went through several revisions on How-to: Install the Stable Version of Qubes-Whonix ™ 16… This cannot be clear enough… In an attempt to clarify things, do you think it’s a good idea to combine the 3 notices

  • Qubes version support notice
  • Qubes-Whonix ™ 15 to Qubes-Whonix ™ 16 Release Upgrade Notice:
  • Qubes-Whonix ™ 16 Notice

into a table of notices similar to how it’s presented on Release Upgrade Whonix 15 to Whonix 16 - Whonix?

new wiki page:

new wiki template:

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]