https://bugzilla.redhat.com/show_bug.cgi?id=1388945 --- Comment #11 from mgansser@xxxxxxxx <mgansser@xxxxxxxxx> --- (In reply to Andrew Toskin from comment #10) > 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. Will stay with the support of GNOME 3.20 as F24 EOL is soon reached. > (In reply to mgansser@xxxxxxxx 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. Thanks for the info, works for me too. > > 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. Use Version 0 as you mentioned, until upstream formally designates an actual version. Spec URL: https://martinkg.fedorapeople.org/Review/SPECS/gnome-shell-extension-media-player-indicator.spec SRPM URL: https://martinkg.fedorapeople.org/Review/SRPMS/gnome-shell-extension-media-player-indicator-0-0.6.20170308git67e54ae.fc25.src.rpm %changelog * Thu Mar 09 2017 Martin Gansser <martinkg@xxxxxxxxxxxxxxxxx> - 0-0.6.20170308git67e54ae - Use Version 0 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx