GNOME Colorscheme is a very simple application for the GNOME desktop that allows you to generate a variety of colorschemes from a single starting color. http://home.gna.org/colorscheme Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 68929 [details] colorscheme-0.2.2.ebuild I have this placed under the x11-misc category in my local portage tree (it complements gcolor2, which is in the same category).
Created attachment 71014 [details] colorscheme-0.2.2.ebuild - a bit better I Added versionator for folder (this is a bit more gentooisher) and added minimum needed version vor cppunit
(In reply to comment #2) > I Added versionator for folder (this is a bit more gentooisher) > and added minimum needed version vor cppunit Thanks! When renamed to colorscheme-0.2.2.1.ebuild this ebuild also seems to work for the new 0.2.2.1 release.
(In reply to comment #3) > Thanks! When renamed to colorscheme-0.2.2.1.ebuild this ebuild also seems to > work for the new 0.2.2.1 release. Renaming colorscheme-0.2.2.ebuild to colorscheme-0.2.2.2.ebuild works too.
*** Bug 111517 has been marked as a duplicate of this bug. ***
Created attachment 73423 [details] colorscheme-0.3.ebuild Added the boost dependency and added versions to dependencies as listed at http://home.gna.org/colorscheme/downloads.shtml
Created attachment 73716 [details, diff] Patch for colorscheme-0.3.ebuild Specified RDEPEND variable due to the fact that not all build dependencies are required at runtime.
gnome-common should probably only be a build dependency as well (assuming it's the same as the gnome-common package in debian). It only provides tools for developers as far as I know.
Created attachment 83261 [details] colorscheme-0.3.90.ebuild updated to work with version 0.3.90 >=dev-cpp/gconfmm-2.6 dependency added >=dev-cpp/vfsmm-2.6 removed also added ~amd64, works just fine on ~x86 and ~amd64 for me inherit versionator not needed.
Created attachment 91710 [details] x11-misc/colorscheme-0.3.91
Attached slightly modified ebuild. While at first glance it seems gnome-base/gnome-common should be an rdepend, it doesn't seem to be required in any way - running is not impaired on a system without it. Come to think of it, there are probably a couple more things I can do to it. The real question is this: This bug has been open for nearly a year - what is it waiting on? Is it unsuitable, or just waiting on someone to maintain it? If its waiting on a maintainer I would be happy to take it on, as it's not a particularly complicated one.
This package apparently will to call itself 'agave' now. http://download.gna.org/colorscheme/releases/agave-0.4.0.tar.bz2 Should the ebuild/package reflect the same name, or should we modify the name during the unpack and build process?
Yes, the ebuild should reflect the name change. :) It helps to keep with upstream.
Created attachment 108173 [details] media-gfx/agave-0.4.1.ebuild updated ebuild reflecting name change and version bump: copy ebuild file to: /usr/local/portage/media-fx/agave/agave-0.4.1.ebuild go to this directory and create manifest files: ebuild agave-0.4.1.ebuild manifest
Comment on attachment 108173 [details] media-gfx/agave-0.4.1.ebuild version bump + name change
*** This bug has been marked as a duplicate of bug 151526 ***
Created attachment 142180 [details] x11-misc/agave-0.4.4.ebuild
