Bugzilla – Bug 1218332
Dependency issue: the installed wireshark-ui-qt-3.6.17-150000.3.103.1.s390x requires 'wireshark = 3.6.17', but this requirement cannot be provided
Last modified: 2024-03-06 06:49:42 UTC
Created attachment 871522 [details] y2log_wireshark_dependency_issue This issue happens on SLES-15SP4/SP5 s390x arch Steps: - Install SLES15SP5 by autoyast installation, all patterns selected, and update the packages to latest, the system role is textmode. After installation, de-register the system and publish the image - Boot the image and register the system with live patching, container module, legacy module, transactional server module, public cloud module, and web scripting module - Then fully patch the packages Then observed an conflict: ------------------------------ Problem: the installed wireshark-ui-qt-3.6.17-150000.3.103.1.s390x requires 'wireshark = 3.6.17', but this requirement cannot be provided ------------------------------ Please find the attached y2log and the openqa test results as below: 15SP5 job: https://openqa.suse.de/tests/13135631#step/patch_sle/103 15SP4 job: https://openqa.suse.de/tests/13135566#step/patch_sle/117
You need the desktop applications module enabled to get wireshark-ui-qt It was probably enabled during installation, but no longer is now.
Thanks for your info, I will check the installation case and update results here.
(In reply to Marcus Meissner from comment #1) > You need the desktop applications module enabled to get wireshark-ui-qt > > It was probably enabled during installation, but no longer is now. Yes, desktop applications module is enabled during installation, and after reboot it and re-registering the image, we didn't register desktop applications module. Here is a VR that re-register it, the dependency issue is gone: https://openqa.suse.de/tests/13186559#step/patch_sle/132 We will update the installation case to exclude desktop applications module during installation, already filed a ticket: https://progress.opensuse.org/issues/153043 Thanks for your info and this bug report can be close now, thanks.
We are still seeing the particular failure after removing the Desktop applications module from both the parent test that produces the hard disk that the failing test boot into, and the failing test itself: https://openqa.suse.de/tests/13307192#step/patch_sle/96 This only happens fos s390x arch. Could we be missing something?
A bit though to debug as the zypper.log is a bit strange to read b/c of the length: Basesystem_Module, which contains the wireshark-3.6.17-150000.3.103.1.s390x.rpm, gets disabled: > 2024-01-22 05:14:50 <1> susetest(13230) [zypp] RepoFileReader.cc(repositories_in_stream):217 - alias : Basesystem_Module_15_SP5_s390x:SLE-Module-Basesystem15-SP5-Debuginfo-Updates > 2024-01-22 05:14:50 <1> susetest(13230) [zypp] RepoFileReader.cc(repositories_in_stream):217 - name : SLE-Module-Basesystem15-SP5-Debuginfo-Updates > 2024-01-22 05:14:50 <1> susetest(13230) [zypp] RepoFileReader.cc(repositories_in_stream):217 - enabled : 0 < !!! > 2024-01-22 05:14:50 <1> susetest(13230) [zypp] RepoFileReader.cc(repositories_in_stream):217 - autorefresh : 1 > 2024-01-22 05:14:50 <1> susetest(13230) [zypp] RepoFileReader.cc(repositories_in_stream):217 - url : https://updates.suse.com/SUSE/Updates/SLE-Module-Basesystem/15-SP5/s390x/update_debug?PPOBsM9iadnstV7DR9IPkIZR9Sg6ixK-q7M81yfiLqJx1i1lIWbnyzGxiNJHL0AGCmD3wdIzNtDnXFPft9W4HK56_K7C_UultslHOdhDsNZG6tvE65qwkudVFKa3ltM9sXP-clmFhgtoNWDJE-lRnItjpZF7Z-zkBpDG > 2024-01-22 05:14:50 <1> susetest(13230) [zypp::media++] RepoInfo.cc(probeCache):65 Probed cached type N/A at > 2024-01-22 05:14:50 <1> susetest(13230) [zypp] RepoFileReader.cc(repositories_in_stream):217 - type : N/A > 2024-01-22 05:14:50 <1> susetest(13230) [zypp] RepoFileReader.cc(repositories_in_stream):217 - priority : 99 > 2024-01-22 05:14:50 <1> susetest(13230) [zypp] RepoFileReader.cc(repositories_in_stream):217 - gpgcheck : D(Y) repoD(Y)* sig? pkgD(Y)* > 2024-01-22 05:14:50 <1> susetest(13230) [zypp] RepoFileReader.cc(repositories_in_stream):217 - service : Basesystem_Module_15_SP5_s390x > 2024-01-22 05:14:50 <1> susetest(13230) [zypp] RepoFileReader.cc(repositories_in_stream):217 - filePath: /etc/zypp/repos.d/Basesystem_Module_15_SP5_s390x:SLE-Module-Basesystem15-SP5-Debuginfo-Updates.repo Later the install is tried: > 2024-01-22 05:14:51 <1> susetest(13230) [zypp::solver] SATResolver.cc(problems):1353 Encountered problems! Here are the solutions: > 2024-01-22 05:14:51 <1> susetest(13230) [zypp::solver] SATResolver.cc(problems):1353 > 2024-01-22 05:14:51 <1> susetest(13230) [zypp::solver] SATResolver.cc(problems):1357 Problem 1: > 2024-01-22 05:14:51 <1> susetest(13230) [zypp::solver] SATResolver.cc(problems):1358 ==================================== > 2024-01-22 05:14:51 <1> susetest(13230) [zypp::solver] SATResolver.cc(problems):1362 the installed wireshark-ui-qt-3.6.17-150000.3.103.1.s390x requires 'wireshark = 3.6.17', but this requirement cannot be provided > 2024-01-22 05:14:51 <1> susetest(13230) [zypp::solver] SATResolver.cc(problems):1363 ------------------------------------ What is important to understand: wireshark is shipped with basesystem module, while wireshark-ui-qt is part of desktop applications module. If wireshark-ui-qt is needed then both Modules need to be enabled, as the dependency onto wireshark is fulfilled via basesystem module. HTH
(In reply to Robert Frohl from comment #5) > A bit though to debug as the zypper.log is a bit strange to read b/c of the > length: > > Basesystem_Module, which contains the > wireshark-3.6.17-150000.3.103.1.s390x.rpm, gets disabled: > > > 2024-01-22 05:14:50 <1> susetest(13230) [zypp] RepoFileReader.cc(repositories_in_stream):217 - alias : Basesystem_Module_15_SP5_s390x:SLE-Module-Basesystem15-SP5-Debuginfo-Updates > > 2024-01-22 05:14:50 <1> susetest(13230) [zypp] RepoFileReader.cc(repositories_in_stream):217 - name : SLE-Module-Basesystem15-SP5-Debuginfo-Updates > > 2024-01-22 05:14:50 <1> susetest(13230) [zypp] RepoFileReader.cc(repositories_in_stream):217 - enabled : 0 < !!! > > 2024-01-22 05:14:50 <1> susetest(13230) [zypp] RepoFileReader.cc(repositories_in_stream):217 - autorefresh : 1 > > 2024-01-22 05:14:50 <1> susetest(13230) [zypp] RepoFileReader.cc(repositories_in_stream):217 - url : https://updates.suse.com/SUSE/Updates/SLE-Module-Basesystem/15-SP5/s390x/update_debug?PPOBsM9iadnstV7DR9IPkIZR9Sg6ixK-q7M81yfiLqJx1i1lIWbnyzGxiNJHL0AGCmD3wdIzNtDnXFPft9W4HK56_K7C_UultslHOdhDsNZG6tvE65qwkudVFKa3ltM9sXP-clmFhgtoNWDJE-lRnItjpZF7Z-zkBpDG > > 2024-01-22 05:14:50 <1> susetest(13230) [zypp::media++] RepoInfo.cc(probeCache):65 Probed cached type N/A at > > 2024-01-22 05:14:50 <1> susetest(13230) [zypp] RepoFileReader.cc(repositories_in_stream):217 - type : N/A > > 2024-01-22 05:14:50 <1> susetest(13230) [zypp] RepoFileReader.cc(repositories_in_stream):217 - priority : 99 > > 2024-01-22 05:14:50 <1> susetest(13230) [zypp] RepoFileReader.cc(repositories_in_stream):217 - gpgcheck : D(Y) repoD(Y)* sig? pkgD(Y)* > > 2024-01-22 05:14:50 <1> susetest(13230) [zypp] RepoFileReader.cc(repositories_in_stream):217 - service : Basesystem_Module_15_SP5_s390x > > 2024-01-22 05:14:50 <1> susetest(13230) [zypp] RepoFileReader.cc(repositories_in_stream):217 - filePath: /etc/zypp/repos.d/Basesystem_Module_15_SP5_s390x:SLE-Module-Basesystem15-SP5-Debuginfo-Updates.repo > > Later the install is tried: > > > 2024-01-22 05:14:51 <1> susetest(13230) [zypp::solver] SATResolver.cc(problems):1353 Encountered problems! Here are the solutions: > > 2024-01-22 05:14:51 <1> susetest(13230) [zypp::solver] SATResolver.cc(problems):1353 > > 2024-01-22 05:14:51 <1> susetest(13230) [zypp::solver] SATResolver.cc(problems):1357 Problem 1: > > 2024-01-22 05:14:51 <1> susetest(13230) [zypp::solver] SATResolver.cc(problems):1358 ==================================== > > 2024-01-22 05:14:51 <1> susetest(13230) [zypp::solver] SATResolver.cc(problems):1362 the installed wireshark-ui-qt-3.6.17-150000.3.103.1.s390x requires 'wireshark = 3.6.17', but this requirement cannot be provided > > 2024-01-22 05:14:51 <1> susetest(13230) [zypp::solver] SATResolver.cc(problems):1363 ------------------------------------ > > > What is important to understand: wireshark is shipped with basesystem > module, while wireshark-ui-qt is part of desktop applications module. If > wireshark-ui-qt is needed then both Modules need to be enabled, as the > dependency onto wireshark is fulfilled via basesystem module. > > HTH What is weird in this situation is that during installation, wireshark is installed by default, without Desktop module and the system doesn't complain. But when we boot into the disk and try to patch it, we get the given error message. So, from a user's point of view this logic could be considered unfriendly.
(In reply to Sofia Syrianidou from comment #6) > What is weird in this situation is that during installation, wireshark is > installed by default, without Desktop module and the system doesn't > complain. But when we boot into the disk and try to patch it, we get the > given error message. So, from a user's point of view this logic could be > considered unfriendly. But something is disabling the basesystem repo a second (05:14:50) before the update (05:14:51). That looks to me like it is triggered by openQA and not a user visible issue.
ah wait, I just looked again. Looks like I missed something important : the disabled repo is Basesystem15-SP5-Debuginfo-Updates, that should not be the issue. Let me recheck, to make sure that I find the real issue..
ok, so I do not understand what the log is supposed to be showing: the latest released wireshark version is 3.6.20. Why does the test run with 3.6.17 on 2024-01-22 ? And why does it look like the Desktop Module is disabled [0] at the end of the setup phase. Also the zypper ref run does not show any hint that the desktop module is enabled [1]. The log is also incredibly useless for debugging anything, it starts at 2023-10-29 and ends at 2024-01-22. How should I understand what happened in these 3 months with the system? Would it be possible to provide a shorter log that is showing the error case and not as much noise? The Desktop Repo was enabled on the 2023-10-29, while the test fails on the 2024-01-22. My best guess at the moment is that the system has a stale wireshark-ui-qt from October and then was never properly set up to use the Desktop Module. [0] https://openqa.suse.de/tests/13307192#step/patch_sle/76 [1] https://openqa.suse.de/tests/13307192#step/patch_sle/92
(In reply to Robert Frohl from comment #9) > ok, so I do not understand what the log is supposed to be showing: the > latest released wireshark version is 3.6.20. Why does the test run with > 3.6.17 on 2024-01-22 ? Because it can take a while for the latest package build to be included in the sles builds that run on openqa. > > And why does it look like the Desktop Module is disabled [0] at the end of > the setup phase. Also the zypper ref run does not show any hint that the > desktop module is enabled [1]. The Desktop module should not be enabled at all, we thougth that this was causing the depedency issue and we disabled it during installation of the hdd and during patching of the hdd. > > The log is also incredibly useless for debugging anything, it starts at > 2023-10-29 and ends at 2024-01-22. How should I understand what happened in > these 3 months with the system? Would it be possible to provide a shorter > log that is showing the error case and not as much noise? That is very weird, the hdd is supposed to be created the same day as the whole test runs. I will try to rename the disk and run tests, so that I exclude the possibility of the test running on some old hdd. > > The Desktop Repo was enabled on the 2023-10-29, while the test fails on the > 2024-01-22. My best guess at the moment is that the system has a stale > wireshark-ui-qt from October and then was never properly set up to use the > Desktop Module. > > [0] https://openqa.suse.de/tests/13307192#step/patch_sle/76 > [1] https://openqa.suse.de/tests/13307192#step/patch_sle/92
After creating a new image with a new name, both tests pass. I assume that the old image was not replaced by the latest runs of the test for some reason. I will delete it manually and proceed to replcae it. Thanks a lot for the replies.
The issue is caused by using an old image, it works fine when using a new image. So verify it is invalid, thanks.