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@cox.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
