lprng-devel Mailing List for LPRng

On Mon, Jan 29, 2007 at 05:09:00PM +0100, Bernhard R. Link wrote:
> I doubt making each line something to be translated on its own is that
> feasible. Unless po file editors have problems with multi-line strings,
> I'd suggest to make that all in one item. Things might have a different
> length in different languages, and the splitting in lines is too a large
> part layout depending on those lengths.
It's actually very annoying for a translator as you are nailing stuff 
into seaprate lines.  Consider languages where the adjective comes after
the noun, and the words are split
 _("....... the big red"),
 _("house ...."),

How do they translate that? The red needs to go on the next line, the
house above it. 

I do something like
 _("..... the big red"
   "house ...."
   "...")

This puts all the text into one translation .po file "chunk" so they can
move stuff around.

 - 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

* walter harms <wh...@bf...> [070128 16:49]:
> 
> Time_str() is used only once. You can use this userinfo() to get rid of it completly.
> /* the comment is the org line remove if you get the same results */
> 
>  static void userinfo( void )
> {
>         time_t tmp;
>         time(&tmp);
> 	(void) SNPRINTF( bline, sizeof(bline)) "User:  %s@%s (%s)", login, host, bnrname);
> 	Out_line();
>         strftime(bline,sizeof(bline),"Date: %b %d %T",localtime(&tmp));
> //	(void) SNPRINTF( bline, sizeof(bline)) "Date:  %s", );
> 	Out_line();
> 	(void) SNPRINTF( bline, sizeof(bline)) "Job:   %s", job );
> 	Out_line();
> 	(void) SNPRINTF( bline, sizeof(bline)) "Class: %s", class );
> 	Out_line();
> }

applied with %H:%M:%S instead of %T

> this vars can also be static
> [...]

added

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

* walter harms <wh...@bf...> [070128 16:02]:
> +       static char *lpstat_msg[] = {
> +               N_("usage: %s [-A] [-d] [-l] [-r] [-R] [-s] [-t] [-a [list]]\n"),
> +               N_("  [-c [list]] [-f [list]] [-o [list]]\n"),
> +               N_("  [-p [list]] [-P] [-S [list]] [list]\n"),
> +               N_("  [-u [login-ID-list]] [-v [list]] [-V] [-n] [-Tdbgflags]\n"),
> +               N_(" list is a list of print queues\n"),
> +               N_(" -A        use authentication specified by AUTH environment variable\n"),
[...]

I doubt making each line something to be translated on its own is that
feasible. Unless po file editors have problems with multi-line strings,
I'd suggest to make that all in one item. Things might have a different
length in different languages, and the splitting in lines is too a large
part layout depending on those lengths.

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

hi craig,
i guess that is to much to ask for :)
at least should it now be easy to identify if it is a doku bug or a programming bug.

re,
 wh


Craig Small wrote:
> On Sun, Jan 28, 2007 at 04:10:32PM +0100, walter harms wrote:
>> this is aprt of my effort to get an idea WHAT options actualy are support
>> by WHAT type.
> 
> Woo hooo, you mean no more "I tried option X and it did nothing" bug
> reports?
> 
>  - Craig

On Sun, Jan 28, 2007 at 04:10:32PM +0100, walter harms wrote:
> this is aprt of my effort to get an idea WHAT options actualy are support
> by WHAT type.

Woo hooo, you mean no more "I tried option X and it did nothing" bug
reports?

 - 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 wrote:
> * Craig Small <csm...@en...> [070122 00:51]:
>>>> 2) configuration files
>> Config files in Debian packages would go in
>> /usr/share/doc/lprng/examples  I don't care where you put them as long
>> as I can hunt them down and put the into the directory post-install
> 
> The current package ships /etc/lprng/lpd.conf and /etc/lprng/lpd.perms
> and I'd rather not suggest to place them somewhere else.
> (lpd.conf is only comments with the defaults, lpd.perms is sane
> defaults, or perhaps can be changed a bit to be sane defaults ;-> ).
> 
	
 /etc/lprng is ok with LSB, please note that the current setup supports
also /usr/local/etc/ what is nice in cases where CUPS or else is also running.


> I think for distributions it is quite easy, as there the files can be
> just placed there and the package manager will make sure no user config
> is overwritten unasked.
> 
perhaps we should provide an RPM spec file and place an RPM packet onto sourceforge.
	

> Problem is for people installing by hand and doing a plain make install,
> where those files should not be just overwritten.
> 

if you use 'install' use option '-b' to make a backup; automaticly.	

have fun,
walter

Time_str() is used only once. You can use this userinfo() to get rid of it completly.
/* the comment is the org line remove if you get the same results */

 static void userinfo( void )
{
        time_t tmp;
        time(&tmp);
	(void) SNPRINTF( bline, sizeof(bline)) "User:  %s@%s (%s)", login, host, bnrname);
	Out_line();
        strftime(bline,sizeof(bline),"Date: %b %d %T",localtime(&tmp));
//	(void) SNPRINTF( bline, sizeof(bline)) "Date:  %s", );
	Out_line();
	(void) SNPRINTF( bline, sizeof(bline)) "Job:   %s", job );
	Out_line();
	(void) SNPRINTF( bline, sizeof(bline)) "Class: %s", class );
	Out_line();
}


this vars can also be static

static char bline[1024];
static int bigjobnumber, biglogname, bigfromhost, bigjobname;
static int top_break,	/* break lines at top of page */
	top_sep,	/* separator from info at top of page */
	bottom_sep,	/* separator from info at bottom of page */
	bottom_break;	/* break lines at bottom of page */
static int breaksize = 3;	/* numbers of rows in break */



hope that helps,

re,
 wh


Bernhard R. Link wrote:
> Attached patch changes lpbanner to not include all headers but
> only the needed ones (like lpf does) and makes all functions static.
> If noone objects, I'll apply it monday afternoon.
> 

this is aprt of my effort to get an idea WHAT options actualy are support
by WHAT type.



cleanup LPRM option, divert into SYSV style and BSD style


--- /home/walter/src/lprng-3.8.28.org/src/common/lprm.c	2004-09-24 22:19:58.000000000 +0200
+++ lprm.c	2006-12-08 21:48:02.000000000 +0100
@@ -280,17 +280,12 @@
  ***************************************************************************/

  extern char *next_opt;
- char LPRM_optstr[]   /* LPRM options */
- = "AaD:P:U:V" ;
- char CLEAN_optstr[]   /* CLEAN options */
- = "AD:" ;
+static void Get_parms_clean(int argc, char *argv[] );
+static void Get_parms_lprm(int argc, char *argv[] );

 void Get_parms(int argc, char *argv[] )
 {
-	int option;
 	char *name;
-
-
 	if( argv[0] && (Name = strrchr( argv[0], '/' )) ) {
 		++Name;
 	} else {
@@ -299,29 +294,25 @@
 	/* check to see if we simulate (poorly) the LP options */
 	if( Name && safestrcmp( Name, "clean" ) == 0 ){
 		LP_mode = 1;
-		while ((option = Getopt (argc, argv, CLEAN_optstr )) != EOF)
-		switch (option) {
-		case 'A': Auth = 1; break;
-		case 'D':
-			Parse_debug( Optarg, 1 );
-			break;
-		default: usage(); break;
-		}
-		if( Optind < argc ){
-			name = argv[argc-1];
-			Get_all_printcap_entries();
-			if( safestrcasecmp(name,ALL) ){
-				if( Find_exists_value( &All_line_list, name, Hash_value_sep ) ){
-					Set_DYN(&Printer_DYN,name);
-					argv[argc-1] = 0;
-				}
-			} else {
-				All_printers = 1;
-				Set_DYN(&Printer_DYN,"all");
-			}
-		}
-	} else {
-		while ((option = Getopt (argc, argv, LPRM_optstr )) != EOF)
+		Get_parms_clean(argc,argv);
+	}
+	else {
+		Get_parms_lprm(argc,argv);
+	}
+
+	if( Verbose ){
+		FPRINTF( STDERR, "%s\n", Version );
+		if( Verbose > 1 ) Printlist( Copyright, 1 );
+	}
+}
+
+
+static void Get_parms_lprm(int argc, char *argv[] )
+{
+	char LPRM_optstr[]   /* LPRM options */
+		= "AaD:P:U:V" ;
+	int option;
+	while ((option = Getopt (argc, argv, LPRM_optstr )) != EOF)
 		switch (option) {
 		case 'A': Auth = 1; break;
 		case 'a': All_printers = 1; Set_DYN(&Printer_DYN,"all"); break;
@@ -331,13 +322,65 @@
 		case 'P': Set_DYN(&Printer_DYN, Optarg); break;
 		default: usage(); break;
 		}
+
+}
+
+
+
+static void Get_parms_clean(int argc, char *argv[] )
+{
+	char CLEAN_optstr[]   /* CLEAN options */
+		= "AD:" ;
+	char *name;
+	int option;
+
+	while ((option = Getopt (argc, argv, CLEAN_optstr )) != EOF)
+		switch (option) {
+		case 'A': Auth = 1; break;
+		case 'D':
+			Parse_debug( Optarg, 1 );
+			break;
+		default: usage(); break;
+		}
+
+	if( Optind < argc ){
+		name = argv[argc-1];
+		Get_all_printcap_entries();
+
+		if( safestrcasecmp(name,ALL) ){
+			if( Find_exists_value( &All_line_list, name, Hash_value_sep ) ){
+				Set_DYN(&Printer_DYN,name);
+				argv[argc-1] = 0;
+			}
+		} else {
+			All_printers = 1;
+			Set_DYN(&Printer_DYN,"all");
+		}
+
 	}
-	if( Verbose ){
-		FPRINTF( STDERR, "%s\n", Version );
-		if( Verbose > 1 ) Printlist( Copyright, 1 );
+}
+
+
+
+
+
+void prmsg( char **msg )
+{
+	int i;
+	char *s;
+	for( i = 0; (s = msg[i]); ++i ){
+		if( i == 0 ){
+			FPRINTF(STDERR, _(s), Name );
+		} else {
+			FPRINTF(STDERR, "%s", _(s) );
+		}
 	}
 }

+
+void usage(void)
+{
+
  char *clean_msg[] = {
  N_(" usage: %s [-A] [-Ddebuglevel] (jobid|user|'all')* [printer]\n"),
  N_("  -A           - use authentication\n"),
@@ -371,25 +414,11 @@
  N_("  Note: lprm removes only jobs for which you have removal permission\n"),
 	0 };

-void pr_msg( char **msg )
-{
-	int i;
-	char *s;
-	for( i = 0; (s = msg[i]); ++i ){
-		if( i == 0 ){
-			FPRINTF(STDERR, _(s), Name );
-		} else {
-			FPRINTF(STDERR, "%s", _(s) );
-		}
-	}
-}

-void usage(void)
-{
 	if( !LP_mode ){
-		pr_msg(lprm_msg);
+		prmsg(lprm_msg);
 	} else {
-		pr_msg(clean_msg);
+		prmsg(clean_msg);
 	}
 	Parse_debug("=",-1);
 	FPRINTF( STDOUT, "%s\n", Version );

fix missing i18n
use std function name for usage


--- /home/walter/src/lprng-3.8.28.org/src/common/lpstat.c       2004-09-24 22:19:58.000000000 +0200
+++ lpstat.c    2006-12-24 12:48:09.000000000 +0100
@@ -71,7 +71,7 @@
  struct line_list Lpq_options;
  int Rawformat;

-#define MAX_SHORT_STATUS 6
+//#define MAX_SHORT_STATUS 6

 /***************************************************************************
  * main()
@@ -583,45 +583,61 @@
        }
 }

- static char *lpstat_msg[] = {
-       "usage: %s [-A] [-d] [-l] [-r] [-R] [-s] [-t] [-a [list]]\n",
-       "  [-c [list]] [-f [list]] [-o [list]]\n",
-       "  [-p [list]] [-P] [-S [list]] [list]\n",
-       "  [-u [login-ID-list]] [-v [list]] [-V] [-n] [-Tdbgflags]\n",
-       " list is a list of print queues\n",
-       " -A        use authentication specified by AUTH environment variable\n",
-       " -a [list] destination status *\n",
-       " -c [list] class status *\n",
-       " -d        print default destination\n",
-       " -f [list] forms status *\n",
-       " -o [list] job or printer status *\n",
-       " -n        each -n increases number of status lines (default 1) *\n",
-       " -N        maximum number of status lines *\n",
-       " -p [list] printer status *\n",
-       " -P        paper types - ignored\n",
-       " -r        scheduler status\n",
-       " -s        summary status information - short format\n",
-       " -S [list] character set - ignored\n",
-       " -t        all status information - long format\n",
-       " -u [joblist] job status information\n",
-       " -v [list] printer mapping *\n",
-       " -V        verbose mode \n",
-       " -Tdbgflags debug flags\n",
-       "    * - long status format produced\n",
-       0 };


-void usage(void)
+void prmsg( char **msg )
 {
-       char **sptr, *s;
-       for( sptr= lpstat_msg; (s = *sptr); ++sptr ){
-                       FPRINTF( STDERR, s, Name );
+       int i;
+       char *s;
+       for( i = 0; (s = msg[i]); ++i ){
+               if( i == 0 ){
+                       FPRINTF(STDERR, _(s), Name );
+               } else {
+                       FPRINTF(STDERR, "%s", _(s) );
+               }
        }
+}
+
+
+
+void usage(void)
+{
+       static char *lpstat_msg[] = {
+               N_("usage: %s [-A] [-d] [-l] [-r] [-R] [-s] [-t] [-a [list]]\n"),
+               N_("  [-c [list]] [-f [list]] [-o [list]]\n"),
+               N_("  [-p [list]] [-P] [-S [list]] [list]\n"),
+               N_("  [-u [login-ID-list]] [-v [list]] [-V] [-n] [-Tdbgflags]\n"),
+               N_(" list is a list of print queues\n"),
+               N_(" -A        use authentication specified by AUTH environment variable\n"),
+               N_(" -a [list] destination status *\n"),
+               N_(" -c [list] class status *\n"),
+               N_(" -d        print default destination\n"),
+               N_(" -f [list] forms status *\n"),
+               N_(" -o [list] job or printer status *\n"),
+               N_(" -n        each -n increases number of status lines (default 1) *\n"),
+               N_(" -N        maximum number of status lines *\n"),
+               N_(" -p [list] printer status *\n"),
+               N_(" -P        paper types - ignored\n"),
+               N_(" -r        scheduler status\n"),
+               N_(" -s        summary status information - short format\n"),
+               N_(" -S [list] character set - ignored\n"),
+               N_(" -t        all status information - long format\n"),
+               N_(" -u [joblist] job status information\n"),
+               N_(" -v [list] printer mapping *\n"),
+               N_(" -V        verbose mode \n"),
+               N_(" -Tdbgflags debug flags\n"),
+               N_("    * - long status format produced\n"),
+               0 };
+
+       prmsg(lpstat_msg);
        Parse_debug("=",-1);
        FPRINTF( STDOUT, "%s\n", Version );
        exit(1);
 }

+
+
+
 #if 0

 #include "permission.h"

Attached patch changes lpbanner to not include all headers but
only the needed ones (like lpf does) and makes all functions static.
If noone objects, I'll apply it monday afternoon.

Hochachtungsvoll,
	Bernhard R. Link

* Craig Small <csm...@en...> [070122 00:51]:
> > > 2) configuration files
> Config files in Debian packages would go in
> /usr/share/doc/lprng/examples  I don't care where you put them as long
> as I can hunt them down and put the into the directory post-install

The current package ships /etc/lprng/lpd.conf and /etc/lprng/lpd.perms
and I'd rather not suggest to place them somewhere else.
(lpd.conf is only comments with the defaults, lpd.perms is sane
defaults, or perhaps can be changed a bit to be sane defaults ;-> ).

I think for distributions it is quite easy, as there the files can be
just placed there and the package manager will make sure no user config
is overwritten unasked.

Problem is for people installing by hand and doing a plain make install,
where those files should not be just overwritten.

Hochachtungsvoll,
	Bernhard R. Link

On Thu, Jan 18, 2007 at 05:28:48PM +0100, walter harms wrote:
> > 1) making changes to the system, like moving the old print system
> >    out of the way, stopping other stuff, registering to be started
> >    at boot time, and so on.
Debian at least does this with its own scripts, the other distros
more or less do the same.

> > 2) configuration files
Config files in Debian packages would go in
/usr/share/doc/lprng/examples  I don't care where you put them as long
as I can hunt them down and put the into the directory post-install

> and other blob is the additional documentation (aka cookbook) did someone take
> a look at that ? maybe someone can generate a pdf from it ?
I'll try.

 - 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

* walter harms <wh...@bf...> [070118 17:53]:
> > 2) configuration files
> >    Currently I think the best way would be something like installing
> >    configuration files at "make install" time to their final place
> >    but with a ".example" or ".example-for-LPRng" or other suffix by
> >    default, making the suffix a make-variable, so that something
> >    like
> >    make install CONFIGSUFFIX=""
> >    would install the examples to their final place (overwriting what
> >    is there).
> >
> >    Other solutions would be an extra
> >    make install-config-examples (for installing with suffix)
> >    or
> >    make force-install-config-defaults (for overwriting what is there)
> >    to make them easily instalable but not at all in the make install.
> > 
> i would prefer a special directory. i helps to cleanup the distributed tarball
> and makes sure nobody thinks these are configfiles.
> (IMHO) the configfiles belong into a special dir. they should be simple expandable.

Sorry, I do not understand.
Special directory where? In the source? (Not feasible, as the examples
for the lpd.conf are generated with the default values in them, so to
make sure they are in sync with the binaries, they should be below the
src/ directory)
in the install? why? where?

Hochachtungsvoll,
	Bernhard R. Link

Bernhard R. Link wrote:
> * Craig Small <csm...@en...> [070118 01:53]:
>> On Mon, Jan 15, 2007 at 10:20:25PM +0100, Bernhard R. Link wrote:
>>> - think about postinstall scripts (currently everything disabled,
>>>   it just installes the programs and does nothing else)
>> Don't muck up the distribution installers by adding too much here.
> 
> I think there are two issues here:
> 
> 1) making changes to the system, like moving the old print system
>    out of the way, stopping other stuff, registering to be started
>    at boot time, and so on.
> 
>    I was very scared to see this in the old make install, and would
>    prefer to not do anything of this at all, but instead documenting
>    what needs to be done and perhaps generating some examples for
>    init.d scripts ready to be copied somwhere.
> 
>    Anyone familar about this and could take a look at what what done
>    until now and write documentation how to install LPRng? I must
>    admit that my knowledge where what has to be is severly limited
>    to Debian, as I only use other systems, but do no administrate
>    them for long enough to remember anything.
> 

i will try to make some progress on the WE (i am on duty).
A question arises with other systems since the last clean up,
we have only linux here and i can not check anything beyond that.
The next problem are the different distros but i expect no major
problems since LSB should make it work or at least easy adaptable.

> 2) configuration files
>    Currently I think the best way would be something like installing
>    configuration files at "make install" time to their final place
>    but with a ".example" or ".example-for-LPRng" or other suffix by
>    default, making the suffix a make-variable, so that something
>    like
>    make install CONFIGSUFFIX=""
>    would install the examples to their final place (overwriting what
>    is there).
> 
>    Other solutions would be an extra
>    make install-config-examples (for installing with suffix)
>    or
>    make force-install-config-defaults (for overwriting what is there)
>    to make them easily instalable but not at all in the make install.
> 


i would prefer a special directory. i helps to cleanup the distributed tarball
and makes sure nobody thinks these are configfiles.
(IMHO) the configfiles belong into a special dir. they should be simple expandable.



and other blob is the additional documentation (aka cookbook) did someone take
a look at that ? maybe someone can generate a pdf from it ?

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=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Lprng-devel mailing list
> Lpr...@li...
> https://lists.sourceforge.net/lists/listinfo/lprng-devel
> 
> 

* Craig Small <csm...@en...> [070118 01:53]:
> On Mon, Jan 15, 2007 at 10:20:25PM +0100, Bernhard R. Link wrote:
> > - think about postinstall scripts (currently everything disabled,
> >   it just installes the programs and does nothing else)
> Don't muck up the distribution installers by adding too much here.

I think there are two issues here:

1) making changes to the system, like moving the old print system
   out of the way, stopping other stuff, registering to be started
   at boot time, and so on.

   I was very scared to see this in the old make install, and would
   prefer to not do anything of this at all, but instead documenting
   what needs to be done and perhaps generating some examples for
   init.d scripts ready to be copied somwhere.

   Anyone familar about this and could take a look at what what done
   until now and write documentation how to install LPRng? I must
   admit that my knowledge where what has to be is severly limited
   to Debian, as I only use other systems, but do no administrate
   them for long enough to remember anything.

2) configuration files
   Currently I think the best way would be something like installing
   configuration files at "make install" time to their final place
   but with a ".example" or ".example-for-LPRng" or other suffix by
   default, making the suffix a make-variable, so that something
   like
   make install CONFIGSUFFIX=""
   would install the examples to their final place (overwriting what
   is there).

   Other solutions would be an extra
   make install-config-examples (for installing with suffix)
   or
   make force-install-config-defaults (for overwriting what is there)
   to make them easily instalable but not at all in the make install.

Hochachtungsvoll,
	Bernhard R. Link

On Mon, Jan 15, 2007 at 10:20:25PM +0100, Bernhard R. Link wrote:
> - think about postinstall scripts (currently everything disabled,
>   it just installes the programs and does nothing else)
Don't muck up the distribution installers by adding too much here.

> I think this is a good starting point to apply to CVS and check how
> to improve it afterwards.
Yes, sounds good.

  - 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

Attached is the cleaned-up improved patch for switching to automake.

Missing/still to do:

- update INSTALL file
- think about postinstall scripts (currently everything disabled,
  it just installes the programs and does nothing else)

- try TESTSUPPORT and ship it in make dist
- decide which files in UTILS to keep/ship
- ...

I think this is a good starting point to apply to CVS and check how
to improve it afterwards.

Hochachtungsvoll,
	Bernhard R. Link

yep, i noticed that also.
the UNIT4 should be uint32_t from <stdint.h>.
i thing is is ok when we keep it that way it is (minus a frw warnings) and
be aware of the 64bit problem. there are several md5 implementations that
are gpl compatible.

i would like to publish the new autoconf code soon as possible and hammer out
problems with the source afterwards. We got some new (silent) members on the mailing
list after the freashmeat anouncement and i hope for more after a slashdot article.

i have some more (but minor) fixes in the pipe mainly documentation related. i will
take an look into the surrounding documentation (aka readme) after we have finished
the man pages.

re,
 wh


Bernhard R. Link wrote:
> * walter harms <wh...@bf...> [070112 17:41]:
>> --- src/LPRng-3.8.28/src/include/md5.h	2004-01-27 20:10:38.000000000 +0100
>> +++ lprng/src/include/md5.h	2007-01-11 20:13:08.000000000 +0100
>> @@ -48,6 +48,6 @@
>>    unsigned char digest[16];     /* actual digest after MD5Final call */
>>  } MD5_CONTEXT;
>>  
>> -void MD5Init ();
>> -void MD5Update ();
>> -void MD5Final ();
>> +void MD5Init (MD5_CONTEXT *mdContext);
>> +void MD5Update (MD5_CONTEXT *mdContext,unsigned char *inBuf,unsigned int inLen );
>> +void MD5Final (MD5_CONTEXT *mdContext);
>> --- src/LPRng-3.8.28/src/common/user_auth.c	2004-09-24 22:19:59.000000000 +0200
>> +++ lprng/src/common/user_auth.c	2007-01-11 20:57:36.000000000 +0100
> 
> Yeah, I missed those files in user_auth, as I did not want to touch
> md5.* yet.
> 
> These files have two problems:
> 
> 1) As they are currently, they fail on 64-bit architectures, because of
> (in src/include/md5.h):
> | /* typedef a 32 bit type */
> | typedef unsigned long int UINT4;
> I just tested on a amd64, and the calculated md5sum differs from what it
> generates on 32bit.
> 
> 2) I'm frightened by its license:
> /*
>  **********************************************************************
>  ** Copyright (C) 1990, RSA Data Security, Inc. All rights reserved. **
>  **                                                                  **
>  ** License to copy and use this software is granted provided that   **
>  ** it is identified as the "RSA Data Security, Inc. MD5 Message     **
>  ** Digest Algorithm" in all material mentioning or referencing this **
>  ** software or this function.                                       **
>  **                                                                  **
>  ** License is also granted to make and use derivative works         **
>  ** provided that such works are identified as "derived from the RSA **
>  ** Data Security, Inc. MD5 Message Digest Algorithm" in all         **
>  ** material mentioning or referencing the derived work.             **
>  **                                                                  **
>  ** RSA Data Security, Inc. makes no representations concerning      **
>  ** either the merchantability of this software or the suitability   **
>  ** of this software for any particular purpose.  It is provided "as **
>  ** is" without express or implied warranty of any kind.             **
>  **                                                                  **
>  ** These notices must be retained in any copies of any part of this **
>  ** documentation and/or software.                                   **
>  **********************************************************************
>  */
> 
> The second paragraph looks quite ugly. I'm not actually sure what it
> means but the "all material mentioning or referencing the derived work"
> sounds comparable evil to "All advertising materials mentioning features
> or use of this software" from the obnoxious GPL-incompatible 4-clause BSD.
> 
> There is a public domain implementation of the md5sum algorithm around,
> but that AFAIR not only needs a 32-bit type but also knowledge of its
> endianess. That's no problem if one can #include <endian.h>, but making
> that portable is more ugly.
> 
> Hochachtungsvoll,
> 	Bernhard R. Link

* walter harms <wh...@bf...> [070112 17:41]:
> --- src/LPRng-3.8.28/src/include/md5.h	2004-01-27 20:10:38.000000000 +0100
> +++ lprng/src/include/md5.h	2007-01-11 20:13:08.000000000 +0100
> @@ -48,6 +48,6 @@
>    unsigned char digest[16];     /* actual digest after MD5Final call */
>  } MD5_CONTEXT;
>  
> -void MD5Init ();
> -void MD5Update ();
> -void MD5Final ();
> +void MD5Init (MD5_CONTEXT *mdContext);
> +void MD5Update (MD5_CONTEXT *mdContext,unsigned char *inBuf,unsigned int inLen );
> +void MD5Final (MD5_CONTEXT *mdContext);
> --- src/LPRng-3.8.28/src/common/user_auth.c	2004-09-24 22:19:59.000000000 +0200
> +++ lprng/src/common/user_auth.c	2007-01-11 20:57:36.000000000 +0100

