openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

Re: (ITS#5876) Build fix: ODBC
by manu＠netbsd.org 29 Dec '08

29 Dec '08

Erratum: please consider ftp://ftp.openldap.org/incoming/manu-odbc-20081229.patch.1 instead of that one, which is broken: ftp://ftp.openldap.org/incoming/manu-odbc-20081229.patch -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5875) sparc64/gcc-3.3 build fix
by manu＠netbsd.org 29 Dec '08

29 Dec '08

Howard Chu <hyc(a)symas.com> wrote: > > NetBSD's pkgsrc has a 5 years old OpenLDAP patch that address a build > > problem on sparc64 with gcc 3.x (x<= 3). The build failure is caused by > > a bug in gcc. > > > > I think it would not hurt to commit this patch in OpenLDAP CVS: > > everything is guarded by macros, so it cannot cause any harm to > > unaffected systems, and the workaround has been tested by NetBSD people > > for 5 years. > > Kurt will probably have something to say about this too - this is more than a > couple-line patch, it needs to be submitted by its original author, with > appropriate rights attributions etc. Klaus Klein <kleink(a)kleink.org> is the contributor (I added him to the recipients of this messages). Do we need anything more than an e-mail with the patch and the excerpt below correctly filled? "This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by <YOUR NAME> <YOUR-EMAIL-ADDRESS>. I have not assigned rights and/or interest in this work to any party. " -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

(ITS#5876) Build fix: ODBC
by manu＠netbsd.org 29 Dec '08

29 Dec '08

Full_Name: Emmanuel Dreyfus Version: HEAD OS: NetBSD-4.0 URL: ftp://ftp.openldap.org/incoming/manu-odbc-20081229.patch Submission from: (NULL) (213.41.141.172) In unixODBC and iODBC, SQL_NO_DATA_FOUND was turned into SQL_NO_DATA, starting with ODBC 3.0. Supporting older ODBC package is easy, we just have to test both macros, as in the attached patch. This is an cleanup from a 3 years old patch that has been available in NetBSD package system.

1 0

Re: (ITS#5875) sparc64/gcc-3.3 build fix
by Kurt＠OpenLDAP.org 29 Dec '08

29 Dec '08

On Dec 28, 2008, at 4:10 PM, hyc(a)symas.com wrote: > manu(a)netbsd.org wrote: >> Full_Name: Emmanuel Dreyfus >> Version: HEAD >> OS: NetBSD-4.0 >> URL: http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/pkgsrc/ >> databases/openldap/patches/patch-ad?rev=1.7 >> Submission from: (NULL) (213.41.141.172) >> >> >> NetBSD's pkgsrc has a 5 years old OpenLDAP patch that address a >> build problem on >> sparc64 with gcc 3.x (x<= 3). The build failure is caused by a bug >> in gcc. >> >> I think it would not hurt to commit this patch in OpenLDAP CVS: >> everything is >> guarded by macros, so it cannot cause any harm to unaffected >> systems, and the >> workaround has been tested by NetBSD people for 5 years. > > Kurt will probably have something to say about this too - this is > more than a > couple-line patch, it needs to be submitted by its original author, > with > appropriate rights attributions etc. On a technical note, use of platform macros (sun and gcc versions) should be avoided. Instead, autoconf should be used to detect conditions for need to be adapted for. On an IPR review, I suspect it would be easier to update to: http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/hash/sha1.c?rev=1.21;con… then to try to identify the contributors and get their "okay". -- Kurt

1 0

Re: (ITS#5875) sparc64/gcc-3.3 build fix
by hyc＠symas.com 29 Dec '08

29 Dec '08

manu(a)netbsd.org wrote: > Full_Name: Emmanuel Dreyfus > Version: HEAD > OS: NetBSD-4.0 > URL: http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/pkgsrc/databases/openldap/pa… > Submission from: (NULL) (213.41.141.172) > > > NetBSD's pkgsrc has a 5 years old OpenLDAP patch that address a build problem on > sparc64 with gcc 3.x (x<= 3). The build failure is caused by a bug in gcc. > > I think it would not hurt to commit this patch in OpenLDAP CVS: everything is > guarded by macros, so it cannot cause any harm to unaffected systems, and the > workaround has been tested by NetBSD people for 5 years. Kurt will probably have something to say about this too - this is more than a couple-line patch, it needs to be submitted by its original author, with appropriate rights attributions etc. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5872) slapo-cloak
by ando＠sys-net.it 28 Dec '08

28 Dec '08

manu(a)netbsd.org wrote: > Howard Chu <hyc(a)symas.com> wrote: > >> I suppose so. I put my stuff in there when I don't consider it worth my effort >> to autoconf-iscate it. Things like nssov only work with Linux, so there's no >> point in adding the overhead. Stuff in there really is of too limited use to >> warrant the full effort of maintenance that the core code gets. > > That means the added value of contrib/ is that it will only be > maintained by its contributor and will rot otherwise. > > Overlays that have been autoconf-ified could all reside in > server/slapd/overlays. Non-core thing would be disabled by default, and > would rot if not maintained by their contributors, as they are now... Didn't mean to start a holy war about contrib/ vs. overlays/. My intention was to isolate overlay development from autoconf-ing, until generality and usefulness demand for moving to overlays/. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5872) slapo-cloak
by ando＠sys-net.it 28 Dec '08

28 Dec '08

Hallvard B Furuseth wrote: > ando(a)sys-net.it writes: >> On a related note, if this can be considered of general usefulness, LDAP >> specs would need to be changed in order to define a finer grain of >> attribute request; something like: >> >> empty or "*" ; all user, except attrs that need to be explicitly req. >> "+" ; all operational >> <all including attrs that need to be explicitly requested> >> <...> > > Would it be cleaner if slapo-cloak redefines the attributes to be > operational, or to behave as if they are? Maybe give them an > X-AS-OPERATIONAL extension? Or would that just mess up schema code, > things like attribute inheritance? I think things would mess up. The X-AS-OPERATIONAL could help, although it would result in a modification of otherwise standard-track schema items. Moreover, I see a number of features system administrators could ask for; e.g. hide attributes only when matching a URI (base, scope, filter), or based on size limit, or based on client's identity and so. In this case, I'd keep schema out. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5875) sparc64/gcc-3.3 build fix
by manu＠netbsd.org 28 Dec '08

28 Dec '08

Full_Name: Emmanuel Dreyfus Version: HEAD OS: NetBSD-4.0 URL: http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/pkgsrc/databases/openldap/pa… Submission from: (NULL) (213.41.141.172) NetBSD's pkgsrc has a 5 years old OpenLDAP patch that address a build problem on sparc64 with gcc 3.x (x <= 3). The build failure is caused by a bug in gcc. I think it would not hurt to commit this patch in OpenLDAP CVS: everything is guarded by macros, so it cannot cause any harm to unaffected systems, and the workaround has been tested by NetBSD people for 5 years.

1 0

Re: (ITS#5872) slapo-cloak
by manu＠netbsd.org 27 Dec '08

27 Dec '08

Howard Chu <hyc(a)symas.com> wrote: > I suppose so. I put my stuff in there when I don't consider it worth my effort > to autoconf-iscate it. Things like nssov only work with Linux, so there's no > point in adding the overhead. Stuff in there really is of too limited use to > warrant the full effort of maintenance that the core code gets. That means the added value of contrib/ is that it will only be maintained by its contributor and will rot otherwise. Overlays that have been autoconf-ified could all reside in server/slapd/overlays. Non-core thing would be disabled by default, and would rot if not maintained by their contributors, as they are now... -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5872) slapo-cloak
by hyc＠symas.com 27 Dec '08

27 Dec '08

manu(a)netbsd.org wrote: > Pierangelo Masarati<ando(a)sys-net.it> wrote: > >> I'd see this overlay more appropriate for contrib/slapd-modules right >> now, until its functionality is considered of general usefulness, which >> doesn't seem to be the case right now. > > Do you think an overlay in the contrib directory could have its --enable > flag in top level configure? > My feeling about the contrib directory is that it is some kind of evil > swamp where things are much more difficult to automatically build for > inclusion in a package. I suppose so. I put my stuff in there when I don't consider it worth my effort to autoconf-iscate it. Things like nssov only work with Linux, so there's no point in adding the overhead. Stuff in there really is of too limited use to warrant the full effort of maintenance that the core code gets. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs