[gentoo-amd64] Re: Xorg-server-1.14.1.901 Fails Emerge

[Duncan]

Dale posted on Wed, 05 Jun 2013 04:16:43 -0500 as excerpted:

> Frank Peters wrote:
>> On Wed, 5 Jun 2013 06:00:01 +0000 (UTC)
>> Duncan <1i5t5.duncan@×××.net> wrote:
>>
>>> But xorg-server-1.14.1.901 is definitely built/installed/running fine
>>> here!
>>>
>> Thanks for your help in this matter.  Your advice allowed me to locate
>> the exact error, and after some searching I believe that I have found
>> the cause of the problem.  It is the issue of not using UDEV.
>>
>> I filed a bug report:
>>
>> https://bugs.gentoo.org/show_bug.cgi?id=472378

That would appear to be the problem, yes.  Good work! =:^)

>> Because I don't know how to reconfigure the ebuild to use a patched
>> source I'll have to wait until the maintainer gets around to applying
>> the patch.

>  Digest command:

While I replied just a few minutes ago discussing the digest command, 
it's actually not needed here at all.

There's an easier way! =:^)

These instructions assume you're using portage.  If you're using one of 
the other PMs (package managers, paludis or pkgcore being the other two 
besides portage), you'd do it their way, which may or may not be 
different, instead.

/etc/portage/patches can form the root of a directory tree organized 
similarly to the gentoo tree layout, with category and package names, and 
the patches to apply to a particular package appearing as files in this 
tree.

So given that the package we're discussing is x11-base/xorg-server:

1) Create the directory /etc/portage/patches/x11-base/xorg-server/ .  
Make sure the permissions at all levels are such that the portage user 
can read it, but preferably that only root (or your admin user if you're 
not quite as strict on security) can write it.  Say root:root or 
root:portage, 644 or 640 perms.

2) Drop your patch file named as *.patch in that subdir.  (I'm not 
actually sure whether *.diff will work as well or whether it must be 
*.patch, but something like *.bak should be ignored.)

As an example, you could call this patch noudev-build.patch, or something 
similar, so it would appear as the file

/etc/portage/patches/x11-base/xorg-server/noudev-build.patch.

3) Run the emerge again, and you should be able to see fairly early in 
the log, after unpack but before it starts actually building, something 
like:

Applying user patches:

You should then see it try the patch, and whether it applies 
successfully.  Note that if it detects the patch and it does NOT apply 
successfully, that's an error, and the build will stop.  But if it can't 
see the patch at all, say because permissions are wrong or perhaps 
because it's named with the wrong extension, off course it'll continue as 
if the patch wasn't there at all.


4) This same trick should work for many packages, but there's a few it 
won't work on.  The user-patches function that it relies on is a 
mandatory part of EAPI-5, and if you look in the
xorg-server-1.14.1.901.ebuild file, you'll see this line near the top:

EAPI=5

So if it doesn't work, either there's a bug in the ebuild or you have 
permissions or something (maybe the -pN patch level?) wrong.

In earlier EAPIs, it was an optional function that many but not all gentoo 
devs opted to include in their packages.  So it isn't /guaranteed/ to 
work on EAPIs before 5, but there's a reasonably good chance it will, 
depending on the package.  (And some projects applied it by policy.  IIRC, 
it has long been policy for the gentoo/kde project, for instance, so 
pretty much any kde package honored it.)  But in EAPI-5, if it doesn't 
work there's a bug.

And because the ebuild will stop with an error if it finds a patch that 
does NOT apply, you don't have to worry about stale patches accumulating 
long after the patch was applied upstream, or the code changing out from 
under the patch.  Because if it does, the ebuild will simply error out, 
and you can go delete the patch from the patches tree and try again.


Meanwhile, where it DOES work (as it should here), it's a lot easier to 
just drop the patch in the appropriate patches subdir and let portage 
automatically apply it, then it is to futz around with the ebuild itself, 
editing it manually and making sure it can find the patch, redigesting, 
etc.  It makes things a LOT easier, which means a lot more gentoo users 
are likely to be able to test patches than could otherwise. =:^)

Plus it's nice not to have to worry about either losing the fix or having 
to put the ebuild in an overlay to avoid losing it.  And if it's a long-
term patch that you like but upstream hasn't seen fit to apply yet, with 
it in the patches tree, every upgrade gets patched automatically.  No 
having to futz around with overlaying the ebuild every single time, just 
to apply a custom patch.

There's actually several packages that I apply long-term custom patches 
to in this way.  As examples, gwenview and superkaramba are two packages 
I carry my own patches for.  (In the superkaramba case, I have a couple 
bugs filed with the patches attached in kde's bugzilla, but I think 
superkaramba is an orphan package upstream, no maintainer, simply kept 
building by the release team, so no comments on the bugs at all.  In the 
gwenview case, the upstream dev decided that stepping the magnification 
in whole 100% increments was the thing to do, while I preferred 5% or so 
increments, so when that changed I was able to see where they changed the 
code and change it back to something I liked better.  But obviously 
that's not a patch upstream will take, since they deliberately changed it 
to the way it is now.)

I've been upgrading both at every kde dot-upgrade release, so basically 
monthly (more often now, since I'm actually running live-branch 
4.10.49.9999 and rebuilding once or twice a week to get the latest 
changes), and am still using the same patchfiles I originally placed 
there several years ago.  Imagine how many times I'd have had to manually 
edit the ebuild to add those patches, if it weren't for the user-patching 
functionality handling it entirely automatically, once I put the patches 
in the right place. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman