xorg 1.20 is 3 month old and many distros have already switched to it.
Sidenote: 1.20.1 is out with bug fixes: https://lists.freedesktop.org/archives/xorg/2018-August/059380.html
I tried to use the update script but it downgraded many tarballs.
People don't always respect that the file is auto-generated, apparently :-/ Even before those parts get fixed, one can still use it and e.g. use git checkout -p
to cancel the "unintended" changes...
The update script pulls X11R7.7, which is quite old at this point (from here: https://www.x.org/releases/X11R7.7/src/everything/)
We need to instead pull the latest versions of packages from https://www.x.org/releases/individual/
Anybody got a script handy that does this? :D
Edit: Or maybe the perl script can just be adjusted to support that...
You don't need to do that line. I always just edited the versions manually, and the script does the rest.
I looked at this for a while but I think I am in over my head.
I made a few changes but the derivation generation reports a lot of NOT FOUND
that I cannot figure out how to resolve:
https://gist.github.com/NeQuissimus/9e11fc78f5c986d11e21a5c1cca80a37
I wonder if there is much need for the update script anymore as long as the derivations would be written in a way that @r-ryantm can find updates for them?
nixpkgs-update/r-ryantm currently skips xorg because the expressions have multiple fetchers in the same file. If each one was written as a separate file it would start trying to update them.
I'm not sure that it is needed, but it doesn't have a way of grouping updates.
The NOT FOUND
errors are normal for the script IIRC, and the resulting diff seems OK at a superficial look.
With the update, it would be great to configure X to be able to run as non-root (without a display manager, started by a normal user with startx
). Not exactly sure what needs to be changed for that to work.
Yes, but non-root X doesn't seem realistic for 18.09, as I'd expect it to be relatively intrusive wrt. various display managers.
Not necessarily. I don't mean "always run as non-root" but "be able to run as non-root". E.g. on Arch, you can either use a display manager which runs X as root, or start it as a normal user with startx
, both works.
@xeji
There are instructions along that line in https://nixos.wiki/wiki/Using_X_without_a_Display_Manager.
Those are not very nixy though, so I wrote a small module (https://gitlab.com/xaverdh/my-nixos-config/blob/master/xserver-rootless.nix) which does just enough, to make things work with my setup.
Its probably horribly broken in more than one way, but it "works for me".
so I'm running xorg 1.20.1 on 4.18.11 now. Things appear to work. I bypassed the update script for now as it probably needs to be rewritten/modified. My reasoning is that their website says R7.7 was the last official release and from then on things should be updated on an as-is basis. So I decided to just update the proto stuff and bump xorgserver to 1.20.1.
Will start putting a patch together.
My main motivation for this was the new drm lease support, used by SteamVR for high performance VR in linux. This requires 4.18 so I figure I would bump that as well. I'm testing right now to make sure that works. It looks like a need to update and test a few more things before I put a patch together.
4.18 doesn't seem suitable as kernel default. The policy so far is to use the latest longterm kernel (once it's in some fairly stable state), and that will soon be 4.19. I'd expect we can switch the default to 4.19 on unstable in several weeks.
Vladim铆r 膶un谩t notifications@github.com writes:
4.18 doesn't seem suitable as kernel default. The policy so far is to use the latest longterm kernel (once it's in some fairly stable state), and that will soon be 4.19. I'd expect we can switch the default to 4.19 on unstable in several weeks.
Good to know!
I'm working on this branch for anyone interesting in testing this out:
git fetch https://github.com/jb55/nixpkgs xorg-1.20
git checkout -b xorg-1.20 FETCH_HEAD
@jb55 pkgs/servers/x11/xorg/default.nix
is still (almost whole) a generated file. Your changes to it appear "manual", so that will clash with future updates. Well we might change the style we do this, but so far the generation seemed to work fine to me. What are your plans about that?
@xaverdh thank you, I'll give that a try! We definitely should work on a NixOS module that allows using xorg without a display manager.
Vladim铆r 膶un谩t notifications@github.com writes:
@jb55
pkgs/servers/x11/xorg/default.nix
is still (almost whole) a generated file. Your changes to it appear "manual", so that will clash with future updates. Well we might change the style we do this, but so far the generation seemed to work fine to me. What are your plans about that?
It's a generated file, but the releases it was generating from are no
longer updated. The site mentions that there may be a 7.8 release in the
future, but noone has stepped up to be a release manager:
https://www.x.org/wiki/Releases/7.8/
I think it makes sense to update them individually for now until a new
release is available? The script would probably need to be updated at
that time as well.
Well, yes, you need to update the version of each package manually (so far), but the rest still works. EDIT: we probably don't need to rehash the beginning of this thread.
@vcunat ok I think I see what you mean. In theory if I just scrape all the latest tarballs it should work?
Just their names, that's enough. It was done recently but not finished, see https://github.com/NixOS/nixpkgs/issues/44492#issuecomment-414157422 (above)
Thinking longterm, I should explicitly mention another viable alternative: migrate to the usual one file per package (without override.nix) and use some "universal updater" instead, e.g. r-ryantm.
I'm working on this branch for anyone interesting in testing this out: git fetch https://github.com/jb55/nixpkgs xorg-1.20 git checkout -b xorg-1.20 FETCH_HEAD
Can you submit this a PR? :+1: Or is it unsuitable for some reason?
The discussion about auto-generation is a bit orthogonal to your changes here, I think:
the big pain here was the unification of the proto's into xorgproto which is a big manual change and not something any update system (new or existing) would handle anyway.
Really would be nice to be able to use a modern X server! :grin:
Really would be nice to be able to use a modern X server! :grin:
Wayland compositor, you mean?
Will Dietz notifications@github.com writes:
The discussion about auto-generation is a bit orthogonal to your
changes here, I think: the big pain here was the unification of the
proto's into xorgproto which is a big manual change and not something
any update system (new or existing) would handle anyway.
agreed, but @vcunat claims that it should still be possible, I just
haven't had the time to look into updating the script.
Can you submit this a PR? :+1: Or is it unsuitable for some reason?
mostly blocked on the above point.
There a security vulnerability in Xorg prior to 1.20.3
https://www.opennet.ru/opennews/art.shtml?num=49500
Most helpful comment
Wayland compositor, you mean?