How to Install MATE 1.8 complete desktop environment in OpenSUSE 13.1

I installed opensuse from usb and got this in /boot/grub2/device.map and device.map.new

(hd0)      /dev/disk/by-id/ata-WDC_WD(.....my HDD....)
(hd1)  (...USB device that I installed from....) 

and also in repositories I had to removemy usb repo to update the system, otherwise I had to keep the usb plugged-in as Yast refreshes from all repos.
and sometime while booting, after kernel load I get this:

    1.656234]  usb  1-1.1: device descriptor read/64, error -32

and then systems goes on to booting
I even tried deleting both the enteries in device.map and then updating grub but everynow and then it shows the that usb error line. and also every device including this usb loads as /dev/sdc, and not /dev/sdb

So I cloned my VM with the missing panel, set out to install every single package from the MATE repo not already installed. Rebooted and found no panel still. However there were a set of conflicts when I tried installing all of them and most notable of them exactly those branding packages. I replaced the following four openSUSE brandings with “upstream” counterparts and reboot…guess what! I have a panel above, taskbar below and a pretty looking no nonsense desktop now! :slight_smile:

mate-control-center-branding-openSUSE
mate-menus-branding-openSUSE
mate-panel-branding-openSUSE
mate-session-manager-branding-openSUSE

So I go back to my original VM with only a minimal set of packages and do the same thing, and panel is back!

Now the obvious question is why the openSUSE brandings while they are selected automatically don’t seem to provide what the upstream ones provide?

P.S. I’ll provide the list of all packages I installed starting from minimal in a bit…

And what does this have to do with MATE 1.8? :sarcastic:

Please open a new thread for this problem.
But grub2’s devicemap or grub2 itself have nothing to do with this. That’s an error message of the kernel when trying to access a particular USB device.
Maybe related to this: [ubuntu] USB and networking broken in 64-bit ubuntu for new motherboard ?

Interesting.
But I’m sure I had the openSUSE branding installed, and you had to I suppose when you tried the method of installing 1.6 first and then upgrading.

Maybe it worked because I logged in to 1.6 once before upgrading, so there already was a configuration in the user’s home folder?
Or maybe some MATE 1.6 package was left-over that provided the missing part?

That ‘missing part’ is the mystery. If a logging in once will set things up properly in 1.6 it should also do it in 1.8.
Next I will start with an even bare minimum install like the “text/server mode” and then install MATE 1.8 from there. Yes I can see an obsession developing here! :expressionless: one that began from running away from windows, not ever looking at mac just for random reasons, and not being able to find a stable linux distro so far that not only offers many useful things but more importantly doesn’t show me its unstable side every so often that affects day to day use.

And here are the packages I installed from MATE 1.8 current:

caja, marco, marco-themes, mate-applets, mate-backgrounds, mate-control-center, mate-desktop, mate-disk-usage-analyzer, mate-icon-theme, mate-indicator-applet, mate-media, mate-menus, mate-panel, mate-polkit, mate-power-manager, mate-screensaver, mate-session-manager, mate-settings-daemon, mate-system-monitor, mate-terminal, mate-themes, mozo, pluma, mate-calc, mate-notification-daemon, mate-screenshot, mate-search-tool

then you have to make sure you have the ‘upstream’ brandings selected for the 4 packages as mentioned above rather than the openSUSE ones for I-don’t-know-yet reasons.

No, what I mean is this:
MATE 1.6’s branding-openSUSE packages are ok, obviously. If you log into Mate 1.6, you get a working configuration.
When you upgrade to MATE 1.8 and login, your user already has a configuration with a panel, you won’t get a fresh configuration from the defaults.
If you login to Mate the first time with 1.8, you get the default configuration which apparently misses the panel in the branding-openSUSE packages (for 1.8 that is).

And here are the packages I installed from MATE 1.8 current:

