openldap-devel

openldap-devel@openldap.org

1431 discussions

back-ndb: retire for 2.5?
by Quanah Gibson-Mount 24 Mar '20

24 Mar '20

The back-ndb backend has never been finished, and relies on partnership with a corporation that has no desire to continue the work since it acquired the original entity involved. I would suggest then that it be removed from the 2.5 release tree and left master only. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

3 6

Issue tracker review complete
by Quanah Gibson-Mount 23 Mar '20

23 Mar '20

I've gone through and looked at all of the open issues that were in the OpenLDAP product queue. The end result of this is that numerous duplicate issues, invalid issues, and issues where we never got any response after asking for more information have been closed out appropriately. As a part of this I've gone through and marked many of the bugs with target milestones and sometimes keywords. Any issues with a target milestone of 2.5.0 and a keyword of OL_2_5_REQ is an item that should likely be fixed for OpenLDAP 2.5. If it is not going to be fixed for 2.5, then we need to come to a decision on what release series we plan on fixing it in. I.e., I generally consider these high priority items. Often these are things we've put off doing for 2.4 due to disruption/incompatible API changes, etc, but are generally necessary for the overall improvement of OpenLDAP. A number of these issues already have patches. Some of them are documentation items that are likely not too hard to deal with, and I've self-assigned many of those. There are a total of 175 items in this list: <https://bugs.openldap.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CON…> Any issues with a target milestone of 2.5.0 but no keyword of OL_2_5_REQ are items that need further review by other team members. I put items in this category that seem of general interest, but may be more appropriate for a later release, or perhaps remain unscheduled at this time. There are 188 issues in this list: <https://bugs.openldap.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CON…> There is one open issue with the 2.4.50 milestone that I'll be taking care of. All other issues I've left unassigned. This does not mean they have no value, but they do not seem critical for the OpenLDAP 2.4.50 or 2.5 releases and can be re-examined at a later time. All of this should help anyone who has expressed a desire in the past to work with the project -- There is now a well sorted set of issues that need addressing. Some of these items are fairly straight forward, especially documentation updates. Feel free to sign up to gitlab, fork the repo, and submit merge requests for issues to be reviewed. Please add any merge request links to the related issue in the tracker as well. Overall, given the list of items in the first category, I'm not sure the 2.5-odd/even track is the best route. I'm personally leaning more towards 2.5, 2.6, 2.7, etc, where each of these releases is of a short duration. There seems to be enough work at this time to support more frequent minor version releases and that would allow us to sucessively improve the product. Having defined sets of issues for given target release milestones should help significantly as far as planning and resource allocation is concerned. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

back-sql: retire for 2.5?
by Quanah Gibson-Mount 23 Mar '20

23 Mar '20

One thing that came up repeatedly in going through the ITS system is issues with back-sql (A quick count gives me 23). Given that this backend has always been marked experimental and has numerous bugs, I would suggest that unless someone steps up who is willing to support it that it be removed from the 2.5 release series (i.e., make it master only until someone is willing to maintain it). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

CVS... should it stay or should it go now?
by Quanah Gibson-Mount 17 Mar '20

17 Mar '20

One of the things we did not migrate over from Gauss was the old CVS repository. However, there are references in the old -software archives (and possibly -technical as well), and existing bug reports, such as <https://bugs.openldap.org/show_bug.cgi?id=831#c6> which have links that will no longer work without the old CVS repository being present, although all of these changes of course do exist in the git repo, just with git change IDs. Is there anyone who feels it is worthwhile to preserve the old CVS repository so that these references can still be examined directly w/o having to parse through the git history to find them? If so, we can certainly restore the CVS repo on the new system. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

archiving test
by Quanah Gibson-Mount 12 Mar '20

12 Mar '20

just an archiving test, ignore :P -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Two log lines for SRCH parameters?
by Michael Ströder 11 Feb '20

11 Feb '20

HI! I'm wondering why there are two log lines for listing the search parameters for a single search operation: SRCH base="dc=ae-dir,dc=example,dc=org" scope=2 deref=0 filter="(objectClass=aePerson)" SRCH attr=cn givenName sn mail aeStatus Is there any rationale for that? Wouldn't it be better to also list attr= along with the other search parameters? The attributes could also be listed as comma-separated list, so parsing with space as separator would be easy. I'm asking for a rather *small* change. I deliberately do not want to start a let's-fix-all-the-log-issues discussion. Ciao, Michael.

3 3

Suggested minor change: LMDB FNV hash code license
by Dan Shearer 07 Feb '20

07 Feb '20

Hello all, In using liblmdb in LumoSQL, we noticed that the FNV code in mdb.c has a non-binding license comment that doesn't match the way it is used in lmdb: "please do not copyright this code. This code is in the public domain." followed by a typical public domain disclaimer. I asked Landon Curt Noll, the author of this code, who proposed this alternative: Title: FNV Hash Author: Landon Curt Noll - http://www.isthe.com/chongo/ Source: http://www.isthe.com/chongo/tech/comp/fnv License: CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/ Share - copy and redistribute the material in any medium or format Adapt - remix, transform, and build upon the material for any purpose, even commercially. The licensor cannot revoke these freedoms as long as you follow the license terms. NOTE: This code was changed to use the 'CC BY 4.0' license by permission of the author. Would the project accept a patch that makes this change? Thanks, -- Dan Shearer dan(a)shearer.org

2 1

get rid of -releng suffix
by Michael Ströder 05 Feb '20

05 Feb '20

HI! Is the releng suffix for the shared libs still needed? It made sense in former times. But given automatic testing in VMs, containers, CI/CD delivery pipelines it just adds this small extra complexity without any benefit. I suggest to drop it for 2.5.x. Opinions? Ciao, Michael.

1 0

Re: RE25 branch testing
by Gavin Henry 03 Feb '20

03 Feb '20

Will have a shot! On Tue, 4 Feb 2020, 00:07 Quanah Gibson-Mount, <quanah(a)symas.com> wrote: > Unfortunately, it's very clear that zero people have been using/testing > the > RE25 code branch, as it was completely unusable until today (wouldn't even > compile). > > I have gotten it now to the point where it both compiles and passes make > test, although my tests do not include any SSL libraries at the moment. > > If anyone on the list could compile, test, and deploy (in a non-production > environment) RE25, that would be great. I'm working on updating the > announcement file with the numerous new features available. Once that's > complete, I'll start looking at getting an alpha tarball together. > > It would also be extremely helpful if there were people who could help > write up documentation as necessary (particularly for the admin guide) on > the new features (or heck, even the numerous unfinished pages for existing > features :( ). > > Thanks, > Quanah > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

RE25 branch testing
by Quanah Gibson-Mount 03 Feb '20

03 Feb '20

Unfortunately, it's very clear that zero people have been using/testing the RE25 code branch, as it was completely unusable until today (wouldn't even compile). I have gotten it now to the point where it both compiles and passes make test, although my tests do not include any SSL libraries at the moment. If anyone on the list could compile, test, and deploy (in a non-production environment) RE25, that would be great. I'm working on updating the announcement file with the numerous new features available. Once that's complete, I'll start looking at getting an alpha tarball together. It would also be extremely helpful if there were people who could help write up documentation as necessary (particularly for the admin guide) on the new features (or heck, even the numerous unfinished pages for existing features :( ). Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

← Newer
1
...
5
6
7
8
9
10
11
...
144
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel