HandBrake 0.10.2 on CentOS 7

HandBrake 0.10.2 on CentOS 7

This article is intended to be a sidebar to "Run Fedora Under CentOS". Here I provide terse instructions for building HandBrake 0.10.2 under CentOS 7. I strongly recommend creating a CentOS 7 systemd-nspawn container for building and running this. The provided spec files are minimally tested---all I can say is "works for me". To build HandBrake, and all its dependencies, you will need to install dozens of other packages, not just from the base repository, but also EPEL.

Prerequisites

  1. Create a systemd-nspawn container for building and running HandBrake. This isn't strictly necessary, but highly recommended. I can pretty much guarantee that installing all the dependencies on your main system will eventually cause some kind of breakage. Keep this mess isolated in its own sandbox.
  2. The version of CentOS 7 I was using for this, per /etc/redhat-release, was::
    CentOS Linux release 7.1.1503 (Core)
  3. Source files. No sense in me hosting free software that is readily available on countless mirrors worldwide. So I'll instead just provide a list of filenames, along with their md5sums.
  4. Note the HandBrake directory has two other source files. The HandBrake spec file (see below) explains where to download these files.
md5sum filename
fd3678f35004b4c92e3da39356996054 atk-2.18.0/atk-2.18.0.tar.xz
90a929e8fe66fb5d19b5adaaea1e9a12 cairo-1.14.4/cairo-1.14.4.tar.xz
c988ea12f4117330246e041109152b4a fontconfig-2.11.94/fontconfig-2.11.94.tar.bz2
0dfa6ce94f13393cecac1f19e68498b2 gdk-pixbuf2-2.33.1/gdk-pixbuf-2.33.1.tar.xz
7340e67da74e872ea1c0afc3802e9bb9 glib2-2.47.1/glib-2.47.1.tar.xz
2becb7e8bcf2adf5cf39e6c463dab02c gtk3-3.18.4/gtk+-3.18.4.tar.xz
b1ac9b8bcc37b26cfb2c5e1761f50ff9 HandBrake-0.10.2/fdk-aac-v0.1.1-6-gbae4553.tar.bz2
db0a71147463664c4230ed3f1caf4fe8 HandBrake-0.10.2/HandBrake-0.10.2.tar.bz2
195c2f04ef562d3e6708f0461ea2eb41 HandBrake-0.10.2/libmfx-v2014.tar.bz2
2256fd144c936936db9c92e77510a011 harfbuzz-1.0.6/harfbuzz-1.0.6.tar.bz2
981396e099bc91c29e6769e49a0cb8d6 libepoxy-1.3.1/v1.3.1.tar.gz
7fde35d4a127b55ce8bbcefe109bc80d pango-1.38.1/pango-1.38.1.tar.xz

SPEC Files

My Convention(s)

Note: a convention I use in my rpmbuild tree is to create a dedicated source directory under SOURCES for each package. In other words, I don't just dump all souce files and patches into SOURCES. I have at least one sub-directory within SOURCES that corresponds to each spec file. You will see this line (or a very similar one) at the top of all my spec files:

%define _sourcedir %{_topdir}/SOURCES/%{name}-%{version}

How I Created These

"Create" is really too generous a term: at best I hacked these. The general procedure was to:

  1. Download the latest vanilla source tarball of the given package (see above)

  2. Download the latest source RPM for the package for CentOS (preferably) or Fedora (if a CentOS source RPM isn't available)

  3. Extract the spec file from the soure RPM:

    rpm2cpio rpmfile.rpm | cpio -idmv
    
  4. Copy the spec file to my rpmbuild/SPECS directory

  5. Add the custom _sourcedir macro (shown above) to the spec file

  6. Modify package version info in the spec file

  7. Remove all the patch directives from the spec file. At first I tried to maintain the patches, but it quickly became way too tedious. I'm guessing many of the patches were backports from future versions anyway, so likely redundant. If nothing else most sources seemed to change enough that the patches wouldn't apply cleanly. I spent too long getting this working to try to maintain all the patches. Sorry. That is left as an exercise to a more enterprising individual.

  8. Attempt "rpmbuild -ba package.spec". I got lucky a few times, and stuff "just worked". But usually something failed, and involved a little bit of real work. This includes, but is not limited to:

    • Packaging new files
    • Updating (i.e. rebuilding) dependency packages
    • Working around/modifying/removing custom hacks in the spec files

Generally the overall process is more tedious than technical. So, without further ado, here they are:

Ubuntu Nightly Builds

I decided I wanted to try out the HandBrake nightly builds for some bleeding-edge functionality. Initially I tried to use the above infrastructure to create a build from the latest git-master snapshot. That re-started me down the dependency hell path. So I decided, maybe it's better to just use nspawn to create an Ubuntu container, since HandBrake nightly builds are readily available for that platform.

The first step is to install debootstrap from epel, then actually create an Ubuntu bootstrap environment:

# yum install debootstrap
# debootstrap --arch amd64 vivid /desired/path/to/ubuntu/bootstrap/ http://archive.ubuntu.com/ubuntu

Now login to the Ubuntu environment:

# systemd-nspawn --directory=/desired/path/to/ubuntu/bootstrap/

First thing I noticed: /etc/resolv.conf is some kind of wacky symlink. There is likely an elegant way to fix it, but I just deleted the symlink and copied over the contents of my real /etc/resolv.conf (in my case it's a simple one-liner, and static at that).

Next, install the package for the add-apt-repository command, which allows installing the HandBrake nightly build PPA. Follow-up with a global update, and an install of some basic/familiar packages:

# apt-get install software-properties-common
# add-apt-repository ppa:stebbins/handbrake-git-snapshots
# apt-get update
# apt-get install vim man-db ssh

Now add additional repos to satisfy dependencies. My default /etc/apt/sources.list file looked like this:

deb http://archive.ubuntu.com/ubuntu vivid main

I modified it to look like this:

deb http://us.archive.ubuntu.com/ubuntu vivid main restricted universe multiverse

Then I ran "apt-get update" again, and finished with this:

# apt-get install handbrake-cli handbrake-gtk