Page MenuHome GnuPG

qtUmbrella
ActivePublic

Members

  • This project does not have any members.
  • View All

Watchers

  • This project does not have any watchers.
  • View All

Recent Activity

Sep 17 2021

mid-kid added a comment to T5551: gpg-agent: DISPLAY is not set when calling pinentry-qt.

I see, I wasn't aware of this. Thanks for fixing!

Sep 17 2021, 12:22 PM · qt, pinentry, gnupg
werner closed T5551: gpg-agent: DISPLAY is not set when calling pinentry-qt as Resolved.

Thanks for commenting. I close this bug then.

Sep 17 2021, 8:07 AM · qt, pinentry, gnupg

Sep 16 2021

gouttegd added a comment to T5551: gpg-agent: DISPLAY is not set when calling pinentry-qt.

Your proposed fix (in your first comment) has actually already been applied (commit 1305baf0994059f458b1d5ca28a355c12932fab3 in master, backported to the -2.2 branch in 455ba49071dea7588c9de11785b3092e45e4560b). It is part of gnupg-2.2.31 released today. :)

Sep 16 2021, 11:11 PM · qt, pinentry, gnupg
mid-kid added a comment to T5551: gpg-agent: DISPLAY is not set when calling pinentry-qt.

The Qt upstream bug report has just been rejected. I hope something can be done here...

Sep 16 2021, 4:31 PM · qt, pinentry, gnupg

Aug 13 2021

werner changed the edit policy for qt.
Aug 13 2021, 11:13 PM

Aug 9 2021

mid-kid added a comment to T5551: gpg-agent: DISPLAY is not set when calling pinentry-qt.

Yeah, that sounds good to me.

Aug 9 2021, 1:13 PM · qt, pinentry, gnupg

Aug 8 2021

gouttegd added a comment to T5551: gpg-agent: DISPLAY is not set when calling pinentry-qt.

I would prefer to see a fix/hack in pinentry-qt instead.

Aug 8 2021, 4:08 PM · qt, pinentry, gnupg

Aug 6 2021

mid-kid added a comment to T5551: gpg-agent: DISPLAY is not set when calling pinentry-qt.

I see. Thanks!

Aug 6 2021, 2:30 PM · qt, pinentry, gnupg
werner added a comment to T5551: gpg-agent: DISPLAY is not set when calling pinentry-qt.

To minimize the risk of regressions.

Aug 6 2021, 12:23 PM · qt, pinentry, gnupg
mid-kid added a comment to T5551: gpg-agent: DISPLAY is not set when calling pinentry-qt.

Not to be bothersome, but why? DISPLAY seems like the universal method of selecting a display to put things on, where a lot of applications don't support --display or equivalent, especially now there's no equivalent for wayland. It's especially confusing to me when the keep-display option will pass DISPLAY instead of --display. This would also prevent other such scenarios with 3rd party qt/gtk plugins or alternative pinentry implementations.

Aug 6 2021, 11:55 AM · qt, pinentry, gnupg
werner triaged T5551: gpg-agent: DISPLAY is not set when calling pinentry-qt as Normal priority.
Aug 6 2021, 11:07 AM · qt, pinentry, gnupg

Jun 24 2021

werner lowered the priority of T3958: GPGME: Qt Bindings and MacOS from Normal to Low.
Jun 24 2021, 6:31 PM · MacOS, qt, gpgme

Feb 18 2021

werner triaged T5307: pinentry-qt unilaterally enables rpath, even when configured with `--disable-rpath` as Low priority.
Feb 18 2021, 8:49 AM · qt, pinentry, Bug Report

Feb 17 2021

dkg created T5307: pinentry-qt unilaterally enables rpath, even when configured with `--disable-rpath`.
Feb 17 2021, 8:22 PM · qt, pinentry, Bug Report

Nov 18 2020

ikloecker closed T5142: Qt gpgme's sign_key function should not set a remark with an empty string as Resolved.

Fixed. Workaround for gpgme 1.15 (and earlier) implemented in Kleopatra: Do not call setRemark() with an empty QString.

Nov 18 2020, 1:55 PM · gpgme, qt, Bug Report
ikloecker added a comment to T5142: Qt gpgme's sign_key function should not set a remark with an empty string.

I think Kleopatra is affected. It calls setRemark() on the job unconditionally with the text from the widget, and I'm pretty sure that this text is empty but not a null QString, if the user doesn't enter a remark.

Nov 18 2020, 12:24 PM · gpgme, qt, Bug Report
werner assigned T5142: Qt gpgme's sign_key function should not set a remark with an empty string to ikloecker.

Ingo, can you please check? I guess we are not affected because Kleo already checks for an empty string. But dkg's suggestion sounds good to me.

Nov 18 2020, 10:34 AM · gpgme, qt, Bug Report
dkg created T5142: Qt gpgme's sign_key function should not set a remark with an empty string.
Nov 18 2020, 9:38 AM · gpgme, qt, Bug Report

