Can I get back to 13.1 from Tumbleweed?

So I installed 13.1 originally and did a upgrade to Tumbleweed.

From what I heard and my own experience I found this is a big mistake, nvidia and many things keep getting broken and some packages inconsistency happens as well so can I get rid of those TW repos and get back to 13.1 repos?

Remove the Tumbleweed repo (with YaST->Software Repositories or “zypper rr”, or by just deleting the corresponding file in /etc/zypp/repos.d/), and run:

zypper dup

You can leave the other repos as they are (but this will automatically switch you to 13.2 when it is released), or better change “openSUSE-current” to “13.1” in the repos’ URLs (again, use YaST->Software Repositories for that, or edit the text files in /etc/zypp/repos.d/).

Thank you wolfi.
It asks me this when I dup

Problem: patterns-openSUSE-base-13.1-13.6.1.x86_64 requires module-init-tools, but this requirement cannot be provided
  deleted providers: kmod-compat-18-13.1.x86_64
uninstallable providers: module-init-tools-3.15-11.1.2.i586[openSUSE:Stable_OSS]
                   module-init-tools-3.15-11.1.2.x86_64[openSUSE:Stable_OSS]
 Solution 1: keep obsolete kmod-compat-18-13.1.x86_64
 Solution 2: deinstallation of patterns-openSUSE-base-13.1-13.6.1.x86_64
 Solution 3: break patterns-openSUSE-base-13.1-13.6.1.x86_64 by ignoring some of its dependencies

Choose from above solutions by number or cancel [1/2/3/c] (c) 

I chose c for now…

What should I do? Don’t know if it’s related, but I’m running on the second to the newest kernel I have, because under newest kernel nvidia doesn’t work there.

Install module-init-tools manually, and the “upgrade” should work:

sudo zypper in -f module-init-tools

This will likely want to remove kmod-compat though, which is ok.

And you would have to manually uninstall the Tumbleweed kernels afterwards. Use YaST->Software Management’s “Versions” tab for that.
Install kernel-desktop 3.11.10 there manually as well if that’s not done automatically, but I think it should.

OK. Just installed module init tools and uninstallled kmod.

However, can I keep the 3.15 kernel that is working well here?

Yes, you can.

But then you shouldn’t use the nvidia driver packages from the repo. Although, if you don’t install any kernel updates, the packages should actually work as well, as they do compile the kernel module for the running kernel when you install them, much like the .run installer.

OTOH, I forgot that you actually have an Optimus system.
So DO NOT install the nvidia driver from the repo, this won’t work!

Rather continue to use Bumblebee the same as before.

You could also add the Kernel:stable repo and install the latest stable kernel version from there (3.16), but then you are back to getting frequent kernel updates, which maybe would break the nvidia driver.

Hello wolfi,

I have 13.1 back now. There were some problem at the beginning after swtich, especially a problem with “pango”, which caused many programs not displaying fonts correctly. I reinstalled pango and the programs that were having problems now it seems all ok.

Two quick questions:

  1. I don’t play to add the stable kernel repo but I just stay with the working 3.15 kernel. Is that ok I keep using it until one day the distribution’s kernel goes up to 3.15 (still long way to go from 3.11)

  2. Is there way to lock vendor for a pacakge? The 13.1 repo wants to update a package that’s from my other repo, but it will break a software from that same repo if I use the distribution version package. How to prevent it from changing vendor. I know there’s a “lock” function, but I think it is different from lock vendor function.

Yeah, right.
Pango can be a bit problematic with its plugin cache that’s incompatible between versions.
Running “/usr/bin/pango-querymodules-32 --update-cache” and/or “/usr/bin/pango-querymodules-64 --update-cache” should fix that as well.
But if you re-install the packages this is done automatically.

  1. I don’t play to add the stable kernel repo but I just stay with the working 3.15 kernel. Is that ok I keep using it until one day the distribution’s kernel goes up to 3.15 (still long way to go from 3.11)

Yes, it is ok. You won’t get any updates though of course. But if it is working for you without problems that’s ok I suppose.
And 13.1’s kernel will never reach 3.15. There normally are no version upgrades in a released openSUSE version, so it will always stay at 3.11.
There have been discussions to upgrade it to 3.12 (which the next SLE will use) for easier maintenance, but I don’t know what has been decided regarding this.

  1. Is there way to lock vendor for a pacakge? The 13.1 repo wants to update a package that’s from my other repo, but it will break a software from that same repo if I use the distribution version package. How to prevent it from changing vendor. I know there’s a “lock” function, but I think it is different from lock vendor function.

YaST/zypper should not change vendor automatically. (as long as you don’t use “zypper dup” of course)
What two repos and which package are you talking about?

There is a “Allow vendor change” option in YaST’s “Options” menu. Check that this is not enabled.
And there’s this option in /etc/zypp/zypp.conf:

