Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Linux 64 and 32 bit packages for latest vdrift
12-10-2008, 08:13 PM
Post: #1
Linux 64 and 32 bit packages for latest vdrift
Hey

I've been trying to install vdrift for a while now (and failing miserably, but that can go into my post in the help section Tongue), I noticed that the packages you have for linux are out of date, and that they are done via autopackage.

I would like to use the latest version and thus have to compile from source Confused Autopackage does not currently support 64bit (they do say you can install 32bit packages on 64bit, but when i try to install from autopackage it just tells me that every thing is the wrong elf class even though i have the 32bit versions of the libs installed as well), so maybe you could either ditch autopackage, or provide your 32bit packages via autopackage, and 64bit via an already compiled tar.gz? (to keep it distro neutral). Or possibly you could just make an rpm/deb. And then if people want to install it on something that uses a dif package system they can use alien to convert it?

So pretty much can we have working 32bit and 64bit installers for the latest version of vdrift on linux? Big Grin
Find all posts by this user
Quote this message in a reply
12-10-2008, 08:56 PM
Post: #2
 
We haven't had any binary releases for linux in a while because no one has had the time and/or know-how to do them. If you're up to the challenge, we could use the help.
Find all posts by this user
Quote this message in a reply
12-10-2008, 11:31 PM
Post: #3
 
ah ok. Well if I can get it to compile i'll have a go at making packages Big Grin
Find all posts by this user
Quote this message in a reply
12-12-2008, 08:45 PM
Post: #4
 
Okay cool, if you need any help with the compilation stuff let me know.
Find all posts by this user
Quote this message in a reply
06-25-2009, 12:37 PM
Post: #5
 
You can get binary packages from here (as exemple):

In order to view links, you must have to reply to this thread.

Maybe you could make a link on the website...?


Tom
Find all posts by this user
Quote this message in a reply
06-26-2009, 06:01 AM
Post: #6
 
I could probably have a go at putting together the necessary tree to make .deb packages - these would normally apply to any debian-derived system.
Should be fairly mundane due to using scons.
Find all posts by this user
Quote this message in a reply
06-26-2009, 09:36 AM
Post: #7
Building Deb packages with scons
Here is a tutorial about making .deb packages with scons:
In order to view links, you must have to reply to this thread.

It requires putting this lines at the end of the SConstruct script:
Code:
# package target build as a Debian package
if 'debian' in COMMAND_LINE_TARGETS:  
    SConscript("deb/debConstruct")

So far I have learned about DEBs, but I am having problems with Scons and Python, which are a little unfamiliar. I couldn't figure yet where should the DEBFILES point to... where to put vdrift documentation, where to put executable files (though I assume it'll be something around /usr/bin/vdrift)


I'll try to put the script I've made so far in the discussion section on In order to view links, you must have to reply to this thread.

The file deb/debConstruct.py should contain:

Code:
# -*- coding: utf-8 -*-
#This script was taken from http://www.qandr.org/quentin/writings/debscons

import os, shutil, sys
Import('env') # exported by parent SConstruct

# I wanted to base the debian version number partly on the
# revision checked out from our SVN repository.
# Skip this if it's not relevant to you.
#svn_version = os.popen('svnversion ..').read()[:-1]

# This may be as simple as '89' or as complex as '4123:4184M'.
# We'll just use the last bit.
#svn_version = svn_version.split(':')[-1]
svn_version = "2009.06.15"


# Here's the core info for the package

DEBNAME = "vdrift"
DEBVERSION = "2009.06.15"
DEBMAINT = "Bogdan bogdan.bivolaru@gmail.com"
DEBARCH = "i386"
DEBDEPENDS = "g++, scons, libsdl-gfx1.2-dev, libsdl-image1.2-dev, libsdl-net1.2-dev, libvorbis-dev, libglew-dev, libasio-dev" # what are we dependent on?
DEBDESC = "VDrift is a driving simulation game made with drift racing in mind"

DEBFILES = [
    # Now we specify the files to be included in the .deb
    # Where they should go, and where they should be copied from.
    # If you have a lot of files, you may wish to generate this
    # list in some other way.
    # ("usr/bin/myutility",                 # "#src/myutility/myutility"),
    # ("etc/myutility/myutility.conf",      # "#misc/myutility.conf"),
    
]

DEBFOLDERS = [
    # Now we specify the files to be included in the .deb
    # Where they should go, and where they should be copied from.
    # If you have a lot of files, you may wish to generate this
    # list in some other way.
    ("/usr/local/share/games/vdrift/data", "data"),
]
    
# This is the debian package we're going to create
debpkg = '#%s_%s-%s_%s.deb' % (DEBNAME, DEBVERSION, svn_version, DEBARCH)

# and we want it to be built when we build 'debian'
env.Alias("debian", debpkg)

#DEBCHANGELOG =
#DEBCOMPAT =
#DEBCOPYRIGHT =
#DEBWATCH =
DEBCONTROLFILE = os.path.join(DEBNAME, "DEBIAN/control")

# This copies the necessary files into place into place.
# Fortunately, SCons creates the necessary directories for us.
for f in DEBFILES:
    # We put things in a directory named after the package
    dest = os.path.join(DEBNAME, f[0])
    # The .deb package will depend on this file
    env.Depends(debpkg, dest)
    # Copy from the the source tree.
    env.Command(dest, f[1], Copy('$TARGET','$SOURCE'))
    # The control file also depends on each source because we'd like
    # to know the total installed size of the package
    env.Depends(DEBCONTROLFILE, dest)

