Linked by Thom Holwerda on Sat 20th May 2006 21:13 UTC, submitted by Joel Dahl
X11, Window Managers 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."
Order by: Score:
thank you
by theGrump on Sat 20th May 2006 22:03 UTC
theGrump
Member since:
2005-11-11

for delivering on the promise of more frequent releases upon forking to x.org. people generally seem pleased.

Reply Score: 5

i hope...
by Anonymo on Sat 20th May 2006 23:11 UTC
Anonymo
Member since:
2005-07-06

Pat uses this for Slackware 11

Reply Score: 3

RE: i hope...
by Best on Sun 21st May 2006 02:14 UTC in reply to "i hope..."
Best Member since:
2005-07-09

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.

Reply Score: 2

RE[2]: i hope...
by raskolnikov on Sun 21st May 2006 12:57 UTC in reply to "RE: i hope..."
raskolnikov Member since:
2006-03-19

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) ?

Reply Score: 1

RE[3]: i hope...
by NxStY on Sun 21st May 2006 14:48 UTC in reply to "RE[2]: i hope..."
NxStY Member since:
2005-11-12

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.

Reply Score: 2

More frequent releases are certainly...
by hhcv on Sat 20th May 2006 23:41 UTC
hhcv
Member since:
2005-11-12

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

Reply Score: 3

abraxas Member since:
2005-07-07

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.

Reply Score: 0

maxx_730 Member since:
2005-12-14

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

Reply Score: 2

Changes...
by kaiwai on Sat 20th May 2006 23:50 UTC
kaiwai
Member since:
2005-07-06

Whats changes are instore for 7.1? I know its all modular now, but apart from that, is XCB going to be included now?

Reply Score: 1

RE: Changes...
by indech on Sun 21st May 2006 00:28 UTC in reply to "Changes..."
indech Member since:
2005-12-06

The proposed changes according to X.org's wiki:
http://wiki.x.org/wiki/ChangesForX11R71

Reply Score: 2

RE[2]: Changes...
by smitty on Sun 21st May 2006 03:13 UTC in reply to "RE: Changes..."
smitty Member since:
2005-10-13

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.

Reply Score: 1

RE[3]: Changes...
by DigitalAxis on Sun 21st May 2006 04:12 UTC in reply to "RE[2]: Changes..."
DigitalAxis Member since:
2005-08-28

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

Reply Score: 2

RE: Changes...
by NxStY on Sun 21st May 2006 14:58 UTC in reply to "Changes..."
NxStY Member since:
2005-11-12

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.

Reply Score: 1

Compiling Xorg
by elsewhere on Sun 21st May 2006 06:05 UTC
elsewhere
Member since:
2005-07-13

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?

Reply Score: 1

RE: Compiling Xorg
by rx182 on Sun 21st May 2006 07:01 UTC in reply to "Compiling Xorg"
rx182 Member since:
2005-07-08

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... ;)

Reply Score: 2

RE: Compiling Xorg
by NxStY on Sun 21st May 2006 15:02 UTC in reply to "Compiling Xorg"
NxStY Member since:
2005-11-12

The only distro where you can do that easily is gentoo. In suse it will be a PITA to get everything working.

Reply Score: 1

RE[2]: Compiling Xorg
by ganloo on Mon 22nd May 2006 01:16 UTC in reply to "RE: Compiling Xorg"
ganloo Member since:
2005-07-06

Another one: ArchLinux

Reply Score: 1

RE: Compiling Xorg
by butters on Mon 22nd May 2006 04:05 UTC in reply to "Compiling Xorg"
butters Member since:
2005-07-08

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 ;)

Reply Score: 1

RE[2]: Compiling Xorg
by elsewhere on Mon 22nd May 2006 17:57 UTC in reply to "RE: Compiling Xorg"
elsewhere Member since:
2005-07-13

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? ;)

Reply Score: 2