Re: 2.4 commit review

[Quanah Gibson-Mount]

--On Thursday, April 2, 2020 9:09 PM +0100 Howard Chu  wrote:


Quanah Gibson-Mount wrote:

I think the following ITSes would be good to add for 2.4.50.  Any
objections?

ITS#7074 - Fix olcDatabaseDummy init for windows
ITS#9003 - Fix slapd-ldap(5) man page to note idassert-authzfrom policy
difference ITS#9181 - Fix race on Windows mutex init
ITS#9182 - pcache: fix private DB init


Sounds fine, they're simple enough.
Did you also pull in the utf8bvnormalize leak patch?


I have it queued up for approval in merge request 20, if you want to sign 
off on it. ;)


--Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: 2.4 commit review

[Howard Chu]

Quanah Gibson-Mount wrote:
> I think the following ITSes would be good to add for 2.4.50.  Any objections?
> 
> ITS#7074 - Fix olcDatabaseDummy init for windows
> ITS#9003 - Fix slapd-ldap(5) man page to note idassert-authzfrom policy 
> difference
> ITS#9181 - Fix race on Windows mutex init
> ITS#9182 - pcache: fix private DB init

Sounds fine, they're simple enough.
Did you also pull in the utf8bvnormalize leak patch?

-- 
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: 2.4 commit review

[Quanah Gibson-Mount]

--On Saturday, January 11, 2020 10:42 AM +0100 Michael Ströder 
 wrote:



There are a few open ITSes that need addressing before I can proceed
with a testing call.


The fix for ITS#9124 is pretty urgent. So other ITS should not block
releasing 2.4.49.


Now that ITS#9150 is addressed, which was also rather serious as far as 
data integrity is concerned, we should be set for a testing call on Monday. 
I still have a side issue that has no ITS yet that may also go into this 
release, but we should be set for the testing call.


--Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: 2.4 commit review

[Michael Ströder]

On 1/10/20 11:25 PM, Quanah Gibson-Mount wrote:
> --On Friday, January 10, 2020 6:06 PM +0100 Clément OUDOT
>  wrote:
>> I would like to know if there was some date planned for 2.4.49, and if
>> this ITS could be added to this release:
>> http://www.openldap.org/its/index.cgi/Software%20Bugs?id=9146;selectid=91
>> 46
> 
> It was already merged into RE24 and added to the CHANGES file for 2.4.49.
> 
> There are a few open ITSes that need addressing before I can proceed
> with a testing call.

The fix for ITS#9124 is pretty urgent. So other ITS should not block
releasing 2.4.49.

Ciao, Michael.

Re: 2.4 commit review

[Quanah Gibson-Mount]

--On Friday, January 10, 2020 6:06 PM +0100 Clément OUDOT 
 wrote:




Le 01/11/2019 à 17:31, Quanah Gibson-Mount a écrit :

A few commits stacking up, so would like to review them for inclusion
in an eventual 2.4.49.



Hello,

I would like to know if there was some date planned for 2.4.49, and if
this ITS could be added to this release:
http://www.openldap.org/its/index.cgi/Software%20Bugs?id=9146;selectid=91
46


It was already merged into RE24 and added to the CHANGES file for 2.4.49.

There are a few open ITSes that need addressing before I can proceed with a 
testing call.


--Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: 2.4 commit review

[Clément OUDOT]

Le 01/11/2019 à 17:31, Quanah Gibson-Mount a écrit :
> A few commits stacking up, so would like to review them for inclusion
> in an eventual 2.4.49. 


Hello,

I would like to know if there was some date planned for 2.4.49, and if
this ITS could be added to this release:
http://www.openldap.org/its/index.cgi/Software%20Bugs?id=9146;selectid=9146

Thanks a lot,

-- 
Clément Oudot | Identity Solutions Manager

clement.ou...@worteks.com

Worteks | https://www.worteks.com

Re: 2.4 commit review

[Hugh McMaster]

On Sun, 24 Nov 2019 at 10:37 pm, Howard Chu wrote:

> We have a project policy of not including content we can't support. And as
> a general
> circumstance, if we don't use something ourselves, then we aren't in a
> position to support it.
> Are you going to be here for the next 20+ years to support this addition?


If I have to be, yes.

