PlaneShift
Support => Linux Specific Issues => Topic started by: Induane on May 01, 2006, 04:04:51 am
-
Current Version in Repository: .9.2
Description:
GooeyBuilder is an easy to install and use tool for building PlaneShift from source. Unlike other scripts, GooeyBuilder has a graphical interface allowing the user to simply point and click their way through the compiling process. Currently GooeyBuilder is for Ubuntu Dapper ONLY!
Features:
- Finally FULLY Point and Click Interface
- Backup art directory in case this isn't the first build
- Can build bleeding edge or laanx compatible so you can play on the server
- Automatic dependacy resolution
- Sudo is now handled graphically so there is no need for an xterm in the background
- User sees no verbose output (only progress bars and friendly looking dialogs)
- Decent logging system. Log file is generated in sections with obvious section names
- Gets CS and CEL from SVN repositories as CVS is now not used
- Allow users to select different install locations
- Uses a temporary sources.list file to make sure it fetches correct files
Caveats:
- Script does not provide optimizations for different architectures yet. Selecting any processor will simply do a generic build.
- Script only supports Ubuntu Dapper Drake as of right now.
- A bug I'm trying to work out forced me to disable to automatic cvs retries for now. SVN continues to work normally.
ToDo:
- Add option to build with or without debug symbols
- Support more versions of linux with the script
- Finish support for processor optimizations and activate that feature
- Add better error handling
- Fix stupid errors
- Add ability to cross compile for windows (will never get around to this probabily)
- Add self destruct button for those that hate their computer
- Add capibility to use a source tarball instead
And now... SCREENSHOTS!
(http://img99.imageshack.us/img99/3589/gb17zn.th.jpg) (http://img99.imageshack.us/my.php?image=gb17zn.jpg)(http://img98.imageshack.us/img98/3069/gb25gi.th.jpg) (http://img98.imageshack.us/my.php?image=gb25gi.jpg)(http://img97.imageshack.us/img97/6836/gb39qo.th.jpg) (http://img97.imageshack.us/my.php?image=gb39qo.jpg)(http://img141.imageshack.us/img141/5480/gb44uq.th.jpg) (http://img141.imageshack.us/my.php?image=gb44uq.jpg)(http://img178.imageshack.us/img178/3092/gb58ka.th.jpg) (http://img178.imageshack.us/my.php?image=gb58ka.jpg)
Left to Right: Backing up the art directory, password prompt, dependancy resolution, processor selection, downloading some sources.
Recent Changes:
- Fixed a minor path problem in my script
- Now has the ability to automatically get correct build dates, or build bleeding edge
- Beginnings of a setup/config utility for gooeybuilder
- Fixed some growing pains from the svn merge
- Uses a temporary sources.list file so your current setup is preserved
An online repository is available to help you stay up to date with GooeyBuilder
Instructions:
- Open a terminal - usually Applications ------> Accessories----> Terminal
- Type: sudo gedit /etc/apt/sources.list
- Go to the very bottom of the file this opens
- Enter this line including the slash at the end:
deb http://vaalnor.mine.nu/repositories/dapper/unstable /[li]Save the file and exit gedit[/li]
[li]Now back at the terminal type: sudo apt-get update[/li]
[li]To install simply enter: sudo apt-get install gooeybuilder[/li]
[/list]
Note: This can also be done through synaptic. Once you have edited the sources.list file and saved it and run sudo apt-get update, you should be able to install it through synaptic. Also, once installed (whether via command line or synaptic) it will automatically update every time I release a new version, using Ubuntu's update manager feature.
If you are having any trouble with the repository simply download it here:http://vaalnor.mine.nu/repositories/dapper/unstable/gooeybuilder.9.2_all.deb
-
This is nice! Thanks Induane! :thumbup:
-
Good work :)
I have a question on the processor optimization stuff... if this thing uses configure and jam (which I assume yes), then when you call the configure script for CS and PS, add --enable-cpu-specific-optimizations=max to the configure line and it'll automatically pick the best optimizations for the CPU.
-
[li]Add self destruct button for those that hate their computer[/li]
:D
-
Good start!
I tried it on Mandriva and... well, it starts and tries to do what it is supposed to do, I'll make more tests later. apt-get and dpkg obviously don't work, but it is harmless - I have all dependecies installed.
For now two spotted bugs:
- missing delay between cal3d source retrieval retries
- window "Creating build environment" sometimes entirely covers "Enter your password" dialog, so You wait, and wait, and wait... ;) (btw: should't it be "Enter root password ?")
I have also a suggestion about code - use some variables instead of hardcoded strings, like file paths, cvs repository paths... etc., it is easier and faster to change single variable than searching for strings in whole code, it would also allow to add user customizable parameters ("Where do You want to put sources ?").
-
I'll look into killing that window. Zenity has a tendacy to stick around when it shouldn't sometimes. Since Ubuntu Dapper uses sudo, and has no root eaccount enabled even, the password needed is the users password. Its convienent for me when writing the script as it is easier to run certain commands with root privlidges, and others without. i.e. sudo apt-get update vs su -----> then apt-get update -----> then exit su root. Later on there will be seperate sets of functions based on the distro you select. Which probabily means its time to partition off my hard drive into about 5 more partitions, and install some more linuxes. Of course having them all listed in grub will be fun, especially mandravia which uses lilo I think instead. The only other distro on my computer right now is Arch linux, so that will probabily be the next version of linux this script supports.
I have also a suggestion about code - use some variables instead of hardcoded strings, like file paths, cvs repository paths... etc., it is easier and faster to change single variable than searching for strings in whole code, it would also allow to add user customizable parameters ("Where do You want to put sources ?").
That will be added later as well. I should have added that to the todo list... I probabily will here soon. Eventually I'll add an option like - enter your own desired install location, or use defaults? Then I'll have those represented as variables instead of strings. The script will populate the strings with default values if they select default, and with whatever they enter as their desired directory. I'm still expirementing with the file selection dialog so that is why its not an option yet.
I have a question on the processor optimization stuff... if this thing uses configure and jam (which I assume yes), then when you call the configure script for CS and PS, add --enable-cpu-specific-optimizations=max to the configure line and it'll automatically pick the best optimizations for the CPU.
From what I've read it makes semi intelligent decisions about processor optimizations. The trouble is some optimizations aren't good for 3d game engines, etc.. I'm going to do alot of expirementing on different hardware to see what yields the best overall results. I don't want to choose something that will degrade performance. I'd rather optimizations be in my control.[/color]
-
Sorry to respond to my own post :oops:
If anyone has any expirence with bash or more sugestions please let me know. I'm sort of at writers block with only a few minor features to add that I think I know how to implement. I'm also not that good with debugging, or bash in general. If anyone has the time to look it all over, please do. I could really use a few suggestions.
-
I'll see if I've the time to look over it for you. :)
-
Sorry to respond to my own post
Don't worry, look at Karyuu's statistics, she never checks Linux forums, Your firstborn is safe ;)
(On the other hand - Xordan may tell on You :whistling:)
Because it doesn't make sense to rewrite your script (it's Your project after all), here are my suggestions:
- If you really want to use bash as shell, the line
#!/bin/bash
must be the first line of the script
- I really recommend using variables from the beginning of the work, You will have less bugs later (for example: replacing strings in many places means more typing errors)
- don't put commands to variables, only command parameters, it makes code more readable and more flexible, like this:
GOOEY_VERSION=".6.1"
CS_CVS_REPOS=":pserver:anonymous:@crystalspace3d.org:/home/crystal/scm/crystal"
CAL3D_CVS_REPOS=":pserver:anonymous:@cvs.sourceforge.net:/cvsroot/cal3d"
CEL_CVS_REPOS=":pserver:anonymous:@crystalspace3d.org:/home/crystal/scm/cel"
PS_CVS_REPOS=":pserver:anonymous:@cvs.sourceforge.net:/cvsroot/planeshift"
BUILD_PATH="/opt/planeshift_cvs"
run_cvs() {
cvs -z3 -d$1 $2 $3
return "$?"
}
#.... somewhre $CVS_COMMAND and $CVS_ARGS is set
run_cvs ${CS_CVS_REPOS} ${CVS_COMMAND} ${CVS_ARGS}
- add a column with numbers (or other simple strings) as first column for zenity's radiolists, You won't need to use grep to recognize choices...
- (continuation of previous paragraph) ... and instead of using "if...then...fi" use "case $var in .... esac" statements, for example:
RET=`zenity --list --radiolist --column "" --column "#" --column "CPU" --column "Desc" \
TRUE 1 "Pentium 4" "Optimize for P4" \
FALSE 2 "Athlon 64" "Optimize for AMD64"`
case $RET in
"1") CFLAGS="-mtune=pentium4"
CXXFLAGS="-mtune=pentium4"
# other instructions here
;;
"2") CFLAGS="-mtune=athlon64"
CXXFLAGS="-mtune=athlon64"
PS_CONF_FLAGS="----enable-cpu-specific-optimizations=max"
# other instructions here
;;
*) #cancel was pressed ?
return 1
;;
esac
- DON'T use "kill -9", it is last resort signal. Just use "kill" (defaults to kill -TERM). Besides - I think, that "Creating build environment." window is not needed, whole process takes miliseconds, so there is no need to display progress at all.
- implement MAX_RETRIES for source retrieval, example:
MAX_RETRIES=10
SLEEP_TIME=5
get_cs_source() {
i=0
until run_cvs ${CS_CVS_REPOS} co CS; do
i=$(( $i + 1 ))
[ "$i" -gt "${MAX_RETRIES}" ] && return 1;
sleep $SLEEP_TIME;
done
return 0;
}
#...
get_cs_source 2>&1 | zenity --progress --pulsate --auto-close --text $"Getting Crystal Space sources, please wait..."
[ "$?" -eq "0" ] || { zenity --error --title "GooeyBuild Failed" --text "No Crystal Space - no Planeshift";
exit 1; }
- add error handling wherever possible and add appropriate messages (I hate messages like "Unknown error has occured")
- avoid putting zenity in background (maybe use "|" as in above example)
- always set one of choices in radiolists to TRUE
Enough for now ...?
-
If you really want to use bash as shell, the line
Code:
#!/bin/bash
must be the first line of the script
OMG How could I have forgotten that!?!?!!! :whistling:
don't put commands to variables, only command parameters, it makes code more readable and more flexible, like this:
Understood. I'll make those changes asap.
add a column with numbers (or other simple strings) as first column for zenity's radiolists, You won't need to use grep to recognize choices...
Good idea. That eliminates the need to have a special unique word in each option.
... and instead of using "if...then...fi" use "case $var in .... esac" statements, for example:
Code:
I'll give that a shot. I've never used the case syntax before so I'll mess with some test scripts to see how it works and get a feel for it, and if its cool I'll make those changes ;) lol ....sniff....but grep is so dang cool!
DON'T use "kill -9", it is last resort signal. Just use "kill" (defaults to kill -TERM). Besides - I think, that "Creating build environment." window is not needed, whole process takes miliseconds, so there is no need to display progress at all.
OK I'll throw out the -9 its just a bad habit of mine. I'll eliminate that window too, as I also noticed that it appears only momentarily, and basically because of a sleep hack. :D
implement MAX_RETRIES for source retrieval
That was listed in my caveats but not in my todo list for some odd reason. Hehe. Not sure why not, but I was basically pondering the inplementation. I'd been working on a way to do it. I had been thinking about a for loop, that repeated a command until the count ran down. You way looks cool and complex, I'll mess with trying to understand it ;)
add error handling wherever possible and add appropriate messages (I hate messages like "Unknown error has occured")
Yea... it was on my mental todo list. :D
avoid putting zenity in background (maybe use "|" as in above example)
Not sure what you mean there. Heh... My skull is a bit thick.
always set one of choices in radiolists to TRUE
I don't understand this one either.
Enough for now ...?
BRING IT ON![/color]
-
avoid putting zenity in background (maybe use "|" as in above example)
Not sure what you mean there. Heh... My skull is a bit thick.
Instead of worrying about killing zenity windows, let the shell take care of it. Operator "|" creates pipeline, through which data flow from one command to the next (from left to right). This gives the following advantages:
- zenity window closes automatically, when command before "|" sends EOF marker (=it is completed or failed) and "--auto-close" was specified; without auto-close OK button becomes active and user has to press it.
- pressing "Cancel" in zenity window causes "Broken pipe" error and whole script ends returning error code. Example:
get_cs_source | zenity --progress --pulsate --auto-close --text "Getting CS sources, please wait..."
The window will close after CS sources are succesfully retrieved (or not), and when user presses "Cancel" installation will be canceled.
- for progress dialogs You really can display progress by sending appropriate data (it is described in gnome-help -> Desktop -> Zenity). So, You can even display progress of compilation! Simple example:
{ echo -e "#at target 500... \n50"; sleep 5; echo -e "#at target 900... \n90"; sleep 5; echo -e "#almost done...\n99"; sleep 2; } | \
zenity --progress --auto-close --width 400 --text "Compiling Crystal Space"
[/list]
always set one of choices in radiolists to TRUE
I don't understand this one either.
Look at my second example from previous post. The first element (Pentium4) has TRUE in first column, so it will be selected by default. By default You can set "No optimization" for users, which don't know, what cpu they have ;) and they will just press OK to accept default choice.
Enough for now ...?
BRING IT ON!
Two more hints:
- instead of "ps -U root -u root u | grep synaptic | grep -v grep" it is sipler to use command pgrep; if synaptic is running "pgrep synaptic" will return pid of process and exit code will be 0, otherwise exit code will be 1.
if pgrep synaptic &>/dev/null; then
zenity --error --text "Please close synaptic"; exit 1;
fi
- implement UPDATING sources instead of deleting them and downloading again
Hmmm... Now it is Your turn :P. You have opportunity to learn something new AND You can discover some things, which I don't know... Waiting for version .6.2 or later...
-
# zenity window closes automatically, when command before "|" sends EOF marker (=it is completed or failed) and "--auto-close" was specified; without auto-close OK button becomes active and user has to press it.
# pressing "Cancel" in zenity window causes "Broken pipe" error and whole script ends returning error code. Example:
Code:
get_cs_source | zenity --progress --pulsate --auto-close --text "Getting CS sources, please wait..."
The window will close after CS sources are succesfully retrieved (or not), and when user presses "Cancel" installation will be canceled.
Seriously awsome suggestion! That cleans up the code SO much and makes it work better too. So simple yet I never thought of it thanks!
5 seconds later....
cvs [login aborted]: received broken pipe signal
cvs [login aborted]: received broken pipe signal
cvs [login aborted]: received broken pipe signal
cvs [login aborted]: received broken pipe signal
cvs [login aborted]: received broken pipe signal
cvs [login aborted]: received broken pipe signal
cvs [login aborted]: received broken pipe signal
cvs [login aborted]: received broken pipe signal
goes on indefinately with this method... is a kill also necessary?[/color]
-
I guess You kill zenity before "cvs login" ends... or You gave wrong parameters to zenity and it does not start at all. So the answer is: no, kill is not necessary. I would need to see current version to give full answer. It works for me...
-
Here is what I think is going on. If you stop the first part of a pipe, then it kills zenity automagically. The bad part is if you kill zenity, it doesn't kill the first command before the pipe. There must be a way to detect and handle the cancel button zenity uses, but I can't find it in the documentation.
-
The command on the left side will die because of broken pipe. Unfortunately, cvs always returns exit code 1, regardless of the reason, so you can't distinguish between network error and canceling zenity. You must use dirty trick here: add inside a loop, which retries downloading sources, any shell command, which tries to write to stdout, for example "echo '#Retrying...'". This will cause death not only to cvs, but also to subshell, in which download loop runs.
You can also add at the very beginning of buildscript "trap 1", which will prevent the main shell from exiting after reseiving SIGHUP (after pipe is broken), and the buildscript will continue. Read about debug traps in bash manual.
edit: ...or use trap to display nice info window before exiting, for example:
trap 'zenity --error --text "Canceled !!!"; exit 1' 1
-
Yea I was playing around with different ways of doing this. A person in #bash gave me this little example which I've been looking over trying to figure out. :D
checkout () {
until cvs checkout prods
date
false
do
sleep 1
done
}
trap "echo >&2 SIGHUP; set -x; exit 100" HUP
(
while sleep 1
do echo dummy
done
) |
zenity --progress --pulsate --auto-close --text "TEXT" &
zenitypid=$!
checkout
kill $zenitypid
echo >&2 done
A trap was suggested there as well. I'll mess around with it to see if I can get something working now :D Thanks for the advice.
-
I finally added an updated versio and fixed the apt repository. There are several improvements, but I've another question for the geniuses here. If the person puts in the wrong password in my dialog how can I set it up so that it catches that and allows say...3 retries or something?
-
Erm... I'm not a genius, but anyway...
function build_env {
NUM_TRIES=3
# sudo -k to test script
sudo -k
for (( i=1; i<=$NUM_TRIES; i++ )); do
# just "sudo -v" below to have exit value of sudo, not command invoked through sudo
zenity --entry --title "Password Prompt" --hide-text --text $"Enter your password (try #$i of $NUM_TRIES)." | sudo -S -v
# exit loop if password was correct
[ "$?" -eq "0" ] && break
done
# "i" greater than $NUM_TRIES means $NUM_TRIES failed tries
[ "$i" -gt "$NUM_TRIES" ] && { zenity --error --text "Number of retries exhausted!"; exit 1; }
[ -d $install_dir/planeshift_cvs ] || sudo mkdir $install_dir/planeshift_cvs
# sudo -v # not needed here ?
sudo chmod -R 777 $install_dir
touch $install_dir/planeshift_cvs/GooeyBuild.log
cd $install_dir/planeshift_cvs
}
BTW: why "Gooey" ?
-
Gooey is the literal pronounciation of G.U.I.
btw thanks I'll mess with the password retry dohickey. Hehe - I'm not so good at this.
-
hi,
after typing gooeybuilder in my cl - the third window i get says: Could not find buildscript compatible with your linux distro. Exiting...
hmm - I am currently running Ubuntu 6.06 alias Dapper Drake - since it was made for dapper i was wonderingn what could have went wrong
-
It worked for me once (well at this time the servers didn't work...) but now I get the same error, so might there be a problem with any updatet libs/etc. ?
EDIT: Here we go with a simple solution: open "/usr/local/GooeyBuild/distro" with a texteditor and change "Dapper" in line 6 to "dapper"...
Thats all!
EDIT2: Since sourceforge changed their naming policy you havo to open another file and change so things:
do a "sudo gedit /usr/local/GooeyBuild/dapper_buildscript"
and then change line 14 to 17 to the following:
ps_login=':pserver:anonymous:@planeshift.cvs.sourceforge.net:/cvsroot/planeshift login'
ps_co=':pserver:anonymous@planeshift.cvs.sourceforge.net:/cvsroot/planeshift co planeshift'
cal3d_login=':pserver:anonymous:@cal3d.cvs.sourceforge.net:/cvsroot/cal3d login'
cal3d_co=':pserver:anonymous@cal3d.cvs.sourceforge.net:/cvsroot/cal3d co cal3d'
-
I've got those issues addressed for .8 but havn't packaged it up yet. My wife was out of town so instead of hiding out on the computer I've been fixing things and relaxing.... lazy I know. :D I'll do a bit more work tonight then see what all I can do. If I'm lucky I'll get a new package ready by tomorrow.
I'm also doing a little research on SVN which is what it looks like alot of these will be switching to for source code control. Eventually the script will have to be updated for that switch.
Edit: SVN added as well now
-
http://vaalnor.mine.nu/PlaneShift%20Builder/ (http://vaalnor.mine.nu/PlaneShift%20Builder/)
The link above is where I keep my script and debian package making environment. Making the packages is now automated with a 4 line script, and really all is working out pretty good. I added SVN, and a max retry variable to everything which seems to be working well. I got two successful builds of the client out of this earlier, so hopefully there aren't any other glaring mistakes. Next on the agenda is true progress indicators. Anyways if anyone has suggestions for the way I have things layed out, etc, let me know. :D Wired_crawler has already been a fantastic help btw thanks!
-
hehe again sorry to respond to my own posts (Induane glances around for Karyuu) but I've finally done a little bugbusting and updating on my script. On two seperate PCs it compiled and updated working versions (too new for the server though) and all seems to be good. It now backs up your current sources.list file, copies in mine, updates the package list, installs packages, then returns your original sources.list file and refreshes the package list again. This means it will now work completely out of the box on a fresh dapper install, but it also adds a little extra time to the whole procedure.
-
Guys, blue doesn't mix with brown. I can't read your font with Karyuu's forum layout. =/
-
hi,
my next attempt to use the gooeyBuilder ended in the following message:cp: Aufruf von stat für „/opt/planeshift_cvs/art“ nicht möglich: No such file or directory which makes sence since there is no directory called /opt/planeshift_cvs/art but only /opt/planeshift_cvs/planeshift/art
due to a lack of knowledge i don't have a clue how to fix that myself...
I used .8.2 on dapper and chose the default install directory.
-
Today I finally released version .9 of gooeybuilder. There are alot of changes to this version. Some variables are now stored in a config file which is parsed by the script. Also, this allows me to start creating a new script will be a setup tool, allowing you to adjust such settings as max cvs retries and stuff.
-
hi,
i ran the .9.0 version today, but get still the same message in the log in the section ART RESTORE that there is no directory /opt/planeshift_cvs/art which is correct because there is a /planeshift missing in the path.
-
thankx fixed :D
-
well, it still didn't work. ??? now the script was looking for /opt/art - just in case that is already at the end of the script - is there a way i don't need to compile everything again?
-
you can manually copy an old art directory back over
but... today they are doing some major updates. The fun thing is that the format that the art is in is changing so it would be best to download all new art anyways. I'll look into why its looking in odd places, I tested it in vmware and it worked for me both with default directories, and with a manually selected directory. Either way you should be able to cd into the directory you installed it in and run ./updater --auto but I'd wait until they notify everyone that the updates to laanx and the client are done and that could take a day or two.
-
This means the next update will be in my standard update manager? Just click and let update?
I thought it was too big for that :-s
-
Raven - GooeyBuilder is a small tool that may be used to compile your own copy of planeshift for your system. Installing it doesn't install planeshift, you still have to run gooeybuilder, then update and get the art as well.
My tool isn't PlaneShift itself. Its simply another way of installing planeshift on your machine.
That said I may be hosting some binaries.