Backport Xorg from newer Fedora release to current dom0 Fedora version

[qubesuser]

Qubes is backporting newer kernels like 4.9 to FC23 dom0 in r3.2, presumably for hardware support, but hardware support for GPUs and input devices also depends on the Mesa and Xorg version.

So I'd propose to backport those as well. I have done it for my system and the FC26 versions seem to work fine on FC23 once the SRPMs are rebuilt for FC23 (although YMMV of course).

Specifically, the following seems to work (done in an FC23 VM or chroot):

1. Download the FC26 signing key and import it with rpm --import

2. Download these SRPMs (or newer versions) and verify their signatures with rpm -K: compiler-rt-4.0.0-1.fc26.src.rpm llvm-4.0.0-2.fc26.src.rpm clang-4.0.0-3.fc26.src.rpm libdrm-2.4.81-1.fc26.src.rpm wayland-protocols-1.7-2.fc26.src.rpm wayland-1.13.0-1.fc26.src.rpm libglvnd-0.2.999-14.20170308git8e6e102.fc26.src.rpm mesa-17.1.2-2.fc26.src.rpm libwacom-0.25-1.fc26.src.rpm libinput-1.7.3-1.fc26.src.rpm xorg-x11-proto-devel-7.7-22.fc26.src.rpm libXfont2-2.0.1-3.fc26.src.rpm xorg-x11-server-1.19.3-4.fc26.src.rpm xorg-x11-drv-amdgpu-1.3.0-1.fc26.src.rpm xorg-x11-drv-ati-7.9.0-1.fc26.src.rpm xorg-x11-drv-dummy-0.3.7-2.fc26.src.rpm xorg-x11-drv-evdev-2.10.5-2.fc26.src.rpm xorg-x11-drv-fbdev-0.4.3-26.fc26.src.rpm xorg-x11-drv-fbturbo-0.5.1-0.9.20150221.fc26.src.rpm xorg-x11-drv-intel-2.99.917-28.20160929.fc26.src.rpm xorg-x11-drv-ivtv-1.2.0-0.23.fc26.src.rpm xorg-x11-drv-libinput-0.25.1-2.fc26.src.rpm xorg-x11-drv-nouveau-1.0.15-1.fc26.src.rpm xorg-x11-drv-openchrome-0.5.0-3.fc26.src.rpm xorg-x11-drv-qxl-0.1.5-3.fc26.src.rpm xorg-x11-drv-sisusb-0.9.6-25.fc26.src.rpm xorg-x11-drv-synaptics-1.9.0-4.fc26.src.rpm xorg-x11-drv-v4l-0.2.0-48.fc26.src.rpm xorg-x11-drv-vesa-2.3.2-26.fc26.src.rpm xorg-x11-drv-vmware-13.2.1-2.fc26.src.rpm xorg-x11-drv-voodoo-1.2.5-26.fc26.src.rpm xorg-x11-drv-wacom-0.34.2-1.fc26.src.rpm xorg-x11-drivers-7.7-19.fc26.src.rpm

3. Install the libglvnd srpm and remove the line "%global _without_mesa_glvnd_default 1" from libglvnd.spec This is necessary because FC26 Mesa expects libglvnd to provide libGL, but the libglvnd spec only does that on newer Fedora versions since it expects the older Mesa versions that provide libGL themselves to be present there instead of the new one we are compiling, so we need to make libglvnd provide libGL even on FC23 to work with the newer Mesa we are backporting.

4. In the correct order (which should be the one I listed them in, but might be slightly off), download SRPM dependencies, build the SRPM and install the resulting RPM. Note that if the VM has many VCPUs and too little memory LLVM may fail to build due to OOM since it runs an instance of the C++ compiler per VCPU; if that happens, increase memory if possible to 2-3 GB per VCPU or reduce the number of VCPUs.

5. Use createrepo to create a repository, copy it to dom0, add to yum real repos and upgrade with allow erasing enabled (it removes the vmmouse x11 driver package)

6. Preferably upgrade dom0 kernel too

It should be easy to package this by updating the qubes-linux-dom0-updates repository according to what described above.

[rtiangha]

