Custom Query (1145 matches)


Show under each result:

Results (115 - 117 of 1145)

Ticket Resolution Summary Owner Reporter
#226 fixed Investigate state of open-vm-tools under Jaunty and determine whether to fully support them at this time jdreed jdreed

Reported by jdreed, 13 years ago.


This is a continuation of ATN-42, in which vmware tools (and open-vm-tools) was horribly broken under Hardy and Intrepid with recent kernels.

We believe everything except LP 332323 has been fixed in Jaunty.

We need to do the following:

  • Confirm that LP 306835 and 302226 are no longer an issue in Jaunty.
  • Test Debathena on Jaunty as a guest with open-vm-tools
  • Document what works and what doesn't, and make a determination about support.
  • Decide that anything older than Jaunty is not Fully Supported(tm) as a VMware Guest with open-vm-tools

History is available in ATN-42, which is archived at for those without Jira access.

#229 fixed CUPS should not scan the local network for printers jdreed geofft

Reported by geofft, 13 years ago.


CUPS by default scans the local network for printers. While this seems at first glance to be either good or neutral. it's the case that lots of users have their personal laptops configured (incorrectly, arguably, but it still happens) to print to Athena printers and then share their local configuration of that printer.

For example, is seeing both a "tree-eater" (which I've locally configured because it's Kerberized; see ATN-28) and a "tree_eater", which someone in the dorm has set up. Users should not click an Athena cluster printer's name in the GUI and get some random laptop as their print server.

#231 worksforme Gnucash breaks gconf configurations jdreed wdc

Reported by wdc, 13 years ago.


If gnucash is started with the "Update Search Path" option, a seemingly benign default, creates a .gconf.path which thereafter forces Athena 10 to look at Athena 9 gconf defaults and suddenly your screen is a broken version of Athena 9 instead of the new Ubuntu setup.

Supplementary documentation on this issue:

removing .gconf.path seems unbreaks the gconf setup, and gnucash runs just fine without that file present,

The problem is that we can't seem to figure out how gnucash got it into its head that making that setup was necessary.

Let's see if we can get an initial gnucash startup to fail again like this and understand WHY it did this.

The two commands:

rm -rf ~/gnucash

gconftool-2 --recursive-unset /apps/gnucash

clears out all the identifiable gnucash state, but does NOT provoke it into a setup dialog that asks if the Gnome Path can be set.

Note: See TracQuery for help on using queries.