Greetings all. I've had quite a few emails concerning some X11R7 .SlackBuilds that a made a little while back so I thought I would share them since some people are interested.
http://jaguarlinux.com/pub/slackware/
The main reason for upgrading would be compositing I suppose. That's the initial reason why I started writing them anyway. Gnome's Metacity-2.16.0 compositing feature seems to have gotten more stable as well and the Start Page is now advertising that option. Compositing is the way of the future I guess.
Regardless of composting v7 is the latest release and we'll all end up running it sooner or later, so why not tackle it now?
A few notes first... I'm getting pretty burned out on the whole thing. I knew it would be quite an undertaking switching to the modular build system. The scripts are about 90% done. Maybe more. Just depends on how anal you are. They are completed to the point where everything builds and X runs just fine, however they REALLY need some tweaking. I would REALLY, REALLY apreciate people helping me out on this and posting diffs on this thread if you find ANY problem with ANYTHING. It would be nice to see these scripts evolve so everything is 'proper'. If you notice something wrong, please post a diff so other people don't have to solve the same problems...
ALL diffs by myself will be posted seperately, but in the same directory, as the X11R7 build scripts. They will be dated/numbered AND cumulative. Just grab the latest patch and apply from with the build script directory.
1. Location, location, location...
Is everything where it's supposed to be?
I don't know.
Probably not. The app-defaults directory is a good example.
I've used $XORG_PREFIX and $XORG_CONFIG so you can easily
change those and I've tried to take into account people using
other prefixes, ( by creating compat symlinks where
appropriate if $XORG_PREFIX != /usr) but I highly suggest you
don't and use /usr for the prefix. Your on your own if you
start changing things. Back to the app-defaults directory. I
use $XORG_PREFIX/share/X11/app-defaults... There is an
inherent problem with building on a system that was already
set up for /usr/X11R6... I don't have this problem on my DIY
build. The letters "X11R6" have never even touched my system,
so I only have /usr/share/X11/app-defaults.
2. Mesa, mesa, mesa... What a crappy package. The way my scripts
work is that they will always fetch the latest source code of
whatever it's trying to build for, with the exception of
freetype and fontconfig. Mesa is going to have to join that
list. They have apparently taken a que from UDEV and decided
to start breaking things. There is a yes/no option in the
mesa script that you can change if you want to go the latest
version route. If you do that, you'll have to figure out any
xorg-server problems on your own. I've made headway but
gave up after awhile. The default is to use 6.5...
3. Preliminary work on compositing has been done but still needs
further work. Read the comments in the xorg-apps build script
for more info. Keep an eye out for diffs on my file server
for continued implementation but I can't say for sure when
I'll get around to it.
4. The 'evdev' module from xorg-drivers requires 2.6 kernel
headers. If 2.6 headers aren't found at script run-time,
evdev isn't even attempted. I'm running without it right now,
but that
is a rather important X module to have...
5. Freetype. Do yourself a favor and ditch the slackware version
and use the included build script. I still haven't figured
out why Pat doesn't enable hinting. Everyone in the free
world does and they haven't gotten sued by Apple yet...
6. Fontconfig. Might as well build the newer version of this as
well, if for no other reason, than to have a newer version.
7. Fonts... This appears to be a problem in my scripts tho I
can't say for sure. The fonts on X11R7 are well... Crap. The
only thing that saves you on Slackware is the stock
dejavu-ttf package that comes with 11.0... dejavu is
supposed to come with xorg-fonts but they are not showing
up. Mainly, the only problem I'm having right now is with
fonts. I use Bitstream Vera on a global basis (now called
dejavu) so this is a problem. Leave the dejavu-ttf font
package installed and imediately switch system wide to them
or you'll probably get as irked as I am about it. This is
what I'd like help with the most. Figuring out if there is
indeed a font problem and how to remedy it. (hint, hint
)
8. About always grabing the latest source code. I was adverse to
this in the beginning because that's never a good idea but
the maintainance burden of specifying hundreds of static
versions of modules just made me want to give up the whole
project before I even started so I knew I had to come up
with something automated. Just think about the next time you
wanted to build it again
. You would have to spend hours
changing version numbers. IMO, they way I've set the scripts
up, is the ONLY feasable way to build this beast. Not only
grabing the latest packages, with the exception of freetype,
fontconfig and mesa, but filtering the hundreds of packages
thru a for loop. It works really nice and I forsee no
problems with this method except for rouges like mesa. I'm
banking on the idea that since they went modular, everyone
is going to be closely working with one another and making
sure all modules play nice with one another. If that's not
the case then going modular was a completely asinine idea...
9. I don't incorporate CFLAGS into my scripts. I believe that's
best handled from your shell environment. All the $ARCH
variables are set to i486 so if you really want them to be
i486 then make yourself a ~/.bash{rc,_profile} and
/etc/bashrc to export your CFLAGS...
10. The xorg.conf* files in ./extra are custom made for my boxes
and the "sample" config still leaves alot to be desired.
You'll have to come up with your own xorg.conf files, I'm
sure... Sorry. This is another area where I could use some
help; is coming up with a defacto xorg.conf-vesa or
something...
11. I've left you little notes that are outputted to the console
after each script finishes regarding what script to run
next. Follow them carefully!!! I wrote the scripts and have
run them MANY times and I STILL screw up by not installing a
package afterwards if that's what it says to do. I think I
can atribute this to sitting at the init3 console and
getting spaced out by the black screen and white text. I
don't know...
Suffice it to say, it's easy to
screw up on the build order. If you do mess up, then you
need to be aware of one thing. You may not be able to just
re-run the last script and pick up where you left off. This
is due to having a couple "first pass" scripts where you
don't actually install a package. We are satisfying deps by
having the first pass automatically build a temp package and
install it, then a script or two down the road, it will
uninstall the child package after the "final" parent is made
and ready to be installed "officially". If that sounds iffy,
it isn't and don't sweat it. Go read thru the scripts and
see what I've done before you shake your head. If I didn't
do this, then we would have quite a few more packages than
we do now. Example: luit should be built after xorg-fonts
but xorg-fonts requires a package from the xorg-apps
package. Luit IS a part of the xorg-apps package
but xorg-apps needs to be run after xorg-fonts
We wind up with a chicken and the egg problem. Since luit
is a part of xorg-apps I refuse to build it solo...
The script determines what pass we are on by the existence
of any temp packages in /var/log/packages... If you forget
to install a package and a second-pass package is next, the
second-pass package will removepkg on the temps and now your
left with having to backtrack to the original first-pass to
get those temp modules back on the system otherwise you'll
be building a first-pass instead of a second-pass.
As long as you pay attention to the notes at the end of each
build script run, you'll be golden. The best thing to do is,
use VC1 for ONLY executing the scripts. Use the other VC's
for side work, such as viewing the logs, so you never loose
sight of what it says to run next. Oh yea........
I redirect output to log files. The only thing you'll see
after runing a script is the fetching of source and then a
"Please wait while xyz builds..." Right above that, it
tells you the loaction of the log files if you want to
tail or cat them on another VC.... I
DID NOT tell
the scripts to exit upon errors so it is up to you to
religiously check your logs after each script before
moving on to the next one. Just checking *.err will suffice.
Well, I think that's about all the thoughts I have. If that last excerpt confused you, then join the club because I still get confused over it at times.... I've tested these alot tho and everything works as it should AND for a reason. Give it a test run and you'll find out that it's actually very straight forward. All that confusing stuff is hidden and everything is auto-resolved. Just stick to the build order and it's painless. I'll post the build order here just so you can actually see it:
Code:
freetype2
fontconfig
xorg-proto
xorg-utils
xorg-lib
libdrm
mesa
xorg-data (first pass)
xorg-apps (first pass)
xorg-data (final)
xorg-fonts
xorg-apps (final) (compiz needs gconf2)
xorg-server
xorg-drivers
xorg-docs (haven't made the script yet)
fontconfig (final) (this used to be the case anyway)
I'm sure I'm missing some "gotcha's". If I think about them, I'll ammend this post. As a general rule, you'll want to read ANY script before you run it, only the ignorant wouldn't do so. By reading them, you should see any potential things you might need to change. And, as stated, post your feedback/expierences/diffs.. It will be much apprecieated.
One last note about the file server directory from the top link.. All packages/scripts there are intended for use on a DIY/LFS build using a modified pkgtools. The main modification being the use of "desc" instead of "slack-desc"... Otherwise, they are ALL .SlackBuilds. I'm going to revert the X11R7 scripts back to using $ARCH=powerpc and slack-desc-->desc just so I can keep them all uniform. If you download the X11R7 scripts, do this from within the extracted folder:
Code:
sed -i 's@ARCH=powerpc@ARCH=i486@g' *.build
sed -i 's@install/desc@install/slack-desc@g' *.build
Now you have .SlackBuilds...
I really don't think I need to post a disclaimer, but here goes anyway... ANYTHING you download from the above link should be considered BETA and potentially harmfull to your system. It's possible that your hard drive might catch fire after running mesa.build, though I would tend to blame that on the mesa devs and not my script... To the best of my knowledge, my scripts will not erase your /etc directory nor should they cause any damage of ANY kind, but that is not explicitly guaranteed. :-)