Can't compile current CVS version
Hi,
I am new to this list -- so: hi there, all! I am Kurt and doing some work related to network printers for a living as well as inside the free software community. I am involved with CUPS, KDEPrint and linuxprinting.org, though not as a programmer, but rather in writing documentation.
I've used the realllllllly nice scli command line version for quite a while now and been able to surprise quite a few people with "my secret knowledge" and "my" easy solution to a problem, which you guys made possible.
Michael Goffioul, the KDEPrint programmer wizard, has started 3 days ago to implement a KDE GUI frontend to scli (for those curious about the first screenshots, see
http://www.geocities.com/kdeprint/skli.html)
He told me it required the latest CVS of scli, if I wanted to test his frontend.
I had the following compile error during "make":
make[2]: Entering directory `/data/cups-versionen/CVSstuff/scli/scli/doc' cd . \ && /bin/sh /home/kde4/cups-versionen/CVSstuff/scli/scli/missing --run makeinfo \ `echo scli.texinfo | sed 's,.*/,,'` scli.texinfo:271: Unbekannter Befehl »verbatim«. scli.texinfo:277: Nicht übereinstimmendes »@end«.
[....repeating similar messages...]
scli.texinfo:1593: Unbekannter Befehl »verbatim«. scli.texinfo:1596: Fehlplazierte {. scli.texinfo:1597: Fehlplazierte {. scli.texinfo:1602: Fehlplazierte }. scli.texinfo:1605: Fehlplazierte }. scli.texinfo:1606: Nicht übereinstimmendes »@end«. scli.texinfo:1631: Unbekannter Befehl »verbatim«. scli.texinfo:1634: Fehlplazierte {. scli.texinfo:1635: Fehlplazierte {. scli.texinfo:1637: Fehlplazierte }. scli.texinfo:1639: Fehlplazierte {. scli.texinfo:1641: Fehlplazierte }. scli.texinfo:1646: Fehlplazierte }. scli.texinfo:1647: Nicht übereinstimmendes »@end«. makeinfo: Entferne Ausgabe-Datei »/data/cups-versionen/CVSstuff/scli/scli/doc/scli.info« wegen der Fehler; --force benutzen, um diese beizubehalten. make[2]: *** [scli.info] Error 1 make[2]: Leaving directory `/data/cups-versionen/CVSstuff/scli/scli/doc' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/data/cups-versionen/CVSstuff/scli/scli' make: *** [all] Error 2
Maybe this is a passing thing, gone with my next "cvs up" syncing. If so, I'll see tomorrow, or the day after, if it compiles for me. If not, please tell me, what I am doing wrong.
System: SuSE 7.3, gcc version 2.95.3 20010315 (SuSE)
Thanks for any help! Cheers, Kurt
Kurt Pfeifle writes:
Kurt> I've used the realllllllly nice scli command line version for Kurt> quite a while now and been able to surprise quite a few people Kurt> with "my secret knowledge" and "my" easy solution to a problem, Kurt> which you guys made possible.
Thanks.
Kurt> Michael Goffioul, the KDEPrint programmer wizard, has started 3 Kurt> days ago to implement a KDE GUI frontend to scli (for those Kurt> curious about the first screenshots, see
Kurt> http://www.geocities.com/kdeprint/skli.html)
Looks cool. I never had the opportunity to test scli with bigger printers with multiple input trays etc. but it seems to work fine.
Kurt> I had the following compile error during "make":
[...]
This is just the documentation. :-) There seem to be problems with different version of makeinfo or texinfo which I never bothered to track down. You should still have a functional scli binary.
BTW, I have makeinfo (GNU texinfo) 4.2.
/js
Juergen Schoenwaelder wrote:
Kurt Pfeifle writes:
Kurt> I've used the realllllllly nice scli command line version for Kurt> quite a while now and been able to surprise quite a few people Kurt> with "my secret knowledge" and "my" easy solution to a problem, Kurt> which you guys made possible.
Thanks.
Kurt> Michael Goffioul, the KDEPrint programmer wizard, has started 3 Kurt> days ago to implement a KDE GUI frontend to scli (for those Kurt> curious about the first screenshots, see
Kurt> http://www.geocities.com/kdeprint/skli.html)
Looks cool. I never had the opportunity to test scli with bigger printers with multiple input trays etc. but it seems to work fine.
Definitely! I've tested it with quite some models and it worked with so many, that I think it is a lacking implementation on the part of the vendor if his model doesn't show a "tray 17 is open" message through scli. Anyway, let me know what I can do to help testing all the stuff... Is there a "raw" or "verbose" mode, which lets me log every byte the printer sends back to me in the original state, which you could use? Or is it just that you "implement a defined standard", and look at the written MIBs to develop scli?
Kurt> I had the following compile error during "make":
[...]
This is just the documentation. :-) There seem to be problems with different version of makeinfo or texinfo which I never bothered to track down. You should still have a functional scli binary.
Thanks for the hint. It is true ;-)
BTW, I have makeinfo (GNU texinfo) 4.2.
kde4@kde-bitshop:~/cups-versionen/CVSstuff/scli/scli> makeinfo --version makeinfo (GNU texinfo) 4.0
I'll try to update and see if it lets me then know the documentation... ;-)
Kurt Pfeifle writes:
Kurt> [...] Anyway, let me know what I can do to help testing all the Kurt> stuff... Is there a "raw" or "verbose" mode, which lets me log Kurt> every byte the printer sends back to me in the original state, Kurt> which you could use? Or is it just that you "implement a defined Kurt> standard", and look at the written MIBs to develop scli?
Yes, I actually read MIB modules. And luckily, the printer vendors seem to do the same and we agree on what we have read. ;-)
Anyway, I am also following somewhat the revision of the printer MIB recently submitted to the IETF - in fact, scli already uses extensions that are not yet published. There will also be an additional finisher MIB for printers that can do magic things once the pages have been printed. This might become an interesting addition coming down the road at some point in time...
/js
Juergen Schoenwaelder wrote:
Kurt Pfeifle writes:
Kurt> [...] Anyway, let me know what I can do to help testing all the Kurt> stuff... Is there a "raw" or "verbose" mode, which lets me log Kurt> every byte the printer sends back to me in the original state, Kurt> which you could use? Or is it just that you "implement a defined Kurt> standard", and look at the written MIBs to develop scli?
Yes, I actually read MIB modules. And luckily, the printer vendors seem to do the same and we agree on what we have read. ;-)
Seems to proof that Microsoft has not yet started to become involved in the printer business... ;-)
Anyway, I am also following somewhat the revision of the printer MIB recently submitted to the IETF - in fact, scli already uses extensions that are not yet published. There will also be an additional finisher MIB for printers that can do magic things once the pages have been printed.
I've access to a lot of devices like these. Let me know if I can help with anything regarding this. Vendors in my reach are (sometimes OEM versions of) Ricoh, Canon, HP, Heidelberg, EfI/Fiery -- mainly from 20ppm up to the top models...
This might become an interesting addition coming down the road at some point in time...
Yes, true.
On Tue, Sep 10, 2002 at 08:34:55PM +0200, Juergen Schoenwaelder wrote:
Kurt> http://www.geocities.com/kdeprint/skli.html) Looks cool.
Yes, very nice.
I never had the opportunity to test scli with bigger printers with multiple input trays etc. but it seems to work fine.
I did some tests with a bigger printer some time ago and it worked fine.
Oliver
participants (3)
-
Juergen Schoenwaelder -
Kurt Pfeifle -
Oliver Wellnitz