ruby-oci8-1.0.3 does currently not install, due to a wrong emake line in the ebuild. I know I provided the ebuild myself not so long ago, but for some reason it is not working anymore. Anyway, I've attached an ebuild for ruby-oci-1.0.4 that fixes the problem. Reproducible: Always Steps to Reproduce: 1.try to emerge ruby-oci-1.0.3 Actual Results: see the error message related to the emake line in the ebuild: The specific snippet of code: * emake CONFIG_OPT="--prefix=${D}usr" || die * The die message: * (no error message) Expected Results: installation of ruby-oci-1.0.3 ebuild I've attached an ebuild for version 1.0.4, because I've noticed an installation problem with Oracle instant-client 11 for version 1.0.3. Version 1.0.4 works without a problem.
Created attachment 182414 [details] ruby-oci8-1.0.4.ebuild
Hrm, you provided the e-build? I don't seem to see you in the changelog. Are you Matthew Marlowe in disguise? ;) I didn't have any make problems with 11.1.0.7.0 instantclient and the 1.0.3 ruby-oci8 ebuild. Are you talking about upstream problems? The Makefile (provided by upstream) runs the commands just the same as your change. Are you sure you're really fixing anything by running setup.rb directly? I wonder what's different about your system. Maybe the ebuild should rdepend on sys-devel/make to make sure you have it? (it'd be silly if you didn't have make. :) ) Anyway, I'm curious to find out what the real error is. Also, why are you not installing in /usr? Gentoo doesn't keep ruby stuff in /lib/ruby. It keeps ruby stuff in /usr/lib/ruby. I find that your ebuild is broken because you don't use the /usr prefix. Regardless, your setup.rb change works, except for the prefix part. I don't know if the change is desirable though. I'd rather use the Makefile with the portage emake. Maybe Hans De Graaff can chime in.
For some reason the build doesn't puke on my system. I have a more vanilla system and tried it on there found that it does puke. Your ebuild dies, too, with the same "(no error message)" message. Further up in the build, it seems it doesn't seem to be able to see the LD_LIBRARY_PATH correctly. I'll dig a little deeper.
Created attachment 182925 [details] ruby-oci8-1.0.4.ebuild I found the real problem: Make was running multiple tasks in parallel, and the config wasn't finished before the setup was run. Adding -j1 to the emake command fixes the problem. For some reason my machine reliably finishes the config before the setup, but in vmware it's another story. I remember we removed the -j1 arg at the request of the ruby team because it seemed to be fine without it, but this e-build really does need it. I've added a comment to the ebuild explaining why it's there. The 1.0.3 ebuild should have the -j3 added to emake, too. We could also probably remove it and the earlier ebuilds.
> The 1.0.3 ebuild should have the -j3 added to emake, too. er, I mean the 1.0.3 ebuild should have the -j1 added to emake, too.
Please try to fix it instead of working it around.
Created attachment 182927 [details] ruby-oci8-1.0.4.ebuild Working it around? Do you mean using a workaround? Okay, here's another way to fix it, which still allows multiple compiles to happen at once. For what it's worth, this problem existed before, and it was fixed the -j1 way: http://bugs.gentoo.org/show_bug.cgi?id=141730 Yet it was removed because of this (because I was clueless): http://bugs.gentoo.org/show_bug.cgi?id=183548#c8 Anyway, this should work now.
Still a workaround actually; try to fix the upstream makefile, check out http://blog.flameeyes.eu/tag/foraparallelworld if you need help to understand what the problem is.
Very interesting, however I'm not too keen on patching upstream's Makefile, as that will require more gentoo developer maintenance overhead, especially since the ebuild is working without a patch. I'm not a developer of the ruby-oci8 upstream. I'd rather submit a bug/patch to get upstream to fix their makefile. If you want to maintain a Makefile patch and fix it every time the Makefile changes, go ahead, but the ebuild works as it is now, with parallel jobs.
I apologise, it looked to me like it was working but I just now notice the line: make[1]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. So, as far as I can tell, the problem is that make isn't running make, it's running ruby setup.rb. So of course it's not going to be able to run in parallel, because setup.rb isn't make, and you can't set the flags to the parent rule for setup.rb. That, or maybe I'm just too clueless about make to get it to work correctly. Any suggestions? If there is a solution, I'll be happy to submit a bug upstream and create a patch in the mean time. But it does appear that other ruby ebuilds force -j1 (ruby-opengl, ruby-ldap, qt4-qtruby bug 132584). In any case, is it really worth the extra work to make this build in parallel? This takes only about two to four seconds to build.
Sorry for my lack of response, busy with other stuff. What is the way to move forward here, because I would like to get this bug fixed? Is forcing -j1 an acceptable fix here? I can also have a look at the make file, but that will probably cost me much more time and no guarantees that I will be able to fix the problem.
My last conclusion was that you can't parallelize setup.rb -- you can't let make run multiple setup.rb instances. Flameeyes didn't seem to reply with a solution, either. I really don't think it's a big deal to force -j1 on this. Unless some mastermind steps in and has some clue about setup.rb parallelism. Either way, a real Gentoo developer has to make a decision and commit this. This bug has been dawdling for so long, 1.0.5 is out already.
I've added ruby-oci8-1.0.6 to CVS which Troy provided in bug 271510. In this case the Makefile is just a thin wrapper around the ruby setup.rb stuff, so why not just call setup.rb directly, as we also do in the convenience code in ruby.eclass? That will also avoid the QA warnings that repoman emits about the -j1 workaround. Thanks everyone, and apologies for not dealing with this in a more timely manner.
