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

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

[Frank Peters]

On my system, emerge wants to update xorg-server to 1.14.1.901 but the
compile phase always fails.  

There is no obvious error recorded in the log file, but based on a
gentoo bug report (Bug 472058) it seems that a -Werror compile flag
could be causing the problem.

My emerge log only reports this:

cc1: some warnings being treated as errors
make[5]: *** [xf86Events.lo] Error 1
make[5]: *** Waiting for unfinished jobs....
/tmp/portage-acc/tmp/portage/x11-base/xorg-server-1.14.1.901/work/xorg-server-1.14.1.901/hw/xfree86/common/xf86Config.c: In function 'configImpliedLayout':
/tmp/portage-acc/tmp/portage/x11-base/xorg-server-1.14.1.901/work/xorg-server-1.14.1.901/hw/xfree86/common/xf86Config.c:1677:35: warning: declaration of 'xf86configptr' shadows a global declaration [-Wshadow]
                     XF86ConfigPtr xf86configptr)
...
[snip a lot of stuff until the end of log]


The bug report (#472058) mentions a failure occurring at a different point,
but -Werror seems to be the cause.

I waited a few days to see if there were any other reports about a similar
compile failure but so far there are none.  I can only assume that xorg-server
is compiling without problem on other systems.  Why is it failing on mine?

Has anyone on the list experienced this failure?

I would like to remove the -Werror compile flag but without patching
the source I don't see how this could be done.

Frank Peters

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

[Duncan]

Frank Peters posted on Tue, 04 Jun 2013 22:17:15 -0400 as excerpted:

> On my system, emerge wants to update xorg-server to 1.14.1.901 but the
> compile phase always fails.  
> 
> There is no obvious error recorded in the log file, but based on a
> gentoo bug report (Bug 472058) it seems that a -Werror compile flag
> could be causing the problem.
> 
> My emerge log only reports this:
> 
> cc1: some warnings being treated as errors
> make[5]: *** [xf86Events.lo] Error 1
> make[5]: *** Waiting for unfinished jobs....
> ...
> [snip a lot of stuff until the end of log]

The actual error will be printed above that.  Depending on how many
make-jobs you are running and some other things, it could actually be
QUITE far above that.  Doing a search for "error:" (without the quotes,
preferably case insensitive) in the log generally finds it pretty fast,
and I tested on the log attached to the mentioned bug and found the
error there pretty fast, so it should work for this package.

> 
> 
> The bug report (#472058) mentions a failure occurring at a different point,
> but -Werror seems to be the cause.
> 
> I waited a few days to see if there were any other reports about a similar
> compile failure but so far there are none.  I can only assume that xorg-server
> is compiling without problem on other systems.  Why is it failing on mine?
> 
> Has anyone on the list experienced this failure?
> 
> I would like to remove the -Werror compile flag but without patching
> the source I don't see how this could be done.

The guy in that bug is using pretty radical CFLAGS (-Ofast and those
-floop flags), and apparently using gcc 4.8 as well, which is still masked.
And one of the problems with upstreams using -Werror by default is that
it's hard telling just /what/ a new gcc is going to warn about next, so
doing -Werror in a release (as opposed to an internal testing version,
which is what the flag is designed for) is pretty much /begging/ for
trouble with some gcc version or other, often the newer ones.

But of course xorg-server-1.14.1.901 isn't a full release, but rather a
pre-release version, so upstream /does/ get some leeway with it, tho
even then it's really asking for trouble unless you /want/ people
testing with all sorts of gcc versions and reporting the -Werror
stoppages that come up, as opposed to wanting people's run-time
testing.  And I don't think that's what they had in mind so I don't
know why they're doing -Werror, but anyway...

I believe I read, I think in flameyes' blog (where this specific error
was being used as a reason NOT to do -Werror, IIRC), that that specific
error is a known issue with -Werror, due to a new warning in gcc 4.8.


Which means... if you're trying to build with gcc 4.8, try again with
4.7.x.  If you're not using gcc 4.8, then your error is likely a
different bug.

And also... USE=kdrive?  In the bug, the log says USE=kdrive, even
tho the reported package settings said USE=-kdrive.  So I'm not
sure what's up there.  But certainly, unless you have a reason
to run USE=kdrive, please ensure that you're running USE=-kdrive.


Meanwhile, I don't have 4.8 installed here, but I can confirm
that xorg-server-1.14.1.901 built here just fine, with gcc
4.7.3.  I should mention, however, that I'm running live-git
-9999 version ebuilds from the x11 overlay for mesa and my
two drivers (xf86-video-ati and xf86-input-evdev), among other
things.  It's possible that there's some issue with the non-git
versions.

But xorg-server-1.14.1.901 is definitely built/installed/running
fine here!

[ebuild   R    ] x11-base/xorg-server-1.14.1.901:0/1.14.1.901
USE="nptl udev xorg -dmx -doc -ipv6 -kdrive -minimal
(-selinux) -static-libs -suid -tslib -xnest -xvfb" 0 kB

CFLAGS="-march=native -pipe -O2 -frename-registers -fweb
-fmerge-all-constants  -fgcse-sm -fgcse-las -fgcse-after-reload
-ftree-vectorize -freorder-blocks-and-partition"

gcc-4.7.3

cat /etc/portage/package.unmask/live 
# live packages I want to test

~media-libs/mesa-9999
~x11-drivers/xf86-video-ati-9999
~x11-drivers/xf86-input-evdev-9999

(Those -9999 builds are from the x11 overlay,
as I mentioned above.)

-- 
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

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

[Frank Peters]

On Wed, 5 Jun 2013 06:00:01 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:


> 
> The actual error will be printed above that.  Depending on how many
> make-jobs you are running and some other things, it could actually be
> QUITE far above that.
> ...
>
> Which means... if you're trying to build with gcc 4.8, try again with
> 4.7.x.
> 

Thanks a lot.  You've been a big help.  Unfortunately, the problem still exists.

I was using gcc-4.8.1, and I found the error WAY back in the log file:

/tmp/portage-acc/tmp/portage/x11-base/xorg-server-1.14.1.901/work/xorg-server-1.14.1.901/hw/xfree86/common/xf86Events.c:566:9: error: implicit declaration of function 'xf86platformVTProbe' [-Werror=implicit-function-declaration]
         xf86platformVTProbe();


The error refers to an "implicit declaration" which only means a lack of some
declaration or a missing header file declaration.  If it were not for -Werror
this probably should have finished compiling.

But, I then installed gcc-4.7.3 in a different slot and tried again to compile.
This also failed but the error seems to be a bit different:

common/.libs/libcommon.a(xf86Events.o): In function `xf86Wakeup':
xf86Events.c:(.text+0xf14): undefined reference to `xf86platformVTProbe'
collect2: error: ld returned 1 exit status
make[4]: *** [Xorg] Error 1

In this case, the location of the error is the same, in xf86Events.c, but
now we have an "undefined reference" which occurs, I think, during the linking.

The problem seems to be a fault of the source code, but then why is it
failing only on my system?

I do have USE=-kdrive.

Frank Peters

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

[Frank Peters]

On Wed, 5 Jun 2013 03:25:29 -0400
Frank Peters <frank.peters@comcast.net> wrote:

> 
> But, I then installed gcc-4.7.3 in a different slot and tried again to compile.
> This also failed but the error seems to be a bit different:
> 
> common/.libs/libcommon.a(xf86Events.o): In function `xf86Wakeup':
> xf86Events.c:(.text+0xf14): undefined reference to `xf86platformVTProbe'
> collect2: error: ld returned 1 exit status
> make[4]: *** [Xorg] Error 1
> 

Possibly this problem relates to the fact that I do not use udev.

Here is a link that possibly explains this error:

http://permalink.gmane.org/gmane.comp.freedesktop.xorg.devel/35490


Examining the Gentoo xorg-server source that is used for this build,
I do not see that this patch has been applied.  Most likely this causes
the error.

I will have report this to the Gentoo bug list.

I would also like to manually apply the patch and then recompile
but I am not sure how to rebuild the digest with a new source.

Frank Peters

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

[Frank Peters]

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

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.

Once again, my decision to avoid the (to me) unnecessary complications
of UDEV has got me into trouble.  It seems that developers just assume
that everyone uses UDEV and they will, inadvertently or otherwise, overlook
those few who choose not to do so.  I just wonder how long I'll be able
to exercise this choice.

Frank Peters

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

[Dale]

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
>
> 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.
>
> Once again, my decision to avoid the (to me) unnecessary complications
> of UDEV has got me into trouble.  It seems that developers just assume
> that everyone uses UDEV and they will, inadvertently or otherwise, overlook
> those few who choose not to do so.  I just wonder how long I'll be able
> to exercise this choice.
>
> Frank Peters
>
>
>

Don't feel bad, I don't use udev either but use eudev.  Some opted to
use mdev too.  Digest command:

ebuild path/to/ebuild manifest/digest

Naturally that is from memory and replace the relevant parts.  You may
need manifest for one or digest but structure is the same.  Actually, I
think they both do the same thing after a quick glance at man ebuild. 
Should get you started tho.

Keep in mind, after you sync, busted again unless you put it in a
overlay.  If you don't sync often, you may not care tho.  May even be
properly fixed by then.

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

[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:

> ebuild path/to/ebuild manifest/digest
> 
> Naturally that is from memory and replace the relevant parts.  You may
> need manifest for one or digest but structure is the same.  Actually, I
> think they both do the same thing after a quick glance at man ebuild.
> Should get you started tho.

That's correct.

Manifest/digest do the same thing now, but years ago there was one 
version of it, then things changed a bit and the other appeared that did 
something a bit different, but on repositories/overlays using the newer 
version the older version simply aliased to the new so people's scripts, 
etc, didn't break.  I've forgotten the exact details, but I remember it 
feeling slightly ridiculous at first using the old form for the new 
function, since it wasn't really technically accurate any more.  I think 
that's why they changed the name on the second, making it more accurate 
again.  But then that broke people's scripts so they aliased the old to 
the new, and now they both do the same thing.

-- 
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

[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@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

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

[David Klann]

[-- Attachment #1: Type: text/plain, Size: 1018 bytes --]

On Thu, 6 Jun 2013 05:26:34 +0000 (UTC) you coerced some electrons to say:

> 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! =:^)

Hey Duncan,

Thanks for this detailed explanation of the /etc/portage/patches
functionality. I occasionally find myself applying patches, usually to test
bug fixes. This'll make it much easier as you describe in your note.

Thanks again for the details!

  ~David

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

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

[Rich Freeman]

On Wed, Jun 5, 2013 at 4:43 AM, Frank Peters <frank.peters@comcast.net> wrote:
> Once again, my decision to avoid the (to me) unnecessary complications
> of UDEV has got me into trouble.  It seems that developers just assume
> that everyone uses UDEV and they will, inadvertently or otherwise, overlook
> those few who choose not to do so.  I just wonder how long I'll be able
> to exercise this choice.

It really isn't any different than running any other exotic
configuration, like prefix, freebsd, or whatever (though those are
treated as archs and get testing before being stabilized).  Developers
don't test under every possible configuration, so the more unusual
your configuration is, the more likely you are to run into these sorts
of issues.

The only thing you can do is report bugs when they happen, or become a
developer and help fix them.  That's how every other arch gets
supported - there are just more people doing it.

Rich