Fedora has issued an advisory on January 15:
Fixed upstream in 1.2.1
Will look at this today.
1.2.1 is now in cauldron, and has been submitted to updates_testing for 6:
Commit: 1199795 | buchan | New version 1.2.1 Fixes #22398
I have done basic testing of normal functionality on a build from the checkout built on my local machine running Mageia 6, and everything seems to work as well as (or better than) before.
Backporting the patches in question seemed to be a bit excessive for a leaf package, where one or two other issues were also addressed, e.g. password leaking (to stdout): https://github.com/IJHack/QtPass/issues/334
MGA6-32 on Dell Latitude D600 Mate with kernel 4.14.18
No installation issues.
qtpass: relocation error: /lib/libQt5Widgets.so.5: symbol _ZTV13QInputControl, version Qt_5_PRIVATE_API not defined in file libQt5Gui.so.5 with link time reference
Ah, this is another package getting screwed by the in-progress qt/plasma update
If you want to get it to work now, a proper set of buildrequires/conflicts should force the use of stuff not in testing
If the Qt maintainer is going to push changes which result in ABI conflicts to updates_testing, there should be useful macros provided to ensure ABI compatibility.
Or, we need to ensure that updates go through the entire QA process in serial with any build deps.
Otherwise, we're going to be endlessly chasing artefacts of a poor process.
(If this *really* is the only option, and we want qtpass to go out sooner than the Qt update can go out, I can do the work, but it seems very counter-productive).
I agree with Buchan. This is one of the major shortcomings of our build system. It would have been much better if the Qt and Plasma update could have been done in its own repository. Hopefully we can get the Qt update out sooner rather than later, as it is holding up other updates besides just this one. I would say let's just wait for now.
This can go back to QA now.
MGA6-32 on IBM Thinkpad R50e Xfce
No installation issues.
Launching qtpass at CLI gives proper window asking for parameters, but after confirming the choices, I get a spinning wheel that didn't stop after some 20 min. running.
Feedback at the CLI:
util.cpp: 104 "/usr/local/bin/pass"
util.cpp: 104 "/usr/bin/pass"
util.cpp: 104 "/usr/local/bin/git"
util.cpp: 104 "/usr/bin/git"
util.cpp: 104 "/usr/local/bin/gpg2"
util.cpp: 104 "/usr/bin/gpg2"
util.cpp: 104 "/usr/local/bin/pwgen"
util.cpp: 104 "/usr/bin/pwgen"
mainwindow.cpp: 306 assuming fresh install
configdialog.cpp: 564 ()
pass.cpp: 34 "/usr/bin/gpg2" ("--gen-key", "--no-tty", "--batch")
pass.cpp: 201 Unhandled process type 10
It looks like you didn't have a pre-existing GPG key (and it is generating a new keypair).
I have only tried using pass/qtpass with pre-existing keys.
I will have to test later (tomorrow) without keys.
There is a problem with the key generation, however this is not a regression.
After generating a gpg2 key and using "pass init <keyid>", the program works before
and after the update.
bug 23118 created for the gen/init problem. Advisory committed to svn.
Validating the update.
An update for this issue has been pushed to the Mageia Updates repository.