Summary: | !!! ERROR: x11-base/xorg-server-1.4.2 failed. / broken version-number | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | saufnix <saufnix> |
Component: | New packages | Assignee: | Gentoo X packagers <x11> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | robbat2 |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 241850 | ||
Attachments: | Compressed file of all Log-Information I found |
Description
saufnix
2008-09-29 20:10:39 UTC
Please attach the build log to this bug report. Created attachment 166794 [details]
Compressed file of all Log-Information I found
Sorry, but there was no file called build.log, so I compressed all files from /var/tmp/portage/x11-base/xorg-server-1.4.2/temp
Build log != build.log Er, maybe it's time you ran `emerge -vuaDN world' to the bitter end. We cannot begin to support odd combinations of ancient versus modern versions. `emerge -vuaDN world' would result in a complete system-update and is no option to me. But I could fix the Bug and I want notice this here in case somebody needs it: In configure.ac at the first line VENDOR_RELEASE="((($PVMAJOR) * 10000000) + (($PVM) * 100000) + (($PVP) * 1000) + $PVS)", $PVM and $PVP variables are missing. The simple fix is, to add "PVM=4" and "PVP=2" before the VENDOR_RELEASE-line. After that, "autgen.sh" must be execute, to re-create the "configure"-script. With the new "configure"-script I could build xorg-server without any problems. Let's see... x11: I suggest depending on autoconf-2.62-r2 or newer. saufnix: jer is right, your system is too out of date. Specifically, your autoconf is too old. Upgrade it and the problem should vanish PVM and PVP are come from the definition of XORG_RELEASE_VERSION (xorg-server-1.4.2/aclocal.m4). If you look at the autoconf-generated configure file ("configure" vs. "configure.ac"), it SHOULD look this like: # Check whether --with-release-version was given. ... PVM=`echo $PACKAGE_VERSION | cut -d . -f 2 | cut -d - -f 1` ... PVP=`echo $PACKAGE_VERSION | cut -d . -f 3 | cut -d - -f 1` ... PVMAJOR=`echo $PACKAGE_VERSION | cut -d . -f 1` PVS=`echo $PACKAGE_VERSION | cut -d . -f 4` ... VENDOR_RELEASE="((($PVMAJOR) * 10000000) + (($PVM) * 100000) + (($PVP) * 1000) + $PVS)" None of the things mentioned above is the trouble source. An outdated util-macros package is. The xorg-server ebuild reruns the whole autoconf toolchain. Before running autoreconf it runs aclocal. The aclocal.m4 file shipped in the xorg-server tar ball has a correct definition of XORG_RELEASE_VERSION (it defines PVM/PVP). However rerunning aclocal with an old util-macros package installed will replace this correct definition with an outdated one, lacking the definitions of PVM/PVP. The error we see comes from this XORG_RELEASE_VERSION being expanded into configure when autoconf runs later. Solution: Make xorg-server depend on at least >x11-misc/util-macros-1.1.5. Err, I meant >=x11-misc/util-macros-1.1.5 of course. 1.1.6 is still ~keyworded. Btw, I just played around with paludis and noticed a different behaviour wrt outdated packages than portage. Paludis seemed to pull in the new version into the dependencies when it can't find the ebuild of the installed version in the portage tree. So practically this means, pulling obsolete versions from portage adds an implicit dependency on the next available version to all other packages that depend on that package directly or indirectly. Using paludis would have not revealed that dependency bug here, so probably portage should copy that behaviour. (Of course, bugs like this one here, still must be fixed until the new portage version becomes standard..) As Clemens said, the issue is with x11-misc/util-macros. Update that package and xorg-server should be fine afterwards. For the record, the PVP and PVM variables were introduced almost 2 years ago in version 1.1.3. If you don't want to update your box, that's your problem, not ours. The ebuilds we currently provide will work just fine without any changes. Closing. Thanks Please see bug report 241850 why this way of handling packaging failures is nothing but unacceptable. |