|
Xorg-7.1.1 build scripts
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? :D 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 :mad:. 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... :scratch: 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. :scratch: 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........ :rolleyes: 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:
freetype2One 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' *.buildI 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. :-) |
Compiz
I've done some pleminary work with compiz from the xorg-app package and it basically wants packages that aren't even on Slackware... :confused: No suprise I guess.
In order to build compiz against KDE, it wants QT4.. In order to build against GTK, it want's libwnck, gconf2 and others. To build against Gnome it obviously requires GTK and Metacity... It can build against DBUS.. Basically the only thing it picks up on is librsvg and I think you have to specify that manually.... You guys are really going to have to install bleeding edge libs to get compositing to work... ;) I'll keep working on it... |
I've been messing around with your build scripts a little... had to adjust the mesa script:
added: mv showfiles.php\?group_id\=3 index.html before grep -o 'f=".*bz2' index.html > new changed: sed 's/<.*//' new2 > new3 to grep sourceforge new2 |rev |cut -f 1 -d ">" |rev > new3 I also changed the prefix to /usr/X11R7 for everything but fontconfig and freetype, as it makes it easier to link X11R6 to X11R7 (I've completely removed all slack packages that reside in /usr/X11R6 for now). With this change, I also had to change how pkgconfig files are handled (I'm moving them into /usr/lib/pkgconfig, and I've linked /usr/lib/pkgconfig to /usr/X11R7/lib/pkgconfig). I also needed to change my /etc/profile and a few other files in etc that reference X11R6 - just changed to X11R7. The resulting slack packages are working with kde and dropline gnome, but I haven't tried installing them on a clean system yet... |
Right on... They must have made some changes to their website then.. I haven't run those build scripts in about a month. I'll update them sometime this week. Might be better to just cat a PKGLST instead of wgeting/seding seeing as how a static version of mesa is defined. That function is a hold over from pulling the latest versions via ./picknew. I just left it in place not thinking it would cause a problem...
Just curious, your using the static versions that I have defined? or are you messing around with the 'picknew' aspect of it? That was a REALLY bad idea on my part... :D Gave me nothing but headaches trying to keep up with all the developmental changes... As soon as a stable 7.1.2 or 7.2 arrives, whichever comes first, I'll try to update them. |
By the way, that 4shared web site is being really wierd. Random files are getting removed for no apparent reason. The latest xorg scripts was one of them.
I've been meaning to get my own server up and running for quite some time now. Looks like a good opportunity to do so. I'll systematically hunt down all my posts with that link and replace it with a new one once my server is up. If your interested in those scripts, just sit tight for a week or so. I'll find a new home for them. |
haha, I was wondering why the scripts disappeared...
I left all your static-versioning sed commands in the scripts, so I suppose it is just keeping them static (even though it is still running picknew). That was going to be my next task, checking through to see what is still static, and what is pulling the newest version. Right now I'm still working on making it as similar to the default slack x11 packs as possible (keeping with the /usr/X11R* layout) - it seems to be working well. I'm currently using some "pinki" builds of xorg which I got from sourceforge, in combination with some other beryl packages for a nice aiglx/beryl setup. However, it is a little buggy, so I'm planning on comparing your build scripts to the pinki ones (compare patches, configure options, etc.). I haven't done much research on mesa yet - have you had any luck with 6.5.1? (or .2 if that's out?) |
EVERYTHING should be static with the last tarball I uploaded, which is now gone. The version numbers are defined in extras/$PKGNAME-static except for mesa, which I still run the picknew script but then just sed the VERSION back to 6.5 as you've noticed...
Hey, If you have the time or inclination, I wouldn't mind seeing a diff of the mods you've been doing. Up to you. Out of the hundred or more people who have downloaded those scripts your the only one who's bothered to comment on them. Pretty annoying... ;) I still have a TODO list for those scripts. I have a bunch of such projects going on. Think I bit off more than I can chew, time wise. Still need to add beryl and get composting integrated. Think I've abandoned the compiz route. I'm pretty sure Fedora and others are still using Mesa-6.5.... The mesa devs are on some serious crack and better get their act together soon. It keeps getting more and more broken with each release. Actually, Fedora might be on the latest. The big problem is, that they are not keeping up with the development of xorg-server. I knew as soon as I heard about the plan to go modular, that some people were going to slack off and not play ball. It's really frustrating for the builder. I really miss the imake system... :cry: Also, since I went static, there are a number of security patches that should be applied to various progs. Get on the homepage of Xorg and see. That's another thing I was going to do with the next update. So little time... |
I just did a quick diff -u - here they are:
http://thoughtbit.com/xorg-build/xorg-7.1-diffs.tar.bz2 (that is my webserver). Aside from adjusting the mesa build, I've changed all the XORG_PREFIX's to /usr/X11R7 (left freetype2 and fontconfig in /usr), and then I added in some pkgconfig cleanup (to move pkgconfig files from /usr/X11R7/lib/pkgconfig to /usr/lib/pkgconfig). It's still a little messy, but I'm going to be messing around with it this week... I'm doing all the building in vmware, but my system is using packages from here right now: http://web.tiscali.it/meskalamdug/aiglx-en.html Beryl is working, just a bit buggy, and since that pinki build script is not in english, I figured I'd start with your script and then compare. I definitely like how your scripts are separated, as it'll allow you to do more individual type updates (I think... so long as everything isn't dependent on what you're recompiling). The pinki build and official slackware builds are more or less (much more than less) single all-encompassing scripts. I'd really love to get beryl up and running though, so once I have some proper packages, I'll get to testing that. That tiscali site does let you download their build scripts, so hopefully it won't be too painful. |
oh, this is my first time trying to build xorg more or less from scratch (aside from a gentoo install I have... but I don't count that, as all I did was emerge xorg), so any random tips would be great! It seems that your scripts are pretty explanatory.
I was thinking that perhaps your picknew script could be separated into a pre-build-xorg script to help build a single list of packages, which you could edit prior to running all the scripts (and therefore allow you to statically set the versions, but dynamically download the most current list)... |
alright, I think I got it!
http://thoughtbit.com/xorg-build/ i had to change your mesa build - i'm using mesa's glut and a few more configure/compile options. you were also missing a few options in your xorg.conf in the Screen section (i've included an updated xorg.conf in my source). so, now i have xorg-7.1.1 and beryl-0.1.4 up and running on slackware11, and WITH dropshadows (finally)! here's a screenshot: http://thoughtbit.com/xorg-build/sla...iglx-beryl.png if you check out the xorg build scripts, make sure to take a peak at README2 |
Advice, please
I have been lurking on this thread from its beginning. This is a subject that I have been interested in for a while. I have a fresh install of Slackware 11 in a qemu environment. I think this may not be appropriate as the video system presented by qemu may not work properly. I will probably make a new partition on my hdd & put another fresh install there. I'm planning on installing X7 into an install that doesn't have X in it all. Is this the best strategy? Have either of you come up with any other tips that might help me out? I'm rather looking forward to this experience, even if it doesn't work completely, it should teach me a lot.
Regards, Bill |
although the video system in qemu might not let you run x (it should work with at least the standard "vesa" driver I would think), you should be able to build x without a problem. (I built x in vmware)
For my vmware image, I used a full install of slack, and then went into the /var/log/packages directory and ran a command to see what was living in /usr/X11R6: cd /var/log/packages grep X11R6 * |cut -f 1 -d ":" |uniq |sort I then removed those packages, made a few system wide changes (changed the references to X11R6 in my path and ld.so.conf files to X11R7), changed a few symlinks, logged out and back in, then started building. There are some more detailed steps in the README2 file in my source files. I think the best idea is to have a basic system image (like a vmware image) with your stock install, and make copies of it to work on, so that way you can start over easily and quickly. hope this helps! |
Hmmmm......
I've noticed a few things in the limited ammount of time I spent looking thru your tarball. Everything in source/ is redundant. In fact, they might even nullify extras/$PKGNAME-static and/or specific $VERSION/$PKGVER variables (fontconfig/freetype). But for the most part, they should get overwritten via script functions. You've disabled the kernel-headers check in drivers. Not a big deal but if someone else is running it and still has 2.4 headers installed, they'll get errors in xorg-drivers.err and wonder what is going on. An annoying time killer for the builder, nothing more. If 2.4 headers are found, an attempt to compile shouldn't even be made IMO... For the secpatches, you should be using $srcdir and not $modname else if the src versions are higher than what the patch was intended for the patch process might stop waiting for user input but we redirect to logs. If it doesn't ask for input and skips the patch, then it should throw cruft in .err which is unnecessary. Just little stuff at first glance. Not entirely sure about the copyright stuff either... ;) GPL yes, ofcourse but you should probably check with the original author before you claim copyright on it, or presume to claim copyright on my behalf... I never was big on that sort of thing. You've basically started a fork of my scripts. That's competely fine with me, but you should probably ditch my README and incorporate any relevant info from it with yours. Some additions you've done make some of my comments either null or confusing. Ditch stuff like that in the scripts. Clean em' up, make them yours and just throw a link to this thread in the README stating that you've forked from an existing set of scripts. Somethin'... ;) Actually, I think it would be more disireable for everyone if we just colaborated and came up with a new and improved tarball. I'm just really busy with work and various things so don't know if that's feasable or not. I was going to try and free up some time for another build and more modifications hopefully this coming weekend.... |
I'm also curious as to why your optimizing for size on mesa. I've had mixed results doing that in the past and don't see a need for it anyway. Your defining the proto locations too. What's up with that? I'm assuming it bombed on you because it couldn't find the headers? Does it still do that if you don't comment out my sed filter? ;)
Ughh.. I have to put this down till I get some free time. I should be sleeping right now... :D |
hehe, i meant to ask you if you wanted that copyright info in there - it was late at night...
I'd prefer to try to keep the two "versions" as one, with user-definable prefixes (I know I missed a few spots in my scripts for that), as I don't think there would be all that much reason for separate scripts (actually, I'll probably be trying the scripts on x86-64 arch at some point). It wouldn't be hard to make all the slackware specific stuff optional. I'll try to take some time to clean up the scripts, and apply the suggestions you made, but I'm back to work this week... it will get done eventually though! I'll post updates as I make them, and check back to see if you've updated anything. ...definitely right about the kernel headers check - I was running a 2.6 compiled kernel, but was trying to figure out problems at one point or another and commented that stuff out... |
| All times are GMT -5. The time now is 10:42 PM. |