caja, marco, marco-themes, mate-applets, mate-backgrounds, mate-control-center, mate-desktop, mate-disk-usage-analyzer, mate-icon-theme, mate-indicator-applet, mate-media, mate-menus, mate-panel, mate-polkit, mate-power-manager, mate-screensaver, mate-session-manager, mate-settings-daemon, mate-system-monitor, mate-terminal, mate-themes, mozo, pluma, mate-calc, mate-notification-daemon, mate-screenshot, mate-search-tool

Ok, I will try this tomorrow I suppose.

then you have to make sure you have the ‘upstream’ brandings selected for the 4 packages as mentioned above rather than the openSUSE ones for I-don’t-know-yet reasons.

Well, no. Actually I want to reproduce the missing panel. And then compare the user configuration files with the working ones. :wink:

Or maybe I’ll just download the 2x4 branding packages and compare them as a first step…:\

While installing Mate 1.8 how did you installed atril1.8 and eom 1.8, as eom gets installed automatically when installing marco.

I get this:

nothing provides mate-desktop-gsettings-schemas = 1.8.0 needed by eom-1.8.0-2.1.x84_64
Conflict Resolution:
1: do not install eom 1.8....
2. breal eom1.8....by ignoring some dependencies\CODE]
same for atril.
I had Mate 1.6 before but then deleted now, and then removed all packages.

Even after slecting mate-desktop-gsettings-schemas it still gives that conflict. Same for atril.
O I got it, eom’s depedenciy is schemas version 1.8.0 while list has schemas version 1.8.1. Should I choose resolution no. 2 now?
and what does the lang packages mean, should I install them too? like mate-desktop-lang mate-control-centre-lang…etc.

I installed it, it logged in but then usual problem happened…INFINITE CAJAs
In 1.6 it got solved by running following

$ grep caja /usr/share/applications/caja.desktop
Exec=caja -n
X-MATE-Bugzilla-Product=caja


$ sudo sed -i.orig  's/^Exec=caja -n/& --sync/' /usr/share/applications/caja.desktop 


$ diff /usr/share/applications/caja.desktop /usr/share/applications/caja.desktop.orig
217c217
< Exec=caja -n --sync
---
> Exec=caja -n

But not in 1.8
I even deleted the user file in /hoome/.config/dconf/ and it recreated it again automatically with me as owner but this didn’t solve the issue
How to solve this?

EDIT - It happens so that 1.8 caja doesn’t have “-n” with Exec command so the above commands didn’t worked if written as it is. Had to do nano it and modify it to: “Exec=caja -n --sync” but didn’t work either.

Solved - “-n” wasn’t there by default, so didn’t have to put it. Finally worked with “Exec=caja --sync”.

And if you are upgrading from 1.6 -> 1.8 then the edition might work or might not, if not then try deleting .config .cache and then try again. Fresh 1.8 install is recommended.

I am sometime getting panel crashes. First times I had opened one windows, and one app to configure stuff and the desktop just crashed and auto logged out, I had to log back in.
Second time, I was downloading stuff and meanwhile seeing the enlarged images of diff linux themes in chromium.
How to solve panel crashes and auto-logouts?
Desktop works fine when using kde environment. I am using lightdm as default, but above mentioned problem is hapenning from the start. Installed 1.8 directly, not 1.6 -> 1.8.

Sorry, I didn’t find time to play with this in the last days, and I won’t have time today either.

But I did compare the mate-panel-branding packages now. The result is that mate-panel-branding-openSUSE-13.1 (from MATE:1.6) and mate-panel-branding-upstream are exactly the same, but mate-panel-branding-openSUSE-13.2 (from MATE:Current, i.e. 1.8) is completely different.
That would explain of course why the panel works in 1.8 with the upstream branding or with 1.6’s openSUSE branding, but not with 1.8’s openSUSE branding.

I suspect this change to be the culprit:


Sun Mar  2 15:31:58 UTC 2014 - p.drouand@gmail.com
- Bump version to 13.2
- Upload opensuse.layout to source
- Use a default layout configuration file to use gnome-main-menu by 
  default
- Remove redundant layout install

