On 07/29/2013 11:07 AM, Ken Dreyer wrote:
You've got rubygem(rack) in your BuildRequires, but you'll
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
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
Since you're keeping all your specs in GitHub, you can even use
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 firstname.lastname@example.org: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
$ 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
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",
wipes the chroot, and you'll have to re-install those binary RPMs
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"
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  for that purpose but I haven't used it yet.
It's good to know all these little details you wrote about, thanks again :)
FAS : axilleas
GPG : 0xABF99BE5