handbrake ebuild

My life has been uncharacteristically busy lately, which is a really new experience for me, because I usually have so much free time that I don’t know what to do with myself.  Anyway.  As a result of lack of time, it’s been interesting to see how I deal with the crunches when there’s stuff I want to work on.  So far though, my adaptation has been nothing more than watching tasks I want to do be ignored for weeks on end.

So, in an attempt to get one task of many moved forward, I’m just going to do a brain dump of my thoughts into a blog post and hope that someone can take it running from here.

To start with, I totally love the video encoding tool Handbrake.  It is an aboslute godsend, one that makes it possible for me to actually encode all my DVDs to MPEG4 using x264, and have me happy on every count.  (If I’ve talked about this already before … oh well.  I can’t remember these things anymore.)

There’s a lot of reasons for it’s awesomeness, but I’ll write those up in a later post.  The simplest summary is probably to say that it passed the Star Trek test with flying colors — which was always assumed to be an impossible task.  So, saying I’m happy is putting it mildly.  It’d be more accurate to say I feel like a schoolgirl on crack who is dancing on the rain.  Or something.

Anyway.  I’d like to roll an ebuild for it and get it into portage, if possible, but because of the build system, there’d be some things that need to change first.

The build system used in Handbrake downloads sources from their website and unpacks them during the building stage.  While that’s fine if you’re building it yourself, and if you wanted to roll your own ebuild (which, in fact, there are some already in our multimedia overlay), it wouldn’t be good from a QA stand for Gentoo.

So, what needs to be done (this is where I start whining about how busy I am, and how this is your job to fill in the gap) is the Makefile needs to be modified so it won’t download and unpack the remote sources.  It can still access them, but it needs to be up to the ebuild to do those in its own stages — like moving the tarballs into SRC_URI and using src_unpack to unpack them.

I haven’t looked closely at the build system, but I imagine it wouldn’t be too difficult to patch.  If someone wanted to take it from there, I could run the last few legs and see about cleaning up the ebuild and possibly getting it included in the tree.

If anyone’s up for the challenge, follow this bug.  Thanks 😀

9 comments on “handbrake ebuild

  1. nightmorph

    Didn’t you already ask to yoink the handbrake ebuild I keep in my GitHub overlay? IIRC it was a month or so ago. That ebuild works just fine for me; the app itself runs nicely. I should probably hit up the homepage and see if there have been any new releases, but the version used in my ebuild works just fine, so I haven’t felt the need to do any updates.

  2. andrew

    As someone who has written handbrake ebuilds, and posted to that popular bug, I must admit it’s quite de-motivating having been shot down time and time again for portage inclusion. The instructions for generating a tarball have been posted in the bug for a *LONG* time, and it shouldn’t take more than 5 minutes to do.

  3. DRAiNO

    Handbreak is indeed a neat multi-platform transcoding tool, which I would be delighted to see included into ‘prod’/main portage tree. What I would like to know is what is this ‘Star Trek’ test you mention?

  4. OOPMan

    I was looking at rolling an ebuild for this myself in the hopes of submitting it and getting it included in Sabayon at some point.

    Something to keep in mind is the detail that version 0.9.4 is not very compatible with more recent versions of Gnome. Is is thus best to use the latest svn source bundle rather than the 0.9.4 source.

    Anyways, if the problem Gentoo have with HB is that the Makefile uses custom-downloaded libs rather than system-installed ones then I’m sure that it should be possible to to rewire things appropriately…


Leave a Reply