So apparently the 1.8 openSUSE branding needs gnome-main-menu (why?), but this isn’t installed by the package dependencies (that’s a packaging bug IMHO).
I suppose the panel would appear if you install gnome-main-menu, but haven’t tested this yet.
It would explain though that it worked for me with the 1.8 openSUSE branding, as I do have gnome-main-menu installed.

Regarding the conflict:
They updated mate-desktop to 1.8.1 recently, but the rest is still at 1.8.0. The other packages do require a mate-desktop (mate-desktop-gsettings-schemas in particular) in the exact same version like they have themselves, i.e. 1.8.0.
I have no idea if only the requirement is too strict, or they simply “forgot” to update the other packages as well.

Ignoring the conflict should be ok though.

Sorry, my mind was playing me tricks…
I do not have gnome-main-menu installed. I had it installed years ago when it (and GNOME2) were still part of the distribution.

So I guess that in my case it indeed was the existing 1.6 user configuration that made it work.

Note to myself:
I’ll have to test whether installing gnome-main-menu would help on a fresh MATE:Current install.

Small update:
I tried that now, and could reproduce the missing panel issue. But I had to create a new user, the old user still had a working panel.
I found where this is saved now, in ~/.config/dconf/user, so it seems to use dconf as well (like GNOME3).

Intalling gnome-main-menu did not help. mate-panel still complained about “Cant find layout file” when starting it manually (after killing it because it was already running)

Installing mate-panel-upstream instead of mate-panel-openSUSE fixed it. After starting it once with the upstream branding, it would then also work with the openSUSE branding.

Btw, I didn’t get any conflict regarding “mate-desktop-gsettings-schemas” when installing it, so at least those dependencies seem to have been fixed in the meantime.

PS: Apparently also killing mate-panel and starting it again fixes the missing panel as well (or logout/login?), and it’s there now everytime I start it. So there’s not really a need for installing the upstream branding.

Because of unsolved differences (and at least errors) between 1.8 and 1.6, that may occur,
a safer way would be to remove all pattern and repo packages from 1.6 and the repo 1.6 (and Mate 1.6 user and system config files),
before installing 1.8 .

In practise an 1.8 repo besides 1.6 repo and an update, did not work on an other machine and would give more certain errors.

A secure method of install 1.8, is really to select all packages from the Mate repository or that ones you need, wich ones, ask on mate-desktop.org.
You can select them under yast GUI/command-line -> software manager -> show/filter -> “repository”.

It would install all packages from Mate - for Mate, but only from this repository, but maybe Mate needs packages from outside too.
So a complete anwser is needed, hopefully they select a pattern.

The X-server have to be installed too, the X-server pattern is good for that.

A method of small size would be to see wich packages the pattern of 1.6 needs, and install that on 1.8,
but maybe 1.8 needs more than 1.6 .

So a safe way would be to select all packages, or certain packages.

Yes maybe Mate from an outside repo could be replaced with Mate from openSUSE repos,
but an extra option for that would be nice, to avoid forcing updates of 1.6 or 1.8 .
A small link for 1.8 in X11:MATE:STABLE: would be good for the the people that do not know about X11:MATE:Current.

The Mate “upstream” packages do work here from a resh Mate 1.8 install, without having Mate there before on my system.
I selected them in a dependency miss, because i though upstream sounds like the intenion to use always the newer things.

Solved - “-n” wasn’t there by default, so didn’t have to put it. Finally worked with “Exec=caja --sync”.

This would a good answer on that topic.

How to solve panel crashes and auto-logouts?

Maybe it is because of missed packages around the system, a full install of X-server pattern and all packages from the Mate repo would solve this.

upstream error

Maybe a running Mate needs mate-panel-branding-upstream, other not importand things of Mate need mate-panel-branding-openSUSE-13.1.
But mate-panel-branding-openSUSE-13.1 and mate-panel-branding-upstream may do not work together, and mate-panel-branding-upstream is for a running system.

