YAST applets not launching

English Applications
#1

Just wondering if this is affecting anyone else.

Sometime between yesterday and today, I can launch YAST/YAST2 (both are affected the same way) but whenever I try to launch almost any applet (only a few work) I get the following error

terminate called after throwing an instance of 'YUIPluginException'
  what():  Couldn't load plug-in qt
YaST got signal 6 at YCP file Wizard.ycp:720
/sbin/yast2: line 431:  4509 Aborted                 $ybindir/y2base $module "$@" "$SELECTED_GUI" $Y2_GEOMETRY $Y2UI_ARGS

Am running 12.3 but with
13.1 components, mostly systemd (version 202).

Have not had any problems running the above for awhile, the problem started appearing doing an update.
Just ran an update but without effect. I don’t remember that YAST is one of the components that is non-standard but this is mine

# zypper info yast2
Information for package yast2:
------------------------------
Repository: openSUSE:Factory
Name: yast2
Version: 2.23.28-1.1
Arch: x86_64
Vendor: openSUSE
Installed: Yes
Status: up-to-date
Installed Size: 3.6 MiB
Summary: YaST2 - Main Package
Description: 
This package contains scripts and data needed for SuSE Linux
installation with YaST2

TSU

#2

On 05/16/2013 07:06 PM, tsu2 wrote:
> Am running 12.3 but with
> 13.1 components, mostly systemd (version 202).

there is no 13.1 yet, so i assume you mean you are running factory
code…in which case you should be posting to the pre-release/beta
forum: http://tinyurl.com/2du7r4s (you can pm a moderator to move
this thread, or you can click the triangular icon at the bottom of
this browser pane and ‘report’ the thread for moving)

> Have not had any problems running the above for awhile, the problem
> started appearing <without> doing an update.

during that “for awhile” did the machine run continuously and then
the trouble started after the first boot following an update (or any
install of any software of anykind?)

hmmmmm…also, are you running straight 12.3 with factory on top or
is it Tumbleweed with factory?

and, your DE is KDE?? (i guess because i see qt mentioned in the
error)…but which KDE?

–
dd
http://tinyurl.com/DD-Caveat

#3

Do you have libyui-qt5 installed? 12.3 only contains libyui-qt4, but your YaST comes from Factory.

I would suggest you check that all yast packages are coming from the same repo, otherwise that can lead to such problems.

#4

On 05/16/2013 07:06 PM, tsu2 wrote:
> terminate called after throwing an instance of ‘YUIPluginException’
> what(): Couldn’t load plug-in qt
> YaST got signal 6 at YCP file Wizard.ycp:720
> /sbin/yast2: line 431: 4509 Aborted $ybindir/y2base $module “$@” “$SELECTED_GUI” $Y2_GEOMETRY $Y2UI_ARGS

a nearly identical error message was posted to the mail list on the
16th by another using factory code…

sure looks like a factory bug to me…(one/both of you needs to log
it, i guess)

follow that other thread (contact other reporter?) here:
http://lists.opensuse.org/opensuse-factory/2013-05/msg00252.html

–
dd

#5

Bugzilla report:
https://bugzilla.novell.com/show_bug.cgi?id=820428

#6

Thx all,
Although I’ve been offline for awhile I’ve come to similar but not exactly same conclusions what has been already posted… Yes, the problem is Factory packages but unless I’m missing something libyui5 may not be the culprit.

I’m not sure when/where libyui5 is used, but when I do a dependency check on yast, followed by inspecting the yast_basis pattern, it <seems> to me the version of YAST I have installed is still referencing libyui4.

Although this thread might be considered referencing “Beta” code, actually the solution raises an interesting question that’s not Beta specific, how would one specify installing a specific pattern, provided by a specified repository? The rest of this post describes what I tried, and at the end the desired solution (unresolved for now).

So,
Description of the current situation:
YAST is installed using Factory packages. This was unintentional, is the result of installing a package from Factory which enabled the Factory repo, then running “zypper up” which updated not only the one package but all packages where a Factory version exists. Lesson be learned… Normally leave the Factory repo disabled, and manually track the specified package. This incident might even lead to a Feature Request that better controls how the Factory repo is managed.

Verification Yast packages are from Factory
The following lists all packages with “yast” in the name from the Factory repo, and yes plenty of yast packages are listed

zypper se -r openSUSE:Factory | grep yast

Initial attempts to “update” packages by force installing from non-Factory sources
Disable Factory repo

zypper mr -d openSUSE:Factory

