On Wed 2022-11-23 16:27:43 +0100, Andreas Metzler wrote:
> Unless kgpg maintainers/upstream has a strong opinion against using
> pkg-config the obvious choice would be to drop cmake/FindGpgme.cmake
> and simply use FindPkgConfig. - Attached patch seems to work for me,
> i.e. build including dh_auto
Thank you for the prompt testing and for the followup, Patrick!
On Sun 2022-05-22 18:32:21 +0200, Patrick Franz wrote:
> So I'd suggest you simply request a transition and state that all these
> packages build against gpgme 1.17 and only need NMUs.
I've done this, and it's #1011505 (https://bugs
Hi KDE folks--
I've recently uploaded gpgme1.0 1.17.1 to debian experimental. I put it
in experimental because libqgpgme changed SONAME from 7 to 15,
indicating an ABI break. As of 1.17.1-3, it appears to build on all
release architectures.
I think the only packages that need to be rebuilt agai
r warnings.
I'm attaching a patch to dpkg which (i think) reflects the fix proposed
by Guillem Jover (in cc):
From 8d01f1419c62e24b662abc2e1ec708a7c63fbbfe Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor
Date: Wed, 1 Jul 2020 17:00:02 -0400
Subject: [PATCH] Use +self_spec: instead of *se
On Tue 2017-07-18 12:58:16 +0200, Michael Weghorn wrote:
> Debian currently contains Okular version 16.08.2, which is
> still KDE 4/Qt 4 based.
>
> The current upstream version is 17.04.3. Among other changes,
> this version has been ported to Frameworks 5.
>
> It would be great if Debian could inc
Hi Qt/KDE maintainers--
Any status on https://bugs.debian.org/840652 ? If we could remove the
gpgmepp source package from the archive, it will help us make stretch
more maintainable.
I understand that we might not be able to remove kdepimlibs due to qt4
remaining in the archive, but i think even
On Sat 2016-09-10 13:00:26 -0400, Daniel Kahn Gillmor wrote:
> As i understand it from a talk given by Andre Heinecke (GPGME upstream,
> cc'ed here) at OpenPGP.conf, GPGME 1.7.0 is likely to take over as
> upstream from pyme, gpgmepp, and qgpgme. (it will also add a
> common-
On Mon 2016-09-19 09:27:25 -0400, Miguel Di Ciurcio Filho wrote:
> On Sun, Sep 11, 2016 at 4:06 PM, Daniel Kahn Gillmor
> wrote:
>>
>> I do note that there's a python3-gpgme, but that is a python3 binding
>> for https://launchpad.net/products/pygpgme (maintained
On Sat 2016-09-10 21:19:49 +0200, Werner Koch wrote:
> On Sat, 10 Sep 2016 19:00, d...@fifthhorseman.net said:
>> It occurs to me that we could try doing this packaging in debian
>> experimental, using a snapshot from upstream git as an upstream tarball
>> instead of waiting for the official 1.7.0.
stus--
On Sat 2016-09-10 19:17:11 +0200, Justus Winter wrote:
> Just a quick clarification...
>
> Daniel Kahn Gillmor writes:
>> pyme (python-pyme and python3-pyme)--
>
> There was no pyme for Python 3 before we ported it,
ah, you're right of course, and i was confus
Hi debian maintainers of:
GPGME,
gpgmepp (libkf5qgpgme5),
qgpgme (libqgpgme1), and
pyme (python-pyme and python3-pyme)--
As i understand it from a talk given by Andre Heinecke (GPGME upstream,
cc'ed here) at OpenPGP.conf, GPGME 1.7.0 is likely to take over as
upstream from pyme, gpgmepp, a
Source: kdepim
Severity: normal
In debian experimental, we are preparing a version of gnupg that is
built from the "modern" GnuPG branch (today, that's GnuPG 2.1.x).
This means that we hope to have the gnupg packages (and /usr/bin/gpg)
provided from 2.1.x.
we'll be providing backward-compatible g
On Mon 2016-04-11 13:17:49 -0400, Andre Heinecke wrote:
> I've integrated the C++ and Qt Libraries for GpgME from the KDE Initiative
> as
> language provider into GpgME in the branch "gpgmepp".
>
> I think that branch is now ready for a merge into master.
>
> Build can be controlled by t
On Thu 2015-05-28 15:34:21 -0400, Daniel Kahn Gillmor wrote:
> https://reproducible.debian.net/dbd/experimental/amd64/ksshaskpass_5.2.2-1.debbindiff.html
>
> shows that docbook is adding timestamps in lines 5 and 10 of
> ksshaskpass.1
>
> this looks a lot like:
>
>
&
Package: ksshaskpass
Version: 4:5.2.2-1
Severity: wishlist
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
Control: affects -1 kdoctools5 pkg-kde-tools
ksshaskpass.1 in experimental ends up being different depending on what
day it is built. This is a problem for making a re
Package: konqueror
Version: 4:4.3.4-1
Severity: normal
Most web browsers show a lock and/or change the address bar to
indicate that an https site has been connected to via TLS. konqueror
shows (afaict) a green shield with a check-mark. Fair enough.
But other browsers also indicate a "broken loc
16 matches
Mail list logo