Jan 24 2019

aheinecke triaged T4339: Qt5 application doesn't support -display any more as Low priority.

The problem only occurs with the gtk platformtheme.

Jan 24 2019, 8:35 AM · qt, pinentry, Stalled, Bug Report

Jan 9 2019

aheinecke closed T3815: tests fail in 2021 as Resolved.

I sent a message to gnupg-devel about this issue as it will probably hit more people now that the keys used are expired :-(

Jan 9 2019, 8:52 AM · qt, Python, gpgme, Bug Report
aheinecke added a comment to T3815: tests fail in 2021.

Oh,.. it is even worse. The conflict keys expired 2019-01-06 so they are actually expired right now.

Jan 9 2019, 8:18 AM · qt, Python, gpgme, Bug Report
aheinecke claimed T3815: tests fail in 2021.
Jan 9 2019, 8:12 AM · qt, Python, gpgme, Bug Report
werner reopened T3815: tests fail in 2021 as "Open".

I don't know why @BenM closed this bug given that he mentioned that the qt part is yet not solved.

Jan 9 2019, 8:00 AM · qt, Python, gpgme, Bug Report

Jan 8 2019

hedning added a comment to T3815: tests fail in 2021.

We've run into the testTofuConflict failure on NixOS. gpgme v1.12, gnupg v2.2.12.

Jan 8 2019, 8:05 PM · qt, Python, gpgme, Bug Report

Dec 10 2018

BenM closed T3815: tests fail in 2021 as Resolved.

Though apparently resolved back in May, this is what ultimately led to T4191 and was thus only properly resolved quite recently.

Dec 10 2018, 6:19 AM · qt, Python, gpgme, Bug Report

May 5 2018

BenM added a comment to T3815: tests fail in 2021.

The Python portion of this is done, the tests will now create a key with an expiration a few years shy of the 2106 end date (NYE 2099).

May 5 2018, 5:10 AM · qt, Python, gpgme, Bug Report

May 3 2018

aheinecke triaged T3958: GPGME: Qt Bindings and MacOS as Normal priority.
May 3 2018, 3:40 PM · MacOS, qt, gpgme
aheinecke added a project to T3958: GPGME: Qt Bindings and MacOS: qt.
May 3 2018, 3:40 PM · MacOS, qt, gpgme

Apr 26 2018

BenM added a comment to T3815: tests fail in 2021.

Not to mention making sure we test for a time after the end of the old 32-bit clock.

Apr 26 2018, 6:44 AM · qt, Python, gpgme, Bug Report

Apr 17 2018

werner triaged T3815: tests fail in 2021 as Normal priority.
Apr 17 2018, 8:30 PM · qt, Python, gpgme, Bug Report
werner assigned T3815: tests fail in 2021 to BenM.

Ben: We need to use a faked system time thing to make those tests more stable.

Apr 17 2018, 8:29 PM · qt, Python, gpgme, Bug Report

Mar 21 2018

aheinecke created T3852: GPGME, qt: possible version mismatch between moc and qt version.
Mar 21 2018, 9:31 AM · qt, gpgme

Feb 28 2018

werner added a project to T3815: tests fail in 2021: qt.
Feb 28 2018, 8:34 AM · qt, Python, gpgme, Bug Report

Sep 26 2017

intuitqb created T3426: quickbooks accountant support Number 1(800) 823 3634 quickbooks accountant support phone number in the S1 Public space.
Sep 26 2017, 2:58 PM

Aug 10 2017

marcus closed T2884: Qgpgme thoughts and issues as Resolved.
Aug 10 2017, 3:15 PM · gpgme, qt, Feature Request
marcus updated the task description for T2884: Qgpgme thoughts and issues.
Aug 10 2017, 3:08 PM · gpgme, qt, Feature Request
marcus updated the task description for T2884: Qgpgme thoughts and issues.
Aug 10 2017, 3:08 PM · gpgme, qt, Feature Request

Mar 30 2017

admin created qt.
Mar 30 2017, 6:42 PM

Jan 2 2017

RJVB added a comment to T2884: Qgpgme thoughts and issues.

Hi,

The patch works. There's 1 more issue that's been standing for a bit longer already,
and that you might want to tackle at the same time: there's no argp.h header on Mac.

On Linux it is only a problem with the headers (e.g. the -dev) Package as the

That's actually an orthogonal issue, and one that's probably easier to rectify as any
changes only become apparent when dependent software is being built.

libraries have different soversions

This is also the case on Mac, but the link library doesn't have a soversion. It's
called libqgpgme.so or libqgpgme.dylib .
There is of course the option to rename just that symlink. A bit of a hack, but one
that's relevant only during the link step, when dependent software is being rebuilt.

How does MacPorts handle this in general? IMO this is not a (q)gpgme(++)
specific problem as you will have this problem with each ABI break.

MacPorts does many things like they're done on more traditional *n*x desktops, i.e.
install libraries in a central, shared location (--prefix=/opt/local by default).
There is nothing specific it does to handle ABI breaks; they can hold up an upgrade,
or a patch is applied at some level, or a conflict is registered. Sadly there is no
central way to create -dev packages, which doesn't help here.

E.g. when we
break the ABI in QGpgME libqt5qgpgme.dylib may be incompatible and we would need
a new name.

That I don't see. The problem here isn't so much the ABI break compared to the
version shipped by kdepimlibs4, but the fact that an incompatible Qt version is used.
So no, a SOVERSION=8 upgrade doesn't impose a library name change. Cf. Poppler and
its Qt backends; they're called libpoppler-qt4 and libpoppler-qt5 .
An alternative would be to do like QCA: install the library wherever Qt's own
libraries are installed. That automatically resolves the conflict with the old
version included with kdepimlibs4, and might be less disruptive for existing
distribution packages.

It's not only the build system but the code using QGpgME / GpgME++ will be more
complex as they would need to have feature checks for both the QGpgME version

What I had in mind was a build system that refuses to do a mismatching build of QpgME
X.Y.Z against GpgME++ that's not X.Y.Z . If you don't do runtime checks there's no
guarantee anyway beyond what the dynamic linker can give, I think. Distributions can
build QpgME and only bundle the QpgME bits, and then install that against any GpgME
install. I've done that for a bit with QpgME 1.7.x against QpgME++ 1.8.0, and didn't
run into any issues.
You could probably even argue that people would be less likely to try this kind of
things if the build system gave off a big hint that they really shouldn't be doing
that. It's not like it's particularly difficult to install only QpgME, after all.

Jan 2 2017, 5:21 PM · gpgme, qt, Feature Request
aheinecke added a comment to T2884: Qgpgme thoughts and issues.

Hi,

thanks for your feedback.

Regarding library suffix in the cmake config files, sorry about that I forgot
MacOS ;-) can you please test the attached patch (macos-cmake-config-fix.diff)
that reintroduces libsuffix to distinguish between macos and linux?

