I am not shure it the Gentoo flavor for Raspi shares the same programs as the Debian-based stuff does but under Raspian I am using OMXPlayer which is adapted for the Raspi and plays back 1080p stuff fine via HDMI without the need for X.

This is a pitty ! Hopefully we will see a merge of the OMXPlayer code (if possible) with the default branch of MPlayer.
OMXPlayer is really cool and it is surprising to see 1080p stuff via HDMI from a Raspi.

I am not shure it the Gentoo flavor for Raspi shares the same programs as the Debian-based stuff does but under Raspian I am using OMXPlayer which is adapted for the Raspi and plays back 1080p stuff fine via HDMI without the need for X.

This is a pitty ! Hopefully we will see a merge of the OMXPlayer code (if possible) with the default branch of MPlayer.
OMXPlayer is really cool and it is surprising to see 1080p stuff via HDMI from a Raspi.

There is an overlay that contains an e-build for it, but a patch failed (and so did the build) and I have no idea where to get support for it.

The patch fails because the lines in hunk1 that need to be removed have been changed.
After you fix that, omxplayer-9999-wrapper.patch fails to apply too.
The is a bug on bugs.gentoo.org for that.

My Pi doesn't have layman yet, so I can check that the patches apply but not usefully build the code.

And it looks like it isn't fixed yet. So we are waiting on the developer of the patch then? What's disheartening is that this was posted in June, it kinda reaks of being dropped with little to no support.

I just tried mplayer using unaccelerated fbdev with overclocking turned on (it isn't mine and I got permission), for the average sized movies it will play fine, although I'm not sure if there is a switch to scale the video in a framebuffer display to fullscreen, so the image is small. If anyone knows a flag, option, or switch to make mplayer scale the video to fit fullscreen in a framebuffer, let me know. For bluray quality stuff, it doesn't even come close to cutting it, even with framdrop turned on.

It would be very nice to get direct rendering to work for gentoo.

*edit*

Would posting that I'm experiencing the same thing on the bug in bugzilla help get some traction on the issue?

Its not hard to fix so the patches apply.
You need to be able to read the patch files, apply the patch by hand, make a

Code:

diff -u oldfile newfile >patchfile

then use the new patchfile.

A - at the start of the line is a line to be removed
A + at the start of a line is a line to be added.
There is 3 lines of context at the top and bottom of each 'hunk'. A hunk is considered a single change.

The problem with the Makefile.patch is that the region to be patched by hunk1 has changed, so patch can't find it.

I've not really looked at omxplayer-9999-wrapper.patch from a quick look, its a wrapper to set up the output resolution to 1920x1080 and start omxplayer.
If you don't mind doing that by hand, its not needed. The hack is to change the ebuild to not apply the patch.

Whenever you change anything that goes into an ebuild, you need to fix the manifest, so portage doesn't mind. Thats

Code:

ebuild /path/to/.ebuild manifest

Lastly, work in your own private overlay, or syncing will wipe out all your hard work.

You can get my revised Makefile.patch and test if you want.
All I can say right now is that it applies cleanly._________________Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

There are two things here. layman installs overlays, which themselves are normally held in a version control system, such as git.

The code you want to compile using the ebuild was at sometime in it life held in a version control system. All projects work that way so that many people can apply patches to the sources at the same time. Again this may be git. For most packages, gentoo provides a mirror of the sources. The is the useful bit of the source code repository. There is no need for you to have the history.
ebuilds ending in -9999 are a special case. The fetch the source code (not the ebuild) for the projects repository. After the first fetch, they just update what you already have.

The source repository for the ebuild and the source repository for the code it builds are two different places.

If you want to have the same ebuild installed on your system from several different repositories, there are two mechanisims for controlling when one gets used.
In your own local overlay, you are in change of versions - you can bump the -r part of the ebuild file name. I usually stat at -r101 as its obvious when you look at the output of emerge -av <package>

The other mechanism is package masking you may speciifiy a repository name in a package.mask, such as

Code:

=media-video/omxplayer-9999::x-portage

This prevents media-video/omxplayer at version 9999 from the x-portage overlay being used. If you have media-video/omxplayer-9999 in another overlay, it cam still be used.
If you have media-video/omxplayer-9999-r1 somewhere, that beats all as its a higher version number._________________Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

So, I'm still confused. If I have a potential Makefile that could fix this mess, but this e-build will continue to grab the material from the git repository until a successful e-build, but it won't build without the makefile, then how do I apply this patch?

I really don't mean to sound stupid, I've just never messed with 3rd party e-builds all that much.

I've gotten rid of the overlay, as you said, on the next emerge my changes will be gone, no point in having it. So the only thing I have is my own custom overlay.

Last edited by Bigun on Fri Nov 09, 2012 1:41 pm; edited 1 time in total

Heres the process. In the directory with the .ebuild file is a directory called ./files
You will find the patch files here with names ending .patch.

Rename the makefile patch. You will want to read it to make the new patch file, so don't loose it.
Run

Code:

ebuild /path/to/ebuild manifest

so that portage is happy with the file names, sizes and assorted checksums.

Run

Code:

emerge omxplayer

If you have set your keywords correctly, emerge will start and fail as it can't find the Makefile patch (you renamed it above).

The fail message will tell where the build location is. Proably /var/tmp/portage somewhere. cd to there and you will find
omxplayer sources unpacked. You could just unpack it yourself somewhere in ~/ but this will give you and insight into some of the works.

You will find Makefile there, unchanged by any successfully applied patch hunks. Make a copy of Makefile called Makefile.old You need this to make your patch later.
Open Makefile in your editor and open the original patch file (which you renamed) in your pager.

The first hunk applies tight at the top of the Makefile. Make the changes line by line in Makefile. Where a line in the patch starts with a -, delete the same line from Makefile.
Where it starts with a +, add the line to Makefile. Work through the first hunk like this.
Notice that the three lines of context at the end of hunk1, the line without a leading + or - have changed between the Makefile and the patch. This is what caused the patch to fail.

Further down the file, repeat for hunk2. Save the changed Makefile.

You now have an original Makefile, called Makefile.old and a changed Makefile, so you have all of the ingredients needed to produce a patch.
Do this with

Code:

diff -u Makefile.old Makefile > patch.file

I often get the input files the wrong way round, look at patchfile to make sure the + and - are against the right lines or you will have a reversed patch, which portage won't apply. When the patch is correct, put in in place of the patch file you originally renamed on ./files, using the same name as the original patch.

Make the ebuild manifest again and emerge to test. This time, the Makefile patch will apply but the -wrapper patch will fail.
Rinse and repeat for the -wrapper.

When you have built and tested omxplayer, file a bug at bugs.gentoo.org. In the bug explain what you did, and how you tested it. Attach the two patches to your bug.
It will save others after you repeating your work. Leave a comment on the existing -wrapper bug pointing to your new bug.
Thats how Open Source works. Now you can move on to your next bug.

When you post enough patches, you will be encouraged to become a developer because its less work for existing devs. You get to commit your own work to the tree.
Thats how Gentoo works. You have a lot to learn from your first patch to commit access to the portage tree but everyone starts somewhere.

The workflow I outined is not the best but it takes advantage of portage working the way it normally works. You could fetch the sources to your ./~ and to all the work there._________________Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

I have it at /usr/local/portage/layman/xmw/media-video/omxplayer/files/omxplayer-9999-wrapper.patch
Fetch http://bpaste.net/show/57139/ put it into the files dir and call it omxplayer-9999-wrapper.patch

It looks like you lost it somehow. Have you already removed the .patch from the filename?_________________Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.