lprng-devel Mailing List for LPRng

hi all,
i have reworked most man pages by now (simpler nroff, added missing
options etc). since the current version of lpstat.n is a stub here a more
complet one.

* Bernhard R. Link <br...@de...> [061221 20:00]:
> > ntl: i have a patch ready that moves the sysv and the bsd interface into
> > sperate functions. actualy i planed this typo of patches for 3.8.20
> > or should we add them now ?
> 
> What kind of changes are this? I'd rather suggest to look more at the
> feature level than at the type level. From what I read there is a myriad
> of systems somewhere between sysv and bsd making a strong seperation
> hard. And I'd rather throw out all explicit system detection code than
> adding new artifical branches.

Sorry, I think I misunderstood you. Was to much into HAVE_xyz
and _SYSTYPE_SYSV. If you mean the command line interfaces, I've no
objections at all.

Hochachtungsvoll,
	Bernhard R. Link

* Walter Harms <wh...@bf...> [061221 17:58]:
> hi list,
> here is the first version of cancel.n, the GPL man page for the cancel cmd.
> 
> while looking for the cli  i found that lprm looks for clean not for
> cancel.Did i miss somehing ?

I wrote about this at Sat, 9 Dec 2006 17:52:41 +0100
with msgid <200...@pc...>
| Looking into this I found some more strangeness:
| 
| While the cancel binary is just a symlink to lprm, lprm does not check
| it it is called as "cancel", but only checks for "clean" (which should
| be never triggered, because noone would name a copy of
| or link to lprm clean) to active different argument parsing.
| 
| That means that unless I overlooked something, cancel always behaved
| just like lprm and especially never allowed to give a printer name as
| last argument as the manpage states, which noone seems to have noticed
| ever.
| 
| My suggestion is thus to just make cancel.1 a reference to lprm.1 and
| add a note that cancel is a alias to lprm to that manpage, which I will
| do if noone objects in the next days.

> ntl: i have a patch ready that moves the sysv and the bsd interface into
> sperate functions. actualy i planed this typo of patches for 3.8.20
> or should we add them now ?

What kind of changes are this? I'd rather suggest to look more at the
feature level than at the type level. From what I read there is a myriad
of systems somewhere between sysv and bsd making a strong seperation
hard. And I'd rather throw out all explicit system detection code than
adding new artifical branches.

Hochachtungsvoll,
	Bernhard R. Link

hi list,
here is the first version of cancel.n, the GPL man page for the cancel cm=
d.

while looking for the cli  i found that lprm looks for clean not for
cancel.Did i miss somehing ?

ntl: i have a patch ready that moves the sysv and the bsd interface into
sperate functions. actualy i planed this typo of patches for 3.8.20
or should we add them now ?

re,
 wh

* Walter Harms <wh...@bf...> [061219 17:13]:
> attached is the result of a few days of work to understand the autotools.
> I have a totaly new configure.ac and a dummy Makefile.am.

I'm also working on this and have an system almost ready that at least
does the compiling already. (and without such hacks like defs.h)

> NTL:Please take a look since i have no clue if the code is now better
> maintainable.

some comments: the Makefile.am is quite overloaded. You do not need to 
define all the dirs and vars yourself, that is done my automake for you.

I'm against moving single-time tests to m4 files. (Especially when those
all are at the end, it just means one has to dive into extra files to
find out what is happening)

Hochachtungsvoll,
	Bernhard R. Link

Hi list,
attached is the result of a few days of work to understand the autotools.
I have a totaly new configure.ac and a dummy Makefile.am.

THIS IS NOT INTENDED FOR INCLUSION INTO THE CVS

NTL:Please take a look since i have no clue if the code is now better
maintainable.

hi list,
ths patch removes a bzero (the only bzero) from linksupport.c

re,
 wh

Attached patch includes even more format fixes. It's not always
easy to guess what the code was supposed to do, so please take
a look at it.

Hochachtungsvoll,
	Bernhard R. Link

