Arch Linux User Repository

reserved

Installation instructions:

1. Prepare a non-X session. If you still want a GUI session, (temporarily) opt for another backend, such as Wayland. If you're fine with using the terminal, perform everything from a fresh TTY. This is an unfortunate requirement because installing XLibre requires removing Xorg, which obviously breaks the X session.

2. Install xlibre-server-bootstrap. This is a bootstrap package and will not provide a working X session, so be sure to follow the next steps!

3. When prompted to install xlibre-server-bootstrap, pacman will report a few conflicts, namely with xorg-*, xf86-*, and packages that depend on Xorg components. Agree to remove those (but be careful, these are likely important packages) and make note of their names.

4. Install xlibre-input-libinput. Again, expect similar conflicts.

5. Install xlibre-server. When prompted, agree to replace xlibre-server-bootstrap.

6. For every xorg-* and xf86-* package you previously removed, install an xlibre-* counterpart. I’ve uploaded all the xlibre-drivers counterparts for the xorg-drivers group from extra, but I haven’t touched the AUR-only drivers yet. I’m considering adding them once I’ve researched further. In the meantime, feel free to request a specific one.

7. For every other package you previously removed and every package that makedepends on Xorg components, you’ll need to manually modify the PKGBUILD to update provides, conflicts, and ABI versions, and then recompile them. In theory, many of the packages removed due to requiring xorg-server don’t actually need recompilation and should depend on x-server instead, but good luck getting Arch/AUR maintainers to fix those. You may also upload your modified PKGBUILDs to the AUR with a changed pkgname and pkgdesc. I suggest naming them $original_pkgname-xlibre and appending something like (built against XLibre) to the pkgdesc.

Important notes:

1. If you fail to fully complete a step, do not continue, it will not magically fix itself. Better to exit early than waste your time.

2. Installing and using this as a daily driver is a hassle. If you’re unsure of your skills, don’t do it, and definitely don’t blame anyone else (including the project authors or me) for your mistakes. And don't be like this guy: https://files.catbox.moe/yqoe5e.png

3. Do not report packaging or installation issues to the upstream. They won’t be able to help, even if they wanted to, since we are not affiliated in any way. If you’re unsure who to report your issue to, describe the situation here and we’ll decide together whether it’s a task for me or for upstream.

@vitaliikuzhdin let's continue the discussion on the mailing list please, in order to make sure every participants can be properly informed and the discussion will remain separated not burden by future comments on this package

please feel free to reply on aur-requests for eventual clarifications or objections

@Muflone, thank you for notifying me. The concern was that, as stated by an upstream maintainer, compatibility will only be achieved in the next major release (26.*.*.*). The current state of XLibre requires proprietary Nvidia driver users to add a line to their Xorg config to ignore the ABI check, which will become the default in the next release. Apart from the ABI ignore check not being recognised as a proper solution by some people, users with an Nvidia card who pacman -U the required XLibre components might be met with a broken X session on their next log-in (I have not tested this myself yet).

Since you are effectively the most experienced person on this topic, could I please ask you to glance over the last few comments made by @jcrowell (he changed and deleted some of them, but most of the content is still there) and provide a final verdict? I trust your solution will be sound. Also, if the provisioning of Xorg should be done by every XLibre package, it would apply to every package except for xlibre-server-devel, correct? Sorry for making you spend quite some time on this.

@vitaliikuzhdin

https://lists.archlinux.org/archives/list/aur-requests@lists.archlinux.org/thread/4RYNAZRUIRPU56E2GANQMKVAV5EJB32G/#4RYNAZRUIRPU56E2GANQMKVAV5EJB32G

@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.

Alright. If you can do that then we're good and it will be fixed.

On a side note, I guess xorg isn't a drop in replacement for xorg since the same exact thing happened every time there was a major version update with... xorg.

Sorry about my "claim" but you as a reasonable human being can understand how you and your "lizardfolk ordered actions" can come off that way right? I've never seen someone hold on to their maintainership of a development community/project they're not a part of so vehemently before. You should really start talking to us on Telegram. We might even end up liking you if we get to know you. Crazier things have happened. Plus Telegram won't send you an email every time I edit a message.

Artist is more interested in the tech side of things and wants to work on 'tech things'. He doesn't want to be involved in all this drama. Honestly neither do I but someone has to have the hard discussions so we can move forward.

@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.