Package Base Details: xorg-server-dev

Git Clone URL: (read-only)
Submitter: Det
Maintainer: dbermond
Last Packager: dbermond
Votes: 19
Popularity: 0.015078
First Submitted: 2010-06-27 07:53
Last Updated: 2018-12-11 13:26

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 11 ... Next › Last »

desaparecido commented on 2014-06-20 06:14

Hi, thanks for the package :) I successfully builded the packages with libepoxy (1.2) from AUR. After install the packages I didn't have my X session started :(
I use mesa-git repo with [testing] enable. My GPU is a Radeon HD7970 and I want test it because "usually" the're a lot of improvements in this bug:

I can't take the time to see how to resolve because was late the last night but only like question, it's needed to build mesa stuffs after installed this Xorg version ?

thanks :-)

Det commented on 2014-06-17 11:50

This turned out to be a bug in Yaourt:

Things like aurget and pacaur work just fine:,

Det commented on 2014-06-17 07:47

I'm assuming you haven't encountered a lot of split packages, but they all share the same PKGBUILD, even though the resulting packages are different (that's what a split package means - a single PKGBUILD describes multiple packages. We have a totally different meaning for the term "package group").

Now, I'm not sure whether this is a bug in the AUR tools or the AUR itself, but split packages shouldn't indeed be tried to update "separately", when the same PKGBUILD does it for all.

thx1138 commented on 2014-06-17 06:07

Hmm - something is not right with the "PKGBUILD", combining multiple packages. All these packages in "pkgname" have the same PKGBUILD file, but are distinct packages, and are seen as distinct packages by "pacman".

When there is an update, and the update is applied with "yaourt -Syua", then "n^2" packages built, and "n^2 - n" of those tedious builds are a redundant waste of time.

I assume that you are trying to create a pacman "package group". The documentation for pacman groups is really terrible. My expectation is that the members of a group or a "meta-group" are not, themselves, "versioned", so that, once they are installed, they are never meant to be re-installed due to some change in version. Then, each of the _members_ of the group or meta-group would be versioned, and those members would be simple standard pacman packages.

So, I'm thinking that these packages need to be split-up, into simple packages having a shared "group" designation, or/and a meta-group package should be created to reference the members of the meta-group. You can have both a "group" and a "meta-group", if you like.

For a pacman group, the PKGBUILD for each member package would have an entry of "Groups some-shared-group-name".

If instead, or if in addition, there were to be a meta-group, there would have to be an explicit PKGBUILD file for just that meta-group, where "Each split package uses a corresponding packaging function with name package_foo(), where foo is the name of the split package." There should be _no_ build instructions in the meta-group PKGBUILD file! There is sparse documentation at:, "Package Splitting".

You can see an example at:


Det commented on 2014-06-12 21:36

Done. Just tell me, if libepoxy (1.2) isn't enough.

intgr commented on 2014-06-12 17:41

Now that Glamor has been merged into xorg-server, should this package be built with builtin Glamor support?

I added --enable-glamor to the configure line and 'glamor-egl' to xorg-server-dev provides= and conflicts= lines, and things seem to work fine. This fixes a bug with Radeon drivers:

Det commented on 2014-04-16 08:31

Not just maybe, we should do that.

jdbrown commented on 2014-04-16 07:15

fontsproto 2.1.3 and xproto 7.0.26 were recently released and it seems that the code can be built against them. Maybe we can change the dependencies back to the official ones.

jdbrown commented on 2014-04-16 07:15

fontsproto 2.1.3 and xproto 7.0.26 were recently released and it seems that the code can be built against them. Maybe the dependencies back to the official ones.

edtoml commented on 2014-04-14 00:42

For everyones info. The tarball for is missing headers needed to compile glamor. changing the PKGBUILD to use git and appling fixes from enabling glamor and removing glamor-egl before installing the new xserver along with xf86-video-ati-git xf86-input-evdev-git xf86-video-modesetting-git & xf86-video-fbdev-git gives a working install here. On my r7 260x (see if you have one) it runs the uniengine tropical benchmark 20% faster than 1.15.