Bugzilla – Bug 116756
ethereal does not work out of the box
Last modified: 2008-06-25 09:52:45 UTC
just did a fresh install of RC2 using Minimal+X installation option. This is, what happens, when I start ethereal: # ethereal (ethereal:5196): GdkPixbuf-WARNING **: Cannot open pixbuf loader module file '/e tc/opt/gnome/gtk-2.0/gdk-pixbuf.loaders': Datei oder Verzeichnis nicht gefunden (ethereal:5196): GdkPixbuf-WARNING **: Error loading XPM image loader: Bildtyp » xpm« wird nicht unterstützt (ethereal:5196): Gdk-CRITICAL **: gdk_pixbuf_render_pixmap_and_mask_for_colormap : assertion `GDK_IS_PIXBUF (pixbuf)' failed (ethereal:5196): Gtk-CRITICAL **: gtk_image_set_from_pixmap: assertion `pixmap = = NULL || GDK_IS_PIXMAP (pixmap)' failed (ethereal:5196): Pango-WARNING **: No builtin or dynamically loaded modules were found. Pango will not work correctly. This probably means there was an error in the creation of: '/etc/opt/gnome/pango/pango.modules' You may be able to recreate this file by running pango-querymodules. (ethereal:5196): Pango-CRITICAL **: _pango_engine_shape_shape: assertion `PANGO_ IS_FONT (font)' failed Pango-ERROR **: file shape.c: line 75 (pango_shape): assertion failed: (glyphs-> num_glyphs > 0) aborting... Abgebrochen
Running pango-querymodules does not help... :-(
who generates /etc/opt/gnome/gtk-2.0/gdk-pixbuf.loaders ?
Did you install the ethereal by yast? sbrarbes said, that gdk-pixbuf.loaders is builded by SuSEconfig. Try run SuSEconfig.
That's it. So why doesn't gtk2 run SuSEconfig in %post? %run_suseconfig -m gtk2
Should be possible to install packages without using yast, shouldn't it? In the my case, I used y2pmsh to install.
jpr@kasparov:~> rpm -q gtk2 --scripts postinstall scriptlet (through /bin/sh): /sbin/ldconfig touch var/adm/SuSEconfig/run-gtk It should be running SuSEconfig.gtk2 with the touch. Stanislav knows more about this.
AFAIK, running SuSEconfig after installation of any package is expected behavior, isn't it. Living without ut would be very complicated due to lack of required RPM features. There are many packages, which still uses stamping to run SuSEconfig. I can change it to %run_suseconfig -m gtk2 in %post if it can guarantee, that it will be run only once after finishing of installation batch (in extreme case {like packages installing icons to more themes}, one run of gtk SuSEconfig module can take a minute). Please note, that shorteted run of SuSEconfig gtk module is needed to be started after installation of all GUI packages (even non-gtk), even if they don't set /var/adm/SuSEconfig/run-gtk. To fix it, we could need to add %run_suseconfig -m gtk2 to %trigerin and %triggerun of thousands packages.
I'm not sure, if I understand. What sideeffects/negative effects does it have to run the gtk2 SuSEconfig script in %post of gtk2? Why is it currently only executed when /var/adm/SuSEconfig/run-gtk exists?
It is executed every time SuSEconfig is called. But if /var/adm/SuSEconfig/run-gtk does not exist exist, parts of the script are skipped. We need to run gtk2 SuSEconfig script for about 210 packages and many third party applications (and %post is too early, we would need both %triggerin and %triggerun to work correctly). That is why we decided to run it every time and not edit particular spec files.
Looking at run_suseconfig macro implementation, adding run_suseconfig to particular packages would make installing multiple packages outside RPM unacceptably slow, because it will be started twice for each package and each run can take one minute. I can add this to %post of gtk2 only. In this case, you will not see upper mentioned crash, but without running SuSEconfig you will experience missing icons coming from packages installed later than gtk2. So I think we can close it as WONTFIX (exactly CANTFIX with current RPM features).
Typo fix: < would make installing multiple packages outside RPM > would make installing multiple packages outside YaST
After some discussions in #suse I think we missunderstood ourselfs. IMHO it should be sufficient to just run %run_suseconfig -m gtk2 in %post of the gtk2 package. Not in any other package, of course. Does anything speak against that?
Yes: 1) Speed. You have to re-run SuSEconfig after installation of any icons. It means waiting up longer for one minute. See bug 113261 for more. 2) It will not fix anything. You only get different bug - missing icons instead of missing loader. But if you prefer misbehavior 2), I can split SuSEconfig to two scripts: 1) Searching input methods will moved to %post and %postun of gtk2 and to %triggerin and %triggerun ofted by gtk2 of input method providers. This is relatively fast and starting it more times during installation is not a big problem. 2) Searching icons will be started any time by SuSEconfig and the end of installation. It will not be started from spec file and if you will not start SuSEconfig after installation, you will not see icons.
just noticed, that it is also neccessary to run SuSEconfig.pango
Yes it is the same case. To run properly, GNOME needs to have updated: - Pango rendering method cache. - GTK+ input method cache. - GTK+ icon cache (if exists). - MIME database. If one of those files is missing (with exception of GTK+ icon cache) or is outdated, GTK+ does not work properly. Once RPM will have a features like starting post-transaction scripts of defined name once after complete installation batch and ex-post definable file path triggers, I can think about not-doing the stuff in SuSEconfig but in rpm.
Correction Should be: To run properly, GTK+ needs to have updated: And also: - GTK+ pixbuf loader cache. GNOME needs also: - MIME desktop cache.
Closing as LATER with similar comment as for bug 118172. Due to lack of features in RPM, I can't create any fix without introducing new bug or without extreme increasing of installation time. Maybe I can implement partial work-around using %posttrans, once we will update to RPM 4.4. For now, the only work-around I can imagine is starting SuSEconfig after every installed or removed package. If you see another work-around which does not cause another bug or increase install time, please let me know. Please reopen this bug, when RPM will support: 1. Post-transaction scripts Script of defined name will be started only once after complete installation batch. Maybe this feature can be implemented by using %posttrans (which is started at the end of transaction, but for each package, where it is present) with some limitations. Without this feature, script needs to be started many times during batch installation (up to two times per package). %pretransscript /sbin/conf.d/SuSEconfig.gtk2 %s %preuntransscript /sbin/conf.d/SuSEconfig.gtk2 %s %posttransscript /sbin/conf.d/SuSEconfig.gtk2 %s %postuntransscript /sbin/conf.d/SuSEconfig.gtk2 %s %s will be names of RPM, which trigger this call 2. Modifiable path triggers. When any package installs or removes file in defined directory (complete directory list is not surely known in time of package installation), selected action will be performed. Without this feature, package cannot create specific caches without adding triggers to many other unrelated packages. Without path collection feature, package cannot change configuration of listed paths in path trigger. echo "/usr/share/applications /opt/gnome/share/applications" >/etc/opt/gnome/gtk2_cache.lst %triggerglob /sbin/conf.d/SuSEconfig.gtk2 /opt/gnome/share/icons/* /usr/share/icons/* or even: %triggerpath /etc/opt/gnome/gtk2_paths.d/*.lst or %triggerpathscript /opt/gnome/bin/collect_icon_paths
mass reopening all SuSE Linux bugs that are set to REMIND+LATER to change the resolution to WONTFIX (adapting to new policy)
Closing old LATER+REMIND bugs as WONTFIX - if you still plan to work on it, feel free to reopen and set to ASSIGNED. In case the report saw repeated reopen comments, it's due to bugzilla timing out on the huge request ;(