I maintain the kwotes chat quote database system on sourceforge.net (http://kwotes.org). I've written an ebuild for installing said webapp on gentoo systems. Please integrate this into portage. I believe the ebuild is actually stable (there isn't much to it)... and i know the kwotes application is stable. But i still masked it at ~x86. I'm new to the process of submitting and maintaining ebuilds, so I'd like some help in determining when it should be marked stable. Either way, here it is... hope to see it in portage soon :)
Created attachment 66242 [details] ebuild for kwotes webapp
When should i expect to see this in portage?
Please reopen when you can attach an ebuild with the following fixed: * Is LICENSE really GPL-1? * Fix KEYWORDS to only include archs on which you have actually tested * Fix IUSE as per policy * Fix RDEPEND entries as per policy * Fix S as per policy * Remove src_unpack * Fix quoting in src_install * Fix incorrect find usage in src_install * Fix pkg_postinst sleep as per policy * Consider installing a cron.d entry
Created attachment 66243 [details] new ebuild for kwotes new ebuild for kwotes
Ok, added another ebuild. Please bear with me... this is my first time. Issues i addressed (hopefully): * Is LICENSE really GPL-1? yes * Fix KEYWORDS to only include archs on which you have actually tested fixed * Fix IUSE as per policy fixed * Fix RDEPEND entries as per policy fixed * Fix S as per policy fixed * Remove src_unpack fixed * Fix quoting in src_install Not sure what you mean here * Fix incorrect find usage in src_install Not sure what you mean here * Fix pkg_postinst sleep as per policy fixed - removed sleep * Consider installing a cron.d entry considered :)
> * Fix IUSE as per policy > fixed Not as far as I can tell. IUSE is for USE flags that affect the behaviour of the ebuild. apache2 is the only one that seems to do so. > * Fix RDEPEND entries as per policy > fixed I don't see any improvement. > * Fix quoting in src_install > Not sure what you mean here He means that you're not quoting things that need to be quoted. It'll break if certain variables contain spaces, for example. > * Fix incorrect find usage in src_install > Not sure what you mean here That find command won't work with new findutils or non-GNU versions. Reopen again once those are addressed please.
Created attachment 66257 [details] yet another ebuild yet another ebuild
Ok, trying again: * Fix IUSE as per policy Fixed * Fix RDEPEND entries as per policy > I don't see any improvement. What are you wanting me to do here? I was under the assumption that RDEPEND are runtime depencies of the application. (I looked at the bugzilla ebuild as a template for this BTW). * Fix quoting in src_install Fixed * Fix incorrect find usage in src_install Fixed
(In reply to comment #8) > * Fix RDEPEND entries as per policy > > I don't see any improvement. > What are you wanting me to do here? I was under the assumption that RDEPEND > are runtime depencies of the application. (I looked at the bugzilla ebuild as a > template for this BTW). RDEPEND=" ... cron " You really think that this is a valid dependency?
Well, it's valid, but categoryless atoms are forbidden in ebuilds.
oops, meant to do the virtual cron package... i'll put a new ebuild up right now.
Created attachment 66267 [details] new ebuild (fixed RDEPEND) new ebuild (fixed RDEPEND)
Ok, how's it look now?
There's still the find usage. The correct portable way to use find is $(find "path" -type f ), where "path" is a relative path if possible. If I was feeling really picky I'd also pull in the closing double quote on RDEPEND onto the line above. Anyway, I can't be entirely happy with this ebuild until one of our infra friends shows up and enables the new bugzilla VERIFIED keyword to tag it with :)
what if i do cd "${D}" && find . -type f ?
Yup, the usage suggested in comment #15 is fine.
Created attachment 66346 [details] finally, a working and approved ebuild? finally, a working and approved ebuild?
Ok, new ebuild attached.
I'll be the maintianer.... can this go into portage yet?
It can go into Portage when an existing dev can be found with the time, knowledge, and inclination to maintain it properly. Until then, reopening the bug.
So how/when does that happen?
It will happen whenever an existing developer who has the inclination finds time.
So at this point it's a waiting game?
Pretty much that.
Well then, I'll wait :(
What's the status on this? I'd like to see this included in portage. I'd be less inclined to write ebuilds in the future if they end up sitting in an idle state like this for so long. I tried to word that in the most unconfrontational manner possible. Anyway, i'd like to know what i need to do to get this into portage.
$20 bucks via paypal to the dev that accepts maintainer status for this ebuild and puts it into portage :)
Looks like a dead project now.
