gnome-do 0.6.1.0-0ubuntu2 fails to start with Unhandled Exception: System.ArgumentException: First component must not be null or empty

Bug #318575 reported by Stéphane Graber
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gnome-do (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: gnome-do

When starting gnome-do 0.6.1.0-0ubuntu2 on our application servers (multiple LTSP and NX users) gnome-do fails to start with:

Unhandled Exception: System.ArgumentException: First component must not be null or empty
Parameter name: first
  at Do.Paths.Combine (System.String first, System.String[] components) [0x00000]
  at Do.Paths.get_SystemData () [0x00000]
  at Do.Paths.get_SystemPlugins () [0x00000]
  at Do.Core.PluginManager.get_RepositoryUrls () [0x00000]
  at Do.Core.PluginManager.Initialize () [0x00000]
  at Do.Do.Main (System.String[] args) [0x00000]

That's on Intrepid with the regular gnome-do installation, running other mono softwares like tomboy works fine.

Revision history for this message
Chris Halse Rogers (raof) wrote :

So, the only way I can see the code failing is if the XDG_DATA_DIRS environment variable is terminated by a ':', meaning it has an empty component, which seems somewhat malformed.

Can you post the output of "echo $XDG_DATA_DIRS" from a NX or LTSP session?

Changed in gnome-do:
assignee: nobody → raof
status: New → Incomplete
Revision history for this message
Stéphane Graber (stgraber) wrote :

After some debugging it looks like the error was mine.
XDG_DATA_DIRS was starting with a : instead of the first value making gnome-do to fail.

This was probably caused by our custom xdg desktop-profiles making Xsession to generate a wrong XDG_DATA_DIRS variable.

I'm closing the bug as Invalid, though better error reporting would be great and would have saved me a lot of time debugging the issue :)

Changed in gnome-do:
assignee: raof → nobody
status: Incomplete → Invalid
Revision history for this message
Stéphane Graber (stgraber) wrote :

Oh, thanks for the quick answer, I actually only saw it when closing my bug report.
So you were absolutely right it was indeed a XDG_DATA_DIRS issue, I'll have a look at it tomorrow to find what's causing it.

Thanks

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.