https://bugzilla.redhat.com/show_bug.cgi?id=1388945
--- Comment #10 from Andrew Toskin <and...@tosk.in> --- I just noticed that the spec says it requires GNOME 3.20+, but the extension's metadata.json file says it supports 3.16. This maybe isn't a big deal for Fedora, since Fedora 23 reached end-of-life. But allowing GNOME 3.16 would make your package usable in EPEL... if/when they rebase to a version of GNOME newer than 3.14. In any case, I think it would be better to stick with the upstream's stated supported versions of GNOME, unless you *know* the extension does not actually work with GNOME older than 3.20. (In reply to mgans...@alice.de from comment #9) > i activated it with gnome-shell-extension-prefs Turns out my problem with Banshee was that I needed to enable the MPRIS D-Bus Interface extension in the Banshee preferences. https://github.com/eonpatapon/gnome-shell-extensions-mediaplayer/issues/270 I feel like this is going to be a common point of confusion for new users, but I'm not sure how we could avoid it. It's already noted in the packaged README, but how many people read those? Not me, apparently :P FYI: The method used to activate the extension shouldn't really matter. Launching gnome-shell-extension-prefs, the GNOME Tweak Tool, or running the gnome-shell-extension-tool command line -- it's all the same. Also, the extension does show up in Tweak Tool now. I had reloaded GNOME Shell (Alt+F2, r, Enter), but maybe it still needed me to logout and login for some reason. > I think it is a PreRelease ? I guess that depends on whether upstream ever plans to tag releases, and what they intend their first version number to be. Some projects use 0.1 or 1.0 for their first official release. If they tag their first release as version 0.1, then you're okay: You would simply bump your Release tag from a "prerelease" number (0.x) to a regular release (1). And if they tag version 1.0, then that will always be sorted as newer than version 0.1, so you'd still be good. However, some developers really like to count from 0, and tag their first release as 0.0 -- and *that* would be a problem for your package, because RPM won't recognize the tagged version 0.0 as being newer than the version "0.1" you've been packaging. You would have to add an Obsoletes tag or something, and things would get messy... So if upstream doesn't plan on ever tagging their releases, or if they are undecided on their versioning scheme in any way, I would set the spec's Version to plain 0. And continue with the "prerelease" Release tag you're using, unless or until upstream formally designates an actual version. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@lists.fedoraproject.org To unsubscribe send an email to package-review-le...@lists.fedoraproject.org