That said, you clearly don’t believe pkg-config will benefit the project,
and I respect that decision. I also respect (and appreciate) that you’ve
gone into detail explaining your reasoning.

I won’t push this further here. Thanks for the debate.

Hugh

>

Re: 2.4 commit review

[Howard Chu]

Hugh McMaster wrote:
> PKG_CONFIG_PATH will help you here, but it's just one option. You
> could also use a (s)chroot or other containers.

When someone tells you they don't like something because it adds extra steps,
suggesting *even more* additional steps is not a smart response.

>> So from an active developer's perspective, it adds steps but doesn't add 
>> useful information.

-- 
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: 2.4 commit review

[Howard Chu]

Hugh McMaster wrote:
> Hi Howard,
> 
> On Sun, 24 Nov 2019 at 01:59, Howard Chu wrote:
>> AFAICS it is just another moving part that breaks. It doesn't provide any 
>> information.
>> To use it you have to know whether to look in the /usr configs or /usr/local 
>> (or other places),
> 
> pkg-config automatically knows where the headers and libraries are,
> since information is hard-coded into the pc file. If the headers and
> libraries are installed in a standard system location (e.g. /usr/lib
> or /usr/include), this information is not passed to the command line,
> since the paths are already in the environment.If you have pkg-config
> files in a custom location (e.g. /opt), you can simply set
> PKG_CONFIG_PATH and you'll get
> -L/opt/my/custom/path -ldap -lber
> 
> It's just a different workflow.
> 
> One of the problems with detecting openldap is that developers need to
> know where the libraries and headers are. pkg-config handles this for
> you when compiling. (And yes, I'll admit developers should know this
> anyway.)
> For instance, how many people know ldap depends on lber?

If they're linking to shared libraries, they don't need to know, since
libldap.so already links to liblber.so.

If we had a sane static library implementation, that included its dependency
libraries in a __LIBS element (the same way ranlib stores symbol offsets in
a __SYMDEF element in static libraries) then nobody would ever need to know.
pkg-config is a bullshit hack that doesn't solve the root problem.

>> If I know to look in /usr/local to find the package config I want, then I 
>> already know that the
>> header and lib paths I need are in /usr/local and it hasn't helped at all.
> 
> The point is that you had to know about your setup.

And pkg-config doesn't change that; I still have to know where the .pc files 
went.

> But I
> don't believe it's fair to prevent people from having the option to
> use pkg-config support if we can offer it.

We have a project policy of not including content we can't support. And as a 
general
circumstance, if we don't use something ourselves, then we aren't in a position 
to support it.
Are you going to be here for the next 20+ years to support this addition?

-- 
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: 2.4 commit review

[Hugh McMaster]

Hi Howard,

On Sun, 24 Nov 2019 at 01:59, Howard Chu wrote:
> AFAICS it is just another moving part that breaks. It doesn't provide any 
> information.
> To use it you have to know whether to look in the /usr configs or /usr/local 
> (or other places),

pkg-config automatically knows where the headers and libraries are,
since information is hard-coded into the pc file. If the headers and
libraries are installed in a standard system location (e.g. /usr/lib
or /usr/include), this information is not passed to the command line,
since the paths are already in the environment.If you have pkg-config
files in a custom location (e.g. /opt), you can simply set
PKG_CONFIG_PATH and you'll get
-L/opt/my/custom/path -ldap -lber

It's just a different workflow.

One of the problems with detecting openldap is that developers need to
know where the libraries and headers are. pkg-config handles this for
you when compiling. (And yes, I'll admit developers should know this
anyway.)
For instance, how many people know ldap depends on lber?

> If I know to look in /usr/local to find the package config I want, then I 
> already know that the
> header and lib paths I need are in /usr/local and it hasn't helped at all.

The point is that you had to know about your setup. pkg-config is just
an easier way of working with headers and libraries. It also means I
don't need to know which libraries depend on which others. It just
works. OpenLDAP makes this harder than it should be.

> More importantly, relying on it actively prevents you from working with 
> packages in their
> own build directories. As someone who frequently has to build multiple 
> versions of various
> dependencies to check that they all work with our OpenLDAP builds, I can't be 
> bothered to
> re-install every different version I'm working with, particularly when I 
> could otherwise
> just add a few items to LDFLAGS, LIBPATH, or whatnot. Every time I run across 
> a build
> script that requires using pkg-config to find a package I have to go through 
> and comment
> it out just so my env var settings will take effect.

