Bugzilla – Bug 1213343
[Build 41.1] openQA test fails in start_install: Missing dialog-information icon
Last modified: 2023-07-17 15:14:08 UTC
Presumably after the last libyui update in 15 SP4, the dialog-information icon from the embedded Qt resources fails to load. In y2log there's only the message Couldn't load icon: dialog-information I guess it's because the resource is an svg and https://github.com/libyui/libyui/pull/100 did not end up in 15 SP4, so it uses the wrong check? ## Observation openQA test in scenario opensuse-15.4-KDE-Live-x86_64-kde_live_upgrade_leap_15.0@64bit fails in [start_install](https://openqa.opensuse.org/tests/3427278/modules/start_install/steps/22) ## Test suite description Uses the live installer on the kde live media for upgrading the system. jpupava: RAM increased to 3072 firefox needs half run time and general performance is much better, defined in medium types VNC_STALL_THRESHOLD=100 to solve grub_test failures where grub is missed because screen is not updated ## Reproducible Fails since (at least) Build [34.13](https://openqa.opensuse.org/tests/3390756) ## Expected result Last good: [33.3](https://openqa.opensuse.org/tests/3387513) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensuse&flavor=KDE-Live&machine=64bit&test=kde_live_upgrade_leap_15.0&version=15.4)
FTR, a failure using the CR DVD: https://openqa.opensuse.org/tests/3427316#step/select_packages/35
Fabian, thanks for bringing this to our attention. But IIRC we had decided back then to fix this only for SLE-15-SP5 and TW because that icon loading had already developed into a neverending story. There are so many fringe cases that every change in that area always involves considerable risk to break another one that might be more important: - We have icons for a package status in libyui-qt-pkg. Those are compiled in via Qt resource because not having those icons would make the Qt package selector pretty much unusable. - We have icons for patterns in libyui-qt-pkg. Those are mostly decorative, but very prominently visible. Those are not compiled in because they tend to change dynamically depending on the product that is being installed. - We have icons for actions and for device types in the partitioner. IIRC those are loaded from the desktop theme, if available, with a fallback from the YaST theme. Those are also quite prominently visible. - We have decorative icons in the Qt wizard. Those are also very prominently visible, and they are the branding of our product, making the product recognizable. They are loaded from the YaST theme via QSS style sheets. - We have some decorative icons in odd places in the code. That missing (i) icon in that "Automatic Changes" dialog in the Qt package selector is one of them. While it's annoying not to have it, it's only "nice to have"; the dialog and its purpose is still recognizable with its very distinct look and feel and the packages table. So, while this is annoying, it's no more than a nuissance. And given that the life time of Leap 15.4 is coming to its end, and that hopefully SLE-15 SP4 customers start migrating to SP5, IMHO this does not warrant the risk that it would involve to do yet another backport to 15.4; let alone the confusion that it would bring with our YaST code merge policy where we merge forward 15.4 -> 15.5 -> master to ensure that all fixes in older branches are also included in newer ones. This one would for sure lead to conflicts and revert commits etc. to keep them in sync. So please adapt that needle in the OpenQA test case instead; I see there are already several ones, with and without that icon.
(In reply to Stefan Hundhammer from comment #2) > Fabian, > > thanks for bringing this to our attention. But IIRC we had decided back then > to fix this only for SLE-15-SP5 and TW because that icon loading had already > developed into a neverending story. > > There are so many fringe cases that every change in that area always > involves considerable risk to break another one that might be more important: > > ... From a quick glance at the code I would assume that more than just this icon is affected. I'm mostly worried that some more important icons might be missing too. If it's just this or other decorative ones, it's probably ok to accept this regression as is. > So please adapt that needle in the OpenQA test case instead; I see there are > already several ones, with and without that icon. Yeah, I added a workaround needle already.