Convert patches between 32 and 64 bit library path

[nephros]

Fixes #71
#71

[nephros]

PoC type implementation - it does work and produces patches that apply.

Mode of operation could be improved - currently it does a lot of looping and grepping the same files. Could probably be done with one or two bigger sed commands all at once.

Testing required:

• produces correct patch from a 32bit source on a 64bit system
• produces correct patch from a 32bit source on a "simulated" 64bit system (hack the script to detect 64bit)
• produces correct patch for a 64bit source on a 32bit system
• when a converted patch is unapplied: Are the correct files deleted?
• when a converted patch is uninstalled: Are the correct files deleted?
• does it work reliably with patches that contain both lib64 and lib paths (e.g. patches a Silica file and a systemd service on 64bit)?
• does it correctly detect patches to be left alone, i.e. do not need conversion?

Oh, and the candidate list currently contains "/usr/lib/patchmanager-test" for easy testing. This should be removed before merging.

[b100dian]

I tested this on a 64-bit device and the reason it was failing was that /tmp/patchmanager did not had the copies to patch. I've added POC support for mangling those cache files.
I've checked the "produces correct patch from a 32bit source on a 64bit system"

[nephros]

As discussed, we don't want to duplicate the mangle list in both cpp source and shell script.
So introduce a config file to hold that information, and read it from both.

[nephros]

@b100dian please review, seems to work but may be bad c++.

[b100dian]

Nothing wrong per se in the changes (just nits) but, however I tried playing around with 1. having only one MANGLED_CANDIDATES entry and 2. see if pm_unapply would work and even 3. If a setting could show the paths to the user (not clear how to pass the setting to pm_apply now, maybe $2) in my fork - but currently I get errors applying the Return old pulley menu 4.x that used to work. So I need to figure out if any of (my|your) changes did this last since I tested this. That's for tomorrow..

[b100dian]

Ok @nephros managed to pinpoint it to toStringList not splitting the QVariant value - I have made a PR against this PR for the changes are somewhat numerous. Let me know if you can review that and merge --squash it. There is one caveat, see #140

[b100dian]

All good from my point of view, maybe it needs more testing. Oh, and the wording in the settings page maybe needs review.

I've added a last commit refreshing patches on bitness mangling change and fixed the 'last' caveat.

[b100dian]

Hmm maybe I spoke too soon, I still get errors like "PatchManagerObject::tryToUnlinkFakeParent" error while trying to cd from "/usr/lib" to: "qt5" on dynamic switch

[b100dian]

Ok, just tested this build with 4.3.0 armv7hl and the setting does not harm existing 32-bit patches, and it tried to fix this 64-bit patch https://coderus.openrepos.net/pm2/project/patch-five-cameras-tucana which didn't apply as it shouldn't, but for the right reasons (the /etc/dconf/db/vendor.d/jolla-camera-hw.txt file was not having the expected contents)

Other than this, with the last change (re-order to mangle before test if applied) it seemed to work correctly even at pm3 upgrade scripts on my 4.2.0 64-bit device.

[b100dian]

Zig-zagging through my notifications, I need to test the last two checkboxes. Could find some time tomorrow.

[b100dian]

Tested by "does it work reliably with patches that contain both lib64 and lib paths (e.g. patches a Silica file and a systemd service on 64bit)?" appending this to an existing patch

--- /usr/lib/patchmanager-test/test.txt
+++ /usr/lib/patchmanager-test/test.txt
@@ -1 +1,2 @@
-# Test line
+# test
+# replaced line
--- /usr/lib/test.txt
+++ /usr/lib/test.txt
@@ -1 +1,2 @@
-# Nothing
+# test
+# replaced line

To an existing patch, looks alright (it patched one file in lib64 and another one in lib)