Arch Linux User Repository

Release 25.1.3 of xlibre-xserver is still in beta status. Package xlibre-xserver-beta is available for this.

For the latest updates package xlibre-xserver-git can be used.

Please do not flag this package out-of-date.

Building and installing xlibre-xserver to replace xorg-server

Attention

To enable building this package a binary xlibre-xserver-devel or xorg-server-devel package needs to be installed as a prerequisite for the initial build.

As during this procedure xorg-server is replaced with xlibre-xserver the running X-session - if being used - should not be stopped. As an alternative this procedure can be performed from a terminal session.

Notes

• As the ABI versions of xlibre-xserver do not match those of xorg-server this first needs to be overcome by building and - temporarily - installing a bootstrap package.
• The xf86-input/video driver packages will be uninstalled. Before starting the procedure make sure to query and store the names of these and install the respective xlibre-input/video drivers at the end of the procedure.
• Some distributions have meta packages installed for input devices and video drivers. In case pacman reports a conflict with these make a note of their names and uninstall them.

Build and installation Procedure

1. Build and install xlibre-xserver-bootstrap
2. Build and install xlibre-input-libinput
3. Build and install xlibre-xserver and confirm pacman's request to remove xlibre-xserver-bootstap
4. Build and install the xlibre-input/video packages that correspond to the removed xf86-input/video ones
5. Install any removed meta package again

@jcrowell, if the next release actually becomes a drop-in replacement, I will provide Xorg. But this release is not a drop-in replacement, so I do not provide Xorg. Again, if the user has to add extra things to their config, this package IS NOT a drop-in replacement. I have already stated that, and yet there is no comment from you on that. I have acknowledged the next release too, and again, there is no comment from you on that.

Instead, you delete your older comments, send external links that were already mentioned in the past, make random false accusations (including on other platforms), and send many comments at once (all of which send an email to my inbox) instead of putting your thoughts in a single comment (not too critical, but please stop doing that).

You removed the provides to cause issues with more packages, making it more difficult for people to install our software.

And from my point of view, it seems like those provides/depends were added to break our software on Arch Linux. It's almost as bad as someone randomly/intentionally dropping backdoor trojans into AUR packages to destroy people's trust in it. These are supposed to be expert package maintainers after all who would know that those changes wouldn't fix anything but instead break more things.

Sorry about that one, just following orders from the Freemason lizards. They really hate it when an AUR package breaks their X session. Outstanding theories aside, "your point of view" can very well stay with you, especially when it's an offensive false claim you have zero (0) proof for.

I don't need a lesson from you.

Guess if I need one from you. I also don't get why I'm getting all these messages from random people who are not even responsible for packaging. AFAIK, Artist is the one who wrote all of the new PKGBUILDs, and yet he did not contact me on any platform.

We have our own separate repository if any of you want to use XLibre while avoiding all the issues from these AUR packages.

https://github.com/X11Libre/binpkg-arch-based

Also, here are our official package builds: https://github.com/X11Libre/pkgbuilds-arch-based

Please read the instructions on the repo carefully for switching to the repo.

I removed the faulty provides to avoid claiming that there is no issue at all.

You removed the provides to cause issues with more packages, making it more difficult for people to install our software.

I know all about depends/provides.. I've been using Arch for 20 years and used to maintain packages of my own and XLibre provides the same level of compatibility with the Nvidia driver that Xorg did, soon better. I don't need a lesson from you.

@jcrowell,

We're removing the ABI check for the Nvidia proprietary driver. That fixes the problem you mention. It'll be in the next release.

...but not this release.

Your provides change didn't solve that issue. My ABI Ignore instructions did.

My provides do not claim to solve the issue. I removed the faulty provides to avoid claiming that there is no issue at all. The thing about provides on Arch is that they imply full and exact compatibility with the provided package. That is, if I install an XLibre component, the rest of the packages should continue to function and everything should work out of the box. If the user is required to make manual changes (like adding ABI Ignore flags), we can no longer specify provides. That is because they will not be strictly required to do so, as pacman cannot handle such situations, meaning most people won't do that and will end up with broken setups.

