I'll attach an ebuild that builds dev-ruby/ruby-oci8-1.0.0_rc2. It'd be cool to get this in the portage tree (albeit masked until 1.0.0 is done with it's release candidates). Reproducible: Always Steps to Reproduce:
Created attachment 123328 [details] ruby-oci8-1.0.0_rc2.ebuild
Given that the package is clearly marked no-herd I think mattm should really take a look at this (or change metadata). I'm also not sure if anyone in the ruby herd has access to oracle, so if we were to pick it up we could only be proxy-maintainer. Troy, would you be up for maintenance when Matt doesn't respond?
Yes, I could do that. This is a relatively simple ebuild. I've never been an official ebuild/portage maintainer though... Would that be required? For what it's worth rc3 is out now, too, and http://ruby-oci8.rubyforge.org/ says that 1.0 is stable.
No, you don't need to be an official developer. The idea is that you would be listed as maintainer (and get the bugs assigned :-) but that an official maintainer (in this case the ruby herd) would commit fixes and updates to Gentoo's CVS after checking them. Anyway, let's wait a bit for a response from mattm, he might just be busy atm. Otherwise we can pursue this course of action.
I seen now that mattm is retired. Troy, it would be great if you could maintain this package with me or others from the ruby herd as proxy-maintainer. Since you mention that version 1.0.0 is out, could you create and test an ebuild and attach it to this bug so that it can be added to CVS?
Wow. I just browsed to this page and noticed you posted something on the 15th of September. For some wild reason, I never received an e-mail for that comment. Hrmph. I'll get a new ebuild made for rc3. It should be relatively the same as the one I posted for rc2.
Created attachment 135348 [details] oci8 Release Candidate 3 Here is an ebuild for oci8 1.0 rc3. Apparently the upstream hasn't move to 1.0 release yet. It'd still be nice to have this in portage, masked, until it's considered a release.
Thanks for the update. Looking through the ebuild I noticed some QA-related things: * virtual/ruby is also an RDEPEND, so just setting DEPEND to RDEPEND should work fine. * In src_compile, is parallel make really broken? If so, it would be great to fix it or to comment the specific way in which it is broken. * src_install should also use emake, and needs quoting for ${D} It would be great if you could fix these things. After that I'd be happy to add it to CVS. Why do you think it should still be package-masked?
Created attachment 137631 [details] 1.0.0 ruby-oci8 stable release Sigh, I didn't get notified of your comment again. I added myself as a CC: on this bug, hopefully I'll get your replies now. It looks like upstream has a 1.0.0 (sans rc3) release now. I don't think any masking would be needed anymore. In addition to changing the ebuild for the 1.0.0 release, I've: - Put virtual/ruby in RDEPEND. - Removed single-fork make. It was in there from the current ruby-oci8 ebuild, it seems to work fine without it. - src_install uses emake, and quotes ${D} I hope this is sufficient now :)
Created attachment 137633 [details] 1.0.0 ruby-oci8 stable release Noticed I could use ${P}.tar.gz instead of ruby-oci8-${PV}.tar.gz :)
Thanks Troy, I've just added the 1.0.0 ebuild to CVS. Please let us know if there are bugfixes or updates.
Thanks :) I have a procmail rule that puts the mail in a folder named from the X-Bugzilla-Product header if it exists, unfortunately, it was putting it in the wrong place. Sorry about that. Fixed now, though :)
Time for a version bump. 1.0.0 -> 1.0.2. (I missed 1.0.1!) I'll attach the ebuild shortly.
Created attachment 160149 [details] 1.0.2 stable build Added 1.0.2.
Thanks Troy, I've added the ebuild to CVS! Three minor points: * it's better to open a new bug for future version bumps, otherwise this bug would get unwieldly quickly * we have a nice new mirror for rubyforge stuff which means you don't need to hunt down that download number every time. See e.g. rmagick 2.5.1 for an example of its use * please don't include stable keywords in new ebuilds. repoman warns me about that and I should check myself, but better safe than sorry.
