[ubuntu-x] packaging of piglit

[Tormod Volden]

The short story for users:
Install piglit from https://launchpad.net/~xorg-edgers/+archive/piglit
$ piglit-run.py /usr/share/piglit/tests/quick.tests my-results-day-1
Sleep and update system
$ piglit-run.py /usr/share/piglit/tests/quick.tests my-results-day-2
$ piglit-summary-html.py my-compare-html my-results-day-1 my-results-day-2
$ xdg-open my-compare-html/index.html
Enjoy nice, coloured regression reports

Note that running piglit may make your X session explode.

On Thu, Jan 13, 2011 at 4:17 PM, Christopher James Halse Rogers wrote:
> Awesome.  Thanks very much for this - it's been somewhere on my todo
> list for a while.

Thanks for confirming the interest in this.

>> Finally I have run out of time, and there are some known issues:

Meanwhile, I found time to look more at the code and packaging and
have resolved the blocking issues.

>> * the python scripts use a python module which I have shipped in
>> /usr/lib/piglit/framework, but this needs to be either a) moved where
>> python looks for it b) patch the script to find it c) some dh_python
>> magic?

I just moved the scripts to /usr/lib/piglit and added links to them in
/usr/bin. Works fine.

>> * the test scripts are shipped in /usr/share/piglit but it would be
>> nice if piglit-run.py could search there without the user providing
>> full path

Not looked at yet, but for now, please use the full path to the tests like this:
piglit-run.py /usr/share/piglit/tests/sanity.tests my-results-today

>> * the executable tests are shipped in /usr/lib/piglit but again,
>> piglit-run.py should be told where they are

Patched.

>> * lintian warnings en mass, the most serious I think is
>> http://lintian.debian.org/tags/binary-or-shlib-defines-rpath.html
>> which means the build directory path is written into the binaries.

Patched. The reason is that cmake adds rpath when building so that
binaries can be tested from the build tree, then removes the rpath
when installing. So far, "make install" does nothing, I am therefore
copying the built binaries manually from the build tree.

>> Probably some more issues will pop up once these are fixed. I hope
>> someone more proficient in packaging of python stuff, or cmake, can
>> help out. Thanks in advance for any hints or patches.

The failing "make install" can probably be solved with some cmake-fu.

>> For now, I uploaded it to my own PPA for lucid, but I am thinking
>> creating a xorg-edgers PPA for it (and add a launchpad piglit project
>> for branches etc):
>>
> This would be a good idea.  It would also be worth investigating the ppa
> daily-build infrastructure to keep the piglit packages minty fresh.

https://code.edge.launchpad.net/piglit
https://code.edge.launchpad.net/~xorg-edgers/piglit/debian-packaging

Here is an untested daily-build recipe:
https://code.edge.launchpad.net/~xorg-edgers/+recipe/piglit-daily

I have not requested builds from the recipe myself because of some
bugs in launchpad (it picks my wrong e-mail address, bug 620137). But
anyone from xorg-edgers, feel free to try it out and fix it if needed.
BTW, bug 620132 is also on my wishlist (git commit ID in package
recipe).

> Either Bryce or I should be able to pick this up from here, either at
> the rally or once we're home.

We should maybe add a convenience script that runs standard tests
(maybe depending on detected hardware) and generates a html report
which will be opened in a browser. Having a pastebin-like service for
uploading results from a live session would be nice.

live-cd image + xorg-edgers + piglit = easy, quasi-automated
regression testing for everybody :)

Cheers,
Tormod