So apparently the 1.8 openSUSE branding needs gnome-main-menu (why?)

I think this change gives a possibility to run gnome-main-menu, and has gnome-main-menu not as dependency.
And maybe they want to give only the possibility to use it as default.

It would explain though that it worked for me with the 1.8 openSUSE branding, as I do have gnome-main-menu installed.

Wich branding to you mean exactly?

“Cant find layout file” when starting it manually

Maybe mate-settings-daemon is not running.
Ah, i remember i had this error too, the solution i dont know anymore.

But the installation of all Mate 1.8 packages without Mate before, the X-Server pattern and the branding upstream packages is working here.

But this worked fine here. The 1.6 system config files should be removed/replaced via the packages, and the user config files made no problem whatsoever (it even prevented the problem).
And you don’t have to remove the pattern, as a pattern is just a list of packages anyway.

In practise an 1.8 repo besides 1.6 repo and an update, did not work on an other machine and would give more certain errors.

What repo? What errors?
I agree it would be better to remove the 1.6 repo before adding the 1.8 repo, though.

You can select them under yast GUI/command-line -> software manager -> show/filter -> “repository”.

Small correction: the button is labelled “View”.

It would install all packages from Mate - for Mate, but only from this repository, but maybe Mate needs packages from outside too.

Of course it needs packages from “outside”. But those should get installed automatically via package dependencies.

The X-server have to be installed too, the X-server pattern is good for that.

Obviously. But this should be taken care of by package dependencies as well I think. Haven’t checked though.
At least a “Minimal X-server installation” should install the X-server anyway… :wink:

A method of small size would be to see wich packages the pattern of 1.6 needs, and install that on 1.8,
but maybe 1.8 needs more than 1.6 .

Yes. That’s what we tried to do earlier already.
I posted a list of packages that the 1.6 pattern installs, but this was not enough apparently.

So a safe way would be to select all packages, or certain packages.

Yes.

Yes maybe Mate from an outside repo could be replaced with Mate from openSUSE repos,
but an extra option for that would be nice, to avoid forcing updates of 1.6 or 1.8 .

[QUOTE]A small link for 1.8 in X11:MATE:STABLE: would be good for the the people that do not know about X11:MATE:Current.

Well, the maintainers have to decide that. Apparently their decision is to only provide X11:MATE:Current, so that people do not have to change repos for upgrading to the latest version, just like the KDE Maintainers do now.

And how would people “that do not know about X11:MATE:Current” know about X11:MATE:STABLE:1.8?

[/QUOTE]The Mate “upstream” packages do work here from a resh Mate 1.8 install, without having Mate there before on my system.
I selected them in a dependency miss, because i though upstream sounds like the intenion to use always the newer things.[/QUOTE]
No. “Upstream” means the default configuration/branding that upstream (i.e. the MATE developers) provides.
As opposed to the “openSUSE” branding packages which contain openSUSE’s default configuration/branding, which might differ.

Maybe it is because of missed packages around the system, a full install of X-server pattern and all packages from the Mate repo would solve this.

Maybe.
Or maybe it could be one of dozen other problems, f.e. a buggy/broken graphics driver.
I did not have such an issue here.

Maybe a running Mate needs mate-panel-branding-upstream, other not importand things of Mate need mate-panel-branding-openSUSE-13.1.
But mate-panel-branding-openSUSE-13.1 and mate-panel-branding-upstream may do not work together, and mate-panel-branding-upstream is for a running system.

Of course, mate-panel-branding-openSUSE-13.1 and mate-panel-branding-upstream do not work together, you cannot even install them both as they conflict.
mate-panel-branding-upstream is not “for a running system” though. It worked here with the openSUSE branding too, as I wrote.

I think this change gives a possibility to run gnome-main-menu, and has gnome-main-menu not as dependency.
And maybe they want to give only the possibility to use it as default.

Possibly. As I wrote already, installing gnome-main-menu did not fix this issue anyway. This was just a guess by me.
And as I wrote as well, after killing mate-panel, it starts fine now every time even with the openSUSE branding.

