xorg-server fails to detect current the tslib when USE=kdrive is use. The configure.ac looks for tslib-0.0.pc which no longer exists. It became tslib-1.0.pc but I just patched tslib to install just a standard tslib.pc file in addition to the versioned one. This change will likely hit tslib upstream. This was done so that xorg-server will no longer have to try and auto detect which tslib-VER.pc to look for. It can simply check for pkg-config tslib --libs now. I'll attach a patch for xorg-server a bit later. But It's going to require the use of SNAPSHOT=yes in order to run eautoreconf.
Created attachment 218943 [details, diff] Remove versioned tslib checking
my ebuild changes inlined. Granted the patch should be included in a tarball or elsewhere. But for my testing this is what works. --- /usr/portage/x11-base/xorg-server/xorg-server-1.7.4.901.ebuild 2010-01-30 17:45:35.000000000 +0000 +++ xorg-server-1.7.4.901.ebuild 2010-02-08 21:50:58.000000000 +0000 @@ -5,7 +5,7 @@ EAPI="2" # Must be before x-modular eclass is inherited -#SNAPSHOT="yes" +SNAPSHOT="yes" inherit x-modular multilib versionator @@ -128,6 +128,7 @@ PATCHES=( "${UPSTREAMED_PATCHES[@]}" + "${FILESDIR}/tslib-1.0-check.patch" ) pkg_setup() {
tslib support was almost removed a while back, in fact it might already be gone (I'd need to check). In any case, this patch should go upstream first. Please file a bug and/or post it on the xorg-devel mailing list to get this included in master, and paste the url here. Thanks
I don't have any relationship at all with upstream. If I did, I would skipped filing a bug at Gentoo and gone directly to upstream. I have a good relationship with tslib upstream however and have gotten the fixed pushed there already. So I ask that our own X11 team contact upstream if we feel that is any type of requirement. As of now this patch fixes what is broken when USE=kdrive is used. The xorg-input-tslib module is fine.
To be perfectly honest with you, the X11 team members don't have much free time ATM. This bug being rather low priority, this will probably won't be fixed in the coming days, but rather in the coming weeks or even months (hopefully not). Cheers
How about I just fix it? This really is a blocker for us.
ACK, but please leave this bug open so I don't forget to ping upstream about this. Thanks
I really am not a big fan of tslib-1.0-r1 since you rename upstream's .pc file. I'll gladly apply a patch that checks for "tslib" (falling back to "tslib-XX" if needed) once upstream _releases_ a new version that recommends using "tslib". Until then, I don't really see a reason to apply that patch. Thanks
It's reasons like this that make me at times agree with the "Gentoo is doomed to fail" mentality. When our own maintainers would rather leave the tree in a broken state then take a perfectly working patch that is in upstream.
(In reply to comment #5) > To be perfectly honest with you, the X11 team members don't have much free time > ATM. This bug being rather low priority, this will probably won't be fixed in > the coming days, but rather in the coming weeks or even months (hopefully not). > > Cheers > We all have limited time. So, *please* *please* don't waste our time and yours. This is a serious blocker, touchscreen is obviously needed on some embedded devices including the ones that are now in focus (ARM netbooks and tablets). Please don't let -embedded in the dark just because some "I don't care" kind of decision. Thanks, - Angelo
Hold on, you guys _broke_ tslib for no reason other than "it doesn't need a numbered .pc", upstream however is going with a transition, and you're blaming _me_ for trying to kill the embedded team? You gotta be joking. See, that's how I feel about this patch and that's why I feel Gentoo is doomed. </sarcasm> Sarcasms aside, as I said in an earlier comment, feel free to apply the patch, although I'd much prefer one that checked for "tslib", then "tslib-1.O". I could then send commit that patch upstream. Just reopen this bug once you do apply it so we can push it to the overlay too. Cheers
(In reply to comment #11) > Sarcasms aside, as I said in an earlier comment, feel free to apply the patch, > although I'd much prefer one that checked for "tslib", then "tslib-1.O". I > could then send commit that patch upstream. Sure I can revise the patch to check for that. But with the upstream tslib we moved to no version checking. It should of never been there in the first place. But for the sake of completeness. Sure thing. > Just reopen this bug once you do apply it so we can push it to the overlay too. Thank you.
grep -i tslib build.log * USE: arm kdrive kernel_linux minimal nptl tslib userland_GNU * Applying tslib-1.0-check.patch ... ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=armv5te-softfloat-linux-gnueabi --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr /share --sysconfdir=/etc --localstatedir=/var/lib --prefix=/usr --datadir=/usr/share --disable-ipv6 --disable-dmx --enable-kdrive --enable-tslib --enable-xca librate --disable-xvfb --disable-xnest --disable-record --disable-xfree86-utils --disable-install-libxf86config --disable-dri --disable-dri2 --disable-glx -- disable-xorg --enable-glx-tls --disable-config-hal --sysconfdir=/etc/X11 --localstatedir=/var --enable-install-setuid --with-fontdir=/usr/share/fonts --with- xkb-output=/var/lib/xkb --without-dtrace --disable-xsdl --enable-xcalibrate --enable-xcalibrate --enable-xcalibrate --enable-xcalibrate checking for TSLIB... no checking for TSLIB... yes ## first check fails. Second finds it. I don't know if there is a better way to make use of PKG_CHECK_MODULES. It if it can all be done in the same macro or not. scanelf -n shows it's linking properly too.
Pushed to the tree in 902
Sorry I guess you wanted this OPEN
@solar you broke it. ... checking for TSLIB... no checking for TSLIB... configure: error: Package requirements (tslib) were not met: No package 'tslib' found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables TSLIB_CFLAGS and TSLIB_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. ^^ When merging with -tslib
attached patch seems ok, but it's DIFFERENT from the one which landed in the tree
Also, is this patch really needed? It seems tslib is installing TWO pc files: /usr/lib64/pkgconfig/tslib.pc /usr/lib64/pkgconfig/tslib-1.0.pc
(In reply to comment #16) > @solar you broke it. > > ... > checking for TSLIB... no > checking for TSLIB... configure: error: Package requirements (tslib) were not > met: Commented out the patch for now. Will fix it up then push again later today.
Created attachment 223969 [details, diff] Fixed patch for tslib triple check This is a fixed patch that triple checks for all possible tslib pkg-config variations. This also obsoletes solar's patch.
(In reply to comment #20) > Created an attachment (id=223969) [details] > Fixed patch for tslib triple check Looks good, I'm applying it now to portage. Thanks
And this is now in portage, thanks Sven! I'll wait a couple days and then I'll submit and commit this patch upstream. Cheers
(In reply to comment #21) > (In reply to comment #20) > > Created an attachment (id=223969) [details] [details] > > Fixed patch for tslib triple check > > Looks good, I'm applying it now to portage. Thanks Sven and Remi.