PKG_CONFIG_PATH will help you here, but it's just one option. You
could also use a (s)chroot or other containers.

> So from an active developer's perspective, it adds steps but doesn't add 
> useful information.

`pkg-config --libs ldap' or`pkg-config --cflags ldap' tells me
everything I need to know to link against openldap.

If there is some particular information you need, we can also add
custom variables.

One thing I'd like to reiterate is that you wouldn't be using these
pkg-config files. They are for third parties. I believe there is a
need for them -- and Ryan has expressed support after testing the
patches. You seem to disagree about the need - that's fine. But I
don't believe it's fair to prevent people from having the option to
use pkg-config support if we can offer it.

Hugh

Re: 2.4 commit review

[Howard Chu]

Hugh McMaster wrote:
> On Fri, 22 Nov 2019 at 21:59, Howard Chu wrote:
>> Quanah Gibson-Mount wrote:
>>> Howard, what's your opinion/thought on adding this for master/RE25?  Ryan 
>>> tested it and it worked for him.
>>
>> My personal opinion is that pkg-config is garbage and in all my experience 
>> it has
>> only ever prevented me from building whatever I was working on at the time.
> 
> I get the feeling there's an interesting backstory here. I'm actually
> quite surprised you've had a bad experience with pkg-config.
> It's really quite useful and far easier than calling foo-config legacy 
> scripts.
> 
> With regards to merging #8996, you didn't really answer Quanah's
> question. I'll also point out that you're not being forced to use
> openldap's pkg-config files.
> 
> Many people prefer pkg-config because of its simplicity in handling
> library dependencies and header inclusions. I'm simply trying to
> extend this simplicity to openldap.

AFAICS it is just another moving part that breaks. It doesn't provide any 
information.
To use it you have to know whether to look in the /usr configs or /usr/local 
(or other places),
If I know to look in /usr/local to find the package config I want, then I 
already know that the
header and lib paths I need are in /usr/local and it hasn't helped at all.

More importantly, relying on it actively prevents you from working with 
packages in their
own build directories. As someone who frequently has to build multiple versions 
of various
dependencies to check that they all work with our OpenLDAP builds, I can't be 
bothered to
re-install every different version I'm working with, particularly when I could 
otherwise
just add a few items to LDFLAGS, LIBPATH, or whatnot. Every time I run across a 
build
script that requires using pkg-config to find a package I have to go through 
and comment
it out just so my env var settings will take effect.

So from an active developer's perspective, it adds steps but doesn't add useful 
information.

-- 
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: 2.4 commit review

[Hugh McMaster]

On Fri, 22 Nov 2019 at 21:59, Howard Chu wrote:
> Quanah Gibson-Mount wrote:
> > Howard, what's your opinion/thought on adding this for master/RE25?  Ryan 
> > tested it and it worked for him.
>
> My personal opinion is that pkg-config is garbage and in all my experience it 
> has
> only ever prevented me from building whatever I was working on at the time.

I get the feeling there's an interesting backstory here. I'm actually
quite surprised you've had a bad experience with pkg-config.
It's really quite useful and far easier than calling foo-config legacy scripts.

With regards to merging #8996, you didn't really answer Quanah's
question. I'll also point out that you're not being forced to use
openldap's pkg-config files.

Many people prefer pkg-config because of its simplicity in handling
library dependencies and header inclusions. I'm simply trying to
extend this simplicity to openldap.

Regards,

Hugh

Re: 2.4 commit review

[Howard Chu]

Quanah Gibson-Mount wrote:
> --On Friday, November 22, 2019 9:14 AM +1100 Hugh McMaster 
>  wrote:
> 
> 
>> Any chance that ITS#8996 could be included? Back in April, you said
>> pkg-config support would need to wait for a 2.5 release [1], but given
>> the pace of development, that could still be months or years away.
> 
> Howard, what's your opinion/thought on adding this for master/RE25?  Ryan 
> tested it and it worked for him.

My personal opinion is that pkg-config is garbage and in all my experience it 
has
only ever prevented me from building whatever I was working on at the time.

-- 
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: 2.4 commit review

[Quanah Gibson-Mount]

--On Friday, November 22, 2019 9:14 AM +1100 Hugh McMaster 
 wrote:




Any chance that ITS#8996 could be included? Back in April, you said
pkg-config support would need to wait for a 2.5 release [1], but given
the pace of development, that could still be months or years away.


Howard, what's your opinion/thought on adding this for master/RE25?  Ryan 
tested it and it worked for him.


--Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: 2.4 commit review

[Hugh McMaster]

On Sat, 2 Nov 2019 at 11:02 pm, Hugh McMaster wrote:

> Hi Quanah,
>
> On Sat, 2 Nov 2019 at 03:32, Quanah Gibson-Mount wrote:
> >
> > A few commits stacking up, so would like to review them for inclusion in
> an
> > eventual 2.4.49.
>
> Any chance that ITS#8996 could be included? Back in April, you said
> pkg-config support would need to wait for a 2.5 release [1], but given
> the pace of development, that could still be months or years away.
>
> Thanks,
>
> Hugh
>
> [1] http://www.openldap.org/lists/openldap-devel/201904/msg00012.html
>
Just following up on this. I’m guessing it could be merged for RE25a? I’d
prefer earlier but that’s outside my control.

Hugh

Re: 2.4 commit review

[Quanah Gibson-Mount]

--On Thursday, November 21, 2019 1:32 PM + Howard Chu  
wrote:



Are you OK with the rest of the changes (outside of ITS#8753) then?


So totp isn't part of contrib in RE24, so I'll skip those changes and it 
can go out with the RE25 alpha (Thinking January or so for that).


--Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: 2.4 commit review

[Howard Chu]

Quanah Gibson-Mount wrote:
> 
> 
> --On Tuesday, November 5, 2019 8:12 PM + Howard Chu  
> wrote:
> 
>> Ryan Tandy wrote:
 ITS#9069 Do not call gnutls_global_set_mutex()
>>>
>>> Subject to hyc's approval, but I think this could go in. It's been in
>>> Debian since 10.0 and Ubuntu since 19.04, no negative feedback.
>>
>> OK, sounds fine then.
> 
> Are you OK with the rest of the changes (outside of ITS#8753) then?

Sure
> 
> --Quanah
> 
> 
> -- 
> 
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> 
> 


-- 
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: 2.4 commit review

[Quanah Gibson-Mount]

--On Tuesday, November 5, 2019 8:12 PM + Howard Chu  
wrote:



Ryan Tandy wrote:

ITS#9069 Do not call gnutls_global_set_mutex()


Subject to hyc's approval, but I think this could go in. It's been in
Debian since 10.0 and Ubuntu since 19.04, no negative feedback.


OK, sounds fine then.


Are you OK with the rest of the changes (outside of ITS#8753) then?

--Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: 2.4 commit review

[Howard Chu]

Ryan Tandy wrote:
>> ITS#9069 Do not call gnutls_global_set_mutex()
> 
> Subject to hyc's approval, but I think this could go in. It's been in Debian 
> since 10.0 and Ubuntu since 19.04, no negative feedback.

OK, sounds fine then.


-- 
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: 2.4 commit review

[Ryan Tandy]

On Fri, Nov 01, 2019 at 09:31:07AM -0700, Quanah Gibson-Mount wrote:

ITS#8753 Set minimum GnuTLS version to 3.2.2


Not on its own. Only needed if the rest of that ITS goes (guessing no).


ITS#9069 Do not call gnutls_global_set_mutex()


Subject to hyc's approval, but I think this could go in. It's been in 
Debian since 10.0 and Ubuntu since 19.04, no negative feedback.

Re: 2.4 commit review

[Hugh McMaster]

Hi Quanah,

On Sat, 2 Nov 2019 at 03:32, Quanah Gibson-Mount wrote:
>
> A few commits stacking up, so would like to review them for inclusion in an
> eventual 2.4.49.

Any chance that ITS#8996 could be included? Back in April, you said
pkg-config support would need to wait for a 2.5 release [1], but given
the pace of development, that could still be months or years away.

Thanks,

Hugh

[1] http://www.openldap.org/lists/openldap-devel/201904/msg00012.html