Subject: Re: [bug#27356] [PATCH 0/1] gnu: Add gnome-planner.
From: Marius Bakke <[email-masked]>
To: Chris Marusich <[email-masked]>, [email-masked]
Cc: Chris Marusich <[email-masked]>
Date: Sat, 17 Jun 2017 14:48:02 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

Chris Marusich <[email-masked]> writes:

> Hi,
>
> This patch adds GNOME Planner, a project management tool.  I've
> verified that it builds and that it's usable on GuixSD.  Some features
> are disabled by default (e.g., the database integration).  I've
> disabled the Python bindings explicitly because it turned out to be
> non-trivial to build that, and I don't need the Python bindings at
> this time.  Here's a summary of the optional features, taken from the
> build log:
>
>     Build API docs               : no
>     Python bindings              : no
>     Python plugin                : no
>     Simple priority scheduling   : no
>     Database/GDA support         : no, 
>     Evolution Data Server import : no
>     Evolution Data Server backend: no
>
> I didn't test everything, but I verified that the following things
> worked:
>
>     * The built-in help browser correctly displays the manual.
>     * Save a file, open a file.
>     * Print to PDF, print to PostScript, export to HTML.
>     * Add tasks and resources, and customize their attributes.
>     * Assign tasks to resources, and establish task predecessor
>       relationships.
>     * All the views - Gantt, task, resource, resource utilization.
>     * Calendar creation and modification.
>
> Along the way, I noticed some errors, but as far as I could tell,
> these errors did not stop the software from functioning.  I'll list
> the errors below for completeness.  Maybe somebody will know what to
> do about some of them.
>
> During the build, there were lots of messages like this (one for each
> locale or translation, I guess):
>
>     WARNING: failed to install schema
>     `/schemas/apps/planner/views/resource_view/print_enabled', locale
>     `ast': Unable to store a value at key
>     '/schemas/apps/planner/views/resource_view/print_enabled', as the
>     configuration server has no writable databases. There are some
>     common causes of this problem: 1) your configuration path file
>     /gnu/store/vnqdzjkfwlp0zgs4f9vqfi56g7vav206-gconf-3.2.6/etc/gconf/2/path
>     doesn't contain any databases or wasn't found 2) somehow we
>     mistakenly created two gconfd processes 3) your operating system
>     is misconfigured so NFS file locking doesn't work in your home
>     directory or 4) your NFS client machine crashed and didn't
>     properly notify the server on reboot that file locks should be
>     dropped. If you have two gconfd processes (or had two at the time
>     the second was launched), logging out, killing all copies of
>     gconfd, and logging back in may help. If you have stale locks,
>     remove ~/.gconf*/*lock. Perhaps the problem is that you attempted
>     to use GConf from two machines at once, and ORBit still has its
>     default configuration that prevents remote CORBA connections - put
>     "ORBIIOPIPv4=1" in /etc/orbitrc. As always, check the user.*
>     syslog for details on problems gconfd encountered. There can only
>     be one gconfd per home directory, and it must own a lockfile in
>     ~/.gconfd and also lockfiles in individual storage locations such
>     as ~/.gconf
>
> The above message seems related to another error I saw, which always
> gets emitted when starting the application from the command-line:
>
>     GConf Error: Failed to contact configuration server; the most
>     common cause is a missing or misconfigured D-Bus session bus
>     daemon. See http://projects.gnome.org/gconf/ for
>     information. (Details - 1: GetIOR failed:
>     GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
>     org.gnome.GConf was not provided by any .service files)
>
> I noticed the following error while modifying the predecessor for a
> task (in the "Edit task properties" window):
>
>     (planner:32632): GLib-GObject-CRITICAL **: Object class
>     PlannerPopupEntry doesn't implement property 'editing-canceled'
>     from interface 'GtkCellEditable'
>
> I noticed (when creating a new, empty calendar) the following error
> when applying the changes to a day's hours (via the following button:
> Project > Manage Calendars > (Calendar Editor) Default week... >
> Apply):
>
>     ** (planner:32632): CRITICAL **: mrp_day_get_id: assertion 'day !=
>     NULL' failed
>
> And on another occasion (I can't remember what I was doing which
> caused it), I noticed the following error:
>
>     (planner:32431): libglade-WARNING **: Could not load support for
>     `gnome': libgnome.so: cannot open shared object file: No such file
>     or directory
>
> I also noticed some graphical errors every now and then.  For example,
> while zooming in/out, the Gantt chart view sometimes fails to render
> either partially or wholly, but usually it looks just fine.  Various
> other sections of the UI exhibit similar behavior infrequently.  Since
> I personally observe a similar kind of issue with my graphical Emacs
> on GNOME3 already, I have no reason at this time to suspect that this
> is an issue limited to the GNOME Planner application.
>
> Also, the "Zoom to fit the entire project" button doesn't always seem
> to zoom correctly; sometimes it leaves part of the project out of
> view.  This is a minor nuisance, but I don't know if it's a
> GuixSD-specific problem.
>
> Finally, the build is non-deterministic.  I looked into this briefly
> and found that at least one of the causes is because, for some
> dependencies (e.g., GIO), the retained store path is not always the
> same.  This suggests that perhaps those dependencies themselves do not
> build deterministically.
>
> Despite all of these issues, as far as I could tell, the Planner
> application still worked just fine.

Wow, thanks for the detailed summary. Looks like you exposed some bugs
in other programs along the way. Would be nice to track down that
missing 'libgnome.so' reference.

I've pushed the patch, though I'm sure Ludo' can set you up with
commit access if you send over a Savannah account. :-)