| *** frinring_ is now known as frinring | 08:45 | |
| dcaliste | abranson 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 |
|---|---|---|
| dcaliste | abranson, 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 |
| abranson | dcaliste: 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 it | 09:04 |
| dcaliste | Ok, 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 |
| dcaliste | This 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 |
| dcaliste | Then, to build dirmngr, from my reading of their configure, one requires ldap implementation, adviced to use openldap one. | 09:07 |
| dcaliste | It 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 |
| abranson | dcaliste: 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 |
| dcaliste | Ok, 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 |
| dcaliste | About your question, the README of dirmngr specify: "DirMngr - X.509 Directory Manager" | 09:17 |
| dcaliste | And 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 |
| dcaliste | So, 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 |
| dcaliste | Besides, 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 |
| dcaliste | abranson, 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 |
| dcaliste | I think, we can start with this and add things later if we discover that they are required. | 09:53 |
| * lbt looks at repo | 09:53 | |
| dcaliste | I need to try on OBS to see if it build properly. It's fine in SDK at the moment. | 09:54 |
| dcaliste | thanks lbt. | 09:54 |
| lbt | dcaliste: where is the upstream of dirmngr? | 09:54 |
| lbt | I really don't want a tarball in there | 09:54 |
| dcaliste | There 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 |
| dcaliste | The tar comes from an official download though: ftp://ftp.gnupg.org/gcrypt/dirmngr | 09:55 |
| lbt | OK - so would you mind unpacking and committing the expanded tree | 09:56 |
| dcaliste | Sure, I can. | 09:56 |
| lbt | The commit message should reference the tarball and its sha1sum (or md5sum) | 09:57 |
| dcaliste | In that case, should I apply patch from spec, or simply keep modification as git modifications ? | 09:57 |
| lbt | the intention is that the commit could be verified in the future | 09:57 |
| lbt | I would much prefer a branch with the patch applied | 09:57 |
| dcaliste | Ok, to put the sha1sum. I understand the security implication, that's wise indeed. | 09:57 |
| lbt | ty | 09:58 |
| lbt | oh, include the .sig too | 09:59 |
| dcaliste | lbt: 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 |
| dcaliste | Since the sha1sum is not published on their FTP, I've done it myself, you'll have to trust me ;) | 10:07 |
| dcaliste | Or download it yourself and verify ! | 10:08 |
| lbt | *grin* ... hmm isn't that what the .sig is for? | 10:09 |
| dcaliste | I need to find their public key so I can check the signature. | 10:09 |
| dcaliste | I'll do that after lunch. | 10:09 |
| lbt | *cough* tarball is still there :) | 10:09 |
| dcaliste | Oh, I didn't catch that you don't want the tarball. | 10:10 |
| dcaliste | I'm going to remove it. | 10:10 |
| lbt | ty - and then we can squash and gc the git repo so it's nice and minimal | 10:10 |
| lbt | tarballs in git are evil | 10:10 |
| dcaliste | Ok, I've added a commit removing the tarball. | 10:11 |
| lbt | watch out for the spec ... iirc the %setup macro would unpack and overwrite your unpacked src | 10:11 |
| lbt | since Source0: | 10:11 |
| dcaliste | Ah, 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 |
| lbt | np.. later | 10:13 |
| dcaliste | lbt: first, the public key used to sign the package is expired and not public anymore (https://www.gnupg.org/signature_key.html), too bad… | 12:23 |
| lbt | *sigh* | 12:23 |
| dcaliste | I'm testing build on OBS, it seems to work, see https://build.merproject.org/package/show/home:dcaliste:OpenPGP/dirmngr | 12:23 |
| lbt | good | 12:23 |
| lbt | I looked at configure and saw (I think) --disable-ldap | 12:24 |
| lbt | did you try that? | 12:24 |
| dcaliste | One day, we'll be able to use GPLv3 software and won't have to deal with prehistoric versions ! | 12:24 |
| lbt | haha - one day... | 12:24 |
| dcaliste | "dirmngr-1.0.3$ ./configure -h | grep ldap" returns nothing. Maybe I miss something obvious. | 12:25 |
| lbt | mmm - never mind. I wonder what I was thinking | 12:27 |
| dcaliste | In the configure.ac, 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 |
| lbt | and ..... "*** You need a LDAP library to build this program." | 12:28 |
| lbt | so I think what we need is a repo cleanup :) | 12:29 |
| dcaliste | Yes, but I've patched configure itself, because at that time I was thinking on using the tarball. | 12:29 |
| dcaliste | In fact, you can look at the commit, that I've patched the configure itself and the generated Makefile.in also. Not the configure.ac and Makefile.am since I was working on the source with build system from tarball. | 12:30 |
| lbt | Personally 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/*spec | 12:31 |
| lbt | *nod* ... it makes sense | 12:31 |
| dcaliste | If you prefer, I can patch configure.ac and Makefile.am and add a autoreconf -fi part in spec. | 12:31 |
| lbt | that's a tricky one - I'd go for the approach you used | 12:31 |
| lbt | no dependencies on autoreconf | 12:32 |
| lbt | mainly because you're building the as-shipped tarball | 12:32 |
| dcaliste | I 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 |
| lbt | yes please | 12:33 |
| lbt | it makes sense to have a commit per logical step | 12:34 |
| dcaliste | Ok, 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 |
| dcaliste | There 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 |
| lbt | You can't squash to an initial commit | 12:39 |
| lbt | which is why I always try to start with an empty commit :) | 12:40 |
| dcaliste | smart ! | 12:40 |
| alterego | You can ammend it though ;) | 12:58 |
| coderus | PyQt5, if anyone care :D https://build.merproject.org/package/show/home:coderus:2.2/python-qt | 13:15 |
| coderus | lbt: ping. can you please upload https://sourceforge.net/projects/pyqt/files/sip/sip-4.18.1/sip-4.18.1.tar.gz/download and https://sourceforge.net/projects/pyqt/files/PyQt5/PyQt-5.6/PyQt5_gpl-5.6.tar.gz/download to https://git.merproject.org/mirror ? | 13:41 |
| NeoChapay | Who can help me? https://build.merproject.org/project/monitor/home:neochapay:mer:core my x86_64 target is broken and i not understand why | 14:34 |
| *** Nokius_ is now known as Nokiu | 14:36 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!