# This copies the necessary files into place into place.
# Fortunately, SCons creates the necessary directories for us.
for f in DEBFOLDERS:
    # We put things in a directory named after the package
    dest = os.path.join(DEBNAME, f[0])
    src = os.path.join(DEBNAME, f[1])
    # The .deb package will depend on this file
    env.Depends(debpkg, dest)
    # Copy from the the source tree.
    shutil.copytree(dest, src)
    # The control file also depends on each source because we'd like
    # to know the total installed size of the package
    env.Depends(DEBCONTROLFILE, dest)

# Now to create the control file:

CONTROL_TEMPLATE = """
Package: %s
Priority: optional
Section: games
Installed-Size: %s
Maintainer: %s
Architecture: %s
Version: %s-%s
Depends: %s
Description: %s

"""
env.Depends(debpkg,DEBCONTROLFILE )

# The control file should be updated when the SVN version changes
env.Depends(DEBCONTROLFILE, env.Value(svn_version))

# This function creates the control file from the template and info
# specified above, and works out the final size of the package.
def make_control(target=None, source=None, env=None):
    installed_size = 0
    for i in DEBFILES:
        installed_size += os.stat(str(env.File(i[1])))[6]
    control_info = CONTROL_TEMPLATE % (
        DEBNAME, installed_size, DEBMAINT, DEBARCH, DEBVERSION,
        svn_version, DEBDEPENDS, DEBDESC)
    f = open(str(target[0]), 'w')
    f.write(control_info)
    f.close()
    
# We can generate the control file by calling make_control
env.Command(DEBCONTROLFILE, None, make_control)

# And we can generate the .deb file by calling dpkg-deb
env.Command(debpkg, DEBCONTROLFILE,
            "fakeroot dpkg-deb -b %s %s" % ("deb/%s" % DEBNAME, "$TARGET"))

Hopefully, if people improve this to really work it will be included in the SCons build.
UPDATE: So far I have only have copied the vdrift data to a packaging folder. I have only thought about making a single DEB package for the whole work. But what if we would do two packages a vdrift and a vdrift-data (such as openarena and openarena-data)? What advantages would that offer?
Find all posts by this user
Quote this message in a reply
06-26-2009, 11:02 PM
Post: #8
 
Wow, and I was just going to use debhelper.

Splitting it out into binary and data files would allow different levels of data package - you could have a 'full' package and a 'minimal' package but only have to packages the binaries once. It would also allow you to retain data and install new binaries for when they changed but data didn't (which is fairly normal).
Find all posts by this user
Quote this message in a reply
06-27-2009, 05:01 AM
Post: #9
a few points
1) I have a small problem:
the script that was given as an example for building DEBs from scons processes every single file, but I don't know how to cope with so many files under a deep tree: there are over 1000 files here and lumping them together in a single file just doesn't cut it for me. If I am to finish this I believe I should build a list of files in every single folder:
just as SConscript main file calls data/SConscript which in turn calls data/carparts/SConscript, which in turn calls... ok I guess people can figure the rest I should call a subscript in every folder.... or maybe I can build the DEBFILES array in every single SConscript in every subfolder gather them arround and process them at in the end file.

Don't rely too much on my work: I'm just learning Python, SCons and DEB packages as I go (ok I had build 2 example DEB packages but that's hardly a deep experience)

2) The debhelper option is good too, but I just didn't figure out how to do it, where to find files and stuff (the build folder only contains binary files, I didn't find the data/carparts folder at first). Maybe you will like to test the checkinstall utility for building DEB packages, as it's very wizzard-like.

Maybe I could help building the debhelper version too if you could help finding where some files go when installing: where does the documentation files go?

3) Ok, I just found that the tools folder contains Deb packaging files from 2006.
I'll try to see if I can figure something out of it (although old I hope most of the info is still valid).
Find all posts by this user
Quote this message in a reply
06-27-2009, 06:11 AM
Post: #10
 
UPDATE: DEBFILES, a gobal variable array which tracks where each file in the package should go, would be highly distribution dependant, meaning that the documentation would go into some folder for Debian distributions and in another folder for other distributions, so if Fedora people decide they want to build RPMs with SCons they would also need to make some kind of RPMFILES or FedoraFILES.

Suddenly it doesn't sound like a good idea. What do you think?
Find all posts by this user
Quote this message in a reply
06-27-2009, 06:36 AM
Post: #11
 
You'd want to build your file list using globbing...
Find all posts by this user
Quote this message in a reply
06-27-2009, 10:55 AM
Post: #12
 
You mean global variables? Isn't it a better idea to add this list into the env global variable?
Could this be another SCons target (more or less in the official scons build script)?
Find all posts by this user
Quote this message in a reply
06-27-2009, 09:10 PM
Post: #13
 
No, file globbing.... I'm sure python has utilities somewhere for building lists from glob patterns, I'm just not sure where (Perl junkie here :rollSmile
Actually now that I'm looking I can find anything for recursive matching which is why you'd want.

But yeah, you've certainly put your thumb on why having one packaging script for all distributions rarely works properly (and why most projects are happy to let the distro vendor do the packaging).
Find all posts by this user
Quote this message in a reply
06-28-2009, 03:10 AM
Post: #14
 
I Found out about file globbing In order to view links, you must have to reply to this thread. - it seems to be somewhere in between RegExp ([a-z][0-9]+) and wildcard search (*, ?)

I'm trying to become an Ubuntu maintainer btw, so you can still say the distro vendor does the packaging.
Find all posts by this user
Quote this message in a reply
06-28-2009, 01:30 PM
Post: #15
 
It would be nice to have a generic autopackage (or some other simple installer system) binary available from the VDrift site that would work with many different distributions (in addition to the packages that the distro maintainers make). I see a lot of forum posts from folks who have problems with their distribution's binary (or it's out of date) and would like to try the latest release without having to compile it themselves.
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 2 Guest(s)