Bug 164786 - Mark x11-drivers/xf86-input-evdev-1.1.5-r1 stable
|
Bug#:
164786
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: AMD64
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: x11@gentoo.org
|
Reported By: diacone@diacone.org
|
|
Component: Ebuilds
|
|
|
URL:
|
|
Summary: Mark x11-drivers/xf86-input-evdev-1.1.5-r1 stable
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2007-02-01 06:53 0000
|
There is problem with x11-drivers/xf86-input-evdev-1.1.2-r2 compilation:
make all-recursive
make[1]: Entering directory
`/var/tmp/portage/xf86-input-evdev-1.1.2-r2/work/xf86-input-evdev-1.1.2'
Making all in src
make[2]: Entering directory
`/var/tmp/portage/xf86-input-evdev-1.1.2-r2/work/xf86-input-evdev-1.1.2/src'
if /bin/sh ../libtool --tag=CC --mode=compile x86_64-pc-linux-gnu-gcc
-DHAVE_CONFIG_H -I. -I. -I.. -Wall -march=k8 -O2 -pipe -DXFree86Server
-DIN_MODULE -DXFree86Module -DXFree86LOADER -I/usr/include/xorg -I../src -MT
evdev_drv_la-evdev.lo -MD -MP -MF ".deps/evdev_drv_la-evdev.Tpo" -c -o
evdev_drv_la-evdev.lo `test -f 'evdev.c' || echo './'`evdev.c; \
then mv -f ".deps/evdev_drv_la-evdev.Tpo"
".deps/evdev_drv_la-evdev.Plo"; else rm -f ".deps/evdev_drv_la-evdev.Tpo"; exit
1; fi
if /bin/sh ../libtool --tag=CC --mode=compile x86_64-pc-linux-gnu-gcc
-DHAVE_CONFIG_H -I. -I. -I.. -Wall -march=k8 -O2 -pipe -DXFree86Server
-DIN_MODULE -DXFree86Module -DXFree86LOADER -I/usr/include/xorg -I../src -MT
evdev_drv_la-evdev_brain.lo -MD -MP -MF ".deps/evdev_drv_la-evdev_brain.Tpo" -c
-o evdev_drv_la-evdev_brain.lo `test -f 'evdev_brain.c' || echo
'./'`evdev_brain.c; \
then mv -f ".deps/evdev_drv_la-evdev_brain.Tpo"
".deps/evdev_drv_la-evdev_brain.Plo"; else rm -f
".deps/evdev_drv_la-evdev_brain.Tpo"; exit 1; fi
mkdir .libs
x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -march=k8 -O2 -pipe
-DXFree86Server -DIN_MODULE -DXFree86Module -DXFree86LOADER -I/usr/include/xorg
-I../src -MT evdev_drv_la-evdev_brain.lo -MD -MP -MF
.deps/evdev_drv_la-evdev_brain.Tpo -c evdev_brain.c -fPIC -DPIC -o
.libs/evdev_drv_la-evdev_brain.o
x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -Wall -march=k8 -O2 -pipe
-DXFree86Server -DIN_MODULE -DXFree86Module -DXFree86LOADER -I/usr/include/xorg
-I../src -MT evdev_drv_la-evdev.lo -MD -MP -MF .deps/evdev_drv_la-evdev.Tpo -c
evdev.c -fPIC -DPIC -o .libs/evdev_drv_la-evdev.o
evdev.c: In function 'EvdevSwitchMode':
evdev.c:235: error: 'SendCoreEvents' undeclared (first use in this function)
evdev.c:235: error: (Each undeclared identifier is reported only once
evdev.c:235: error: for each function it appears in.)
evdev.c:236: error: 'DontSendCoreEvents' undeclared (first use in this
function)
make[2]: *** [evdev_drv_la-evdev.lo] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory
`/var/tmp/portage/xf86-input-evdev-1.1.2-r2/work/xf86-input-evdev-1.1.2/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/var/tmp/portage/xf86-input-evdev-1.1.2-r2/work/xf86-input-evdev-1.1.2'
make: *** [all] Error 2
!!! ERROR: x11-drivers/xf86-input-evdev-1.1.2-r2 failed.
Call stack:
ebuild.sh, line 1546: Called dyn_compile
ebuild.sh, line 937: Called src_compile
ebuild.sh, line 1255: Called x-modular_src_compile
x-modular.eclass, line 333: Called x-modular_src_make
x-modular.eclass, line 328: Called die
!!! emake failed
!!! If you need support, post the topmost build error, and the call stack if
relevant.
Reproducible: Always
You're building this driver against xorg-server-1.2, aren't you? You need the
newer version (1.1.5).
actually, I tried to build it against the 1.1.1-r4 version. I downgraded all
x11 relative staff to the stable version for amd64
I was not able to downgrade x11-drivers/xf86-input-evdev. I was forced to use
xf86-input-evdev-1.1.5-r1.
It's possible you need to downgrade inputproto to 1.3.2 and rebuild libXi,
xorg-server, etc. before evdev 1.1.2 will compile, but I'm not entirely sure.
(That is, if you have newer inputproto/libXi installed.)
I'm hitting this same thing wrt the 2007.0 release. I can tell you what
versions of what that we're using, if you need them. We pulled in the newer
XCB-enabled stuff just yesterday since we had the newer libX11 due to the
security bug, but our snapshot is from over a month ago otherwise. If I need
to adjust any versions, let me know. I don't know what information you may
need otherwise.
I get the same error on my x86 stable Gentoo. Stable 1.1.2-r2 fails but
1.1.5-r1 from testing works. I've tried to recompile all X-related stuff etc.
but nothing has helped. I think the newer version needs to get stabilized.
Agreed. Using 1.1.5-r1 worked for me, also.
I am getting this same error while trying to build an x86 LiveCD on an amd64
platform. I am trying to keep everything very generic so I can continue to use
the name spec files in the future so I am really stuck here.
It appears to me that inputproto-1.4 has been unmasked for x86 and it is not
including SendCoreEvents and DontSendCoreEvents in XI.h, so the compilation of
xf86-input-evdev does not work. On amd64 inputproto-1.4 has not been unmasked
yet, so I am still using 1.3.2 and everything works fine.
So if I am seeing this correctly, stable x86 is broken right now and
inputproto-1.4 needed to be masked again.
No, it's a bad idea to move something back to ~arch, and something that is
discouraged by policy, especially when there is another solution. Mark
1.1.5-r1 stable.
Same problem here on a 2006.1 fresh configuration. Emerging the ~x86 version
(1.1.5-r1) of xf86-input-evdev worked from me, too.
CPU type: athlon64, legacy mode.
(In reply to comment #9)
> No, it's a bad idea to move something back to ~arch, and something that is
> discouraged by policy, especially when there is another solution. Mark
> 1.1.5-r1 stable.
>
Fair enough, my point really is, don't leave stable broken like it has been for
the last couple of days.
Just waiting on the maintainers to give us the go-ahead and I'll start marking.
I'm just not positive if this is the course of action the maintainers want, or
if they have a different/better solution. If I don't hear anything by the end
of the day, I'll likely just start marking it stable on arches, since I've been
testing this now on several arches for the release and it seems fine.
(In reply to comment #12)
> Just waiting on the maintainers to give us the go-ahead and I'll start marking.
> I'm just not positive if this is the course of action the maintainers want, or
> if they have a different/better solution. If I don't hear anything by the end
> of the day, I'll likely just start marking it stable on arches, since I've been
> testing this now on several arches for the release and it seems fine.
>
We were going to stable 7.2 this weekend, so this works into our plans well.
I'll change this bug so that evdev gets stabled sooner rather than later.
So can we add arches to CC now?
(In reply to comment #14)
> So can we add arches to CC now?
>
Oh, yeah - sorry. I'll do that.
ARM, MIPS and s390 will need to stable >=inputproto-1.4 as well.
Nevermind about s390, they don't have a keyword on this package.
(In reply to comment #21)
> Thanks but their was nothing new to me. My setup is ok and always worked before
>
You should file a new bug with the information you've given here.