ViewCVS

Made a few more changes to the Gnome viewcvs. Pretty much all of the original ugly colour scheme is gone now, and I got it to pretty print some more files with gnome specific file extensions.

We are maintaining the modifications in CVS using the standard vendor branch/main branch setup. Since the cvs import command is one that people screw up the most, I wrote some scripts to help with exporting viewcvs from upstream CVS and then importing it into our CVS.

When I went to test the script, it worked fairly well, except for the fact that some of the template files had been moved between the two pulls. Since there was no link between the two different file names, CVS wasn’t able to merge my local changes. Other than that, the merge went okay.

I wonder if Arch or Subversion would have been able to handle this situation any better, given that the upstream repository didn’t record that the file had been moved?

14 April 2004

  • Post author:
  • Post category:Uncategorized

ViewCVS

After the breakin at the gnome.org web server, the CVS server were moved over to the new server HP donated. However, the LXR and Bonsai tools weren’t considered as high a priority, so have not been restored yet.

Since it was easier to set up than either LXR or Bonsai, I set up ViewCVS (with jdub‘s help), so we now have online repository browsing again. It doesn’t provide all the features found in the other packages, so it’ll be good to get them set up again too though.

We made a few superficial changes to the templates to make them look a bit more gnomey, but they probably still need a bit more work.

jhbuild

Merged a patch to add an optional "make clean" phase to jhbuild, and added a "make check" phase (also off by default). These should be useful for the unattended “tinderbox” mode.

It does increase the complexity a bit, so I think I’ll have to look at how to simplify it a bit (probably pull a bit more of the logic out of the program code).

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.