qtUmbrella
ActivePublic

Members

  • This project does not have any members.

Watchers

  • This project does not have any watchers.

Recent Activity

Mon, Dec 10

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.

Mon, Dec 10, 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 · qt, gpgme
aheinecke added a project to T3958: GPGME: Qt Bindings and MacOS: qt.
May 3 2018, 3:40 PM · 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