gqclient-discuss Mailing List for GQ LDAP client (Page 31)

On Tue, 15 Oct 2002, Simon Matter wrote:

> > > > > Hi,
> > > > >
> > > > > I have just tried to compile GQ 0.7beta2 on a RedHat 8.0 box with no
> > > > > success. I guess it's a automake/autoconf issue.
> > > > >
> > > > > make[2]: Leaving directory `/usr/src/redhat/BUILD/gq-0.7.0beta2/intl'
> > > > > make[2]: Entering directory `/usr/src/redhat/BUILD/gq-0.7.0beta2/intl'
> > > > > make[2]: Nothing to be done for `all'.
> > > > > make[2]: Leaving directory `/usr/src/redhat/BUILD/gq-0.7.0beta2/intl'
> > > > > Making all in src
> > > > > make[2]: Entering directory `/usr/src/redhat/BUILD/gq-0.7.0beta2/src'
> > > > > cd .. && automake --gnu --include-deps src/Makefile
> > > > > src/Makefile.am: required file `./depcomp' not found
> > > > > make[2]: *** [Makefile.in] Error 1
> > > > > make[2]: Leaving directory `/usr/src/redhat/BUILD/gq-0.7.0beta2/src'
> > > > > make[1]: *** [all-recursive] Error 1
> > > > > make[1]: Leaving directory `/usr/src/redhat/BUILD/gq-0.7.0beta2'
> > > > > make: *** [all] Error 2
> > > >

[snip]

> > I use automake 1.4 and autoconf 2.13 (yeah, old stuff, but it works). I
> > just don't understand why automake gets called here. It is not required to
> > have automake installed at all, so I am definitly puzzled here. I think
> > depcomp is required to be in the source distro in packages based on later
> > versions of automake/autoconf.
>
> I have a bit more info:
>
> 1)
> gq-0.7.0beta1 compiles fine on RH 8.0.
>
> 2)
> The following "fixes" the compile problems which seem to be autoconf
> related:
> aclocal-1.4 ; automake-1.4 ; autoconf ; ./configure ; make
>
> Looks like some ac stuff broke between beta1 and beta2.

You are right, and I think I found the problem. I would like to send you a
fixed beta2 distribution (because this is a distribution problem a patch
would not do). Would you mind receiving a 350KB attachment with your
personal beta release?

peter

Peter Stamfest schrieb:
> 
> On Mon, 14 Oct 2002, Simon Matter wrote:
> 
> > Date: Mon, 14 Oct 2002 16:31:00 +0200
> > From: Simon Matter <sim...@ch...>
> > To: Peter Stamfest <pe...@st...>
> > Cc: gqclient-discuss <gqc...@li...>
> > Subject: Re: [Gqclient-discuss] compiling GQ 0.7beta2 on RedHat 8.0
> >
> > Peter Stamfest schrieb:
> > >
> > > On Mon, 14 Oct 2002, Simon Matter wrote:
> > >
> > > > Date: Mon, 14 Oct 2002 13:12:06 +0200
> > > > From: Simon Matter <sim...@ch...>
> > > > To: gqclient-discuss <gqc...@li...>
> > > > Subject: [Gqclient-discuss] compiling GQ 0.7beta2 on RedHat 8.0
> > > >
> > > > Hi,
> > > >
> > > > I have just tried to compile GQ 0.7beta2 on a RedHat 8.0 box with no
> > > > success. I guess it's a automake/autoconf issue.
> > > >
> > > > make[2]: Leaving directory `/usr/src/redhat/BUILD/gq-0.7.0beta2/intl'
> > > > make[2]: Entering directory `/usr/src/redhat/BUILD/gq-0.7.0beta2/intl'
> > > > make[2]: Nothing to be done for `all'.
> > > > make[2]: Leaving directory `/usr/src/redhat/BUILD/gq-0.7.0beta2/intl'
> > > > Making all in src
> > > > make[2]: Entering directory `/usr/src/redhat/BUILD/gq-0.7.0beta2/src'
> > > > cd .. && automake --gnu --include-deps src/Makefile
> > > > src/Makefile.am: required file `./depcomp' not found
> > > > make[2]: *** [Makefile.in] Error 1
> > > > make[2]: Leaving directory `/usr/src/redhat/BUILD/gq-0.7.0beta2/src'
> > > > make[1]: *** [all-recursive] Error 1
> > > > make[1]: Leaving directory `/usr/src/redhat/BUILD/gq-0.7.0beta2'
> > > > make: *** [all] Error 2
> > >
> > > Hmmmm, if you did a d/l of the normal distro, used a langpack
> > > and then did
> > >
> > >    ./configure; make
> > >
> > > Then I think the attached patch should help. It is a patch to the
> > > langpack, thus apply it within the extracted langpack directory.
> >
> > I didn't use a GQ langpack nor did I install any 'additional languages'
> > in my RedHat 8.0. Only US English, which is the default.
> > The box uses autoconf 2.53 and automake 1.6.3 and I do the usual
> > ./configure ; make. Do I miss something obvious?
> >
> 
> Obviously: not ;-)
> 
> I use automake 1.4 and autoconf 2.13 (yeah, old stuff, but it works). I
> just don't understand why automake gets called here. It is not required to
> have automake installed at all, so I am definitly puzzled here. I think
> depcomp is required to be in the source distro in packages based on later
> versions of automake/autoconf.

I have a bit more info:

1)
gq-0.7.0beta1 compiles fine on RH 8.0.

2)
The following "fixes" the compile problems which seem to be autoconf
related:
aclocal-1.4 ; automake-1.4 ; autoconf ; ./configure ; make

Looks like some ac stuff broke between beta1 and beta2.

Simon

> 
> BTW: Is your system time correct? If you did a time-warp into the past
> recently, maybe this accounts for such the observed effect...
> 
> The simple answer of course is to just provide a depcomp program from your
> automake/autoconf distribution, but I would really like to know the
> reasons for your problems...
> 
> peter

Peter Stamfest schrieb:
> 
> On Mon, 14 Oct 2002, Simon Matter wrote:
> 
> > Date: Mon, 14 Oct 2002 16:31:00 +0200
> > From: Simon Matter <sim...@ch...>
> > To: Peter Stamfest <pe...@st...>
> > Cc: gqclient-discuss <gqc...@li...>
> > Subject: Re: [Gqclient-discuss] compiling GQ 0.7beta2 on RedHat 8.0
> >
> > Peter Stamfest schrieb:
> > >
> > > On Mon, 14 Oct 2002, Simon Matter wrote:
> > >
> > > > Date: Mon, 14 Oct 2002 13:12:06 +0200
> > > > From: Simon Matter <sim...@ch...>
> > > > To: gqclient-discuss <gqc...@li...>
> > > > Subject: [Gqclient-discuss] compiling GQ 0.7beta2 on RedHat 8.0
> > > >
> > > > Hi,
> > > >
> > > > I have just tried to compile GQ 0.7beta2 on a RedHat 8.0 box with no
> > > > success. I guess it's a automake/autoconf issue.
> > > >
> > > > make[2]: Leaving directory `/usr/src/redhat/BUILD/gq-0.7.0beta2/intl'
> > > > make[2]: Entering directory `/usr/src/redhat/BUILD/gq-0.7.0beta2/intl'
> > > > make[2]: Nothing to be done for `all'.
> > > > make[2]: Leaving directory `/usr/src/redhat/BUILD/gq-0.7.0beta2/intl'
> > > > Making all in src
> > > > make[2]: Entering directory `/usr/src/redhat/BUILD/gq-0.7.0beta2/src'
> > > > cd .. && automake --gnu --include-deps src/Makefile
> > > > src/Makefile.am: required file `./depcomp' not found
> > > > make[2]: *** [Makefile.in] Error 1
> > > > make[2]: Leaving directory `/usr/src/redhat/BUILD/gq-0.7.0beta2/src'
> > > > make[1]: *** [all-recursive] Error 1
> > > > make[1]: Leaving directory `/usr/src/redhat/BUILD/gq-0.7.0beta2'
> > > > make: *** [all] Error 2
> > >
> > > Hmmmm, if you did a d/l of the normal distro, used a langpack
> > > and then did
> > >
> > >    ./configure; make
> > >
> > > Then I think the attached patch should help. It is a patch to the
> > > langpack, thus apply it within the extracted langpack directory.
> >
> > I didn't use a GQ langpack nor did I install any 'additional languages'
> > in my RedHat 8.0. Only US English, which is the default.
> > The box uses autoconf 2.53 and automake 1.6.3 and I do the usual
> > ./configure ; make. Do I miss something obvious?
> >
> 
> Obviously: not ;-)
> 
> I use automake 1.4 and autoconf 2.13 (yeah, old stuff, but it works). I
> just don't understand why automake gets called here. It is not required to
> have automake installed at all, so I am definitly puzzled here. I think
> depcomp is required to be in the source distro in packages based on later
> versions of automake/autoconf.
> 
> BTW: Is your system time correct? If you did a time-warp into the past
> recently, maybe this accounts for such the observed effect...

Time is correct.

> 
> The simple answer of course is to just provide a depcomp program from your
> automake/autoconf distribution, but I would really like to know the
> reasons for your problems...

Me too. If you need any information just let me know.

Simon

> 
> peter
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gqclient-discuss mailing list
> Gqc...@li...
> https://lists.sourceforge.net/lists/listinfo/gqclient-discuss

On Mon, 14 Oct 2002, Simon Matter wrote:

> Date: Mon, 14 Oct 2002 16:31:00 +0200
> From: Simon Matter <sim...@ch...>
> To: Peter Stamfest <pe...@st...>
> Cc: gqclient-discuss <gqc...@li...>
> Subject: Re: [Gqclient-discuss] compiling GQ 0.7beta2 on RedHat 8.0
>
> Peter Stamfest schrieb:
> >
> > On Mon, 14 Oct 2002, Simon Matter wrote:
> >
> > > Date: Mon, 14 Oct 2002 13:12:06 +0200
> > > From: Simon Matter <sim...@ch...>
> > > To: gqclient-discuss <gqc...@li...>
> > > Subject: [Gqclient-discuss] compiling GQ 0.7beta2 on RedHat 8.0
> > >
> > > Hi,
> > >
> > > I have just tried to compile GQ 0.7beta2 on a RedHat 8.0 box with no
> > > success. I guess it's a automake/autoconf issue.
> > >
> > > make[2]: Leaving directory `/usr/src/redhat/BUILD/gq-0.7.0beta2/intl'
> > > make[2]: Entering directory `/usr/src/redhat/BUILD/gq-0.7.0beta2/intl'
> > > make[2]: Nothing to be done for `all'.
> > > make[2]: Leaving directory `/usr/src/redhat/BUILD/gq-0.7.0beta2/intl'
> > > Making all in src
> > > make[2]: Entering directory `/usr/src/redhat/BUILD/gq-0.7.0beta2/src'
> > > cd .. && automake --gnu --include-deps src/Makefile
> > > src/Makefile.am: required file `./depcomp' not found
> > > make[2]: *** [Makefile.in] Error 1
> > > make[2]: Leaving directory `/usr/src/redhat/BUILD/gq-0.7.0beta2/src'
> > > make[1]: *** [all-recursive] Error 1
> > > make[1]: Leaving directory `/usr/src/redhat/BUILD/gq-0.7.0beta2'
> > > make: *** [all] Error 2
> >
> > Hmmmm, if you did a d/l of the normal distro, used a langpack
> > and then did
> >
> >    ./configure; make
> >
> > Then I think the attached patch should help. It is a patch to the
> > langpack, thus apply it within the extracted langpack directory.
>
> I didn't use a GQ langpack nor did I install any 'additional languages'
> in my RedHat 8.0. Only US English, which is the default.
> The box uses autoconf 2.53 and automake 1.6.3 and I do the usual
> ./configure ; make. Do I miss something obvious?
>

Obviously: not ;-)

I use automake 1.4 and autoconf 2.13 (yeah, old stuff, but it works). I
just don't understand why automake gets called here. It is not required to
have automake installed at all, so I am definitly puzzled here. I think
depcomp is required to be in the source distro in packages based on later
versions of automake/autoconf.

BTW: Is your system time correct? If you did a time-warp into the past
recently, maybe this accounts for such the observed effect...

The simple answer of course is to just provide a depcomp program from your
automake/autoconf distribution, but I would really like to know the
reasons for your problems...

peter

Peter Stamfest schrieb:
> 
> On Mon, 14 Oct 2002, Simon Matter wrote:
> 
> > Date: Mon, 14 Oct 2002 13:12:06 +0200
> > From: Simon Matter <sim...@ch...>
> > To: gqclient-discuss <gqc...@li...>
> > Subject: [Gqclient-discuss] compiling GQ 0.7beta2 on RedHat 8.0
> >
> > Hi,
> >
> > I have just tried to compile GQ 0.7beta2 on a RedHat 8.0 box with no
> > success. I guess it's a automake/autoconf issue.
> >
> > make[2]: Leaving directory `/usr/src/redhat/BUILD/gq-0.7.0beta2/intl'
> > make[2]: Entering directory `/usr/src/redhat/BUILD/gq-0.7.0beta2/intl'
> > make[2]: Nothing to be done for `all'.
> > make[2]: Leaving directory `/usr/src/redhat/BUILD/gq-0.7.0beta2/intl'
> > Making all in src
> > make[2]: Entering directory `/usr/src/redhat/BUILD/gq-0.7.0beta2/src'
> > cd .. && automake --gnu --include-deps src/Makefile
> > src/Makefile.am: required file `./depcomp' not found
> > make[2]: *** [Makefile.in] Error 1
> > make[2]: Leaving directory `/usr/src/redhat/BUILD/gq-0.7.0beta2/src'
> > make[1]: *** [all-recursive] Error 1
> > make[1]: Leaving directory `/usr/src/redhat/BUILD/gq-0.7.0beta2'
> > make: *** [all] Error 2
> 
> Hmmmm, if you did a d/l of the normal distro, used a langpack
> and then did
> 
>    ./configure; make
> 
> Then I think the attached patch should help. It is a patch to the
> langpack, thus apply it within the extracted langpack directory.

I didn't use a GQ langpack nor did I install any 'additional languages'
in my RedHat 8.0. Only US English, which is the default.
The box uses autoconf 2.53 and automake 1.6.3 and I do the usual
./configure ; make. Do I miss something obvious?

Simon

> 
> Gee, I only hope that most "touch" commands recognize the "-r" switch,
> SUSv2 mentions that option...
> 
> peter
> 
>   ------------------------------------------------------------------------
>                      Name: langpack-patch
>    langpack-patch    Type: Plain Text (TEXT/PLAIN)
>                  Encoding: BASE64

On Mon, 14 Oct 2002, Simon Matter wrote:

> Date: Mon, 14 Oct 2002 13:12:06 +0200
> From: Simon Matter <sim...@ch...>
> To: gqclient-discuss <gqc...@li...>
> Subject: [Gqclient-discuss] compiling GQ 0.7beta2 on RedHat 8.0
>
> Hi,
>
> I have just tried to compile GQ 0.7beta2 on a RedHat 8.0 box with no
> success. I guess it's a automake/autoconf issue.
>
> make[2]: Leaving directory `/usr/src/redhat/BUILD/gq-0.7.0beta2/intl'
> make[2]: Entering directory `/usr/src/redhat/BUILD/gq-0.7.0beta2/intl'
> make[2]: Nothing to be done for `all'.
> make[2]: Leaving directory `/usr/src/redhat/BUILD/gq-0.7.0beta2/intl'
> Making all in src
> make[2]: Entering directory `/usr/src/redhat/BUILD/gq-0.7.0beta2/src'
> cd .. && automake --gnu --include-deps src/Makefile
> src/Makefile.am: required file `./depcomp' not found
> make[2]: *** [Makefile.in] Error 1
> make[2]: Leaving directory `/usr/src/redhat/BUILD/gq-0.7.0beta2/src'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/usr/src/redhat/BUILD/gq-0.7.0beta2'
> make: *** [all] Error 2


Hmmmm, if you did a d/l of the normal distro, used a langpack
and then did

   ./configure; make

Then I think the attached patch should help. It is a patch to the
langpack, thus apply it within the extracted langpack directory.

Gee, I only hope that most "touch" commands recognize the "-r" switch,
SUSv2 mentions that option...

peter

Hi,

I have just tried to compile GQ 0.7beta2 on a RedHat 8.0 box with no
success. I guess it's a automake/autoconf issue.

make[2]: Leaving directory `/usr/src/redhat/BUILD/gq-0.7.0beta2/intl'
make[2]: Entering directory `/usr/src/redhat/BUILD/gq-0.7.0beta2/intl'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/usr/src/redhat/BUILD/gq-0.7.0beta2/intl'
Making all in src
make[2]: Entering directory `/usr/src/redhat/BUILD/gq-0.7.0beta2/src'
cd .. && automake --gnu --include-deps src/Makefile
src/Makefile.am: required file `./depcomp' not found
make[2]: *** [Makefile.in] Error 1
make[2]: Leaving directory `/usr/src/redhat/BUILD/gq-0.7.0beta2/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/redhat/BUILD/gq-0.7.0beta2'
make: *** [all] Error 2

TIA
Simon

Compiled and ran without any problems on FreeBDS!

-- 
Dave Horsfall  DTM  VK2KFU  da...@ci...  Ph: +61 2 9906-4333

Dear members of the Gqclient-discuss mailing list:

I have just released the second beta version of the upcoming gq 0.7.0.
Please download and test the thing.

Thanks go to all the testers who have provided feedback for the last beta
release.

I would like to point your attention to the introduction of the language
pack distribution found along with the gq source code. In order to have
localized messages for german, czech (limited, translation was provided
for 0.6.0) or japanese you will have to download a langpack and follow the
instructions in the README.langpack file.

For those wishing to build an RPM, it might be as simple as:

  * download gq-0.7.0beta2.tar.gz
  * download gq-0.7.0beta2-langpack-0.tar.gz
  * run
      rpm -ta gq-0.7.0beta2.tar.gz


If all goes well, I plan to release a final version of 0.7.0 in 1-2 weeks
time. If any serious issues arise another beta release might be released
instead.

I would also like to kindly ask any translators who have provided
translations to update their translations to catch to the the latest
messages...

Please note that the langpack distribution has been made independent of
the main source distribution to allow for out-of-sync releases of
translated messages. The system would also allow for different translators
to release language packs themselves.

peter

On Fri, 11 Oct 2002, Dave Horsfall wrote:

> Date: Fri, 11 Oct 2002 13:04:04 +1000 (EST)
> From: Dave Horsfall <da...@ci...>
> To: GC Client Discussion List <Gqc...@li...>
> Subject: Re: [Gqclient-discuss] 0.7.0beta1 - Status
>
> On Thu, 10 Oct 2002, Peter Stamfest wrote:
>
> > > But checking with a Linux box in captivity here (Mandrake 8.0) I see
> > > this:
> > >
> > > # ifdef __USE_BSD
> > >   long int tm_gmtoff;           /* Seconds east of UTC.  */
> > >   __const char *tm_zone;        /* Timezone abbreviation.  */
> > > # else
> > >   long int __tm_gmtoff;         /* Seconds east of UTC.  */
> > >   __const char *__tm_zone;      /* Timezone abbreviation.  */
> > > # endif
> > >
> > > So they're in the right place, but different names; what an awful mess!
> >
> > It all cries for addditional configure checks...
>
> I have access to Linux/OpenBSD/FreeBSD/BSDI/Solaris, so I'll try and find
> time to do this, unless someone else wants to...

I forgot to add the __tm_gmtoff case in the configure checks... Compiling
on different platforms would be great. I do have access to the SF compile
farm, but those machines miss most prerequisite software needed for gq.

peter

On Fri, 11 Oct 2002, Dave Horsfall wrote:

> Date: Fri, 11 Oct 2002 13:12:32 +1000 (EST)
> From: Dave Horsfall <da...@ci...>
> To: GC Client Discussion List <Gqc...@li...>
> Subject: Re: [Gqclient-discuss] 0.7.0beta1 - Status
>
> On Thu, 10 Oct 2002, Peter Stamfest wrote:
>
> > Thanks as well, you see, my keyboard is, well, funky. Some keys do have
> > there problems (you may find some ddouble-d-s [see] lately in my posts, as
> > well as s-problems, v-problems, ...) I am looking for a supply of those
> > old IBM keyboards you could use to kill somebody because of their weight.
> > NB: My keyboard is dated Dec-1994 with a (c) date of 1984!!!
>
> Yes, I know the keyboards you mean!  A nice positive action, so you
> knew whether a key was pressed or not.  Bit rough on the ears, though.

People are always impressed if we talk on the phone and I happen to type
away on the keyboard...

> Another suggestion: now that passwords are encoded, there's no need for
> that pop-up that asks "Do you want to store your bind password as
> clear text?".

No, this is not true. Passwords are encoded, not encrypted. Ie. they are
available in cleartext-equivalent form:

Thus if one really forgets a password (or gets hold of somebody else's .gq
file) one can always do the following:

Lookup bindpw and pw-encoding:

        <bindpw>c2VjcmV0</bindpw>
        <pw-encoding>Base64</pw-encoding>

In case of "Base64" (the only known encoding at this time):

	echo c2VjcmV0 | mimencode -u     # prints "secret"

(mimencode taken from the metamail package). The reason for this is that
to bind to an LDAP server we need the password in its original, cleartext,
form.

Encoding is done to prevent a casual observer of the password (eg. a
sysadmin digging around in backups, grepping around for something, a
co-worker casually looking on your screen when you have opened .gq in your
fav editor, whatever) of obtaining a password without actually wanting to.
This is similar to why basic authentication in HTTP encodes the password
as well - people sniffing around legally should not see passwords without
wanting to.

The reason for the existance of <pw-encoding> is the anticipation of a
possible "master password" used to encode/decode a <bindpw> using a
symmetric cipher. This would have to be entered immediately after program
start. OTOH: maybe it would be better to encrypt the entire .gq config
file then, as there is other sensitive information in there, like the
binddn, the hostname/LDAP URI and possibly others. But such a decision has
not yet been made.

BTW: What do people think about such an (optional) master-password?

peter

On Thu, 10 Oct 2002, Peter Stamfest wrote:

> Thanks as well, you see, my keyboard is, well, funky. Some keys do have
> there problems (you may find some ddouble-d-s [see] lately in my posts, as
> well as s-problems, v-problems, ...) I am looking for a supply of those
> old IBM keyboards you could use to kill somebody because of their weight.
> NB: My keyboard is dated Dec-1994 with a (c) date of 1984!!!

Yes, I know the keyboards you mean!  A nice positive action, so you
knew whether a key was pressed or not.  Bit rough on the ears, though.

Another suggestion: now that passwords are encoded, there's no need for
that pop-up that asks "Do you want to store your bind password as
clear text?".

-- 
Dave Horsfall  DTM  VK2KFU  da...@ci...  Ph: +61 2 9906-4333

On Thu, 10 Oct 2002, Peter Stamfest wrote:

> > But checking with a Linux box in captivity here (Mandrake 8.0) I see
> > this:
> >
> > # ifdef __USE_BSD
> >   long int tm_gmtoff;           /* Seconds east of UTC.  */
> >   __const char *tm_zone;        /* Timezone abbreviation.  */
> > # else
> >   long int __tm_gmtoff;         /* Seconds east of UTC.  */
> >   __const char *__tm_zone;      /* Timezone abbreviation.  */
> > # endif
> >
> > So they're in the right place, but different names; what an awful mess!
>
> It all cries for addditional configure checks...

I have access to Linux/OpenBSD/FreeBSD/BSDI/Solaris, so I'll try and find
time to do this, unless someone else wants to...

[ timezone ]

> It has nothing to do with gtk, it is only used to get the GMT Offset
> correct in generalizedTime values for where the user is located. This is
> to allow for local time in time stamps and the correct timezone. Ie. it is
> trivial to convert between generalizedTime and, say, a unix timestamp, as
> the offset is always known. Most people probably do not really care about
> this, unless they are located in organizations spanning multiple
> timezones...

Thanks.

-- 
Dave Horsfall  DTM  VK2KFU  da...@ci...  Ph: +61 2 9906-4333

On Thu, 10 Oct 2002, Dave Horsfall wrote:

