Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 594206

Summary: dev-lang/ruby-2.1.9 will not build due to failure to remove a non-existent rubygems directory
Product: Gentoo Linux Reporter: G.Wolfe Woodbury <redwolfe>
Component: Current packagesAssignee: Gentoo Ruby Team <ruby>
Status: RESOLVED OBSOLETE    
Severity: major CC: redwolfe
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 594962    
Attachments: Ebuild log for dev-lang/ruby-2.1.9
dev-lang/ruby-2.1.9.ebuild text
partial patch for ebuid
emerge --info from building system.
emerge --info new install
list of installed packages on build machine
dev-lang/ruby 2.1.10 ebuild copy
portage ebuild logfile from wolves
console output from build that failed on wolves
ruby-ng.eclass copy from wolves
ebuild log from attempt to install dev-lang/ruby:2.3
dev-lang/ruby-2.2.9 build log
emerge --info =dev-lang/ruby-2.2.9
dev-lang/ruby-2.2.9.ebuild
extrated eix information for this system (machine)
installation make.conf file
log for update to ruby-2.5.1
emerge --info =dev-lang/ruby-2.5.1
ls -lR of /var/tmp/portage/dev-lang/ruby-2.5.1/ (compressed)

Description G.Wolfe Woodbury 2016-09-18 10:14:40 UTC
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.
Comment 1 G.Wolfe Woodbury 2016-09-18 10:17:35 UTC
Created attachment 446392 [details]
dev-lang/ruby-2.1.9.ebuild text

Current dev-lang/ruby-2.1.9 ebuild with failing src_install()
Comment 2 G.Wolfe Woodbury 2016-09-18 10:26:02 UTC
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.
Comment 3 G.Wolfe Woodbury 2016-09-18 10:31:16 UTC
Created attachment 446400 [details]
emerge --info from building system.

The required emerge --info dump
Comment 4 G.Wolfe Woodbury 2016-09-18 10:33:16 UTC
This error is preventing completion of an emerge kde-plasma/plasma-meta install.
Comment 5 G.Wolfe Woodbury 2016-09-21 02:43:25 UTC
The dev-lang/ruby-2.1.10(~) also fails the exact same way.

Not going to put logs, etc... in here unless requested.
Comment 6 G.Wolfe Woodbury 2016-09-21 11:47:18 UTC
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.
Comment 7 G.Wolfe Woodbury 2016-09-28 14:28:31 UTC
(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.
Comment 8 Hans de Graaff gentoo-dev Security 2016-10-02 07:00:07 UTC
(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.
Comment 9 G.Wolfe Woodbury 2016-10-03 11:33:49 UTC
(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.
Comment 10 G.Wolfe Woodbury 2016-10-16 17:39:46 UTC
Created attachment 450446 [details]
emerge --info new install

New install on a Braswell Celeron N3150 processor machine (wolves.private)
Comment 11 G.Wolfe Woodbury 2016-10-16 17:41:22 UTC
Created attachment 450448 [details]
list of installed packages on build machine

list of installed packages from eix database on wolves.private
Comment 12 G.Wolfe Woodbury 2016-10-16 17:42:55 UTC
Created attachment 450450 [details]
dev-lang/ruby 2.1.10 ebuild copy

the unaltered dev-lang/ruby-2.1.10.ebuild from wolves.private
Comment 13 G.Wolfe Woodbury 2016-10-16 17:44:02 UTC
Created attachment 450452 [details]
portage ebuild logfile from wolves

The log from the build that failed
Comment 14 G.Wolfe Woodbury 2016-10-16 17:45:17 UTC
Created attachment 450454 [details]
console output from build that failed on wolves

screen capture of the failing emerge on wolves.private
Comment 15 G.Wolfe Woodbury 2016-10-16 17:48:09 UTC
Created attachment 450456 [details]
ruby-ng.eclass copy from wolves

unaltered ruby-ng.eclass file from wolves.private machine
Comment 16 G.Wolfe Woodbury 2016-10-16 17:54:40 UTC
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.
Comment 17 G.Wolfe Woodbury 2016-10-17 11:27:07 UTC
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)
Comment 18 G.Wolfe Woodbury 2016-10-17 20:33:40 UTC
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.
Comment 19 G.Wolfe Woodbury 2016-10-17 20:39:33 UTC
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(?)
Comment 20 Hans de Graaff gentoo-dev Security 2016-10-23 07:03:56 UTC
(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.
Comment 21 G.Wolfe Woodbury 2016-10-24 08:11:19 UTC
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.
Comment 22 G.Wolfe Woodbury 2017-01-26 22:12:07 UTC
(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.)
Comment 23 G.Wolfe Woodbury 2017-01-26 22:17:08 UTC
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.
Comment 24 G.Wolfe Woodbury 2018-03-10 17:01:42 UTC
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.
Comment 25 G.Wolfe Woodbury 2018-03-10 17:03:40 UTC
Created attachment 523300 [details]
dev-lang/ruby-2.2.9 build log
Comment 26 G.Wolfe Woodbury 2018-03-10 17:04:57 UTC
Created attachment 523302 [details]
emerge --info =dev-lang/ruby-2.2.9
Comment 27 G.Wolfe Woodbury 2018-03-10 17:05:56 UTC
Created attachment 523304 [details]
dev-lang/ruby-2.2.9.ebuild
Comment 28 G.Wolfe Woodbury 2018-03-10 17:07:44 UTC
Created attachment 523306 [details]
extrated eix information for this system (machine)
Comment 29 G.Wolfe Woodbury 2018-03-10 17:10:19 UTC
Created attachment 523308 [details]
installation make.conf file
Comment 30 Hans de Graaff gentoo-dev Security 2018-04-02 06:14:22 UTC
*** Bug 651948 has been marked as a duplicate of this bug. ***
Comment 31 G.Wolfe Woodbury 2018-04-07 14:55:48 UTC
(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/
Comment 32 G.Wolfe Woodbury 2018-04-07 14:57:55 UTC
Created attachment 526780 [details]
log for update to ruby-2.5.1
Comment 33 G.Wolfe Woodbury 2018-04-07 15:00:19 UTC
Created attachment 526782 [details]
emerge --info =dev-lang/ruby-2.5.1
Comment 34 G.Wolfe Woodbury 2018-04-07 15:08:06 UTC
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.
Comment 35 G.Wolfe Woodbury 2019-08-14 20:28:53 UTC
Note:  ruby24 installs fine on current systems

about to add another ruby slot build
Comment 36 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2023-04-10 05:01:11 UTC
(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.