Yeah, I missed those files in user_auth, as I did not want to touch
md5.* yet.

These files have two problems:

1) As they are currently, they fail on 64-bit architectures, because of
(in src/include/md5.h):
| /* typedef a 32 bit type */
| typedef unsigned long int UINT4;
I just tested on a amd64, and the calculated md5sum differs from what it
generates on 32bit.

2) I'm frightened by its license:
/*
 **********************************************************************
 ** Copyright (C) 1990, RSA Data Security, Inc. All rights reserved. **
 **                                                                  **
 ** License to copy and use this software is granted provided that   **
 ** it is identified as the "RSA Data Security, Inc. MD5 Message     **
 ** Digest Algorithm" in all material mentioning or referencing this **
 ** software or this function.                                       **
 **                                                                  **
 ** License is also granted to make and use derivative works         **
 ** provided that such works are identified as "derived from the RSA **
 ** Data Security, Inc. MD5 Message Digest Algorithm" in all         **
 ** material mentioning or referencing the derived work.             **
 **                                                                  **
 ** RSA Data Security, Inc. makes no representations concerning      **
 ** either the merchantability of this software or the suitability   **
 ** of this software for any particular purpose.  It is provided "as **
 ** is" without express or implied warranty of any kind.             **
 **                                                                  **
 ** These notices must be retained in any copies of any part of this **
 ** documentation and/or software.                                   **
 **********************************************************************
 */