hi all,
i am working on a new version of configure.in but this is far the largest
project i ever used it so it will certainly break some things therefor
i would ask for patience. we should fix know problems (e.g. man pages)
and break the rest later :)



re,
 wh

ps: for -RC1 i used tar --exclude



<zitiere wer=3D"Craig Small">
> On Wed, Dec 13, 2006 at 12:08:44PM +0100, Bernhard R. Link wrote:
>> I fear "make dist" is not yet supported at all. The dist rules are
>> still the ones from Patrick Powell and not suiteable for the general.
> How are we getting a tar file for distributing then?
>
>> (It also uses a "all-but-listed" approach as opposed to a "only-listed=
"
>>  one like automake uses, which causes spurious files showing up in
>>  every second past release of LPRng.)
> Ah, that's why those sorts of things appear.
>
>> My vote is for using automake instead (and also throwing out libtool
>> in that step, too, as I guess nothing outside of LPRng uses that
>> library).
> That's my vote too.
>
>> I'm for it better earlier than later, and also willing to put some wor=
k
>> into that. This should be the first thing to do after the first bug-fi=
x
>> release is out. (And in my option also worthy to do before, but I'm no=
t
>> insisting on it)
> It depends on how easy it is to get a tar file that is somewhat clean
> out. If it is not possible then something would need to be fixed first.
>
>  - Craig
>
> --
> Craig Small      GnuPG:1C1B D893 1418 2AF4 45EE  95CB C76C E5AC 12CA DF=
A5
> http://www.enc.com.au/                      MIEE         Debian develop=
er
> csmall at : enc.com.au                      ieee.org           debian.o=
rg
>
> -----------------------------------------------------------------------=
--
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> _______________________________________________
> Lprng-devel mailing list
> Lpr...@li...
> https://lists.sourceforge.net/lists/listinfo/lprng-devel
>
>
>

<zitiere wer=3D"Bernhard R. Link">
> I suggest we apply the attached patch at least when leaving bugfix-only
> mode after the first release. It's really ugly (and removes some really
> unneeded checks.)
>

the check add only bytes since it is not possible to filter the
myriad binary files.
the user gets what the user wants.

it is ok for me to add this to RC-2.

re,
 wh




> Hochachtungsvoll,
> 	Bernhard R. Link
> -----------------------------------------------------------------------=
--
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV_______________________________________________
> Lprng-devel mailing list
> Lpr...@li...
> https://lists.sourceforge.net/lists/listinfo/lprng-devel
>

Attched patch hopefully fixes some problems that become visible
when telling gcc to check format strings for SNPRINTF. 

Hochachtungsvoll,
	Bernhard R. Link

I suggest we apply the attached patch at least when leaving bugfix-only
mode after the first release. It's really ugly (and removes some really
unneeded checks.)

Hochachtungsvoll,
	Bernhard R. Link

On Wed, Dec 13, 2006 at 12:08:44PM +0100, Bernhard R. Link wrote:
> I fear "make dist" is not yet supported at all. The dist rules are
> still the ones from Patrick Powell and not suiteable for the general.
How are we getting a tar file for distributing then?

> (It also uses a "all-but-listed" approach as opposed to a "only-listed"
>  one like automake uses, which causes spurious files showing up in
>  every second past release of LPRng.)
Ah, that's why those sorts of things appear.

> My vote is for using automake instead (and also throwing out libtool
> in that step, too, as I guess nothing outside of LPRng uses that library).
That's my vote too.

> I'm for it better earlier than later, and also willing to put some work
> into that. This should be the first thing to do after the first bug-fix
> release is out. (And in my option also worthy to do before, but I'm not
> insisting on it)
It depends on how easy it is to get a tar file that is somewhat clean
out. If it is not possible then something would need to be fixed first.

 - Craig

-- 
Craig Small      GnuPG:1C1B D893 1418 2AF4 45EE  95CB C76C E5AC 12CA DFA5
http://www.enc.com.au/                      MIEE         Debian developer
csmall at : enc.com.au                      ieee.org           debian.org

