Merge pull request #104 from Olf0/qcrypto

Final push for v1.3.1

README.md

@@ -6,7 +6,7 @@ Only SailfishOS on the Jolla 1 (sbj) is known to provide (per its *kernel-adapta
 Thus for all other devices (i.e., on those where `find /lib/modules/ -name qcrypto.ko` yields nothing), the [regular edition](https://github.com/Olf0/crypto-sdcard) shall be used.
 
 Extensively tested with systemd 225 (which includes udev), udisks2 2.7.5 and polkit 0.104 (e.g. SailfishOS 2.2 / 3.x, which provides aforementioned environment).<br />
-Built RPMs are available in the [release section](https://github.com/Olf0/crypto-sdcard/releases) and for easy installation under SailfishOS at [OpenRepos](https://openrepos.net/content/olf/crypto-sdcard_sbj).
+Built RPMs are available in the [release section](https://github.com/Olf0/crypto-sdcard/releases) and for easy installation under SailfishOS at [OpenRepos](https://openrepos.net/content/olf/crypto-sdcard-sbj-edition).
 
 The necessary steps to prepare an SD-card (or any other removable storage) are described at [Together.Jolla.com](https://together.jolla.com/question/195850/guide-creating-partitions-on-sd-card-optionally-encrypted/).<br />
 Note that the "key"-files reside unencrypted on fixed, internal mass storage, as mobile devices usually have only a single user, who unlocks the whole device.<br />

RPM-dependencies_Git-workflow.md

@@ -52,7 +52,7 @@ common "head" branch -------------------------------> release branch non-A, non-
   The process can also be partially executed, i.e. only from a "feature branch" to its "release branches", but always obey the second bullet point ("forward only")!
 
 #### Implementation
-For *crypto-sdcard*, starting with versions 1.3.1, ...
+For *crypto-sdcard*, starting with version 1.3.1, ...
 * the [release string format carries two feature specific identifiers in its second field](https://github.com/Olf0/crypto-sdcard/blob/master/rpm/crypto-sdcard.spec#L7): {*regular*, *qcrypto*} and *sfosABC* (currently with *ABC* out of {*321*, *340*}).<br />
   Each of those two may be used to distinguish between more than two features / properties in the future: By defining more SailfishOS releases to differentiate for, or by extending the list of specified appendices denoting mutually ecxlusive features / properties of a target system.<br />
   Additionally a third (or more) distinguishing identifier ("differentiator") may be defined, but that would require some visual separator for more sub-fields in the second field of the release string other than the dot (`.`) and dash (`-`, minus, hyphen), or introducing a new, third field (moving the extant one to the fourth position).  Both possibilities are not nice, e.g. a `+` as a separator conflicts with the set of allowed characters for git tags (at least at Github), the tilde (`~`) is also likely to cause issues, only the underscore (`_`) likely works (but is visually the ugliest option, IMO), and four or even more fields separated by dots in the release string may infringe some convention.  Hence I will try to avoid this, although the `_` or another, additional field (i.e., not a sub-field of the second field) might provide viable paths for extending this scheme.