Failing tests: cannot load such file -- rack/test during build in mock

[Ken Dreyer]

On Sun, Jul 28, 2013 at 1:20 PM, Axilleas Pipinellis
<axilleaspi at ymail.com> wrote:
> Hi,
>
> I am trying to package omniauth[0] and it fails when running
> the spec tests in mock. Using rpmbuild works fine.
>
> In particular it fails when calling rack/test, although the package
> is in BR and gets installed (as per the root.log).
>
> Same happens when building for f19 (rubygem-rack-1.4.5) and rawhide
> (rubygem-rack-1.5.2) so it is not a version issue.
>
> Here [1] is a koji build with the failed build logs.
>
> Any idea why this could be happening?

You've got rubygem(rack) in your BuildRequires, but you'll need
rubygem(rack-test) as well.

It's a good idea to always use mock to build the package, instead of
using rpmbuild by hand, because rpmbuild will implicitly use all the
RPMs that are installed on your local computer, which leads to
head-scratchers like this one.

Since you're keeping all your specs in GitHub, you can even use fedpkg
to wrap mock. This makes the operations very similar to what you'd do
if you were actually using Fedora's own dist-git infrastructure. It
looks something like this:

$ git clone git at github.com:axilleas/fedora.git
$ cd fedora/packages/rubygem-omniauth

Then get the source gem:

$ gem fetch omniauth

(or if you need a specific version:)
$ gem fetch omniauth --version

Set up the sources file so fedpkg can find the gem (this is sort of
equivalent to what "fedpkg new-sources" does under the hood):

$ md5sum omniauth-1.1.4.gem > sources

Now you can use "fedpkg mockbuild" to build the gem in mock on your
local computer.

$ fedpkg --dist rawhide mockbuild
$ fedpkg --dist f19 mockbuild


As you get higher into the dependency chain for GitLab, you may find
that you are mocking rubygem packages that depend on other packages
that are themselves not yet in Fedora. In those cases, it's still a
good idea to use mock, but there are a couple of additional steps. You
can't really use the "fedpkg mockbuild" wrapper any more, and you'll
have to run mock by hand. This is a little more tedious.

First, mock the dependencies into binary RPMs. I'll use paperclip as
an example. If I'm packaging rubygem-paperclip, that means using mock
to build rubygem-bourne, rubygem-climate_control, and rubygem-cocaine.

Next, I create a fresh mock chroot:

$ mock init

Next, I install these not-yet-in-Fedora deps into the mock chroot by hand:

$ mock install rubygem-bourne-1.5.0-1.fc19.noarch.rpm
rubygem-climate_control-0.0.3-1.fc19.noarch.rpm
rubygem-cocaine-0.5.1-1.fc19.noarch.rpm
rubygem-mocha-0.14.0-1.fc19.noarch.rpm

And lastly, I run "mock rebuild" with the --no-clean flag, so that
mock doesn't clobber the prerequisites that I just installed:

$ mock --no-clean rebuild rubygem-paperclip-3.5.0-1.fc19.src.rpm

(Note that any time you run "mock rebuild" without "--no-clean", mock
wipes the chroot, and you'll have to re-install those binary RPMs
again.)

This approach allows you to stay very cognizant of the dependency
chains, and focus your review submissions accordingly. In fact, in
Bugzilla, you can set the "depends on" values so that you know which
review requests need to come first.

I have a feeling you're going to want to use this approach with the
omniauth -> hashie dependency :)

As you can see, the longer that the "not in Fedora" depchain
stretches, the more tedious this becomes. If the depchain is
incredibly long (gulp), you may want to set up a custom yum repo and
add it to /etc/mock/default.cfg. I don't recommend modifying the
default /etc/mock/fedora-* or /etc/mock/epel-* cfg files, though. Just
set up your own new file in /etc/mock, and symlink
/etc/mock/default.cfg to that. If you modify the default epel or
fedora ones, it can become even more confusing :)

The yum repo approach implies a tradeoff: when you use "mock install"
to put the deps into the chroot by hand, you don't have to deal with
mock's cache, or running "createrepo" all the time. Alternatively,
when you use a private yum repo, you don't have to deal with lots of
shuffling binary RPMs around by hand, or typing the proper "mock
install" commands over and over.

I think my personal boundary for "when do I set up a yum repo" is
around four deps, so the paperclip one was pushing it. EPEL doesn't
have nearly the amount of rubygem packages present, so it is a
nightmare to mock Gitorious deps without a private yum repo.

- Ken