hi all,
the announce it out
i hope some people will show up on this ml.
can someone please take a look at the forums ?

i will be offline for some xmas.

re,
 wh

* Craig Small <csm...@en...> [061212 22:36]:
> CREATE_CONFIGURE fails for me, it cannot find install-sh
> I copyed an autogen.sh and it works to a point, but then dies here:

I'd suggest trying to copy in an install-sh from somewhere else
and run CREATE_CONFIGURE. That also generates all that gettext stuff.

> make dist fails, this is rather important!

I fear "make dist" is not yet supported at all. The dist rules are
still the ones from Patrick Powell and not suiteable for the general.
(It also uses a "all-but-listed" approach as opposed to a "only-listed"
 one like automake uses, which causes spurious files showing up in
 every second past release of LPRng.)

My vote is for using automake instead (and also throwing out libtool
in that step, too, as I guess nothing outside of LPRng uses that library).
That would give a general modernisation and also give a reliably
working dist rule.
I guess that this is less work than writing a proper dist rule ourself
(and cleaning up all those clean rules and so on).

I'm for it better earlier than later, and also willing to put some work
into that. This should be the first thing to do after the first bug-fix
release is out. (And in my option also worthy to do before, but I'm not
insisting on it)

Hochachtungsvoll,
	Bernhard R. Link

hi craig,
i copied the missing install-sh and mkinstalldirs into the directory
and it works for me.
the po/Makefile.in.in is perhaps caused by make3.81, can you please check your make
version.



Craig Small wrote:
> On Wed, Dec 13, 2006 at 08:22:50AM +1100, Craig Small wrote:
>> Or mention it in INSTALL. "make dist" should have all the right things.
> 
> Actually the auto* that are in there are very very old and, well just
> plain evil.
> 
> CREATE_CONFIGURE fails for me, it cannot find install-sh
> I copyed an autogen.sh and it works to a point, but then dies here:
> 
> config.status: error: cannot find input file: po/Makefile.in.in
> so it sounds like gettext has not been correctly setup.
> running gettextize works ok.
> 
> make dist fails, this is rather important!
> $ make dist
> rm -f src/include/license.h src/include/copyright.h
> sed -e 's/"/\\"/g' -e 's/.*/"&",/' LICENSE >src/include/license.h
> sed -e 's/"/\\"/g' -e 's/.*/"&",/' COPYRIGHT >src/include/copyright.h
> for i in VERSION ./src/include/patchlevel.h configure.in ; do \
>                 rcs -l $i; chmod +w $i; \
>         done;
> /bin/sh: -c: line 1: syntax error: unexpected end of file
> /bin/sh: line 1:        rcs -l $i; chmod +w $i; \: command not found
> /bin/sh: line 2: done;: command not found
> make: *** [update] Error 127
> 

	this is a basic problem. i do not see any need for rcs here
	(nor do you since it is not installed).


> OK, so can we hack this together so this stuff works, then after
> this release can I work on all these auto* things so they actually
> work correctly?
> 
> Maybe bring them up to something approaching the modern way of doing it
> too.


	yep, i realy would like it to do. the book is ready but i see
	that lprng is a quit big project to start with. my job is eating
	my time theses days but i will go into xmas holidays tomorrow and
	will but some bug fixes online. i discussed with brl and found the
	idea of a release candidate very nice.
	soon i figured out how i will upload an release candidate into sf
	and do some PR stuff. perhaps we can attract some new developers
	with beginning of the next year there will be a RC2 hopefully with
	all the autostuff included.
	(and some cleanup patches that i have done for the commands).
	

	btw: craig, i had the impression for the last discussion that you
	can provide a new cancel.n ? brl thinks otherwise. can you please
	say something if you are working on a new man page  ?

	
	re
	wh



> 
>  - Craig

On Wed, Dec 13, 2006 at 08:22:50AM +1100, Craig Small wrote:
> Or mention it in INSTALL. "make dist" should have all the right things.

