Ds9 problem --- can't find package xml

A problem with the tutorial at https://pipelines.lsst.io/getting-started/display.html : ds9 doesn’t display pretty pictures.

An instance of ds9 was fired up in a separate terminal. A Pyraf session chatted to it without issue. Working through the tutorial, all seemed ok up to and including
>>> display = afwDisplay.getDisplay()
but then

>>> display.mtv(calexp)
ds9 doesn't appear to be running (XPA: 
  File "python/lsst/display/ds9/xpa.cc", line 115, in const char* lsst::display::ds9::{anonymous}::XPASet1(XPA, char*, char*, char*, char*, int)
    XPASet returned 0 {0}
lsst::pex::exceptions::IoError: 'XPASet returned 0'
, (;iconify no; raise)), I'll try to exec it for you
Error in startup script: can't find package xml
    while executing
"package require xml"
    ("x11" arm line 10)
    invoked from within
"switch $ds9(wm) {
    x11 {
	# set to absolute path so that if -cd command is used,
	# so we can still find our files
	set ds9(root) [file normalize [..."
    (file "/usr/share/saods9/library/ds9.tcl" line 195)
XPA$ERROR no 'xpaset' access points match template: ds9
Error writing image: : Broken pipe
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/src/lsst_stack/stack/miniconda3-4.5.4-fcd27eb/Linux64/afw/17.0.1/python/lsst/afw/display/interface.py", line 551, in mtv
    self._impl._mtv(data.getImage(), data.getMask(), wcs, title)
  File "/usr/local/src/lsst_stack/stack/miniconda3-4.5.4-fcd27eb/Linux64/display_ds9/17.0.1/python/lsst/display/ds9/ds9.py", line 306, in _mtv
    _i_mtv(image, wcs, title, False)
  File "/usr/local/src/lsst_stack/stack/miniconda3-4.5.4-fcd27eb/Linux64/display_ds9/17.0.1/python/lsst/display/ds9/ds9.py", line 485, in _i_mtv
    raise e
  File "/usr/local/src/lsst_stack/stack/miniconda3-4.5.4-fcd27eb/Linux64/display_ds9/17.0.1/python/lsst/display/ds9/ds9.py", line 478, in _i_mtv
    displayLib.writeFitsImage(pfd.fileno(), data, wcs, title)
lsst.pex.exceptions.wrappers.RuntimeError: 
  File "python/lsst/afw/display/simpleFits.cc", line 441, in void lsst::afw::display::writeBasicFits(int, const ImageT&, const lsst::afw::geom::SkyWcs*, const char*) [with ImageT = lsst::afw::image::Image<float>]
    Error writing data for row 10 {0}
lsst::pex::exceptions::RuntimeError: 'Error writing data for row 10'
>>> 

It most certainly is running.

Attempting to fire up a ds9 from the same shell as the one running the tutorial:

Error in startup script: can't find package xml
    while executing
"package require xml"
    ("x11" arm line 10)
    invoked from within
"switch $ds9(wm) {
    x11 {
	# set to absolute path so that if -cd command is used,
	# so we can still find our files
	set ds9(root) [file normalize [..."
    (file "/usr/share/saods9/library/ds9.tcl" line 195)
(lsst-scipipe-fcd27eb) pcl@thoth:~/Astro/lsst$ 

which confuses me. Why does ds9 work in one environment but not the other? Yes, I had run setup display_ds9 as gleaned from another post where ds9 problems were reported.

Ho hum. We’ll get there in the end, I’m sure.

I suspect this will be to do with not having set your XPA_PORT environment variable.

Some guidance on that might be found here, though it covers more than just this issue for sure.

Thanks Merlin,

I couldn’t find anything at that link and its children which I was able to use to get things working.
Perhaps I should emphasise that everything is running locally so why should all the stuff about X11 tunnelling be applicable?

Firing up ds9 -xpa info with no other arguments produces a message box as follows

XPA_VERSION:  2.1.18
XPA_CLASS:  DS9
XPA_NAME:  ds9
XPA_METHOD  7f000001:ppppp

where 7f000001 is recognizably the IPv4 loopback address, aka localhost, and ppppp is a non-privileged port number which varies from run to run.

Perhaps I should also have been more explicit that this is a Ubuntu 18.10 box running Ubuntu’s distribution of ds9.

Trying variations on export XPA_METHOD=localhost, export XPA_METHOD=7f000001, with or without the port number didn’t help.

I don’t know what “can’t find package xml” appears, but perhaps that’s a red herring.

Solved it, after much grubbing around on the interweb thingy. On this Ubuntu box sudo apt install xpa-tools; xpans did The Right Thing.

Perhaps advice to this effect could be added to the installation and / or tutorial material?

Paul