The second paragraph looks quite ugly. I'm not actually sure what it
means but the "all material mentioning or referencing the derived work"
sounds comparable evil to "All advertising materials mentioning features
or use of this software" from the obnoxious GPL-incompatible 4-clause BSD.

There is a public domain implementation of the md5sum algorithm around,
but that AFAIR not only needs a 32-bit type but also knowledge of its
endianess. That's no problem if one can #include <endian.h>, but making
that portable is more ugly.

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

hi list,
Sometime ago an article on slashdot declared lprng dead. i would like to reopen the case.

any comments, hints ? anyone ?

re,
 wh

hi bernhard,
the test looks nice. i got complains out a prototype that is fixed the in patch attached.
the patch is very
unfortunaly i have no alternative system to test anymore :( linux rules :=)

re,
 wh

* walter harms <wh...@bf...> [070112 09:01]:
> > 1) make the cleanup* functions in child.{c.h} __attribute__ ((noreturn))
> > so gcc does not complain non-void functions returning nothing.
> > 
> 	ah, that look nice.
> 	please do not overuse the __attribute__  stuff since it is gcc
> 	specific and people using a native cc should have chance to compile.
> 	(btw: has someone tested the code with icc or other non gcc ?)

It's defined as (in src/include/portable.h):
#ifdef __GNUC__
# define PRINTFATTR(fmtofs,dotsofs) __attribute__ ((format (printf,
# fmtofs, dotsofs)))
# define NORETURN __attribute__ ((noreturn))
#else
# define PRINTFATTR(fmtofs,dotsofs)
# define NORETURN
#endif

