Re: [pkg-gnupg-maint] cpp/qt bindings status

[Daniel Kahn Gillmor]

On Thu 2016-10-13 05:49:32 -0400, Luca Beltrame wrote:
> In data giovedì 13 ottobre 2016 11:45:40 CEST, Sandro Knauß ha scritto:
>
>> @luca, so you managed it to compile kdepimlibs with gpgme 1.7?
>
> No, we have a separate package for the old gpgmepp with different soversion, 
> so it can be coinstalled.
> The "solution" was to force the user to uninstall the kdepimlibs headers if 
> he/she installs the gpgmepp headers from gpgme 1.7.0+.

I think we'll do the same thing in debian -- see
https://bugs.debian.org/842061 as an example of a problem we get if we
do otherwise.

gpgme 1.7.1 is in NEW right now, but once it makes it past NEW i'll push
a new debian release including commit id
33a2dbb58136f911c436fda3e96111318cf579a4 to make the breaks/replaces
unversioned.

  --dkg


signature.asc
Description: PGP signature
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: [pkg-gnupg-maint] cpp/qt bindings status

[Daniel Kahn Gillmor]

Hi Andre--

On Thu 2016-10-13 04:03:23 -0400, Andre Heinecke wrote:

> On Wednesday 12 October 2016 15:02:32 Sandro Knauß wrote:
>> > > The only thing I wanted to check if libgpgme11-dev conficts with the
>> > > other
>> > > -dev packages.
>> > 
>> > yes, i think we will, because kdepimlibs5-dev has usr/include/gpgme++
>> > and /usr/include/qgpgme and usr/lib/gpgmepp, which we will probably want
>> > in libgpgme11-dev or in some separate -dev package.  This means we might
>> > need a rebuild of kdepimlibs with the gpgme stuff removed, right?  and
>> > we might decide to just drop the gpgmepp source package from debian
>> > entirely.
>> 
>> We need to see if we need to be coinstallable with kdepimlibs 4.14, so
>> splitting the -dev packages makes sure anyhow, so that not everyone needs to
>> install whole Qt dependencies.
>
> I also got feedback from Luca (SUSE) that the conflict with kdepimlibs 4.14 
> is 
> causing problems. I wonder if we should change the install locations to 
> "/usr/include/gpgme-cpp" and "/usr/include/gpgme-qt" or do you think it's too 
> late for that?

It's not too late for that in debian; these bindings have only been
published in debian in the experimental repo thus far, so nothing
depends on them explicitly -- yet!

But any changes we want to make in the naming or versioning of these
bindings probably need to happen soon if we want them to be considered
for inclusion in debian.

> I like the suggestion of libgpgme-cpp-dev and libgpgme-qt-dev.

fwiw, i also like the simplicity and clarity of this scheme.

> I don't think gpgmepp and qgpgme are that widespread. And the
> namespaces used are just GpgME and QGpgME. Maybe also changing the
> installed librarary names to match libgpgme-qt.so ?

the list of reverse dependencies in debian isn't all that large, but
getting a full rename transition done so that all of the old versions
can be dropped might end up being too big of a move before the debian
freeze.  I don't think that should stop you from trying to get the right
names going forward upstream, though.

packages that use the new names will get the new code, and packages that
don't transition will limp along on the old stuff until we get them
fixed.

I do worry about providing security support to those orphaned versions,
though :/  And i *really* don't want to try to support three different
versions of gpgme in debian forever!

> FYI there was some API missing / not installed in the qt variant that is used 
> in kleopatra and KMail, so we'll need a new release soon. KDEPIM master 
> already depends on the new libraries.

ah, interesting.  that's good to know.  I saw those commits and was
wondering what was up with that :)

  --dkg


signature.asc
Description: PGP signature
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: cpp/qt bindings status

[Daniel Kahn Gillmor]

Hi Sandro--

On Sun 2016-10-09 21:18:02 -0400, Sandro Knauß wrote:

> I now have managed to build the cpp and qt bindings.

yay, this is great!

> We have no clash with libnames, because the libs are names libgpgmepp6
> (old name was libgpgme++2) and libqgpgme6 (old name was
> libkf5gpgmepp5). so we don't need Replace/Break for those. Do we need
> for this a transition?

We will need a transition in the sense that we want to encourage people
building against the newer libraries, i think, so it's the -dev part of
the transition that is likely to be tricky.

> The only thing I wanted to check if libgpgme11-dev conficts with the other 
> -dev 
> packages.

yes, i think we will, because kdepimlibs5-dev has usr/include/gpgme++
and /usr/include/qgpgme and usr/lib/gpgmepp, which we will probably want
in libgpgme11-dev or in some separate -dev package.  This means we might
need a rebuild of kdepimlibs with the gpgme stuff removed, right?  and
we might decide to just drop the gpgmepp source package from debian
entirely.