1. Attempt to force install by pattern
List patterns

zypper se -t pattern

Force install pattern with Factory installed, assumption is that all packages listed in the pattern would be re-installed, but appears not to be the case

zypper in -f -t pattern yast2_basis

Force install attempt results in “nothing to do”

2. Attempt to force install the yast package, hoping dependencies would also be updated

zypper in -f yast2

Results in the yast package re-installed but nothing else(no dependencies) is re-installed

3. Analyze Dependencies
This may be where the problem exists, dependencies don’t specify a required version, they specify minimal versions so Factory versions are left untouched.

zypper se --requires yast2

**
Desired solution, Is it Possible?**
So, short of creating a list of all currently installed YAST packages, manually uninstalling them and then re-attempting to install yast (likely by pattern), is there another method which can be recommended? Ideally, no package should be uninstalled, but force install a pattern from a specified repo which should over-write existing… I’d expect this approach if can be made to work should be least risky and should easily pick up existing configurations.

If there is no perceived risk, then I might just rm all packages with “yast” in the name, then with the Factory repo disabled install the yast_basis pattern plus the special yast applets. If re-installing the yast applets don’t pick up the existing configurations, I’d expect that re-installing the applets with the corresponding service (eg FTP, LxC, virtualization, etc) should re-build the configs.

TIA,
TSU

#7

On 05/18/2013 11:46 PM, tsu2 wrote:
> This was unintentional, is
> the result of installing a package from Factory which enabled the
> Factory repo, then running “zypper up”

yep. zypper patch is mostly safe (pulls only from update) but up is
dangerous (if you don’ have enabled repos under firm, and correct,
control) and zypper dup is usually fatal (at least partially fatal)
with any repos other than ‘the five’. (unless, of course distro
upgrade is actually expected and the repo so set)

–
dd
http://tinyurl.com/DD-Caveat

#8

You have the Factory version installed which requires libyui5 (libyui4 isn’t contained in Factory), but fails to specify that requirement…

So,
Description of the current situation:
YAST is installed using Factory packages. This was unintentional, is the result of installing a package from Factory which enabled the Factory repo, then running “zypper up” which updated not only the one package but all packages where a Factory version exists. Lesson be learned… Normally leave the Factory repo disabled, and manually track the specified package. This incident might even lead to a Feature Request that better controls how the Factory repo is managed.

Factory’s packages have the same vendor string as 12.3, namely “openSUSE”. So “zypper up” will switch all your packages to the ones from Factory if their version number is higher (which would be true for most of them, I guess)

Why are you using packages from Factory at all? Use them from their devel project (those are available for 12.3 as well mostly).

Verification Yast packages are from Factory
The following lists all packages with “yast” in the name from the Factory repo, and yes plenty of yast packages are listed

zypper se -r openSUSE:Factory | grep yast

Initial attempts to “update” packages by force installing from non-Factory sources
Disable Factory repo

zypper mr -d openSUSE:Factory

1. Attempt to force install by pattern
List patterns

zypper se -t pattern

Force install pattern with Factory installed, assumption is that all packages listed in the pattern would be re-installed, but appears not to be the case

zypper in -f -t pattern yast2_basis

Force install attempt results in “nothing to do”

2. Attempt to force install the yast package, hoping dependencies would also be updated

zypper in -f yast2

Results in the yast package re-installed but nothing else(no dependencies) is re-installed

3. Analyze Dependencies
This may be where the problem exists, dependencies don’t specify a required version, they specify minimal versions so Factory versions are left untouched.

zypper se --requires yast2

**
Desired solution, Is it Possible?**
So, short of creating a list of all currently installed YAST packages, manually uninstalling them and then re-attempting to install yast (likely by pattern), is there another method which can be recommended? Ideally, no package should be uninstalled, but force install a pattern from a specified repo which should over-write existing… I’d expect this approach if can be made to work should be least risky and should easily pick up existing configurations.

If there is no perceived risk, then I might just rm all packages with “yast” in the name, then with the Factory repo disabled install the yast_basis pattern plus the special yast applets. If re-installing the yast applets don’t pick up the existing configurations, I’d expect that re-installing the applets with the corresponding service (eg FTP, LxC, virtualization, etc) should re-build the configs.

TIA,
TSU