We're also moving the open video drivers directly into the xserver source tree so the ABI checks will no longer be necessary.

...in the next release.

Why would we need to satisfy you? The only reason we're even having to deal with you is because you squatted on our packages so quickly when we already had package maintainers. I'm one of the developers.

And I don't have to deal with you at all.

In any case, forward such discussions to the GitHub issue I have linked below.

@vitaliikuzhdin we're removing the ABI check for the Nvidia proprietary driver. That fixes the problem you mention. It'll be in the next release. Your provides change didn't solve that issue. The ABI Ignore instructions I got from NVidia and provided to the community did. What you did was make a mess. We have protocols/standards to follow that guarantee the display managers and display environments will continue to work because the functions they use don't change.

We're also moving the open video drivers directly in to the xserver source tree so the ABI checks will no longer be necessary. The only thing we can't do that to is the NVidia proprietary driver. You'll have to build from the xserver repo in the future to get updated video drivers.

Why would we need to satisfy you? The only reason we're even having to deal with you is because you squatted on our packages so quickly when we already had package maintainers.

Yes I'm one of the XLibre developers.

Have you read the thing you keep quoting?

"In constrast to Xorg (master - which probably won't see any release ever), we're taking special measures to keep compatibility with proprietary NVidia driver." - and all other drivers.

So we are fixing the ABI issues you as a package maintainer shouldn't have needed/tried to resolve. HaplessIdiot specifically tests the NVidia proprietary drivers before every release now because of the issues over the first few weeks.

This has nothing to do with Display Managers and Desktop Environments. They were never going to have compatibility issues. That was an issue you introduced with your incorrect fix.

@jcrowell, to follow up on this: even if XLibre strives to resemble the original Xorg ABI as closely as possible, it is still not fully compatible, thus we cannot have the provides you want. A good chunk of the issues and the Wiki of the upstream are just people reporting issues with the Nvidia driver, which is also the primary reason for @xiota suggesting to remove the excessive provides in the discussion linked below. This is just one example.

I do, however, think I have a solution that would satisfy both of us. For context, this is not the first, and definitely not the last, experimental new project that claims to replace the older stable one. As an example, uutils-coreutils, a Rust rewrite of the standard Linux utilities, does not provide coreutils, even though some distros choose to act otherwise (similarly to how Artix did here). Anybody who is willing to take the risk can install a wrapper package with the necessary depends, provides, and symlinks.

For XLibre, there is already xlibre-is-xorg, and although it currently only features a wrapper for a single package, it would be really easy to add the rest. This way, the default is to have a proper stable setup, but users who choose to take and acknowledge the risk can just install the wrapper package and make the installation easier.

@jcrowell, like I’ve already stated:

XLibre packages cannot provide their Xorg counterparts. The ABI versions have changed, meaning XLibre is not a drop-in replacement. Having it otherwise will result in broken systems and GUI sessions. I initially did this myself only because users would be reading the install instructions anyway, which required them to rebuild necessary components manually. However, now that there are discussions about adding XLibre to binary repositories, such provides/replaces must be removed. I agree it's inconvenient and I don’t enjoy the install process either, but for as long as there are several ABI versions, this trade-off is unavoidable. The author of the project has also made this clear: https://github.com/chaotic-aur/packages/issues/3684#issuecomment-3013197463

This is not up for discussion. I cannot list Xorg components under provides because users will end up with broken GUI sessions, report this package as the cause, and get it deleted from the AUR, since shipping packages that break systems (whether malicious or not) is obviously not allowed. I’m not even the one enforcing that. Please see the full discussion on GitHub if you'd like more context.

Also, you used "we", so I assume you're a project maintainer. This is the third (?) time I’ve had to quote the project author to a project maintainer. I’ve also already stated that I’m open to XLibre maintainers being co-maintainers here on the AUR.