runtime-install: install rsvg-pixbuf-loader

[AdamWill]

This was split out of librsvg2 as a subpackage recently, and is only Recommended by the parent (not Required). For size's sake, we don't pull Recommends into the installer env by default. But we do really need this package, because quite a lot of icons used in the installer are only present as SVGs in the installer environment, so if we don't have the SVG loader we can't show the icons.

Right now anaconda actually crashes if the SVG renderer isn't present, which wasn't an expected outcome, but even if the crash is fixed, the result would be that anaconda would run but not show a lot of icons, which obviously isn't what we want. So we should add this regardless of a fix for the crash.

[coveralls]

Pull Request Test Coverage Report for Build 5631471302

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 43.325%

---

Totals
Change from base Build 5557115468:	0.0%
Covered Lines:	1578
Relevant Lines:	3435

---

💛 - Coveralls

[mcatanzaro]

You could also just say:

Suggested change

	## this is only recommended by librsvg2, but anaconda crashes without it
	## see https://bodhi.fedoraproject.org/updates/FEDORA-2023-f069ac712b
	installpkg rsvg-pixbuf-loader
	## required to display SVG images
	installpkg rsvg-pixbuf-loader

i.e. it would be needed even without the crash

[AdamWill]

OK, I'll tweak that.

One thing I think we maybe can tell from the backtrace: it's trying to display an icon which only exists (in the installer environment at least) as an SVG. Frame 11 mentions input-keyboard-symbolic , and in the installer env, the only file with that in its name is /usr/share/icons/Adwaita/symbolic/devices/input-keyboard-symbolic.svg. IIRC there is some kinda hidden magic fallback to a non-symbolic version somewhere in the codepath, but even with that, the only input-keyboard icons we have are also SVGs, there is no PNG input-keyboard* anywhere.

So maybe there's a path where GTK just assumes it will definitely be able to render the icon somehow once it's been found, but because we don't have the SVG renderer and we don't have any non-SVG icons, that assumption breaks? Or something along those lines?

[AdamWill]

comment and commit message updated, thanks.

[mcatanzaro]

It's not possible to know without understanding the missing frame in the backtrace. What I can say for sure is that it shouldn't crash inside gtk_widget_show_all().

[AdamWill]

yeah, that does seem odd. I tried following it out from that end but it's a long way. it gets into glib deciding whether the thing is a widget, which involves trying to instantiate it as one, best as I can tell...

I think the thing to do might be to try and write a simpler reproducer which doesn't involve python and gobject introspection, maybe? just...see what happens if you do stuff with an icon that's present, but only as SVG, without the SVG pixbuf loader being there...

[bcl]

This belongs in anaconda-install-env-deps, not in the template. Or maybe even on anaconda-gui.

[AdamWill]

oh, right, I kinda forgot about anaconda-install-env-deps. you're right, that would be better. so many places...

[AdamWill]

for now the dep was changed to a Requires: anyway which makes the whole point moot, so I think I'll leave it for a bit and see whether there's any danger of it going back to Recommends:.