Contributed by mbalmer on from the x10-x11-x12 dept.
The new X.Org release will be imported in OpenBSD shortly after OpenBSD 4.0 release, to be ready for OpenBSD 4.1. As people may already know, one of the main change in X.Org 7.x is a new modular build system, using GNU autotools. The X.Org source tree has been split into more than three hundred (http://wiki.x.org/wiki/ModuleComponentList) more or less independdant packages.
The existing X11 source tree, built using the imake build system, was considered as a big monolithic thing in which most developers found themselves uncomfortable. The need for global releases, updating all drivers at once every six month or so doesn't really fit the market of graphics cards that can produce new models more often than that timeframe.
Based on the experiences of other software projects, it was decided to switch to a more modular organization of the project, with more or less independent components ( http://people.freedesktop.org/~daniels/exdctalk/ ). This new organization will allow drivers maintainers (or others) to make independent releases, whenever they are needed.
X.Org has decided that the best tools to manage the build of this new modularized source tree are the GNU auto-tools. They have an existing large user and developer base, and thus feel easier to use by the majority of developers. Being maintained outside of the X.Org project is supposed to lower the maintenance burden on the X developers which are now free to concentrate on their code. The gnome pkg-config tool is used to keep track of version dependencies between new modules.
And how does this all affect the OpenBSD CVS repository? To coordinate the build of the myriad of
packages, I've been working on a "meta" build system, using
Makefile.bsd-wrapper. I've named this system "xenocara" after the fish
known to clean the aquarium's windows
(http://fins.actwin.com/species/index.php?t=9&i=496).
I already have a fully working X11R7.1 installation on i386, amd64 and
macppc machines. Other arches will follow in the next weeks, and I
will also finish merge OpenBSD local changes into the new X.
(Comments are closed)
By Venture37 (217.22.94.66) venture37 (AT) hotmail DOT com on www.geeklan.co.uk
http://tinyurl.com/zjvot
:)
By kalevala (84.3.136.59) on
With other words, X11 maintaner must use xenocara and GNU autotools also - or the OpenBSD eject the GNU autotools?
Thank you for your answer.
Comments
By Matthieu Herrb (213.41.176.184) on
> With other words, X11 maintaner must use xenocara and GNU autotools also - or the OpenBSD eject the GNU autotools?
Xenocara is a set of Makefile.bsd-wrapper style makefiles to drive autotools.
We have a MIT-licensed replacement for pkgconfig to use there.
Comments
By Anonymous Coward (156.34.222.176) on
> > With other words, X11 maintaner must use xenocara and GNU autotools also - or the OpenBSD eject the GNU autotools?
>
> Xenocara is a set of Makefile.bsd-wrapper style makefiles to drive autotools.
> We have a MIT-licensed replacement for pkgconfig to use there.
>
>
>
I'm thinking/wondering two things:
First this is a great opportunity to weed out accumulated fluff and cruft from X -- perhaps moving some of it to ports (or nowhere at all; Does anyone really need or want xeyes?)
I'm assuming there are still some other GNU autotools dependencies? I'm wondering will the necessary tools require installation autotools installation from ports, or will the necessary autotools be imported into the GNU portion of the source tree? It is nice to keep the GNU stuff to a minimum, but I guess 'ya need what ya need'. Not a big deal either way, I'm just curious.
Comments
By Anonymous Coward (66.225.162.55) on
> First this is a great opportunity to weed out accumulated fluff and cruft from X -- perhaps moving some of it to ports (or nowhere at all; Does anyone really need or want xeyes?)
Yes, it plays a critical role is guarding my server room.
By Igor Sobrado (156.35.26.1) on
Yes, period. We need all these tools. We *need* xclock, xclipboard, xmh, xterm and so on. These are very useful tools when running simple window managers as FVWM or mwm. xeyes and xlogo are a component of X11 too.
xclock, xterm and so on are *required* for people not running Gnome or KDE on their machines. xclipboard is a very useful clipboard able to store hundreds of pasted (and editable!) texts concurrently. xmh is an excellent front-end to nmh. xeyes and xlogo are part of X11 too.
I will ask not only to provide these useful components of X11 but also to fix their current bugs. xclipboard and xmh broke when XFree86 4 was released (xclipboard does not show the sliding bars on large texts or the black rectangle on lines longer than the xwindow width, xmh has issues incorporating new mail that require "resizing" the windows to refresh and update them to make it readable). All these features worked nicely on XFree86 3.x. I submitted a PR on these matters some years ago but no one cared about it.
Oh yes, of course... we can convert X.Org on a platform to support new graphic hardware for KDE/Gnome only but, in this case, I will certainly switch to another platform that supports true X11 again! Gnome and KDE are not the way for some people here.
Comments
By Anonymous Coward (72.66.71.216) on
Well. I have to admit that I sometimes use xlogo to display a color. For example, "xlogo -fg \#c8c8c8" to see if that's the right shade of gray I want.
Comments
By Igor Sobrado (156.35.26.1) on
>
> Well. I have to admit that I sometimes use xlogo to display a color. For example, "xlogo -fg \#c8c8c8" to see if that's the right shade of gray I want.
Because xlogo and xeyes are a component of X11 since 1986-87 (don't remember the date these clients were released). These small clients are not really complex ones and do not require a lot of HDD space. On OpenBSD 3.7 (sorry, X11 is not running at my home system, it is a net4801; there is no way to check sizes with release 3.9... and I have the three CDs set at home, cannot look at the OS media right now) xeyes and xlogo are 14 KB and 38 KB respectively, not too large. Source code required for xeyes is 46 KB and source code for xlogo is 66 KB long. From the CVS repository identifiers I see that these programs were last updated in april 1994 and february 2001 respectively. Changes in xlogo are probably related with supporting the render extension to X11 ("xlogo -render").
In fact, xlogo is useful to check that the render extension is enabled too!
IMHO, all these small clients are a part of X11 and should remain in the X11 distributions (XFree86, Xsun, Xsgi, X.Org...). If we choose removing them, why not removing xmh too? or removing xclipboard? Some people could think that ed(1) is useless too!
I certainly do not want these clients to be removed from the X11 distributions.
Cheers,
Igor.
Comments
By Anonymous Coward (72.66.71.216) on
I don't see why that means we should keep them. Tradition for tradition's sake?
> These small clients are not really complex ones and do not require a lot of HDD space.
This is a good point. In fact:
-rwxr-xr-x 1 root wheel 11.0K Mar 10 13:36 /usr/X11R6/bin/xeyes
-rwxr-xr-x 1 root wheel 34.8K Mar 10 13:36 /usr/X11R6/bin/xlogo
I guess there's no real benefit to removing 45.8K for the sake of saving 45.8K. The trade-off: we use an extra 46K of disk space, and, if someone down the road misses these programs they don't have to do a pkg_add.
> In fact, xlogo is useful to check that the render extension is enabled too!
That's kind of silly, when there's:
$ xdpyinfo | grep RENDER
Comments
By Igor Sobrado (81.35.156.200) on
>
> I don't see why that means we should keep them. Tradition for tradition's sake?
We should not remove an OS component without a good reason to do it. Replacing RCS and CVS with OpenCVS makes sense to me, as we will have a clean, audited and maintained revision control system (and it is even more important for CVS, as it allows remote repositories reachable from untrusted hosts). Same about replacing GNU's gzip with a front-end to the zlib library. But removing a small and stable client that most Unix users will expect in the X11 distribution only because it is not widely used does not seem right to me.
> > In fact, xlogo is useful to check that the render extension is enabled too!
>
> That's kind of silly, when there's:
>
> $ xdpyinfo | grep RENDER
Well, we know if the render extension is enabled looking at the output of xdpyinfo, but xlogo shows how an application will look when using this extension too. It shows how a render-enabled client must look and if this extension is working as we expect in our current hardware. (e.g., will the render extension work on an old X/Terminal connected to an X server using XDMCP?)
By Anonymous Coward (199.18.139.160) on
Go ahead and send the diff. Of course it will have to be maintained as a separate package, ugh. Sounds like more work than to just leave it in.
By Anonymous Coward (87.186.102.213) on
Yes. I use them on all my desktop machines.
By Anonymous Coward (81.57.42.108) on
GNU autohell seems less likely of course ... so what will be the alternative ? will the OpenBSD's cvs import pre-configured (in the autoconf sense) sources ?
How will you avoid the heavy burden to merge a different build system, at every resync beetween OpenBSD's cvs and x.org's one ?
Does the new x.org version brings good things (beside drivers) for OpenBSD ? specifically: will it provide a better support for old/minority architectures (could it obsolete xfree3) ?
Also: will we have yet an other - the third, beside X11 (XFree3) and XF4 (XFree4) - X11 sources cvs module in the OpenBSD cvs, or will the others be removed ?
Comments
By Anonymous Coward (74.71.191.127) on
>
Oh please NO (do not remove XFree3) - it gets slower and buggier by the release, and if you've ever compared XFree3 vs. others on "lowend" hardware you'll know exactly what I speak of.
By Anonymous Coward (216.220.225.229) on
Comments
By Justin (216.17.68.210) on
<hopeless hope>
Or less likely it will get moved to the attic for a replacement of Xorg called OpenX or maybe they'd rename it to OpenWindows. Redmond might not like that though.
</hopeless hope>
Comments
By Anonymous Coward (86.194.71.163) on
> Or less likely it will get moved to the attic for a replacement of Xorg called OpenX or maybe they'd rename it to OpenWindows. Redmond might not like that though.
> </hopeless hope>
That's just stupid. What the hell is wrong with Xorg? So they decided to switch from imake to GNU autotools, big fucking deal. What a stupid reason to call for the creation of another implementation of X Windows. Shouldn't you be calling for the creation of some sort of BSD-licensed autoconf/automake/pkgconfig replacement if you really are that irrationally opposed to the idea of a piece of the base system requiring GPL'd software to build?
In fact, just because modular Xorg requires GNU autotools to compile doesn't mean GNU autotools needs to become part of the base system. Being only required for _building_, they can remain in the ports tree.
Comments
By Anonymous Coward (70.27.15.123) on
> > Or less likely it will get moved to the attic for a replacement of Xorg called OpenX or maybe they'd rename it to OpenWindows. Redmond might not like that though.
> > </hopeless hope>
>
> That's just stupid. What the hell is wrong with Xorg?
Its a loonix-centric, poorly designed security hole? Its stupid desire to have direct access to my hardware, and thus the ability to totally lock up my machine?
Comments
By Anonymous Coward (71.96.189.16) on
So... don't use it? *gasp*
Comments
By Anonymous Coward (70.27.15.123) on
>
> So... don't use it? *gasp*
I have no choice. Are you really this stupid? He asked what's wrong with Xorg. I told him. Why are you posting complete bullshit like this?
Comments
By Anonymous Coward (128.171.90.200) on
>
> I have no choice.
sure you do, just don't install it
Comments
By Anonymous Coward (84.217.45.124) on
>
> sure you do, just don't install it
Yes, good suggestion there Timmy. pkg_delete the bastard or skip it during a reinstall and then tell your boss why you couldn't finish the work you've been assigned because someone on the Internet told you, you have a choice. Have you ever thought about a career as a politician? You'd make a great one.
-"Hi there! I have no idea who you are or what you do and frankly I don't give a damn, but you have a choice."
"Do I?"
-"Yes, but either way, you're fucked."
By Anonymous Coward (71.126.111.37) on
Most software, if written properly, shouldn't require more than a Makefile. If that is not enough, chances are the software is written in a completely unportable manner anyway
Comments
By SH (82.182.103.172) on
The release manager of Subversion made that pretty clear in the link for a release candidate after a newer autoconf messed things up ;-)
http://lolut.utbm.info/subversion/1.4.0/rc3/i_hate_autoconf/
Comments
By Anonymous Coward (24.119.18.143) on
>
> The release manager of Subversion made that pretty clear in the link for a release candidate after a newer autoconf messed things up ;-)
>
> http://lolut.utbm.info/subversion/1.4.0/rc3/i_hate_autoconf/
>
link bad - is there an alternative?
By Anonymous Coward (72.66.71.216) on
By Noryungi (83.202.34.116) n o r y u n g i @ y a h o o . c o m on
Comments
By Anonymous Coward (63.237.125.164) on
Comments
By Anonymous Coward (64.231.139.29) on
>
Beauty is defined by elitest and patriarchal propaganda.
Comments
By Anonymous Coward (70.169.167.212) on
> >
>
> Beauty is defined by elitest and patriarchal propaganda.
>
And the Gloria Steinem minions raise their ugly heads again! The place for that is the Nat'l Org. for Women forum, not Undeadly.org. Let's keep it technical here, shall we?
By Anonymous Coward (203.58.120.11) on
Comments
By Anonymous Coward (72.66.71.216) on
Comments
By Anonymous Coward (69.246.68.23) on
This sounds exactly like how maintance of wifi drivers in linux have lagged because of the windows driver wrappers.
Isn't there a less-functional open source ati solution? ati-gatos ? I am not sure, I just installed it for somebody on linux some 5 years ago. I think it supported alot the silly stupid features of an ati all-in-wonder. Maybe look into that. And this was before X.org.
Comments
By Anonymous Coward (72.66.71.216) on
Yeah, but last I checked it was a pain to build on OpenBSD. There is also a patch against Xorg's driver, but it is GPL.
Still, a GPL'd driver is better than none, so one day when I have lots of "recompile X with patches written by linux folk which may or may not work" time, I may try to get it working.
Don't get me wrong, the ati driver in tree right now works very very well for me, I am pleased with it. I just want s-video output, which is not presently supported.
Last I heard somebody was tryng to get the guy that wrote the GPL patch to agree to an X licence. That was a year ago.
By Simon 'simmel' Lundström (213.112.203.160) on