Bug 22398

Will look at this today.

Status: NEW => ASSIGNED

1.2.1 is now in cauldron, and has been submitted to updates_testing for 6:

URL: svn+ssh://svn.mageia.org/svn/packages/updates/6/qtpass
Commit: 1199795 | buchan | New version 1.2.1 Fixes #22398 
Package submitted!

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

CC: (none) => bgmilne
Assignee: bgmilne => qa-bugs

MGA6-32 on Dell Latitude D600 Mate with kernel 4.14.18
No installation issues.
At CLI:
$ qtpass 
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

CC: (none) => herman.viaene

Ah, this is another package getting screwed by the in-progress qt/plasma update

CC: (none) => tmb

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.

Assignee: bgmilne => qa-bugs
CC: qa-bugs => bgmilne

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:
$ qtpass 
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.

Whiteboard: feedback => MGA6-64-OK
Keywords: (none) => advisory, validated_update
CC: (none) => davidwhodgins, sysadmin-bugs

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2018-0274.html

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED