[gpm]Re: new release: gpm-1.19.5

[Nico Schottelius]

> >> * After running ./configure in the "make" it re-runs autoconf and configure.
> >>         autoconf may be not installed in the user's computer.
> >
> > hmm...maybe it's just too late in the night, but
> > on my system I ./configure was not rerun by make.
>
> Hmm... on a fresh untar it does.

yeah. I rechecked it, you are right.

> Unfortunately you need to check the
> tar before uploading.

That's right. Unfortuanetly I did, but I must have overseen the autocnf,
maybe I have been in the wrong tree.

> It's one of the boring tasks in being a maintainer.

yes.

> See, you didn't run autoconf before tarring.

You are right!

> Maybe you miss a good "make distrib" rule.

Actually, I am doing the archives 'by hand' currently.


> It was there (note that it used the MANIFEST file, which is no longer valid but
> still there and unused).

you are right. I may use it later.  But currently I don't need make distrib nor
MANIFEST.

> > I wanted to seperate 'real' sources from other stuff, so I moved it
> > to contrib. I did not mean to move it outside gpm,
>
> Yes. But the src rules should not make t-mouse.elc

this was a bug, for sure. It's away in the next release.

> >> * The various "ex_tex" etc stuff is bugged, comparison always fails
> >>         (no $$ in Makefile)
> >
> > fixed & removed.
> > I choosed another method:
>
> maybe you just needed to have $$ex_tex instead of $ex_tex (see make docs).

Yeah, I know, but I didn't like doubled code, so I took the other method.

> >> Same for check_devfs and set_devfs, should be static into     liblow.c
> >
> > How would you fix that most elegant ?
> > #define lib_check_devfs static check_devfs  ?
>
> Oh, didn't see that they were used in two places. Mabe you can make
> them static inline in an header (gpmInt.h).

I wrote a new function st_XXX, which calls the normal variant, but is
static.

> >> * This in gpm.c:
> >>                    chmod(GPM_NODE_CTL,0700);
> >>         allows only root to connect to the server
> >
> > I included this from a security patch. There it's told that this is used for
> > security reasons. (gpm-1.19.1-secenhance.patch)
>
> What security is it if the tool doesn't work?

too much.

> Please check the source of security patches and the reason. What
> secudity bug is this fixing?

see above, it is secenhance.patch,
It was brought to us by Frederic L. W. Meunier.
He brought them to us via redhat patches collection.

> > and chown it to mouse.
> > If group mouse does not exist, use 0777,
>
> Hmm... I'm not sure, really. Anyone should connect, and them gpm must
> grant or deny permission. Do you really want mc, lynx and all gpm clients
> to be group mouse, with suid? I think not.

That's right. I will change it back to 0777.

> >> * defines.h replicates a lot of stuff from gpm.h
> >
> > I know. I partly wanted to cleanup the source.
> > At the end there will be no doubled code anymore anywhere.
>
> *please* remember that gpm.h is exported. You can't split them.
> And gpm-defines.h etc is really ugly, not clean at all.

I am thinking of the following:
Having different header files in our gpm source tree, but only export
gpm.h later. gpm.h could be generated by the other headers.
What do you think about that ?

> >> >    o new daemon name
> >> Sorry?  Didn't find it.
> >
> > Like Eastern in Germany I don't want to show you where the egg
> > is. You will find it very soon ;)
>
> Note that calling it gpmd or whatever is an incompatibility.

I won't change the binary name! Although gpmd would senseful
possibly.

> People is doing "killall -WINCH gpm" or such. Please don't add incompatibilities
>
> unless needed,

Like libc5.0/linux2.0 incompatibilities, if I really open up one, I will remove
it in the next release. I do not intend to be incompatible.

> and when they are there, please mark them in huge letters
> in the documentation and README files.

if I really need todo I will for sure mark it in the docs.

BTW, Alessandro, wherfore is TAGS used ?

Nico