Monthly Archives: March 2004

jhbuild

  • Post author:
  • Post category:Uncategorized

Made some changes to the way “jhbuild bootstrap” works. Whereas previously bootstrap would check to see if each required build tool was installed by the distro and only build the tools that were missing, it now builds all the tools.

If you wish to use the build tools supplied by your distro, it is now recommended that you don’t run bootstrap. To perform the “check that required tools are installed” job that bootstrap used to do, you can instead run the “jhbuild sanitycheck” command, which will do these checks and report any errors. The sanitycheck command also checks for other configuration problems as well, such as whether the all the different automake versions will be able to find the libtool macros.

The upside for me is that there are now only 2 combinations of distro packages vs. packages installed by jhbuild, as opposed to the 2n combinations previously (where n is the number of bootstrap packages). This greatly reduces the number of ways someone can screw up their system.

Since bootstrap is a lot simpler now, I also changed how it was implemented. Rather than using a separate code path, it now uses the same build framework as the main build. The bootstrap command is now functionally equivalent to building meta-bootstrap from the bootstrap module set. Changing the list of bootstrap packages can now be done as easily as modifying any other module set.

Removing the redundant code path should make things a little more robust, since it reduces the amount of infrequently used and/or untested code.

IPP

Did a little more hacking on my IPP client library, and wrote a small PyGTK program that lets you do simple management tasks (view all print queues/classes, view queued and completed jobs for printers, stop and start print queues, etc).

If you want to try it out, grab ipplib.py and printerlist.py. Put them in the same directory and run “python printerlist.py“. Seems to work pretty well for less than a thousand lines of code.

To get things working with CUPS’s authentication, I do the following for operations like Pause-Printer:

  1. Submit request to the HTTP URI corresponding to the IPP one.
  2. If the response has an IPP status code of client-error-not-authorized, then resubmit the request to the URI /admin/ relative to the previous URI (not changing the IPP message).
  3. Return the IPP response message.

This seems to work quite reliably, so I might add the fallback to all the IPP requests.

IPP

Out of curiosity, I decided to write a little IPP client library in Python. An
in-progress version can be found here.

In less than 500 lines of Python, I have an IPP message
encoder/decoder, and some higher level classes to perform a few
operations on printers and jobs. I’ve been able to successfully talk to
the following IPP servers:

  • CUPS (I’ve also got a little code to perform some of the CUPS
    proprietary operations).

  • an HP LaserJet 5100 and a 2300 — both with JetDirect 615n
    (J6057A) cards.

  • a Lexmark Optra C710.

The following didn’t want to talk to me:

  • an HP LaserJet 4V with a JetDirect 400n (J4100A) card (it seems
    to always give me a client-error-bad-request response).

  • a Canon iR C3200. (incidentally, this printer/copier apparently
    runs an embedded version of SunOS 4.1.4)

I’m probably doing something wrong for these last two, although it
is a bit difficult to work out what.

When talking to CUPS, I can use the proprietary CUPS-Get-Printers
operation to list all the printers it knows about which would make it
pretty easy to provide functionality of something like gnome-print-manager:

>>> import ipplib
>>> cups = ipplib.CUPSServer('ipp://localhost/')
>>> for info in cups.get_printer_info():
... print info['printer-name'], '-', info['printer-uri-supported']
...
harryplotter - ipp://hostname/printers/harryplotter
 ...
>>>

Similarly, it is easy to list the jobs (pending or completed) for a
printer. I still haven’t tried out any of the operations that can
change a printer or job’s status, but in theory that should all work 🙂.

Thoughts on the protocol

While IPP uses HTTP as a transport, there is a fair bit of overlap
between what the two protocols do, such as:

  • request methods/operations and response status codes.
  • identification of the resource the operation is being performed
    on.

  • IPP attributes seem quite similar to HTTP headers.
  • message body mime type declarations
  • compression of message bodies

Other things serve no purpose when tunneled through HTTP, such as
message sequence numbers. Apparently the reason for this is so that IPP
could in the future be sent directly using a custom protocol (in that
case, the sequence numbers would allow for pipelining of requests, and
out of order responses). However, I would be surprised if such a
protocol ever gets developed. IPP will probably continue to use HTTP as
its transport.

This does lead to complications though:

  • The URI you do an HTTP POST to may differ from the URI specified
    inside the IPP message. The spec says that the HTTP level URI should be
    ignored. If you have ever looked at the CUPS log files, you might have
    noticed that it almost always posts to “/” rather than the resource it
    is acting on. To make matters more complex, some of the proprietary CUPS
    operations     require that you post to a different HTTP URI to the one
    in the IPP message.

  • A request can fail at one of two levels. An IPP client will need
    to detect and handle both HTTP level and IPP level error responses. In
    fact, most IPP error messages will come back as “HTTP/1.1 200 OK”.

Apart from the few warts, IPP seems like a pretty nice protocol. It
is fairly easy to parse (assuming you have an http client library to
use), and is very extensible. A lot nicer than LPR 🙂.