Created attachment 446392 [details]
dev-lang/ruby-2.1.9.ebuild text
Current dev-lang/ruby-2.1.9 ebuild with failing src_install()
Created attachment 446398 [details, diff]
partial patch for ebuid
This is a relevant patch that mostly fixes the problem, but it is NOT sufficient due to other transformations in the eclasses that make subtle changes in where things get put.
Created attachment 446400 [details]
emerge --info from building system.
The required emerge --info dump
This error is preventing completion of an emerge kde-plasma/plasma-meta install. The dev-lang/ruby-2.1.10(~) also fails the exact same way. Not going to put logs, etc... in here unless requested. Slot 2.2 fares no better, same error dev-lang/ruby:22 dies ins src_install() attempting to remove (non-existent) rubygems directory in build. (In reply to G.Wolfe Woodbury from comment #5) > The dev-lang/ruby-2.1.10(~) also fails the exact same way. > > Not going to put logs, etc... in here unless requested. Now 2.1.10 fails after being required to rebuild after update of libreadline (@preserved-rebuilds) Interestingly ruby:2.3 did build ok. This is on my main machine, not a new install. (In reply to G.Wolfe Woodbury from comment #7) > Now 2.1.10 fails after being required to rebuild after update of libreadline > (@preserved-rebuilds) > Interestingly ruby:2.3 did build ok. This is on my main machine, not a new > install. ruby:2.3 was already using rm -f. I have now updated the other ruby ebuilds to use rm -f as well. Does this solve the issue for you? Note that ebuilds have been fixed in place since this is a built-time issue. (In reply to Hans de Graaff from comment #8) > > ruby:2.3 was already using rm -f. I have now updated the other ruby ebuilds > to use rm -f as well. Does this solve the issue for you? > > Note that ebuilds have been fixed in place since this is a built-time issue. The problem, as I see it, is that the dev-lang/ruby build is using only "rm -f" and the new ebuilds do not seem to create the rubygems and other directories. The builds seem to need to use "rm -rf" so that they do not fail when the directory is not there. "rm -rf" will still return an error if permission or an IO error occurs, so the die will still occur if something else is wrong. I am in the process of populating another VM, so I will soon be in a situation to test the dev-lang/ruby ebuilds. Created attachment 450446 [details]
emerge --info new install
New install on a Braswell Celeron N3150 processor machine (wolves.private)
Created attachment 450448 [details]
list of installed packages on build machine
list of installed packages from eix database on wolves.private
Created attachment 450450 [details]
dev-lang/ruby 2.1.10 ebuild copy
the unaltered dev-lang/ruby-2.1.10.ebuild from wolves.private
Created attachment 450452 [details]
portage ebuild logfile from wolves
The log from the build that failed
Created attachment 450454 [details]
console output from build that failed on wolves
screen capture of the failing emerge on wolves.private
Created attachment 450456 [details]
ruby-ng.eclass copy from wolves
unaltered ruby-ng.eclass file from wolves.private machine
Was installing dev-lang/ruby:2.1 on a new machine (wolves.private) which is a braswell Celeron N3150 Intel SOC system. It failed in the same way as before. Including as much of the unaltered information as I can think of as relevant to the failure. Includes 'emerge --info' 'ebuild' 'ruby-ng.eclass' 'emerge log' and a list of all packages installed so far on the system. I suspect that there is something slightly odd about the 'ruby-ng.eclass' that fails to set the '$RUBY' variable in the install phase. I am going to try resetting to use ruby:2.3 to see if it works. dev-lang/ruby:2.3 does complete build and install dev-lang/ruby BUT dev-ruby/rubygems-2.6.7 et alia will not build and install. (bz #594962) I may have spoken too soon... The ruby:2.3 did NOT finish installing correctly. There is an undetected error during the install phase that prevents the executeable from being installed. Attaching the portage build log. Created attachment 450596 [details]
ebuild log from attempt to install dev-lang/ruby:2.3
The error not flagged by emerge is in the last few lines, when trying to set the initial profile(?)
(In reply to G.Wolfe Woodbury from comment #13) > Created attachment 450452 [details] > portage ebuild logfile from wolves > > The log from the build that failed This is the log from Ruby 2.1.10 failing. This seems to be another issue. Looking at the log file it seems that only the documentations files are being installed, even though the install phase logs that everything works as expected. This then leads to an error from eselect-ruby because it cannot find the /usr/bin/ruby21 to link to /usr/bin/ruby. Consequently no ruby implementations are available and this leads to a missing ${RUBY} later on, preventing merging of further ruby packages. So the question is: why is only the ruby documentation installed. The other steps are present in the ebuild file and show the correct output in the log file. INSTALL_MASK might do this but I don't see that being used in the --info output. I'm not sure what other explanation there could be. It might be useful to investigate the image directory and see what is actually there. There are logs from bot :2.1 and :2.3 available above. :2.1 fails early :2.3 compiles, but fails during installation, thus there is no available RUBY interpreter on the system for $RUBY to be set to for use. Is it possible that using ~amd64 ACCEPT_KEYWORDS is doing something to the system setup that makes Ruby fail? I am sort of presuming that development is being done in ~amd64 environments, but that may not be true. (In reply to Hans de Graaff from comment #20) > (In reply to G.Wolfe Woodbury from comment #13) > > Created attachment 450452 [details] > > portage ebuild logfile from wolves > > > > The log from the build that failed > > This is the log from Ruby 2.1.10 failing. This seems to be another issue. > Looking at the log file it seems that only the documentations files are > being installed, even though the install phase logs that everything works as > expected. > > This then leads to an error from eselect-ruby because it cannot find the > /usr/bin/ruby21 to link to /usr/bin/ruby. Consequently no ruby > implementations are available and this leads to a missing ${RUBY} later on, > preventing merging of further ruby packages. > > So the question is: why is only the ruby documentation installed. The other > steps are present in the ebuild file and show the correct output in the log > file. > > INSTALL_MASK might do this but I don't see that being used in the --info > output. I'm not sure what other explanation there could be. It might be > useful to investigate the image directory and see what is actually there. The "emake" fails in its attempt to install the results in the image/ locations for some obscure reason. This results in there being no working ruby being actually installed -- but the install did not fail because it did install what it had (which was pathological.) The work-around I used was an out-and-out cheat. I changed to the work/ location and ran "make install" directly, which put the pieces directly into the working system (not the /var/tmp/portage/ locations.) Once ANY working ruby was available in the system, the ebuilds work correctly and everything proceeds correctly. It is only when no ruby is available that the emake fails to put the files in the /var/tmp/portage/ places. While installing ruby-2.2.9 in a new setup, the build portion of the emerge makes all of its targets correctly, but while doing the internal install to the /image directory prior to merging into the system tree it fails to complete AND the emerge does not notice the error(!) Consequently, the merge of .../image to the live system "succeeds" but is lacking all the good parts of the build. Attaching relevant build logs, einfo, and .ebuild files. Created attachment 523300 [details]
dev-lang/ruby-2.2.9 build log
Created attachment 523302 [details]
emerge --info =dev-lang/ruby-2.2.9
Created attachment 523304 [details]
dev-lang/ruby-2.2.9.ebuild
Created attachment 523306 [details]
extrated eix information for this system (machine)
Created attachment 523308 [details]
installation make.conf file
*** Bug 651948 has been marked as a duplicate of this bug. *** (In reply to Hans de Graaff from comment #20) > INSTALL_MASK might do this but I don't see that being used in the --info > output. I'm not sure what other explanation there could be. It might be > useful to investigate the image directory and see what is actually there. While doind updates to ruby-2.5.1 this is happening. I set FEATURE += "keepwork" during the emerge examination of .../image/ shows only the usr/share/doc/... files are present even when the log claims the other stuff is in place. Attaching newest log, info, and a recursive ls of the /var/tmp/portage/dev-lang/ruby-2.5.1/ Created attachment 526780 [details]
log for update to ruby-2.5.1
Created attachment 526782 [details]
emerge --info =dev-lang/ruby-2.5.1
Created attachment 526784 [details]
ls -lR of /var/tmp/portage/dev-lang/ruby-2.5.1/ (compressed)
compressed ls -lR listing of the build tree after
emerge --update dev-lang/ruby-2.5.1
Note that the /image directory has only the doc files, other clams about install bins, and whatever in the log, did not seem to happen in reality. Further, there are no error indications that I can find.
Note: ruby24 installs fine on current systems about to add another ruby slot build (In reply to G.Wolfe Woodbury from comment #35) > Note: ruby24 installs fine on current systems > > about to add another ruby slot build Let's close this and move on, I think. We've made a bunch of changes since. |
Created attachment 446388 [details] Ebuild log for dev-lang/ruby-2.1.9 A recent change (I think) to the build procedures internal to the dev-lang/ruby packages that strips out the building of rubygens results in a failure to build (install phase) because the ebuild does an "rm -r" on the rubygems sub-directory, which is no longer present in the build tree. The statement in question is: rm -r "${D}/usr/$(get_libdir)/ruby/${RUBYVERSION}/rubygems" || die "rm rubygems failed" It ought to be: rm -rf "${D}/usr/$(get_libdir)/ruby/${RUBYVERSION}/rubygems" || die "rm rubygems failed" or include a test for the existence of the directory before attempting to remove it. This particular statement is in the src_install() function of the ebuilds [not just ruby-2.1.9] The 2.1.9 ebuild and complete build log are attached as evidence. [Just a month or so ago this didn't seem to be a problem -- did ebuilds get changed without a revbump?] AFAIK, An "rm -rf" can report failures on filesystem operations that are not related to the absence of the named tree.