Bug 1211748 - [Migration][Build 102.1] openQA test fails in yast2_migration due to libvmaf
Summary: [Migration][Build 102.1] openQA test fails in yast2_migration due to libvmaf
Status: NEW
Alias: None
Product: PUBLIC SUSE Linux Enterprise Server 15 SP5
Classification: openSUSE
Component: Basesystem (show other bugs)
Version: unspecified
Hardware: Other Other
: P5 - None : Normal
Target Milestone: ---
Assignee: E-mail List
QA Contact:
URL: https://openqa.suse.de/tests/11194095...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-05-26 09:27 UTC by Sofia Syrianidou
Modified: 2023-05-31 08:11 UTC (History)
0 users

See Also:
Found By: openQA
Services Priority:
Business Priority:
Blocker: Yes
Marketing QA Status: ---
IT Deployment: ---


Attachments
screenshot (11.88 KB, image/png)
2023-05-26 09:27 UTC, Sofia Syrianidou
Details
y2logs (11.59 MB, application/x-bzip)
2023-05-26 09:30 UTC, Sofia Syrianidou
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sofia Syrianidou 2023-05-26 09:27:21 UTC
Created attachment 867239 [details]
screenshot

While attempting to do a yast2 migration from SLE 15 SP4 to the latest build of SLE 15 SP5, the automated migration fails because a manual intervention is needed. When pressing Change-> Packages, the problem appears to be that there is a dependency issue between the installed package libvmaf1-2.3.1-bp154.5.1.x86_64 and the package libvmaf1-2.2.0-150400.1.8.x86_64 . See attached screenshot.

If we chose to install libvmaf1-2.2.0-150400.1.8.x86_64 , the upgrade finishes successfully and the system works after first boot.


## Observation

openQA test in scenario sle-15-SP5-Migration-from-SLE15-SPx-Milestone-x86_64-online_sled15sp4_rmt_basesys-desk-we-phub-python3_def_full_y@64bit fails in
[yast2_migration](https://openqa.suse.de/tests/11194095/modules/yast2_migration/steps/14)

## Test suite description
The base test suite is used for job templates defined in YAML documents. It has no settings of its own.


## Reproducible

Fails since (at least) Build [102.1](https://openqa.suse.de/tests/11189097)


## Expected result

Last good: [93.2](https://openqa.suse.de/tests/10967705) (or more recent)


## Further details

Always latest result in this scenario: [latest](https://openqa.suse.de/tests/latest?arch=x86_64&distri=sle&flavor=Migration-from-SLE15-SPx-Milestone&machine=64bit&test=online_sled15sp4_rmt_basesys-desk-we-phub-python3_def_full_y&version=15-SP5)
Comment 1 Sofia Syrianidou 2023-05-26 09:30:05 UTC
Created attachment 867240 [details]
y2logs
Comment 2 Lukas Ocilka 2023-05-26 14:37:19 UTC
Please see https://en.opensuse.org/openSUSE:How_to_Write_a_Good_Bugreport

Minor issue: Please, don't report failing openQA test-cases, report bugs instead. We debug and fix bugs, we don't debug or fix failing test-cases. An openQA test-case is usually quite a complex scenario with several hidden expectations, dependencies, etc. These must be spelled out or eliminated first.

--> The fact is that upgrade (migration) contains an issue, whether this is an 
    openQA test or manual testing does not really matter

Normal: Don't report wrong content of repositories, package conflicts, incorrectly built media, errors or timeout of some commandline tools, etc. as Installer/YaST bug. Use something that fits better or just Other.

--> Obviously, when there is a version / package conflict, it's the Installer's 
    task to inform the user and let them decide. So, if reported as an installer 
    issue, it should be, ehm, closed as invalid. On the other hand, when reported 
    as "Other" or "Basesystem", i.e., package conflict, then it's a real bug.

Changing the component and reassigning.