Page MenuHome GnuPG

Pinentry: Configure flag to specify Qt4 or Qt5
Closed, ResolvedPublic


The automagic added in pinentry commit abb59f50abf698ff1e56490fb39bcc98c26ab44b
and shipped in release 0.9.6 makes defining proper dependencies rather difficult
and causes a bit more headache packaging than I normally like for a minor
version bump.

Please add a configure flag that allows to specify either Qt4 or Qt5 instead of
only relying on auto-detection.

Event Timeline

The rationale behind this was that it should just compile with Qt > 4.4 and take
the newest version available. But yes with Qt packaging in different names
between 4 and 5 etc. I can see that this can be problematic.

With: 08ec9556c8a384ea7bb5d42d3f6aab6c2f6a8786 I've added an option
"disable-pinentry-qt5" to explicitly disable looking for qt5.

Does this solve your problem?

Thank you, that is exactly the kind of mechanism I was looking for. I'll give it
a try to packaging over the next few days.

"+ have_qt5_libs = no;" result in command not found issues in configure so I
changed this to "+ have_qt5_libs="no";".

I've done some preliminary packaging tests and things seems to be working as
expected, will give it some more local testing before pushing it onto users in

I've fixed the variable assignment with rev. e9d063e
Sorry. Worked for me on debian jessie with dash.

Thanks, but I'm afraid that's not sufficient; the issue of the whitespace after
have_qt5_libs still exists after that commit for bash.

See the following test case: $ cat ./
echo ${have_qt5_libs}

have_qt5_libs2 = "no";
echo ${have_qt5_libs2}

$ ./
./ line 5: have_qt5_libs2: command not found

The good news is that besides this buglet I've now pushed the updated revision
to our testing repository and have yet to get any bug reports. The patch I've
pushed is
which doesn't experience this issue.

Right. Hopefully fixed with 48ab8cd

I wonder why this worked for me. If I try to run your testcase it fails with
bash / dash / zsh.

kristianf removed a project: Testing.