Mate Desktop and BLFS

ordealbyfire83 · 09-14-2014, 09:08 PM

There don't seem to be any official hints/instructions for building the Mate Desktop, so I decided to have a go at writing some. Compilation is fairly simple once you determine the dependencies and build them in order. Right now I'm working on a LFS-7.5 system with some minor modifications (most notably using eudev and gcc-4.6), and have mostly followed BLFS SVN-2014-05-28 and kernel 3.14.4.

However there seems to be some circular-"dependency" problem that may or may not be kernel related that causes some problems for (auto)mounting external drives and power management. In particular:

- To mount external drives in Caja without using the controversial udisks(2) you need to use udisks(1) + libgdu + gvfs(<= 1.12). This is a pain to build because getting libgdu from gnome-disk-utility is sorely inconvenient. However, that issue aside, you do get all of the familiar functionality provided that you can get ConsoleKit to play nice.

- This mounts drives just fine, but when it comes time to disconnect, the above will NOT give you any other option other than Eject if you do not enable CONFIG_USB_SUSPEND (and CONFIG_PM_RUNTIME) functionality in the kernel (after kernel 3.10 you can just enable CONFIG_PM_RUNTIME).

- Also, unless you enable CONFIG_AUDITSYSCALL in the kernel, ConsoleKit will not give you an active session. Once you have all of this enabled, you can get disks to mount/unmount/remove nicely,

- BUT this kills the Suspend/Hibernate options from the "Shut Down" menu (despite 'sudo pm-suspend' / 'sudo pm-hibernate' working just fine).

In other words: having an active ConsoleKit session via CONFIG_AUDITSYSCALL makes the user unable to suspend/hibernate for some reason. What is going on here? Can you not have all of this? Under Debian Wheezy + Mate 1.8 (with NO systemd-logind0 anywhere), all of this works, but not here. Also, without CONFIG_AUDIT_SYSCALL the CPU Frequency applet is not clickable which seems to be the opposite case scenario of suspend/hibernate functionality.

Are there any suggestions for this?

ReaperX7 · 09-15-2014, 10:53 PM

The MATE desktop website should have "SOME" installation documentation, but the general rule for installing is to use the standard:

Code:

./configure --prefix=/usr &&
make

While also checking the:

Code:

./configure --help

readout for any additional support vectors.

Try this:

http://mate-desktop.org/install/

and

https://github.com/mateslackbuilds/msb

You can always read the Slackware SlackBuild scripts and use them to decode the install procedures.

ordealbyfire83 · 10-26-2014, 01:31 PM

The issue is apparently in mate-session-manager (1.8.1).

Since I can see the following when running "upower -d" and suspend/hibernate using d-bus as an ordinary user works (!) then there is another issue at work.

Code:

  can-suspend:     yes
  can-hibernate    yes
  on-battery:      no
  on-low-battery:  no
  lid-is-closed:   no
  lid-is-present:  yes
  is-docked:       no

According to this thread people were having similar issues when using new versions of upower with (and without) systemd. If we look at ./mate-session/gsm-logout.c there is a function that looks like this (and a similar one for suspend as well):

Code:

static gboolean
gsm_logout_supports_system_hibernate (GsmLogoutDialog *logout_dialog)
{
        gboolean ret;
        ret = FALSE;
#ifdef HAVE_SYSTEMD
        if (LOGIND_RUNNING())
            ret = gsm_systemd_can_hibernate (logout_dialog->priv->systemd);
#endif
#if defined(HAVE_SYSTEMD) && defined(HAVE_UPOWER)
        else
#endif
#ifdef HAVE_UPOWER
        ret = up_client_get_can_hibernate (logout_dialog->priv->up_client);
#endif
        return ret;
}

Ideally having upower would be enough to get ret set to the appropriate value but it just never happens. There was no such sanity check in version 1.4 so I just deleted everything inside the function and replaced it with

Code:

return up_client_get_can_hibernate (logout_dialog->priv->up_client);

That forcibly brings back the buttons. Remember, this is only safe or relevant when you know that suspend/hibernate as ordinary user works...