Hey Bill, if you have the hard drive space, I'd go ahead and make a new partition and set up lilo for another boot entry. While I'm sure you can do it in a virtual environment, I'm not sure how functional it'll be after your done.

I suppose it doesn't matter whether you skip the X11R6 install during the instalation or just removepkg on it after you hit the prompt. Either way, you should have a 'clean' system and do it from the init3 prompt. I tried building xorg-7.x while I was in a running xorg-6.9 and 2 packages error out because it's trying to build against some existing X11R6 bits. You can keep an eye out for the errors and when that happens, do a removepkg on the offending stock X package, then build that package again.

Actually, if anyone is uncomfortable with working from the prompt, you could startx and then removepkg on everything. X will still run after you have removed the packages. For some reason I don't feel entirely comfortable with that, but it'll still work.

I plan on really cleaning up my scripts sometime this week. I'll ditch all that latest version crap that's still in the scripts (but not getting used), there is a bunch of clutter in /extras that's left over from development builds. I'll get em' in tip top shape and call them final until the next X11R7 version comes out. It's been months since I started this project and it's high time I finished it I suppose.

A note on the prefix too, I'll be sticking with the default of /usr... The FHS doesn't allow for /usr/X11R7, and putting that aside, I still don't feel comfortable with doing it. Why do all the symlinking madness, modify existing files, and break from FHS, just to maintain an old standard that no one is using anyway. You'd probably be hard pressed to find ANY distro that is using /usr/X11R7... It's all /usr now.

The only thing I might modify are specific ATI install paths so the installer can find everything. Right now, you have to move a few things by hand after installing the ATI drivers. That's something ATI should fix, not me, but I'm not sure how likely that is to happen. We'll see.

Thanks for the hints. Today was full of honey-dos that I didn't quite finish, so will probably start midweek. Will post my progress/results.
Regards,
Bill

Any word on the uploading of a new tarball to your server?

Jon

I haven't gotten around to cleaning up the build scripts, or applying the most recent security update. Hopefully I'll get to it this weekend... But I haven't touched the scripts since tar'ing them up.