Actually the auto* that are in there are very very old and, well just
plain evil.

CREATE_CONFIGURE fails for me, it cannot find install-sh
I copyed an autogen.sh and it works to a point, but then dies here:

config.status: error: cannot find input file: po/Makefile.in.in
so it sounds like gettext has not been correctly setup.
running gettextize works ok.

make dist fails, this is rather important!
$ make dist
rm -f src/include/license.h src/include/copyright.h
sed -e 's/"/\\"/g' -e 's/.*/"&",/' LICENSE >src/include/license.h
sed -e 's/"/\\"/g' -e 's/.*/"&",/' COPYRIGHT >src/include/copyright.h
for i in VERSION ./src/include/patchlevel.h configure.in ; do \
                rcs -l $i; chmod +w $i; \
        done;
/bin/sh: -c: line 1: syntax error: unexpected end of file
/bin/sh: line 1:        rcs -l $i; chmod +w $i; \: command not found
/bin/sh: line 2: done;: command not found
make: *** [update] Error 127

OK, so can we hack this together so this stuff works, then after
this release can I work on all these auto* things so they actually
work correctly?

Maybe bring them up to something approaching the modern way of doing it
too.

 - Craig
-- 
Craig Small      GnuPG:1C1B D893 1418 2AF4 45EE  95CB C76C E5AC 12CA DFA5
http://www.enc.com.au/                      MIEE         Debian developer
csmall at : enc.com.au                      ieee.org           debian.org

On Tue, Dec 12, 2006 at 05:58:45PM +0100, Bernhard R. Link wrote:
> There already was a CREATE_CONFIGURE script in it, so I changed
> that to work for me.
> 
> I first overlooked it, too, as the name is quite uncommon. Perhaps
> we should rename it, or make a autogen.sh that just calls
> ./CREATE_CONFIGURE

Or mention it in INSTALL. "make dist" should have all the right things.

 - Craig
-- 
Craig Small      GnuPG:1C1B D893 1418 2AF4 45EE  95CB C76C E5AC 12CA DFA5
http://www.enc.com.au/                      MIEE         Debian developer
csmall at : enc.com.au                      ieee.org           debian.org

* Craig Small <csm...@en...> [061212 06:46]:
> Could someone build up an autogen.sh file so it is possible to 
> correctly build lprng from CVS?  I can manually run the auto*
> commands but it better to have it scripted so the right flags
> are used.

There already was a CREATE_CONFIGURE script in it, so I changed
that to work for me.

I first overlooked it, too, as the name is quite uncommon. Perhaps
we should rename it, or make a autogen.sh that just calls
./CREATE_CONFIGURE

Hochachtungsvoll,
	Bernhard R. Link

hi craig,
i tried to fix a some problems in configure.in but i must admit
that i have no real clue what is going on.

my target today is to have a release candidate out so we can check out
while xmas for more nasty bugs.

do you have any idea about autoconf ?

re,
 wh

Craig Small wrote:
> Could someone build up an autogen.sh file so it is possible to 
> correctly build lprng from CVS?  I can manually run the auto*
> commands but it better to have it scripted so the right flags
> are used.
> 
>  - Craig

Could someone build up an autogen.sh file so it is possible to 
correctly build lprng from CVS?  I can manually run the auto*
commands but it better to have it scripted so the right flags
are used.

 - Craig
-- 
Craig Small      GnuPG:1C1B D893 1418 2AF4 45EE  95CB C76C E5AC 12CA DFA5
http://www.enc.com.au/                      MIEE         Debian developer
csmall at : enc.com.au                      ieee.org           debian.org

* Bernhard R. Link <br...@de...> [061204 12:01]:
>> As cancel, lp and lpstat are the only files with AT&T,
>> Sun and X/Open listed, that looks somehow strange.
>> It also has the old problem of no permissions in the file,
>> so finding out what real permissions it has might be a bit
>> complicated. If it was just copied from somewhere else, we
>> most likely have to remove them and rewrite.
>>
>> I'll dive through the old archives to find out when they were
>> added for hints of their origin and actual licence...