If there's one thing I've learned from running a Gentoo-based system for years (before I finally got fed up with having to compile everything all the time), it's that the kernel and X stack are the two things you can update independently from everything else (assuming you get all of the X bits in one go).

From a technical standpoint, there's no reason why this wouldn't work, however, if one were willing to go this far, you might as well just update the entire dom0 distribution instead. There's really no technical reason to be frozen on FC23, and from other reports, dom0 using the Qubes R3.2 stack works fine not only on FC23, but possibly also FC24 and FC25. I think someone even got it running on Debian 8.

That said, I do agree that an updated X stack could help some of the graphical quirks that pop up from time to time, especially as the kernel versions start increasing over time. Although updating the R3.2 dom0 environment in general would bring some other side benefits as well, such as ensuring that the kernel compile environment matches R4.0 which might make maintenance easier?

@qubesuser, can this stuff be scripted? My desktop machine has a buggered BIOS that doesn't expose IOMMU under Xen very well, so I was thinking that eventually, since R4.0 will no longer support my machine (unless that's changed since full PVHv2 support is being deferred?) I'd have to take matters into my own hands and spin a R3.2 ISO using a different dom0 distribution some day in the future (I was thinking a newer Fedora or maybe even CentOS if a new major version were to come along). But as a stop gap, your method might be easier, but I'm not as familiar with the Red Hat packaging world as I am with Debian or even Gentoo to know how to do it at the moment.

[marmarek]

Generally updating large set of packages, to much newer version is something we'd like to avoid in stable release. Specifically stable should mean that updates do not break hardware compatibility, or other things. Even if that means also not supporting newest hardware. People use the system to get work done, not to debug why something does not work after some update. Proper place for such updates is new major release - which one can install when planned, prepare for some troubles in advance, etc. We do upgrade kernel, because it's trivial to switch back to the previous one (just a reboot, or one qubes-prefs call). This isn't true for X server. And also such operation requires a lot of testing, and we'd like to spend this time on finishing Qubes 4.0...

But having this scripted would be awesome anyway. For example we could include X server from fc26 in Qubes 4.0 (dom0 on fc25).

[qubesuser]

Yeah, should probably go in a separate "backports" repository that's not included by default.

As for scripting, there's a repository at https://github.com/QubesOS/qubes-linux-dom0-updates that appears to have been used to backport Xorg into an older Fedora dom0, so just updating it with new SRPMs might work.

[marmarek]

As for scripting, there's a repository at https://github.com/QubesOS/qubes-linux-dom0-updates that appears to have been used to backport Xorg into an older Fedora dom0, so just updating it with new SRPMs might work.

Yes, and since then we've learned to not commit SRPMs into git repository...

[qubesuser]

Ok, well, I did my backport manually, so don't quite have a full script ready, and I'm not very familiar with Qubes builder either.

Anyway, the following downloads an FC26 RPM in an older FC chroot: yumdownloader --releasever 26 --disablerepo=* --enablerepo=fedora-source --source "$name"

I'm not sure if that checks signatures, so rpm -K might need to be used afterwards (and rpm --import first to import the FC26 key).

I guess this would need to be done as part of the get-sources phase of Qubes builder.

Then, the existence of https://github.com/QubesOS/qubes-linux-dom0-updates makes me think that Qubes builder already has or had all the necessary logic for building SRPMs, and thus writing a Makefile.builder that uses wildcards or $(shell) to add the downloaded SRPMs would presumably do the trick.

Not sure how to best do the libglvnd patch: perhaps just programmatically unpacking the RPM, sed -i on the spec file and then repacking the SRPM.

[marmarek]

I'm not sure if that checks signatures, so rpm -K might need to be used afterwards (and rpm --import first to import the FC26 key).

BTW do you know how to use alternative keyring for rpm signature verification? Importing key to the system keyring just to verify one foreign package seems wrong.

[noseshimself]

Can this be closed or replaced by a request to separate Fedora release sources and the Xorg tree and separately build Qubes own Xorg packages?

[andrewdavidwong]

Title updated per https://forum.qubes-os.org/t/qubes-ancient-issue-2858-backport-fc26-xorg-to-fc23-dom0/27025.