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

[Axilleas Pipinellis]

On 07/29/2013 11:07 AM, Ken Dreyer wrote:
> You've got rubygem(rack) in your BuildRequires, but you'll need
> rubygem(rack-test) as well.
>

Crap. I should do a repoquery rubygem-rack* first and see if there was a 
package missing from BR...

> 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.
>

I always use mock, that's why I encountered this problem in the first 
place :)

> 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
>
>

That's good information thank you. I haven't yet used fedpkg as a mock 
wrapper, but only when I push to official repositories. I always wanted 
to ask what is everyone's workflow when it comes to packaging and this 
one tip is good to know as it will be easier to package the gems from 
inside my git repo :)

> 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 :)
>

Yeap, I did it a couple of times before I submitted hashie, so I am 
familiar with the process :)

> 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.
>

I have set up a repo [0] for that purpose but I haven't used it yet.
It's good to know all these little details you wrote about, thanks again :)

[0] http://repos.fedorapeople.org/repos/axilleas/gitlab/

-- 
FAS : axilleas
GPG : 0xABF99BE5
Blog: http://axilleas.me