Have you made any changes to yours? (been so busy I haven't checked your download folder lately)

I did get a chance to create an installation (not build) wiki page (for those who already have xorg-6.9 installed):

http://wiki.thoughtbit.com/linux:slackpkg:xorg-7.1

It's not publicly editable right now, but my biggest concern is how I've linked /usr/X11R6 to /usr/X11R7 - I did this to try to keep maximum "compatibility" for programs looking to /usr/X11R6 for things that aren't there anymore (using /usr instead of /usr/X11R7, in retrospect, seems to be a cleaner method to deal with this, but I wonder how Pat is planning on packaging his next release of Xorg - I'd like to stay consistent with that). Any thoughts? (it's been working fine on my laptop so far)

Just as a side note (not sure how big the differences are between vmware and other virtualization software) - I built my packages on vmware (a single core vm), and they installed smoothly and work very well on my dual-core laptop - so with vmware at least, you shouldn't have hardware-type compatibility problems from building on a virtual system. I think the vmware-player should suite these needs fine (so long as you can find a slackware vmware image) - the main limitation is that you can't pause the virtual machine (at least that's all I noticed when trying the player).

Which proto locations are you referring to?

I'm trying to go through the scripts a bit to clean them up, and apply the latest xorg patch... I'll post once I finish that up.

My biggest concern is that you remove the copyright. Sorry but I just don't like it. It's legally and morally dubious. I also don't think it's necessary to include the GPL license, but that's up to you.

Besides, there's nothing too original with those scripts anyway. It's just the BLFS wget files, a logging facility and commands wrapped in a for loop. The only really creative part is the 'latest version' stuff via ./picknew and that was a complete bust (I didn't write picknew anyway). Some stuff was taken from Fedora CVS also. There are too many contributors to start claiming ownership. The main reason would be that I have close to 100 frustrating hours wrapped up into those scripts, believe it or not. If anything, AND assuming I had an ego, it should be:

copyright Jon Grosshart <jgrosshart@gmail.com>
original scripts at: http://jaguarlinux.com/pub/slackware/source
changes made by John ***** *** <your@email.addr>
new scripts at: http://thoughtbit.com/xorg-build/
View thoughtbit.changelog.txt for details

Then remove my README entirely.

That is the proper way to handle it. That way your clearly citing someone else hard work along with informing potential users of the original version so they can diff if they want to. This is basic stuff that we all should have learned in english/literature class... ;) I'm not asking for MLA citation, just the basics.

To be honest, I question alot of your changes and it seems your doing stuff without knowing why your doing it. I've already listed some things a few posts back. You patching is wrong IMO. Change $PKGLST versions and you've just broken your scripts (however minor). Your optimizing for size on mesa. Why? No need for it. If anything you should be using -O3.. Your defining include/lib dir on mesa. No need for it. If it's not finding files on it's own then you have a problem. Slackware comes with 2.4 headers and you disabled the check in drivers. Slackware also comes with glut but your forcing mesa's glut on users, I would prefer to use mesa myself but it can be handled in a better fashion. Your linking xdemos against glut when it's not necessary and doesn't even get used in the first place. Your also missing obvious mistakes that were there to begin with. Ever notice your not building luit? Not sure how it got snubbed in my version. Some of it's a difference in prefrence and some of it's just plain technically wrong. I don't care one way or the other, you can do what ever you wish. It's the unclear citation coupled with your changes that bother me. Either remove the copyright and cite properly or remove my name entirely along with my README (It's completely outdated and irrelevant anyway)...

Do that and I'll pull the stick out of my ass. ;)

And yes, using /usr/X11R7 is a source of problems IMO. You can work around it with symlinks everywhere, but I'd rather stick with what the devs intended along with having everything picked up automatically. Again, it's a preference and that's why I use $XORG_PREFIX, to give the option, but I can all but guarantee Pat will be using /usr.. That would be the proper way IMO along with rebuilding whatever is left in /usr/X11R6. I don't bother with the later because I don't use any of those progs to begin with. I just removepkg on them and forget about it.

I have finalized my scripts and removed all the useless cruft that was in them. However I removed all Slackware related checks and made them DIY/LFS specific. They'll be in my pub/DIY/source directory in a few days. It would be a trivial matter to add the slackware checks back in. Just diff against pub/slackware/source, determine what's old useless cruft and what's slackware specific and adjust accordingly.

version 7.2 is just around the corner and I might make Slackware scripts for those. Don't know. Hardly no one has expressed an interest in them, and along with other things already mentioned by myself, it hardly seems worth it.

My suggestion for a hassle free build is to use the existing Slackware freetype/fontconfig and use /usr for the X prefix. Rebuild the deja-vu package to /usr and then update your font cache. If you find something in /usr/X11R6 isn't working and you need it, then rebuild it to /usr. But there are many ways you could work it.

I'm very sorry about that copyright stuff... I'll most definitely remove it or modify it in the way you suggested (really sorry for stepping on your toes with that!!)

There are definitely some things going on in the scripts that I don't fully understand, but I'm going through them more carefully to clean that stuff up (and understand it a bit more) - I have already changed the patches to use srcdir (your reasoning makes perfect sense).

Building these packages also seemed to be a smoother process in general when using /usr instead of /usr/X11R7, so I'll try that on my next build and see how nicely it can play with Slackware.

My main reason for rebuilding freetype and fontconfig was that, when I had install the pinki xorg packages from sourceforge, my print previews were completely garbled (it seemed to almost be mis-mapping the fonts to incorrect characters). I don't know if that was releated specifically to the pinki.

I had also borrowed some of the mesa stuff from the pinki packages, as you had mentioned having problems with it (and I ran into a few problems myself - I wasn't sure if they were related to switching /usr to /usr/X11R7, or if the options were just wrong or missing something, but I knew the pinki stuff did work...)

I have to go back through the portion of the code with the kernel headers check, and clean that up. I know it shouldn't have just been commented out as it is an important check.

Enough of my rambling for now! And, as I haven't mentioned it prior, thanks for your help!

I updated my scripts archive - removed the "license" files, stuck the copyright type note you suggested at the top of your README (and renamed it to README.orig instead of deleting it for reference and all your notes), and cleaned up my README file a bit. I also added a ChangeLog file. Let me know if that works for you :-) (or let me know what you'd still like changed - and I believe 100 hours would be easy to spend on something like this!)

I didn't include any of my most recent build files though (I haven't tested all of my changes yet), so these scripts are still missing the latest xorg patch, and still have the patch portion of the scripts using modname instead of srcdir (and it looks like I messed up the "patch -Np1 -i $CWD/secpatches/xorg-xserver-1.1.0-setuid.diff" patch - should've been -Np0, and it looks like that patch was included with xorg-xserver-1.1.1 anyway).

Well, thanks. Just a link pointing to the "original" scripts would have sufficed (along with no copyright), but it doesn't matter I suppose.. Haven't looked at them so I don't know what you did.

I'll be uploading my new scripts tonite or tommorow to my DIY directory. They're just about finalized but I still have a couple more things I'd like to tweak. When I'll get around to it I don't know. I put FIXME by stuff I'm still working on.

I'm really getting tired of modular X... :mad: Might be nice for the devs but sucks a big one for the builder/script-developer.

I upgraded to Mesa-6.5.2 and libdrm-2.3.0... Patched xorg-server-1.1.1 with the relevant patches but xvfb and xnest are bombing with errors that are indicative of a non-patched server... Makes no sense. References to mipmap.c and arrayobj.c that should have been taken care of with the patches. So.... I just:

--disable-xvfb --disable-xnest

:D Screw it. Slackware makes those into seperate packages and I never use/install them anyway. Probably 80% of X users don't even know what they do much less use them. If I don't get around to finding out why it's bombing, I may just leave the "disable" stuff. I'll make a conditional that checks for Mesa-6.5.2 on the system. If found AND xorg-server = 1.1.1, the xorg-server script will disable the building of xvfb/xnest. If libdrm-2.0.2 and Mesa-6.5 are found then you'll get a full xorg-server build. Good enough for me.. Make everything dependent on the user defined variables up top and the builder has no one to blame but him/her self if things don't work..

Still need to get security patches and compositing enhancement patches in place, other than that, and what I mentioned above, I'm about done with it. The scripts are significantly smaller since I removed all the clutter. Tidy and easy to read/modify.

Oh, I also changed the dri and module paths so the ATI installer works out of the box. Same prefixes that Fedora uses. The new scripts in /DIY will be far superior to the ones in /slackware... Except I removed the slackware specific stuff... ;)

That's why you use a conditional that uses $srcdir and not $modname. It would have skipped right over it if it were checking for name-version instead of just name.

Hi guys,

Do you know about http://sourceforge.net/projects/slackx/ ?

It's a script created by me to compile/install X11R7.1. It's install at /opt/X11R7, since I don't want the risk to damage my system, since I need my machine for daily work.

A guy that uses it pointed-me that you are with a problem in the order that the packages must be compiled, in SlackX this order is already correctly, it's a bit nasty how the things are done in the script, but it's working :-) I prented to update it soon.

