Monday, 2018-07-16

*** frinring_ is now known as frinring08:45
dcalisteabranson and lbt, good morning. I've read the back log from last Friday. Do I understand properly that openldap project should be called like that, and contains a rpm/openldap-client.spec file building openldap-client rpms ?09:01
dcalisteabranson, may I ask what did you mean by "we need to verify that both of those requirements can't be patched away if they provide functionality that we don't need."?09:02
abransondcaliste: i mean that if ldap is not specifically needed by our use of gnupg, we might be able to disable that part of the build so we don't need to add it09:04
dcalisteOk, I see. The current state is S/MIME part of GnuPG requires dirmngr (which later on has been included inside GnuPG itself but this all-in-one version is GPLv3) for signing operations.09:05
dcalisteThis is related to CRL (certificate revocation list or something), so a net connection to check that certificates are valid. If the net is not available, the operation can proceed anyway, but dirmngr must be called and return a failed operation.09:07
dcalisteThen, to build dirmngr, from my reading of their configure, one requires ldap implementation, adviced to use openldap one.09:07
dcalisteIt seems to me that it's not possible to build dirmngr without ldap. I didn't read the code though to see where this ldap requirement lies.09:08
abransondcaliste: the CRL check sounds like something we should definitely support, but if that part of dirmngr doesn't have anything to do with ldap itself (iirc it's retrieved over http) then it we might be able to avoid that part. seems strange that they use a directory manager (if that's what dirmngr means) for that.09:14
dcalisteOk, looking closer, the ldap part is to build a specific dirmngr_ldap executable that is not strictly required when signing with S/MIME, at least not from my test.09:16
dcalisteAbout your question, the README of dirmngr specify: "DirMngr - X.509 Directory Manager"09:17
dcalisteAnd later on "DirMngr is a server for managing and downloading certificate revocation lists (CRLs) for X.509 certificates and for downloading the certificates themselves." and later "Dirmngr is either invoked internally by gpgsm (GnuPG-2)".09:18
dcalisteSo, you're right, I can patch their build system not to build the dirmngr_ldap executable file, so the openldap dependency may not be mandatory.09:18
dcalisteBesides, all of this is still a bit cryptic to me, I don't know much about certificates and how they are handled on the system.09:19
dcalisteabranson, I've justed pushed a commit in dcaliste/dirmngr repo on Gitlab with a patch not to build the dirmngr_ldap executable. So there is no use to add openldap in Mer.09:53
lbt\o/ :)09:53
dcalisteI think, we can start with this and add things later if we discover that they are required.09:53
* lbt looks at repo09:53
dcalisteI need to try on OBS to see if it build properly. It's fine in SDK at the moment.09:54
dcalistethanks lbt.09:54
lbtdcaliste: where is the upstream of dirmngr?09:54
lbtI really don't want a tarball in there09:54
dcalisteThere is no more versioned tree upstream. dirmngr has been merged with GnuPG itself and they didn't keep the git (well CVS or SVN) repo, as far as I know.09:55
dcalisteThe tar comes from an official download though:
lbtOK - so would you mind unpacking and committing the expanded tree09:56
dcalisteSure, I can.09:56
lbtThe commit message should reference the tarball and its sha1sum (or md5sum)09:57
dcalisteIn that case, should I apply patch from spec, or simply keep modification as git modifications ?09:57
lbtthe intention is that the commit could be verified in the future09:57
lbtI would much prefer a branch with the patch applied09:57
dcalisteOk, to put the sha1sum. I understand the security implication, that's wise indeed.09:57
lbtoh, include the .sig too09:59
dcalistelbt: I've modified the dcaliste/dirmngr repo adding a commit where tar is expanded, and patch is applied as git modifications. I've downloaded the sig data and added the sha1sum.10:07
dcalisteSince the sha1sum is not published on their FTP, I've done it myself, you'll have to trust me ;)10:07
dcalisteOr download it yourself and verify !10:08
lbt*grin* ... hmm isn't that what the .sig is for?10:09
dcalisteI need to find their public key so I can check the signature.10:09
dcalisteI'll do that after lunch.10:09
lbt*cough* tarball is still there :)10:09
dcalisteOh, I didn't catch that you don't want the tarball.10:10
dcalisteI'm going to remove it.10:10
lbtty - and then we can squash and gc the git repo so it's nice and minimal10:10
lbttarballs in git are evil10:10
dcalisteOk, I've added a commit removing the tarball.10:11
lbtwatch out for the spec ... iirc the %setup macro would unpack and overwrite your unpacked src10:11
lbtsince Source0:10:11
dcalisteAh, I see. I'll have to look at this after lunch also. Sorry, I need to go. Thank you for direction and see you later.10:12
lbtnp.. later10:13
dcalistelbt: first, the public key used to sign the package is expired and not public anymore (, too bad…12:23
dcalisteI'm testing build on OBS, it seems to work, see
lbtI looked at configure and saw (I think) --disable-ldap12:24
lbtdid you try that?12:24
dcalisteOne day, we'll be able to use GPLv3 software and won't have to deal with prehistoric versions !12:24
lbthaha - one day...12:24
dcaliste"dirmngr-1.0.3$ ./configure -h | grep ldap" returns nothing. Maybe I miss something obvious.12:25
lbtmmm - never mind. I wonder what I was thinking12:27
dcalisteIn the, there is a "if test "$have_ldap" = "no"; then die=yes", and have_ldap=no by default, switched to yes only if found (I think).12:28
lbtand ..... "*** You need a LDAP library to build this program."12:28
lbtso I think what we need is a repo cleanup :)12:29
dcalisteYes, but I've patched configure itself, because at that time I was thinking on using the tarball.12:29
dcalisteIn fact, you can look at the commit, that I've patched the configure itself and the generated also. Not the and since I was working on the source with build system from tarball.12:30
lbtPersonally I'd start with an empty commit then one which adds the unpacked tarball and .sig.   Then add the patch (with an explanation that we don't need the ldap binary and there's no switch); finally add a packaging rpm/*spec12:31
lbt*nod* ... it makes sense12:31
dcalisteIf you prefer, I can patch and and add a autoreconf -fi part in spec.12:31
lbtthat's a tricky one - I'd go for the approach you used12:31
lbtno dependencies on autoreconf12:32
lbtmainly because you're building the as-shipped tarball12:32
dcalisteI can add some words then in the README I've already added and amend the commit message when the ldap stuff is removed.12:33
lbtyes please12:33
lbtit makes sense to have a commit per logical step12:34
dcalisteOk, done, now, there is the initial commit where I put the tarball and a spec file for it, then one commit that expand the tarball and update the spec file accordingly and one last commit that remove the ldap build and thus dependency.12:38
dcaliste(I don't know how to squash the second commit with the initial one).12:39
dcalisteThere is a README also that explain the origin of the package. Readme that is amended on the ldap commit to explain what has been done and why (succintly).12:39
lbtYou can't squash to an initial commit12:39
lbtwhich is why I always try to start with an empty commit :)12:40
dcalistesmart !12:40
alteregoYou can ammend it though ;)12:58
coderusPyQt5, if anyone care :D
coderuslbt: ping. can you please upload and to ?13:41
NeoChapayWho can help me? my x86_64 target is broken and i not understand why14:34
*** Nokius_ is now known as Nokiu14:36

Generated by 2.14.0 by Marius Gedminas - find it at!