> Date: Thu, 10 Oct 2002 11:47:00 +1000 (EST)
> From: Dave Horsfall <da...@ci...>
> To: GC Client Discussion List <Gqc...@li...>
> Subject: Re: [Gqclient-discuss] 0.7.0beta1 - Status
>
> On Wed, 9 Oct 2002, Peter Stamfest wrote:
>
> > Note that timezone is not used as a function but as a variable. Yes, it is
> > a global variable. It is documented in ctime(3). I guess it should
> > actually be extern time_t timezone, but I do not have the POSIX
> > or any other standard around to double-check.
>
> I just checked; timezone() (in BSD systems) is there for backwards
> compatibility.  I have no idea where timezone (the variable) came
> from.
>
> Actually, I do remember: it's really really old...  I recall being
> disgusted when it was defined as minutes WEST of GMT (obviously the
> Americans didn't want to be negative).
>
> > Do you have compilation problems due to this?
>
> Well, yes; it doesn't compile :-(


Could you try the attached patch? It adds a configure check and should use
tm_gmtoff now. Could you try if the code finds the correct offset for a
generalizedTime? Hm, having said this I suddenly realize that I use
generalizedTime only in my own objectClasses, so you cannot even test
it.... arghh -> Introduced trouble for others for my personal benefit...,
but maybe this pushes the use of generalizedTime, who knows....

But in case you have the time to test this, I have also attached a schema
using generalizedTime for some things. I use it for LDAP based vacation
messages.... The OID space I use is allocated to me, so don't fear that it
interferes with existing stuff.

If others could test this as well, I would be happy. It also changes the
way I18N is tested for, as I realized that there might be problems
regarding I18N, especially on old and un-GNU-ish systems. Now configure
should fail and suggest to use some options if compilation is unlikely to
work due to I18N issues...



peter

On Thu, 10 Oct 2002, Dave Horsfall wrote:

> Date: Thu, 10 Oct 2002 12:41:41 +1000 (EST)
> From: Dave Horsfall <da...@ci...>
> To: GC Client Discussion List <Gqc...@li...>
> Subject: Re: [Gqclient-discuss] 0.7.0beta1 - Status
>
> Found another problem (after kludging the timezone stuff):
>
> browse-dnd.c: In function `drag_begin':
> browse-dnd.c:306: `ulong' undeclared (first use in this function)
> browse-dnd.c:306: (Each undeclared identifier is reported only once
> browse-dnd.c:306: for each function it appears in.)
>
> BSD systems use u_long.

I just did the equivalent to s/ulong/unsigned long/g... thanks.

>
> And a quick spelling correction (just noticed it): in configfile.c, the
> popup box should be "latest", not "lastest".

Thanks as well, you see, my keyboard is, well, funky. Some keys do have
there problems (you may find some ddouble-d-s [see] lately in my posts, as
well as s-problems, v-problems, ...) I am looking for a supply of those
old IBM keyboards you could use to kill somebody because of their weight.
NB: My keyboard is dated Dec-1994 with a (c) date of 1984!!!

'nuf said - fixed

peter

_________________________________________________________________________
Dipl.-Ing. Peter Stamfest         UNIX, Networking & Computing Consultant
Tel: +43/699/10711205             Software Development - Internetservices
E-Mail: pe...@st...

On Thu, 10 Oct 2002, Dave Horsfall wrote:

> Date: Thu, 10 Oct 2002 11:47:00 +1000 (EST)
> From: Dave Horsfall <da...@ci...>
> To: GC Client Discussion List <Gqc...@li...>
> Subject: Re: [Gqclient-discuss] 0.7.0beta1 - Status
>
> On Wed, 9 Oct 2002, Peter Stamfest wrote:
>
> > Note that timezone is not used as a function but as a variable. Yes, it is
> > a global variable. It is documented in ctime(3). I guess it should
> > actually be extern time_t timezone, but I do not have the POSIX
> > or any other standard around to double-check.
>
> I just checked; timezone() (in BSD systems) is there for backwards
> compatibility.  I have no idea where timezone (the variable) came
> from.
>
> Actually, I do remember: it's really really old...  I recall being
> disgusted when it was defined as minutes WEST of GMT (obviously the
> Americans didn't want to be negative).
>
> > Do you have compilation problems due to this?
>
> Well, yes; it doesn't compile :-(
>
> dt_time.c: In function `dt_time_edit_window':
> dt_time.c:237: `timezone' redeclared as different kind of symbol
> /usr/include/time.h:144: previous declaration of `timezone'
>
> >        extern char *tzname[2];
> >        long int timezone;
> >        extern int daylight;
>
> The "tm" structure in time.h (in BSD) has an extra two fields:
>
>         long    tm_gmtoff;      /* offset from CUT in seconds */
>         char    *tm_zone;       /* timezone abbreviation */
>
> But checking with a Linux box in captivity here (Mandrake 8.0) I see
> this:
>
> # ifdef __USE_BSD
>   long int tm_gmtoff;           /* Seconds east of UTC.  */
>   __const char *tm_zone;        /* Timezone abbreviation.  */
> # else
>   long int __tm_gmtoff;         /* Seconds east of UTC.  */
>   __const char *__tm_zone;      /* Timezone abbreviation.  */
> # endif
>
> So they're in the right place, but different names; what an awful mess!

It all cries for addditional configure checks...

>
> > > Just found the answer - it's a Linux-ism...
> >
> > Well, not quite, if this statement is correct:
> >
> > ... I think that the problem is 'timezone' (which is part of the X/Open
> > standard, but neither ISO C nor POSIX)....
> >
> > Is there a POSIX solution to this? I do not like to use global variables
> > like this anyway...
>
> Not being familiar with GTK, I can't see how you are using timezone.
> I just checked a Solaris 8 box, and it uses timezone as a variable as
> well, so it looks like later BSD systems are different :-(
>

It has nothing to do with gtk, it is only used to get the GMT Offset
correct in generalizedTime values for where the user is located. This is
to allow for local time in time stamps and the correct timezone. Ie. it is
trivial to convert between generalizedTime and, say, a unix timestamp, as
the offset is always known. Most people probably do not really care about
this, unless they are located in organizations spanning multiple
timezones...

peter

Found another problem (after kludging the timezone stuff):

browse-dnd.c: In function `drag_begin':
browse-dnd.c:306: `ulong' undeclared (first use in this function)
browse-dnd.c:306: (Each undeclared identifier is reported only once
browse-dnd.c:306: for each function it appears in.)

BSD systems use u_long.

And a quick spelling correction (just noticed it): in configfile.c, the
popup box should be "latest", not "lastest".

Hmmm...  Looks very nice!

-- 
Dave Horsfall  DTM  VK2KFU  da...@ci...  Ph: +61 2 9906-4333

On Wed, 9 Oct 2002, Peter Stamfest wrote:

> Note that timezone is not used as a function but as a variable. Yes, it is
> a global variable. It is documented in ctime(3). I guess it should
> actually be extern time_t timezone, but I do not have the POSIX
> or any other standard around to double-check.

I just checked; timezone() (in BSD systems) is there for backwards
compatibility.  I have no idea where timezone (the variable) came
from.

Actually, I do remember: it's really really old...  I recall being
disgusted when it was defined as minutes WEST of GMT (obviously the
Americans didn't want to be negative).

> Do you have compilation problems due to this?

Well, yes; it doesn't compile :-(

dt_time.c: In function `dt_time_edit_window':
dt_time.c:237: `timezone' redeclared as different kind of symbol
/usr/include/time.h:144: previous declaration of `timezone'

>        extern char *tzname[2];
>        long int timezone;
>        extern int daylight;

The "tm" structure in time.h (in BSD) has an extra two fields:

        long    tm_gmtoff;      /* offset from CUT in seconds */
        char    *tm_zone;       /* timezone abbreviation */

But checking with a Linux box in captivity here (Mandrake 8.0) I see
this:

# ifdef __USE_BSD
  long int tm_gmtoff;           /* Seconds east of UTC.  */
  __const char *tm_zone;        /* Timezone abbreviation.  */
# else
  long int __tm_gmtoff;         /* Seconds east of UTC.  */
  __const char *__tm_zone;      /* Timezone abbreviation.  */
# endif

So they're in the right place, but different names; what an awful mess!

> > Just found the answer - it's a Linux-ism...
>
> Well, not quite, if this statement is correct:
>
> ... I think that the problem is 'timezone' (which is part of the X/Open
> standard, but neither ISO C nor POSIX)....
>
> Is there a POSIX solution to this? I do not like to use global variables
> like this anyway...

Not being familiar with GTK, I can't see how you are using timezone.
I just checked a Solaris 8 box, and it uses timezone as a variable as
well, so it looks like later BSD systems are different :-(

-- 
Dave Horsfall  DTM  VK2KFU  da...@ci...  Ph: +61 2 9906-4333

On Wed, 9 Oct 2002, Emil Assarsson wrote:

> Date: Wed, 09 Oct 2002 20:33:12 +0200
> From: Emil Assarsson <emi...@bo...>
> To: gqc...@li...
> Subject: [Gqclient-discuss] password display type?
>
> Hi...
> I'm not sure but didn't version 0.6 hade some kind of password display
> type?
> and if so were did that brilliant feature go in version 0.7?

It still has, it consists of a text entry box and a list of hash
algorithms to choose from. Maybe you are using a server without schema
information... All in all this is strange, as not much has changed there.

peter

On Wed, 9 Oct 2002, Emil Assarsson wrote:

> Date: Wed, 09 Oct 2002 19:57:52 +0200
> From: Emil Assarsson <emi...@bo...>
> To: gqc...@li...
> Subject: [Gqclient-discuss] Basic template creation (and editor for
>     classes?)
>
> Hi!
> I have an  idee aboute the template creation. I could be nice if there
> was an automatic adding of required superior classes. Maybe even
> Automatic nameing for "straight" templates like "inetOrgPerson" and such.

That sounds good, suppose there is a "default" template called "top". Use
this to create a "naked" object, then use the objectClass
addition mechanism to add an objectclass, and get "intermediate"
objectclasses added automatically. Sounds good... nice feature. Actually I
thought about the automatic addition of missing objectClasses, but somehow
the possibilities escaped me.... well...

>
> Another thing is creation/edit interface for classes, attributes (and
> syntax?) ... but I believe that this will be a server dependent editor.
> Is it possible the add new classes, attributes and syntax via the
> protocol (LDAPv3)?

Bert already put this into the TODO list ages ago (CVS shows changes to
the line on Sept 24, 2000):

  * schema designer (when OpenLDAP supports writable schema)

I have to admit that I haven't looked into it. I doubt I will in the near
future, as designing a schema is a rather rare thing to do, and I would
rather like to concentrate my energy on the rest of the program first.

But, as always, patches are very welcome...

peter

On Wed, 9 Oct 2002, Emil Assarsson wrote:

> Date: Wed, 09 Oct 2002 19:40:37 +0200
> From: Emil Assarsson <emi...@bo...>
> To: gqc...@li...
> Subject: [Gqclient-discuss] Browser search behavior under pressure
>
> Hi!
> I noticed a little strange behavior in the browser. I made a stress test
> with more than 4000 sub objects under one object. When I then tried to
> open this, I pressed a few times to open it when it took some time (a
> natural behavior for a windows user ;-). It reloaded it as many times as
> I pressed the plus-box. I am not sure what should be the correct
> behavior but my suggestion is:
> If you press the same plus-box two times in row: cancel the search and
> print "Search canceled" in the statusbar.
> If you press different buttons: open all.
> ... but I can live with the current behavior.

You'll have to ;-)

Unfortunatly gq does its LDAP operations synchronously wrt the GUI, thus
we have no notion of interrupting a running operation... Though I see a
remote possibility to actually do this using nested gtk main loops....

peter

Hi...
I'm not sure but didn't version 0.6 hade some kind of password display 
type?
and if so were did that brilliant feature go in version 0.7?

--
Emil Assarsson

Hi!
I have an  idee aboute the template creation. I could be nice if there 
was an automatic adding of required superior classes. Maybe even 
Automatic nameing for "straight" templates like "inetOrgPerson" and such.

Another thing is creation/edit interface for classes, attributes (and 
syntax?) ... but I believe that this will be a server dependent editor.
Is it possible the add new classes, attributes and syntax via the 
protocol (LDAPv3)?

--
Emil Assarsson

Hi!
I noticed a little strange behavior in the browser. I made a stress test 
with more than 4000 sub objects under one object. When I then tried to 
open this, I pressed a few times to open it when it took some time (a 
natural behavior for a windows user ;-). It reloaded it as many times as 
I pressed the plus-box. I am not sure what should be the correct 
behavior but my suggestion is:
If you press the same plus-box two times in row: cancel the search and 
print "Search canceled" in the statusbar.
If you press different buttons: open all.
... but I can live with the current behavior.

GQ rules!

-- 
Emil Assarsson

Peter Stamfest schrieb:
> 
> On Tue, 8 Oct 2002, Simon Matter wrote:
> 
> > Date: Tue, 08 Oct 2002 08:49:18 +0200
> > From: Simon Matter <sim...@ch...>
> > To: Peter Stamfest <pe...@st...>
> > Cc: Gqc...@li...
> > Subject: Re: [Gqclient-discuss] 0.7.0beta1 - Status
> >
> > Peter Stamfest schrieb:
> > >
> > > Hello out there,
> > >
> > > Though it is a great situation, it feels strange that I haven't received a
> > > single bug report and/or comment regarding 0.7.0beta1! This allows for a
> > > couple of explanations: ;-)
> > >
> > > 1a) It is bugfree
> > > 1b) It is perfect
> > > 2) There are bugs, but they haven't be reported.
> > > 3) Nobody tried it.
> > > 4) It is a lousy version nobody even cares to try.
> > >
> > > As causes 2-4 are very unlikely, it must be 1a and 1b!! ;-)
> >
> > You're right :)
> >
> > To be honest, I didn't use 0.7.0beta1 too much so I didn't find a bug.
> > But what I found I liked, the new color scheme, the ability to show
> > internal data like modification timestamps and the option to remove all
> > unused attributes from a view. I have tested it on RedHat 7.2 and the
> > new 8.0. I just found out that the new RedHat 8.0 doesn't include GQ
> 
> I also found out it was no longer included, well, I think I have to
> contact them directly, could be that they simply missed the last
> updates... Have you checked if they have _any_ LDAP browsing tool
> included?

Seems there is no tool included. This is also what the 'Reference Guide'
says. The only thing they mention in the docs is the Java LDAP
Browser/Editor from http://www.iit.edu/~gawojar/ldap/ which is not
included too.
I posted to RedHat bugzilla about the missing GQ package. I really don't
understand their decision.

> 
> > anymore! Don't know what happened there, but I took the step forward and
> > created a 0.7.0beta1 RPM package which build and is tested on RedHat 7.2
> > and 8.0. Everybody interested can find it here:
> >
> > http://home.teleport.ch/simix/RPMS/GQ/
> >
> 
> Additionally, I would like to point out that a SPEC file is included in
> the source distribution. It still has some issues, though (especially on
> older systems).

I found the included .spec when I looked at the tarball yesterday. My
problem with those 'embedded' spec files is that I'm not able to make my
own changes and include them in the tarball again - sort of chicken/egg
problem.

> 
> > May I use this opportunity to thank everybody involved in development of
> > GQ.
> > Keep up the good work!
> 
> Thank you very much!
> 
> peter
>