Wich branding to you mean exactly?

mate-panel-branding-openSUSE in this case.

Maybe mate-settings-daemon is not running.
Ah, i remember i had this error too, the solution i dont know anymore.

I don’t think mate-settings-daemon has to be running.
I can start mate-panel just fine now even inside KDE (with mate-settings-daemon definitely not running :wink: ).

As I said, apparently the solution was killing mate-panel and starting it again.

What repo? What errors?

Mate. have to be correct of course ;).

And you don’t have to remove the pattern, as a pattern is just a list of packages anyway.

If openSUSE is really able to remove patterns (the packages of course) anyway - that was not implemented on Tumbleweed.

Of course it needs packages from “outside”. But those should get installed automatically via package dependencies.

Yes you are right, i mean other packages not dependencies, like hddtemp that Mate can handle in the sensors applet, but it is not installed by default.
But its no Problem if packages are not installed that Mate can use anyway but its like missing features.

[QUOTE]The X-server have to be installed too, the X-server pattern is good for that.
Obviously. But this should be taken care of by package dependencies as well I think. Haven’t checked though.[/QUOTE]
Yes its easy, may users only want the Mate files without Xserver, an option or even a mate package like mate-with-xserver would be nice for that.

Well, the maintainers have to decide that. Apparently their decision is to only provide X11:MATE:Current

A bug report for everything here should be done, i have no time now, install Mate is not easy to install, Xserver is not easy (the user have to know), upgrading is not easy.

And how would people “that do not know about X11:MATE:Current” know about X11:MATE:STABLE:1.8?

May they only know, look or search in the place X11:MATE:STABLE, they have to know other places and may not look on the openSUSE Mate portal website or on the site
download.opensuse.org/repositories/, like i did - to know about an update without automatic message is hard.

mate-panel-branding-upstream is not “for a running system” though

Ups, i mean basically the upstream branding packages around :==)

The pulseaudio server (sound at least) had to be installed here manually - i used the method of an fresh install of Mate, by selecting all packages from the Mate 1.8 repo.

As I said, it’s not necessary to remove the pattern, as removing a pattern does not remove any packages (this is unrelated to Tumbleweed).
A pattern is just a pseudo package that requires/recommends/suggests other packages to be installed.
Those packages remain installed when you uninstall the pattern package.
The option “Cleanup when uninstalling packages” in YaST might make a difference though.

Yes you are right, i mean other packages not dependencies, like hddtemp that Mate can handle in the sensors applet, but it is not installed by default.
But its no Problem if packages are not installed that Mate can use anyway but its like missing features.

Hm. Should hddtemp f.e. be forced upon all users even if they don’t want/need that functionality?
hddtemp is not even included in openSUSE.

Yes its easy, may users only want the Mate files without Xserver, an option or even a mate package like mate-with-xserver would be nice for that.

???
What sense does MATE make without an Xserver?

And at least the login manager packages (kdm, gdm, lightdm, …) would require the Xserver anyway.

A bug report for everything here should be done, i have no time now, install Mate is not easy to install, Xserver is not easy (the user have to know), upgrading is not easy.

I agree.
But as I mentioned already, maybe they do plan to add a pattern/installation option for MATE to the installer for 13.2 anyway.
MATE 1.8 has been added to Factory already.

May they only know, look or search in the place X11:MATE:STABLE, they have to know other places and may not look on the openSUSE Mate portal website or on the site
download.opensuse.org/repositories/, like i did - to know about an update without automatic message is hard.

Ok, but how would they know about X11:MATE:STABLE in the first place?
Anyway, IMHO this point is rather moot because MATE will be included in the next openSUSE distribution anyway, as mentioned.

Ups, i mean basically the upstream branding packages around :==)

The openSUSE branding packages work fine. Only mate-panel-branding-openSUSE causes a problem apparently.
But still, you can get mate-panel to work with the openSUSE branding as well.

I haven’t checked the Factory version yet.