This looks stranger and stranger the more I look at it. Those three
files were added later and I cannot find any similar text with google
anywhere.

As I doubt the corporations mentioned would have relicensed anything
in those manpages left from them (which might only be this copyright
header) as dual-GPL-Artistic as LPRng is under, and the only other
free way I can imagine would be some BSD-like license which got lost,
which would still require to find this license statement to distribute
them, I'm suggesting we should rewrite those three manpages.

Looking into this I found some more strangeness:

While the cancel binary is just a symlink to lprm, lprm does not check
it it is called as "cancel", but only checks for "clean" (which should
be never triggered, because noone would name a copy of or link to lprm
clean) to active different argument parsing.

That means that unless I overlooked something, cancel always behaved
just like lprm and especially never allowed to give a printer name as
last argument as the manpage states, which noone seems to have noticed
ever.

My suggestion is thus to just make cancel.1 a reference to lprm.1 and
add a note that cancel is a alias to lprm to that manpage, which I will
do if noone objects in the next days.

Hochachtungsvoll,
	Bernhard R. Link

* walter harms <wh...@bf...> [061208 19:16]:
> 
> > 2) The new files now all seem to speak about -D in the diagnostics
> > part, but monitor for example does not seem to support -D from a quick
> > glance at the source code.
> > 
> the sentence is vailla from the original. I think it means the -D switch in
> lpd.

I've not looked at all of them, but lpr.n for example has this
paragraph, and lpr has a -D switch, but at least in monitor.n you added
that paragraph and monitor has no -D switch. (unless I mislooked in the
source)

Hochachtungsvoll,
	Bernhard R. Link

Bernhard R. Link wrote:
> * walter harms <wh...@bf...> [061207 09:29]:
>> part 1 of spellchecked and improved pages
>> (note the new contact notice)
> 
> I've some questions about those:
> 
> 1) Why do you add those \"$Id$ at the start of every manpage?
> (I guess we would have to switch keyword replacement back on
> in those files to make use of it, which I has to switch of
> to not confuse CVS about the changing id lines of the imported
> files). Do you think adding an id is usefull there? Wouldn't it
> be better to always increment the date when doing changes?
> 
$Id$ is intended for internal CVS hosekeeping.
the date in the man pages should reflect real changes. Actualy it
is only to see if you have a newer version


> 2) The new files now all seem to speak about -D in the diagnostics
> part, but monitor for example does not seem to support -D from a quick
> glance at the source code.
> 
the sentence is vailla from the original. I think it means the -D switch in
lpd.


> 3) Speaking about monitor, it seems the program is only compiled but by
> default not installed. I'd guess it might be sensible to not install the
> manpage by default either. I think we should add looking for other such
> cases to some TODO list...
> 

this is sensible to do. any idea for a switch ?




> Hochachtungsvoll,
> 	Bernhard R. Link

* walter harms <wh...@bf...> [061207 09:29]:
> part 1 of spellchecked and improved pages
> (note the new contact notice)

I've some questions about those:

1) Why do you add those \"$Id$ at the start of every manpage?
(I guess we would have to switch keyword replacement back on
in those files to make use of it, which I has to switch of
to not confuse CVS about the changing id lines of the imported
files). Do you think adding an id is usefull there? Wouldn't it
be better to always increment the date when doing changes?

2) The new files now all seem to speak about -D in the diagnostics
part, but monitor for example does not seem to support -D from a quick
glance at the source code.

3) Speaking about monitor, it seems the program is only compiled but by
default not installed. I'd guess it might be sensible to not install the
manpage by default either. I think we should add looking for other such
cases to some TODO list...

Hochachtungsvoll,
	Bernhard R. Link
-- 
"Never contain programs so few bugs, as when no debugging tools are available!"
	Niklaus Wirth