So one question is whether we should break out separate libqpgme-dev and
libgpgmepp-dev packages, or whether we should (as you've already done)
keep it simple and put all the -dev stuff into a single package?

> Btw. why are the dev package has a version inside?

i think you're asking why the package name has a "11" in it.  TBH, i'm
not entirely sure.  this happened back in 2003 (around 0.4.0 and 0.4.1),
long before i was involved packaging gpgme.  Also, the source package is
named gpgme1.0, and it has been since 2004.

in an ideal (non-legacy, fine-grained) world, i think:

 * the source package would be renamed "gpgme"

 * the -dev binary package would be either libgpgme-dev or gpgme-dev

 * we would have separate -dev packages for libgpgmepp-dev and
   libqgpgme-dev, so that a minimal build system could install only what
   it needs without needing to (for example) drag in all of QT when it
   just needs to build against GPGME or GPGMEPP.  More realistically, we
   might just have a single libgpgmepp-dev package that provides
   build-deps for both QT and KDE.

To deal with legacy, maybe we would need to add a dummy transitional
package from libgpgme11-dev to libgpgme-dev, or just have it Provides:
libgpgme11-dev.

Then we'd need to safely handle the transition from kdepimlibs5-dev for
those packages which build-depend upon it.  Perhaps the updated
kdepimlibs5-dev package (which stops building libqgpgme and libgpgmepp)
could explictly Depend: on the newly-introduced libgpgmepp-dev package.
how does this sound?

> You can look at my changes at my personal clone:
> https://anonscm.debian.org/git/users/hefee/gpgme.git

This is great, Sandro.  Thanks!  If you're OK with me merging from
there, i'll pull your changes into the branch i'm working on.

I'm currently aiming to do an upload to experimental with a bunch of
these changes, including the renames proposed above.  

Barring any complaints or objections from any of the maintainers here, i
aim to have an upload to experimental later this week.

 --dkg


signature.asc
Description: PGP signature
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

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

[Daniel Kahn Gillmor]

On Fri 2016-10-07 16:33:20 -0400, Lisandro Damián Nicanor Pérez Meyer wrote:
> On viernes, 7 de octubre de 2016 6:35:00 P. M. ART Dmitry Shachnev wrote:
>> On Fri, 07 Oct 2016 08:54:53 -0400, Daniel Kahn Gillmor wrote:
>> > I've been reading about -fPIC and -fpic and -fPIE and -fpie and -pie for
>> > years and i confess i've never completely understood the differences or
>> > whether one is "stronger" than another.
>> > 
>> > gcc says of -fPIE and -fpic "generated position independent code can be
>> > only linked into executables." which makes it seem odd that these
>> > parameters would be passed through to building libraries in the first
>> > place.
>> 
>> -PIC implies -fPIE. Replacing -fPIE with -fPIC is the right thing to do,
>> and is needed to get the code working with Qt 5.4.2+.
>
> And also: yes, -fPIE needs overriding if using hardening flags.

can you explain that in more detail?  what specifically should be
overridden and where?

thanks,

   --dkg

-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: [d...@fifthhorseman.net: Re: gpgme 1.7.0~ alpha or beta to debian experimental?]

[Daniel Kahn Gillmor]

¡Hola Maximiliano!

On Fri 2016-10-07 09:45:25 -0400, Maximiliano Curia wrote:
> Yes, sorry for not replying sooner. We are not planning to upload a new 
> version of gpgmepp (we are currently skipping 16.08 and upstream is 
> apparently 
> dropping gpgmepp for 16.12).

ok, cool.  so then taking it over with the gpgme1.0 source package
should be OK.

I'm not entirely sure what to do about the name of the library during
this handoff -- it might drop the "kf5" prefix.  If we don't drop the
"kf5" prefix, i suppose we'll need an epoch number in the package
version to make sure that upgrades happen.  It's also possible that
we'll need to do a similar thing with qgpgme, i guess.

thanks for the reply,

  --dkg


signature.asc
Description: PGP signature
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

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

[Daniel Kahn Gillmor]

On Wed 2016-04-13 08:18:44 -0400, Sandro Knauß  wrote:

>> looks reasonable to me.  I'm assuming that in debian, we'd have the
>> gpgme1.0 package (maintained by pkg-gnupg-maint) take over the binary
>> packages from the gpgmepp souce package (maintained by the Debian Qt/KDE
>> maintainers).  I've cc'ed both groups on this e-mail so that people are
>> aware of the situation.
>
> Ah, this information is already spreading around :D That is good. Yes,  
> Debian 
> Qt/KDE maintainers would have to remove KF5GpgMEpp. But if I see it correcly 
> we won't need to react directly and can wait till all application are 
> switched 
> over to gpgmepp. We should make sure, that both can be install in paralell. 
> But this should be possible, because we have different namespaces.

yep, i think we'll be able to do that with pretty loose coordination,
just wanted to be sure it's visible to everyone involved.

If upstream is going to make this change, i'd hope that it's sooner
rather than later, so that we can get the transition into debian and
well-settled before any sort of freeze next year.

> PS: debian-qt-kde - is mostly a list, that is spammed by the bugs
>pkg-kde-talk - is more the talk list about general topics like this one

thanks for the redirection :)

   --dkg

-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk