Package Base Details: xorg-server-dev

Git Clone URL: (read-only, click to copy)
Submitter: Det
Maintainer: ny-a
Last Packager: ny-a
Votes: 20
Popularity: 0.001553
First Submitted: 2010-06-27 07:53
Last Updated: 2021-02-01 04:14

Latest Comments

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

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.

Det commented on 2014-04-13 15:08

Guess so. You don't have to quote the whole thing, though.

r08 commented on 2014-04-13 14:52

Comment by Det
2014-04-10 09:48
Everybody's suddenly so interested in this.

Yes because if you read the news, xorg-server has some kickass features, bug fixes, and performance enhancements. So everyone is eager to test these. =D

kozzi commented on 2014-04-11 16:08


there are some missing files, I have make my own packages for this xorg-server(+latest mesa and latest llvm) and it is amazing. All bugs with slow radeonsi are gone.