Created attachment 320570 [details, diff] Patch against qtads-2.1.3.ebuild QTads 2.1.4 was released on 2012-08-06. I always avoid doing 0-day bump requests, but an ebuild change is needed that needs to be documented :-) The current ebuild works fine, but won't install the newly provided file icons and MIME types. I've added an ebuild to the interactive-fiction overlay: http://repo.or.cz/w/gentoo-interactive-fiction.git/blob_plain/HEAD:/games-engines/qtads/qtads-2.1.4.ebuild I'm also attaching a diff against the current 2.1.3 ebuild.
fdo-mime functions calls are missing in pkg_postrm use a proper doicon call: newicon -s 256 qtads_256x256.png ${PN}.png (will install into /usr/share/icons/hicolor/256y256/apps) unless the doins -r line already installs there (either way you need to update gnome2 icon cache via gnome2-utils.eclass, see games-arcade/mari0 ebuild for example) doins is missing "|| die" (or use EAPI=4)
the term "gnome2 icon cache" was misleading, I mean gtk icon cache which is mandatory when installing into /usr/share/icons/... because icons might otherwise not show up. Programs look up the icon cache instead of searching the subdirs (except we install into /usr/share/pixmaps but /usr/share/icons is more modern)
Thanks for the pointers, Julian! I've updated the ebuild (and bumped EAPI to 4.) I suppose there's nothing that can be done for the KDE icon cache? It doesn't invalidate until I manually: $ rm /var/tmp/kdecache-$USER/icon-cache.kcache and restart KDE.
Created attachment 320574 [details, diff] Patch against qtads-2.1.3.ebuild
(In reply to comment #3) > Thanks for the pointers, Julian! I've updated the ebuild (and bumped EAPI > to 4.) > > I suppose there's nothing that can be done for the KDE icon cache? It > doesn't invalidate until I manually: > > $ rm /var/tmp/kdecache-$USER/icon-cache.kcache > > and restart KDE. I guess not, I have no real clue about KDE, but when you look at kde4-base.eclass it also uses "gnome2_icon_cache_update" and inherits gnome2-utils.
games.eclass has to go last, always. We want the default games functions exported and eclass behavior might change (like qt4-r2.eclass would suddenly export pkg_setup which will overwrite games_pkg_setup and break the toolchain exports) and could randomly compromise games ebuilds.
also, you removed all runtime dependencies without knowing (by bumping to EAPI=4) "When RDEPEND is unset, there will no longer be an automatic assignment of RDEPEND="${DEPEND}". " from http://devmanual.gentoo.org/ebuild-writing/eapi/index.html
Indeed. I'll fix that. I'll do a 2.1.5 release first because 2.1.4 can't run TADS 3.1.2 games (there was a VM change) and will update the bump request with a corrected ebuild.
I bumped 2.1.4 in the tree, open a new bug about 2.1.5 when it's ready
A few notes: You're enforcing verbose builds. Is this a Gentoo standard I was not aware of? I see lots of packages that use terse build messages. This makes it easier to see warnings. In make_desktop_entry, you missed the GenericName attribute. It should be: make_desktop_entry qtads QTads qtads Game "GenericName=TADS Multimedia Interpreter\nMimeType=application/x-tads;application/x-t3vm-image;"
(In reply to comment #10) > A few notes: > > You're enforcing verbose builds. Is this a Gentoo standard yes
Btw, I fixed that issue in bug 433918 without having to use toolchain-funcs.