So unless those compiler define __GNUC__, those should not have any
effect. (And other compilers supporting those attributes would have to
be explizitly listed there)

> please be carefull while casting. some systems have a long pid_t while older ones
> may come with short.

That's why I choose long, so that any expectable size should fit in
there. Without cast it is just a coincidence weather they match on any
%hd %d or %ld, the only sane way I know of it "%ld", (long)id, that
should result in a proper handling, no matter what type id is.

Hochachtungsvoll,
	Bernhard R. Link

Bernhard R. Link wrote:
> I've tested the new build system on gcc 4.1 on solaris and it seems
> to work.
> 
> As gcc 4.1 is checking some more stuff, it generates some new
> warnings, which are quieted by the attached patch (relative to cvs).
> It does:
> 
> 1) make the cleanup* functions in child.{c.h} __attribute__ ((noreturn))
> so gcc does not complain non-void functions returning nothing.
> 
	ah, that look nice.
	please do not overuse the __attribute__  stuff since it is gcc
	specific and people using a native cc should have chance to compile.
	(btw: has someone tested the code with icc or other non gcc ?)


> 2) newer gcc does not only complain about wrong types for format
>    arguments, but also about types that are only accidentially right.
>    Especially pid_t, gid_t and mode_t being put in %d or %o.
>    This is fixed by casting modes to (unsigned int) before given to %o
>    and pid_t,uid_t and gid_t to long and the flag changed to %ld.
> 
>   While this gives a good urge to check the .po files to be up to date,
>   they seem to be quite fuzzy already anyhow, so that needs to be done
>   anyway.
> 

