Bug#1024417: [pkg-gnupg-maint] Bug#1024417: kgpg FTBFS: Did not find GPGME

2022-11-23 Thread Daniel Kahn Gillmor
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

Re: rebuilding against libqgpgme-dev (soname bump from libqgpgme7 to libqgpgme15)

2022-05-23 Thread Daniel Kahn Gillmor
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

rebuilding against libqgpgme-dev (soname bump from libqgpgme7 to libqgpgme15)

2022-05-21 Thread Daniel Kahn Gillmor
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

Re: Bug#879014: gpgme1.0: FTBFS on some arches: Qt needs a compile with -fPIC (PIE is not enough), hardening downgrades to PIE

2020-07-01 Thread Daniel Kahn Gillmor
. 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 *self_spec: After

Bug#868763: okular: Please package new upstream version

2017-09-08 Thread Daniel Kahn Gillmor
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

any status on this?

2016-11-29 Thread Daniel Kahn Gillmor
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

Re: gpgme 1.7.0~ alpha or beta to debian experimental?

2016-09-22 Thread Daniel Kahn Gillmor
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-

Re: gpgme 1.7.0~ alpha or beta to debian experimental?

2016-09-20 Thread Daniel Kahn Gillmor
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 > <d...@fifthhorseman.net> wrote: >> >> I do note that there's a python3-gpgme, but that is a python3 binding >> for https://launchpad.net/products

Re: [pkg-gnupg-maint] gpgme 1.7.0~ alpha or beta to debian experimental?

2016-09-11 Thread Daniel Kahn Gillmor
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

Re: gpgme 1.7.0~ alpha or beta to debian experimental?

2016-09-11 Thread Daniel Kahn Gillmor
-- On Sat 2016-09-10 19:17:11 +0200, Justus Winter wrote: > Just a quick clarification... > > Daniel Kahn Gillmor <d...@fifthhorseman.net> 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

gpgme 1.7.0~ alpha or beta to debian experimental?

2016-09-10 Thread Daniel Kahn Gillmor
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,

Bug#821854: kdepim: kmail and kleopatra should Depend: gnupg (>= 2) | gnupg2

2016-04-19 Thread Daniel Kahn Gillmor
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

Re: GpgME C++ / Qt language providers ready for merge?

2016-04-11 Thread Daniel Kahn Gillmor
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

Bug#787115: ksshaskpass.1 has timestamps embedded by docbook

2015-05-28 Thread Daniel Kahn Gillmor
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

Bug#787115: ksshaskpass.1 has timestamps embedded by docbook

2015-05-28 Thread Daniel Kahn Gillmor
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: https://wiki.debian.org

Bug#580420: konqueror does not report cleartext content in https pages

2010-05-05 Thread Daniel Kahn Gillmor
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