This does not have a bug description, just an auto-generated template.
It does not describe what's wrong, what you expect, and what happens instead.
It does not have a useful bug title.

PLEASE read the document that we wrote for exactly this kind of bug report:

https://en.opensuse.org/openSUSE:How_to_Write_a_Good_Bugreport


And besides, what makes you think that this might be a YaST bug?

Also, the openQA test case that you link to is just a neverending sequence of screenshots, and the problematic one is a sequence of dozens of shell commands.

Do you seriously expect us to reverse-engineer that to make sense of this bug report? If you can't tell us what's wrong in that scenario, how are we supposed to find out?

##Bug Description:-

In leap 15.5 with the build :18048:gtk4-branding.1693310970 test failed in scenario opensuse-15.5-DVD-Incidents-x86_64-Build:18048:gtk4-branding.1693310970-cryptlvm@uefi-2G with below conflicts 

0| 2023-08-29 08:53:37 <1> localhost(3798) [zypp::solver] SATResolver.cc(problems):1353 Encountered problems! Here are the solutions:
0| 2023-08-29 08:53:37 <1> localhost(3798) [zypp::solver] SATResolver.cc(problems):1353 
0| 2023-08-29 08:53:37 <1> localhost(3798) [zypp::solver] SATResolver.cc(problems):1357 Problem 1:
0| 2023-08-29 08:53:37 <1> localhost(3798) [zypp::solver] SATResolver.cc(problems):1358 ====================================
0| 2023-08-29 08:53:37 <1> localhost(3798) [zypp::solver] SATResolver.cc(problems):1362 nothing provides 'libgtk-4-1 = 4.6.9' needed by the to be installed gtk4-branding-openSUSE-15.0-lp155.3.2.2.noarch
0| 2023-08-29 08:53:37 <1> localhost(3798) [zypp::solver] SATResolver.cc(problems):1363 ------------------------------------
0| 2023-08-29 08:53:37 <1> localhost(3798) [libsolv++] PoolImpl.cc(logSat):131 solver statistics: 0 learned rules, 1 unsolvable, 0 minimization steps

"Test failed" is not a problem description.

Strictly speaking, it means that the test is faulty. But that's probably not what you mean. So in general, it is important WHAT that part of the test is testing, in some cases also HOW it does that, what the expected outcome is and what the actual outcome.

Also, this bug still has the same subject which basically just says "there is a problem somewhere". Duh; of course, otherwise there wouldn't be a bug report. It does not say WHAT the problem is. And no, "test failed" is not appropriate; for the same reason as above.

And for the specific problem which you started to mention (albeit incomplete, so it leaves a lot to guesswork):

Dependency problems are in general almost never the problem of the installer, they are a problem of the involved packages or maybe of the repository (which may be on the installation medium or on an installation server). YaST or zypper only report those problems, they don't create them.

To find out what package maintainer should have a look at it, use

    osc maintainer -e <package-name>


% osc maintainer gtk4-branding-openSUSE

Defined in project:  GNOME:Factory
  bugowner of gtk4-branding-openSUSE : 
   os-gnome-maintainers

  maintainer of gtk4-branding-openSUSE : 
   dimstar, sreeves1, factory-repo-checker, group:factory-maintainers, group:gnome-maintainers, group:factory-staging

Oops, left out the '-e' for the e-mail address...

% osc maintainer -e gtk4-branding-openSUSE
Defined in project:  GNOME:Factory
  bugowner of gtk4-branding-openSUSE : 
   os.gnome.maintainers@gmail.com

  maintainer of gtk4-branding-openSUSE : 
   dimstar@opensuse.org, sreeves@suse.com, factory-repo-checker@kulow.org, -, -, -



Now not only did I have to repeat the better part of the document that I linked to you, I also did your part of the work:

- I changed the bug subject to something meaningful

- I found out the corect package maintainer

- I am reasissigning the bug to that maintainer

- I changed the bug component to the correct one.

If you don't know the component, DO NOT put the burden on us and select "YaST" or "Installation"; use "Other".


Notice that I am only doing this once for you, so please take my advice to heart and look at what I changed and how. Future bugs with all that missing will be closed as INVALID.

Thank you for the help Stefan. I will follow your advice onward.

(In reply to Yogesh Pagar from comment #0)
> ## Observation
> 
> openQA test in scenario opensuse-15.5-DVD-Incidents-x86_64-cryptlvm@uefi-2G
> fails in
> [qam_zypper_patch](https://openqa.opensuse.org/tests/3533269/modules/
> qam_zypper_patch/steps/14)


Are you really reporting a bug from a QA test that failed two months ago?

From what I can understand, at this point, is that gtk4 had a maintenance update released (actually in SLE15SP4, on Aug 29 2023) - and gtk4-branding was not rebuilt as part of that release. the gtk4-branding release into the update channel for Leap happened slightly later (Aug 30 2023)


This matches the timeline of your test failing on Aug 29; the relevant branding was not out yet.

from what I can see at this stage: nothing to be done. Maintenance released the relevant branding package (albeit slightly after the library)

=> FIXED (at the time this error showed on openQA, it was real, so I opt not to go INVALID; but filing a bug 2 months after it was showing in  openQA, without verifying if it is still valid, sounds like wasting some time)