please be carefull while casting. some systems have a long pid_t while older ones
may come with short.


> 3) while execl(CLEAR,CLEAR,NULL) seems to be enough on Linux, on Solaris
> it wants execl(CLEAR,CLEAR,(char*)NULL); Well....
> 
our old friend :)

> If noone objects I plan to apply to cvs.
> 


re,
 wh

I've tested the new build system on gcc 4.1 on solaris and it seems
to work.

As gcc 4.1 is checking some more stuff, it generates some new
warnings, which are quieted by the attached patch (relative to cvs).
It does:

1) make the cleanup* functions in child.{c.h} __attribute__ ((noreturn))
so gcc does not complain non-void functions returning nothing.

2) newer gcc does not only complain about wrong types for format
   arguments, but also about types that are only accidentially right.
   Especially pid_t, gid_t and mode_t being put in %d or %o.
   This is fixed by casting modes to (unsigned int) before given to %o
   and pid_t,uid_t and gid_t to long and the flag changed to %ld.

  While this gives a good urge to check the .po files to be up to date,
  they seem to be quite fuzzy already anyhow, so that needs to be done
  anyway.

3) while execl(CLEAR,CLEAR,NULL) seems to be enough on Linux, on Solaris
it wants execl(CLEAR,CLEAR,(char*)NULL); Well....

If noone objects I plan to apply to cvs.

Hochachtungsvoll,
	Bernhard R. Link

* walter harms <wh...@bf...> [070111 15:59]:
>  the $Id$ stuff should get replaced while checkin.

Which is disabled in the current cvs, as otherwise importing
the old files created lots of conflicts because the cvs version
changed it to the one version, while the next release had it
changed to another version.

> the sprintf() writes into the msgbuf[] but never returns msgbuf[].

I think it still had a cp=msgbuf and later return cp in it. Well,
I changed both copies of Errormsg to your suggestion. (With the
change to make it still return "No Error" or errno 0)

Hochachtungsvoll,
	Bernhard R. Link