According to your repo configuration, you could just run “zypper dup”…
Or install libyui-qt5 and libyui-qt-pkg5 to get YaST running again and then use the “Switch all system packages…” functionality in YaST (or "All in this list->Update unconditionally in the context menu, so you could also combine this with the search function).

#9

Cool Thx!.
So first,
Your suggestion to install libyui-qt5 and libyuiqt-pkg5 resolved the YAST issue, so that seems to resolve the Factory code(assume that’s being fixed, it didn’t seem to be implemented as of a couple hrs ago)… The package dependencies for yast2 are incorrect, these packages need to be installed <and> the corresponding “version 4” packages should be uninstalled.

As for switching all packages, I don’t see that (and hadn’t heard of that in YAST… But I suspect you may be referring to
(after disabling the Factory repo which is required for the above)
YAST Software Manager > Package > All Packages > Update Unconditionally

Yes, I’d considered “zypper dup” also but was uncertain whether it would wipe out anything important in my system. Nothing specific comes to mind, but for something which is so far reaching, it gives me pause.

TSU

#10

Yes, that’s what I wrote. The package dependencies are missing/wrong.
And for the ncurses version to work you would need libyui-ncurses5 and libyui-ncurses-pkg5.

As for switching all packages, I don’t see that (and hadn’t heard of that in YAST… But I suspect you may be referring to
(after disabling the Factory repo which is required for the above)
YAST Software Manager > Package > All Packages > Update Unconditionally

No, I explicitely mentioned that, too.
But if you select a repo in the “Repositories” tab (you might have to create that by using the “View” dropdown) there is a line above the package list that says “Switch all system packages to the versions in this repository”, on which you can click. (it’s the same as “zypper dup --from reponame”)
See here: https://en.opensuse.org/SDB:Vendor_change_update#Full_repository_Vendor_change

#11

OK,
That’s interesting.
On my YAST, for whatever reason that “switch all system packages…” is one black blur which looks like just a black bar. Never thought to click on it, but once clicked there is a link to cancel switching.so I can guess what the black blur should have displayed.

So, it’s cool that this functionality is built into YAST, I wonder if this functionality is not available in zypper?

TSU

#12

The referenced SDB link suggests a zypper command for this, will have to think about whether it really is the same (likely)

#13

Well, yes:

:wink:

#14

Will take some time to consider preferred path going forward.

Have been very happy for awhile with an advanced view of upcoming systemd (v202).
Multimedia seems to have benefitted.

So,
I’m not averse to keeping some Factory things.

Attempted first to return only yast components to oss

zypper in --from repo-oss -t yast2_basis

That resulted in all components from oss instead of Factory but looks to have broken yast in the same way (except now YAST wants v4 components with both v4 and v5 components installed). So, to be clear…

It appears when installing and/or removing the required dependency packages, the resolver properly manages the packages.
But it appears that when running a mass operation like installing/removing a pattern or executing a “dup” operation dependencies are not managed properly.

Then considered doing a mass vendor change to oss

zypper dup --from repo-oss

But I’m prompted for options with application and library change warning about various downgrades. Am considering a “quiet” dup if it’s possible, but for now have re-run “zypper up” and installed the necessary files manually.

In fact, I’ll have to consider the benefits of leaving Factory, there is a lot of good stuff and most have not broken, only this YAST issue. Of course continueing to run Factory will almost certainly invite future instability like what happened this time in YAST.

Probably the most important issue to consider (and should be of interest to avoid my situation in the first place) is understanding and configuring “allowedVendorChange” According to the the SDB Vendor Change it suggests how this would be enabled, but does that mean then that it should be disabled by default? On my machine the following is the setting to disable vendor change but notice it is disabled. There is no similar setting by default in zypper .conf

cat /etc/zypp/zypp.conf | grep allowVendorChange
# solver.allowVendorChange = false

So, still looking for certain answers…

TSU

#15

“zypp.conf” is the config for libzypp and is therefor respected by zypper and YaST. “zypper.conf” is just for zypper (the frontend) specific stuff.
So “solver.allowVendorChange” in zypp.conf is respected by zypper and YaST.
And it is disabled by default.

But, as I wrote before:
The packages in the Factory repo have the same vendor string as the packages in the 12.3 OSS repo. So “zypper up” will happily switch your packages to the Factory versions, regardless of that setting. (they are from the same vendor, this is no vendor change in this case)

So: Don’t add the Factory repo if you don’t want to run Factory!

If you want to try a few packages from Factory, take them from their devel project. Those are available for 12.3.
For example if you want to try the latest systemd package, take it from Base:System, that is also available for 12.3 and has a different vendor, so adding that repo wouldn’t cause trouble with “zypper up”.