I think that the next update of it will be only when X11R7.2 be released, since I'm doing a script to compile GNOME, SlackGNOME, with the same philosophy, that is taking a lot of time. I pretend to update it to the X11R7RC3, but I think that when I get back to work in it X11R7.2 will be out.

I think that you can find this interesting... I will also look with more time at the work that you are doing, since I think that there can be some info that interests me.

Best regards,
Carlos.

How so? Not sure I know what you mean. No problems with the build order and the scripts are extremely clean IMO... Oh... You were talking about your own scripts needing work... Anyways, the build order is correct on mine. Thanks for the info tho...

It looks like, at first glance, that your doing the same exact thing I am only you made hundreds of .SlackBuilds with

--prefix=$PREFIX $ARCH-slackware-linux

Whereas I just used a for loop. Other than that, they work identically except that you use a couple pre-compiled packages to satisfy deps and I use everything from source.

Hi jong357,

Sorry for the confusion. If you thinked that I was criticizing/diminishing your work, sure, that was not what I wanted to do, but when you say:

You appear to diminishing what I'm doing. Yes, my MAIN script, that control what the user will download, compile and package must have clean-ups to become more clear. I did some wrong decisions in how organize the hole thing that complicate a little some aspects of the main script, but now these things are clear in my mind and are some TODOs that I have to address in the main script, not in the .SlackBuilds, but I only have to change to leave the code more clear, not to resolve problems. Maybe when I said:

you thinked that I was refering to your work, but I was refering to my own, so take easy if you work is working, I just wanted to help something that doens't need it.

Moreover, I published something that I done to my own use (the same decision as your, I think), since I think that this could be usefull for someone else, so I don't need to dismish anyone work, since my own works for what I want, but if I can address someone needs that doesn't change the way that I need my scripts, it's okay! I think that this is your intetion too, so we don't need flames!

Best regards,
Carlos.

[post deleted by user. will repost somewhere more appropriate]