Project

General

Profile

Actions
Copy link

action #15578

closed

Test fails in glxgears - command does not exist because packagekit was masked during package installation

Added by mkravec over 7 years ago. Updated over 7 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
okurz
Category:
Bugs in existing tests
Target version:
openQA Project - Milestone 4
Start date:
2016-12-20
Due date:
% Done:

0%

Estimated time:
Difficulty:

Description

Packagekit can not install Mesa-demo-x because it is masked. Results in missing glxgears command.

Observation

openQA test in scenario sle-12-SP3-Server-DVD-x86_64-we@64bit fails in
glxgears

Reproducible

Fails since (at least) Build 0194

Expected result

Last good: 0193 (or more recent)

Further details

Always latest result in this scenario: latest

Related issues 1 (0 open — 1 closed)

Related to openQA Tests - action #13004: re-enablement of modules from BIGTEST (was: what the heck is BIGTEST?)Resolvedokurz2016-08-03

Actions
Actions
Copy link
 #1

Updated by okurz over 7 years ago

packagekit is masked in some scenarios but not in others.

E.g. standard gnome scenario works
while we does not.

The reason is that "we" calls "imagemagick" and "ghostscript" which call pkcon_quit but never "unquit". I see three possibilities for continuing

  1. Use same call in glxgears as in imagemagick and ghostscript, i.e. zypper_call
  2. Use pkcon call in imagemagick and ghostscript, too
  3. Unmask packagekit every time ensure_installed is called

I prefer 3 combined with 2

Actions
Copy link
 #2

Updated by okurz over 7 years ago

  • Status changed from New to In Progress

private branch "fix/packagekit_unavailable", waiting for http://lord.arch/tests/5497

Actions
Copy link
 #4

Updated by okurz over 7 years ago

  • Status changed from In Progress to Feedback

PR merged, considered done but waiting for more verification by tests. The failures I could find related to "glxgears" are e.g. in usbinstall that the package could not be found somehow anymore. Let's see if this is something usbinstall specific.

Actions
Copy link
 #5

Updated by okurz over 7 years ago

  • Target version set to Milestone 4
Actions
Copy link
 #6

Updated by okurz over 7 years ago

  • Status changed from Feedback to Resolved

remaining failures in USBInstall are definitely because of bsc#1012258. There was one more problem in Tumbleweed rescuecd https://openqa.opensuse.org/tests/329647#step/glxgears/8 fixed by https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/2283 . We should be good now.

Actions
Copy link
 #7

Updated by okurz over 7 years ago

  • Related to action #13004: re-enablement of modules from BIGTEST (was: what the heck is BIGTEST?) added
Actions
Copy link

Also available in: Atom PDF