QGpgME builds libqgpme, preserving the same name as the library that used to
be built by kdepimlibs4.

There was a discussion after the 1.7.0 release about this. In summary: I agree
that we should have changed the name to avoid this conflicts, but we think that
it's now too late to do that as we want to avoid additional hassle for packages.
On Linux it is only a problem with the headers (e.g. the -dev) Package as the
libraries have different soversions. On Windows it's not a problem at all as the
Application ships the library it requires.

Is this something that might be considered upstream, e.g. for 1.8.1, possibly as
a build option? I realise this may not be something that has already come up on
Linux desktops but it's likely to do so in other distribution systems; it is
blocking us in MacPorts at this moment, for instance.

How does MacPorts handle this in general? IMO this is not a (q)gpgme(++)
specific problem as you will have this problem with each ABI break. E.g. when we
break the ABI in QGpgME libqt5qgpgme.dylib may be incompatible and we would need
a new name.

On Linux we have soversion and on Windows and MacOS imo usally the libraries are
shipped with the Application. But on MacPorts how does this work?

It will probably a bit more complex to maintain the buildsystem because you'd
want to exclude builds against mismatching qgpgme versions, but when done that
should be all, no?

It's not only the build system but the code using QGpgME / GpgME++ will be more
complex as they would need to have feature checks for both the QGpgME version
and the GPGME version to determine which features are available. This was a huge
hassle in the old days and one of the reasons we wanted to move them closer
together so that you can rely on the API once you have a minimum required version.

See e.g.:
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=commitdiff;h=433bb8e84b2d1e50b5c5b9f7f2006b60cd7d7785
That removed lots of these feature checks.

Jan 2 2017, 2:57 PM · gpgme, qt, Feature Request
aheinecke added a comment to T2884: Qgpgme thoughts and issues.

D403: 936_macos-cmake-config-fix.diff

Jan 2 2017, 2:57 PM · gpgme, qt, Feature Request

Dec 21 2016

werner added a comment to T2884: Qgpgme thoughts and issues.

Aside from the required build system changes we wil run into problems evaluating
bug reports.

Dec 21 2016, 6:56 PM · gpgme, qt, Feature Request
RJVB added a comment to T2884: Qgpgme thoughts and issues.

It will probably a bit more complex to maintain the buildsystem because you'd
want to exclude builds against mismatching qgpgme versions, but when done that
should be all, no?

It's just a bit a pity that you have to build all of the cpp bindings again if
you just want to build the Qt bindings.

Dec 21 2016, 6:50 PM · gpgme, qt, Feature Request
werner added a project to T2884: Qgpgme thoughts and issues: qt.
Dec 21 2016, 6:43 PM · gpgme, qt, Feature Request