The schedule for Xorg 7.2 has been posted to the Xorg announce mailing list; Xorg 7.2 is planned for 17th November 2006. The mail also says xorg 7.1 is planned to be released on 22nd May. “7.1 is basically done at this point. The release won’t actually go out until probably Monday, due to press release timing and (hopefully) doc updates, but excluding the server and the badged tarballs, everything else is pretty much in place. So, woo.”
for delivering on the promise of more frequent releases upon forking to x.org. people generally seem pleased.
Pat uses this for Slackware 11
I’m not sure he’ll switch to an entirely new x server which will require new build scripts and more testing this late in the game. After all, its taken forever for a 2.6 kernel to ship as the default in slackware. Pat is notoriously conservative on matters like this one.
Still, as long as he ships 6.9 with 11 (which is in current now at least) third parties will be able to build X7 without problems since there won’t be library dependency problems. This is the main reason that dropline is still using 6.8.2. We’ve had 7 packs available for a while, but using them would mean breaking compatability with Slackware, so we’re not shipping them yet.
Dropline at least is going to ship 7.1 with slamd64 by default as soon as its built and gone through a bit of testing, since Fred is already shipping 6.9.
From X.Org wiki : The next major release after the 6.9/7.0 release is X11R7.1. For a list of proposed changes, please read ChangesForX11R71. In addition, at least one more minor maintenance release of the 6.8.x and/or 6.9.x series is also planned.
Maybe they are planning a “6.9.1” equivalent to 7.1, but with a monolithic tree… This one may find his way to Slackware , I hope.
By the way, does X rely on PAM (this question should be read : can I grab X.Org 7.1 packages from Dropline when they are out, and install them on vanilla Slackware 11) ?
Maybe they are planning a “6.9.1” equivalent to 7.1, but with a monolithic tree… This one may find his way to Slackware , I hope.
A 6.9.1 release of the monolithic tree would be equal to a 7.0.1 release of the modular. 7.1 is a feature release.
X-org-ilerating!
But seriously, it seems the case for throwing away X and starting again is getting weaker every release. Let’s just hope that haven’t forgotten any more {s
But seriously, it seems the case for throwing away X and starting again is getting weaker every release. Let’s just hope that haven’t forgotten any more {s
Why do you say that? First of all they didn’t throw away X and start again. They started with the XFree codebase before the license changed. Xorg has done a lot in the short time it has been around. Modular X being the most improtant change. Besides that the license itself is reason enough for Xorgs existance.
He’s talking about the comments a lot of people have about X.org, eg that its horribly bloated, that it shouldn’t directly acces the hardware, etc. For these reasons some people think we should start over with unix graphics systems, and most are for some kind of directfb based implementation of that ‘new graphics system’.
Whats changes are instore for 7.1? I know its all modular now, but apart from that, is XCB going to be included now?
The proposed changes according to X.org’s wiki:
http://wiki.x.org/wiki/ChangesForX11R71
Hmm, that list of proposed changes looks exactly like the list of proposed changes for 7.2 – meaning none of them got done in time.
“Below is a list of the features we expected to add to the X11R7.1 release. Unfortunately, many of them were not completed in time, so are now on the list for ChangesForX11R72.”
XCB is probably ready but it hasn’t been out in a stable release yet so it’s unlikely to be included. But it doesn’t matter now when X is modular. You can just use XCB as a drop in replacement for xlib, it doesn’t have to be a part of the release.
This is potentially a stupid question, but I’m not a dev, so I’ll take any flak for it.
Are there any gotchas or distro specific concerns to be aware of if I wanted to try downloading the tarballs for Xorg 7.x and compiling them myself?
I’ve gone through the info on the Wiki, seems straight forward and do-able, but aside from having to possibly edit existing scripts, I’m not sure if I would break anything on my current distro (Suse 10.1). I say that because the wiki said that X.org will default to installing to /usr/local, so I’m thinking (maybe naively) that I can install it without overwriting my existing Xorg and just edit my scripts as appropriate.
Wishful thinking?
Just…dont.
It will break your SUSE install. Mainly because SUSE manages packages itself with YAST.
Well…unless you want to make a SUSE package for it…and deal with all the dependency problems…
The only distro where you can do that easily is gentoo. In suse it will be a PITA to get everything working.
Another one: ArchLinux
This isn’t quite as impossible as the above posters suggest. The key is to make SUSE/YAST happy by not uninstalling the current X and installing the new X into a unique installation path.
For example, X normally installs in /usr or /usr/X11R6. So, you might want to install your new X in /usr/X11R7 or /opt/Xorg. Then find your X binary link using ‘which X’ and change that to point to /usr/X11R7/bin/X or /opt/Xorg/bin/X. You probably want to backup your xorg.conf file and create a new one using ‘X -configure’. The X version should print to the standard output, so you can make sure it’s running your new X.
If it doesn’t work, then ‘rm -rf /opt/Xorg’, move your xorg.conf back into place, and reset your X symlink to point to the old X binary. This way you won’t screw up your system
This isn’t quite as impossible as the above posters suggest. The key is to make SUSE/YAST happy by not uninstalling the current X and installing the new X into a unique installation path.
This is what I was leaning towards, from the docs Xorg will install by default to /usr/local so I should be able to install it without overwriting my existing xorg (and leaving myself an escape route if it doesn’t work). Back up my /etc/X11 to be safe and modify the appropriate scripts, it should be worth a shot. I just wasn’t sure if there was anything Suse specific I needed to do during the compile/install process. I figure I can pull in the build dependencies from the “official” 6.9 source packages in Suse which should eliminate potential dependency problems.
Hell, 98% of my linux expertise has been gained from repairing my own recklessly self-inflicted damage. Where’s the fun otherwise?