##
## EXPERTS ONLY: Per default the solver will not replace packages of
## different vendors, unless you explicitly ask to do so. Setting this
## option to TRUE will disable this vendor check (unless the application
## explicitly re-enables it). Packages will then be considered based on
## repository priority and version only. This may easily damage your system.
##
## CHANGING THE DEFAULT IS NOT RECOMMENDED.
##
## Valid values:  boolean
## Default value: false
##
# solver.allowVendorChange = false

This should be set to false or commented out (which it is by default) if you don’t want vendor changes.

[quote="“wolfi323,post:8,topic:102336”]
Yeah, right.
Pango can be a bit problematic with its plugin cache that’s incompatible between versions.
Running “/usr/bin/pango-querymodules-32 --update-cache” and/or “/usr/bin/pango-querymodules-64 --update-cache” should fix that as well.
But if you re-install the packages this is done automatically.



I just did that with both root and my user account with sudo, as if not it says permission denied to create a file there. 

However, I am trying a program xchat today, when I launch it from terminal it still shows error in console

"Pango-WARNING **: /usr/lib/pango/1.8.0/modules/pango-basic-fc.so: wrong ELF class: ELFCLASS32"

But xchat works without problem so far. I don't know if I should be worried as this error may cause problem in the future?

[QUOTE=wolfi323,post:8,topic:102336"]

YaST/zypper should not change vendor automatically. (as long as you don't use "zypper dup" of course)
What two repos and which package are you talking about?

There is a "Allow vendor change" option in YaST's "Options" menu. Check that this is not enabled.
And there's this option in /etc/zypp/zypp.conf:

EXPERTS ONLY: Per default the solver will not replace packages of

different vendors, unless you explicitly ask to do so. Setting this

option to TRUE will disable this vendor check (unless the application

explicitly re-enables it). Packages will then be considered based on

repository priority and version only. This may easily damage your system.

CHANGING THE DEFAULT IS NOT RECOMMENDED.

Valid values: boolean

Default value: false

solver.allowVendorChange = false


This should be set to false or commented out (which it is by default) if you don't want vendor changes.

[/quote]



Yeah I noticed that yesterday and I can confirm that the "allow..." is unchecked.

The pacakge is the one I had asked before. I had a problem with a program "Gabedit" due to lacking of a package called "libgtkglext-x11-1_0-0". You told me to do a vendor change for that package to the repo where Gabedit is from. The problem is fixed then. However I have now been back to 13.1 from TW, if I do a "zypper update" (not dup), it still asks me to update the libgtkglext package to the opensuse version. So I'm think to let that package sticking to the current repo.

Yes, the pango plugin cache is system global, so you need to run it as root, either when logged in as root or by using sudo (it’s not necessary to do both).

However, I am trying a program xchat today, when I launch it from terminal it still shows error in console

“Pango-WARNING **: /usr/lib/pango/1.8.0/modules/pango-basic-fc.so: wrong ELF class: ELFCLASS32”

Hm. 64bit programs should use /usr/lib64/pango/modules/…

But the 32bit command is just “pango-querymodules”, sorry.
So try to run “sudo pango-querymodules --update-cache”, maybe that will remove that message.

If not, try to remove both 32bit and 64bit caches and recreate them:

sudo rm /usr/lib/pango/1.8.0/modules.cache /usr/lib64/pango/1.8.0/modules.cache
sudo pango-querymodules --update-cache
sudo pango-querymodules-64 --update-cache

And what pango packages do you actually have installed now?

rpm -qa | grep pango

However I have now been back to 13.1 from TW, if I do a “zypper update” (not dup), it still asks me to update the libgtkglext package to the opensuse version. So I’m think to let that package sticking to the current repo.

Well, do you have the repo added to your system now (for 13.1)?
If not, the newer package is not found of course, and zypper update might want to update to the only available one because of dependencies.
Add the repo and zypper should keep the version from that repo.

You should of course change any additional repos that you might have had for Tumbleweed to their 13.1 incantations.
For advise, please post your repo list:

zypper lr -d
~> rpm -qa | grep pango
libpangox-1_0-0-0.0.2-4.1.3.x86_64
pango-tools-32bit-1.36.1-4.2.x86_64
libpangomm-1_4-1-2.34.0-2.1.2.x86_64
pangox-compat-0.0.2-4.1.3.x86_64
libpango-1_0-0-1.36.1-4.2.x86_64
pangox-devel-0.0.2-4.1.3.x86_64
pango-devel-1.36.1-4.2.x86_64
pango-tools-1.36.1-4.2.x86_64
libpango-1_0-0-32bit-1.36.1-4.2.x86_64

and

~> zypper lr -d
#  | Alias                            | Name                                               | Enabled | Refresh | Priority | Type   | URI                                                                             | Service
---+----------------------------------+----------------------------------------------------+---------+---------+----------+--------+---------------------------------------------------------------------------------+--------
 1 | Bumblebee                        | Bumblebee                                          | Yes     | Yes     |   99     | rpm-md | http://download.opensuse.org/repositories/X11:/Bumblebee/openSUSE_13.1/         |        
 2 | Extra                            | Extra                                              | Yes     | Yes     |   99     | rpm-md | http://download.opensuse.org/repositories/KDE:/Extra/KDE_Current_openSUSE_13.1/ |        
 3 | KDE_SC_packages                  | KDE SC packages                                    | Yes     | Yes     |   99     | rpm-md | http://download.opensuse.org/repositories/KDE:/Current/openSUSE_13.1/           |        
 4 | LibreOffice:Factory              | LibreOffice:Factory                                | Yes     | Yes     |   98     | rpm-md | http://download.opensuse.org/repositories/LibreOffice%3a/Factory/openSUSE_13.1/ |        
 5 | Science_BuildService             | Science_BuildService                               | Yes     | Yes     |   98     | rpm-md | http://download.opensuse.org/repositories/science/openSUSE_13.1/                |        
 6 | ftp.gwdg.de-suse                 | Packman Repository                                 | Yes     | Yes     |   99     | rpm-md | http://ftp.gwdg.de/pub/linux/packman/suse/openSUSE_13.1/                        |        
 7 | google-chrome                    | google-chrome                                      | Yes     | Yes     |   99     | rpm-md | http://dl.google.com/linux/chrome/rpm/stable/x86_64                             |        
 8 | google-talkplugin                | google-talkplugin                                  | No      | Yes     |   99     | rpm-md | http://dl.google.com/linux/talkplugin/rpm/stable/x86_64                         |        
 9 | home:ecsos                       | home:ecsos                                         | Yes     | Yes     |  100     | rpm-md | http://download.opensuse.org/repositories/home%3a/ecsos/openSUSE_13.1/          |        
10 | home_opensuse_zh                 | openSUSE for Chinese Users Project (openSUSE_13.1) | No      | No      |   99     | rpm-md | http://download.opensuse.org/repositories/home%3a/opensuse_zh/openSUSE_13.1/    |        
11 | openSUSE:Stable_OSS              | 13.1:Stable_OSS                                    | Yes     | Yes     |   99     | yast2  | http://download.opensuse.org/distribution/13.1/repo/oss/                        |        
12 | openSUSE:Stable_Updates          | 13.1:Stable_Updates                                | Yes     | Yes     |   99     | rpm-md | http://download.opensuse.org/update/13.1/                                       |        
13 | openSUSE:Stable_non-OSS          | 13.1:Stable_non-OSS                                | Yes     | Yes     |   99     | yast2  | http://download.opensuse.org/distribution/13.1/repo/non-oss/                    |                                                                                                                                                          
14 | openSUSE:Stable_non-OSS__Updates | 13.1:Stable_non-OSS__Updates                       | Yes     | Yes     |   99     | rpm-md | http://download.opensuse.org/update/13.1-non-oss/                               |                                                                                                                                                          
15 | virtualbox                       | VirtualBox for openSUSE 12.3                       | Yes     | Yes     |  120     | rpm-md | http://download.virtualbox.org/virtualbox/rpm/opensuse/12.3                     |                                         

The package gabedit needs is in the repo home:ecsos, which has a priority 98. But zypper update just wants to change it. And that pango error just can’t go away.

Looks ok.

and

~> zypper lr -d

Looks ok, too.

The package gabedit needs is in the repo home:ecsos, which has a priority 98. But zypper update just wants to change it.

Hm? Your home:ecsos has priority 100.
And gabedit is only available in science, so it should need the libgtkglext-x11 from science.
There is no libgtkglext-x11 in home:ecsos anyway AFAICS.

Your science repo has the priority 98 though, so maybe that was just a typo?

But what libgtkglext-x11 do you actually have installed now?

rpm -qi libgtkglext-x11-1_0-0

And that pango error just can’t go away.

Hm.
And this only happens with xchat?
Which package do you have installed exactly?

rpm -qi xchat

On 2014-08-16 10:56, bonedriven wrote:

> 2. Is there way to lock vendor for a pacakge? The 13.1 repo wants to
> update a package that’s from my other repo, but it will break a software
> from that same repo if I use the distribution version package. How to
> prevent it from changing vendor. I know there’s a “lock” function, but I
> think it is different from lock vendor function.

That’s happens when the update comes from the update repo, ie, it is a
patch. They don’t obey vendor lock, so you have to taboo the update instead.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

Yes, but a patch normally only applies when a lower (than the patch) package version/revision is installed.

And this cannot be the problem in this case anyway, because there is no update to libgtkglext-x11 (the package he is talking about) in the update repo.