mail/libetpan 6.1 backport

2017-05-16 Thread Paul Irofti
Along with the openvpn backport that jca committed, I also backported and tested mail/libetpan. OK? Index: Makefile === RCS file: /cvs/ports/mail/libetpan/Makefile,v retrieving revision 1.25 diff -u -p -r1.25 Makefile --- Makefile

Re: mail/libetpan 6.1 backport

2017-05-16 Thread Jeremie Courreges-Anglas
Paul Irofti writes: > Along with the openvpn backport that jca committed, I also backported > and tested mail/libetpan. OK? The problem is that the diff below bumps the lib major version. For -stable it is better to avoid this as much as we can, since it means that users have to rebuild all the

Re: mail/libetpan 6.1 backport

2017-05-16 Thread Paul Irofti
Right, so how about this? Index: Makefile === RCS file: /cvs/ports/mail/libetpan/Makefile,v retrieving revision 1.25 diff -u -p -u -p -r1.25 Makefile --- Makefile11 Nov 2016 12:07:00 - 1.25 +++ Makefile16 May 2017 16:

Re: mail/libetpan 6.1 backport

2017-05-16 Thread Daniel Jakots
On Tue, 16 May 2017 19:32:39 +0300, Paul Irofti wrote: > Right, so how about this? I think it's better that way. Thanks for taking care of. ok danj@ > Index: Makefile > === > RCS file: /cvs/ports/mail/libetpan/Makefile,v > retrievi

Re: mail/libetpan 6.1 backport

2017-05-16 Thread Paul Irofti
On 5/16/2017 8:35 PM, Daniel Jakots wrote: On Tue, 16 May 2017 19:32:39 +0300, Paul Irofti wrote: Right, so how about this? I think it's better that way. Thanks for taking care of. ok danj@ What I am worried with this approach of cherry-picking specific CVE patches is that we might skip o

Re: mail/libetpan 6.1 backport

2017-05-16 Thread Jeremie Courreges-Anglas
Paul Irofti writes: > Right, so how about this? Looks fine to me, ok jca@ -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE

Re: mail/libetpan 6.1 backport

2017-05-16 Thread Jeremie Courreges-Anglas
Paul Irofti writes: > On 5/16/2017 8:35 PM, Daniel Jakots wrote: >> On Tue, 16 May 2017 19:32:39 +0300, Paul Irofti wrote: >> >>> Right, so how about this? >> >> I think it's better that way. Thanks for taking care of. ok danj@ > > What I am worried with this approach of cherry-picking specific