0 A.D. Packages

[bitshuffler]

Hi guys.

I read about your game some months ago and thought it were marvelous to have same interesting and even good looking RTS for linux so I now gave it a try to create some installable packages by using the OBS.

The results can be seen here. Basically it currently compiles for recent openSUSE versions, and Fedora 12. Fedora 13 and Mandriva are possible too but need some more love. Also packaging can be done for Debian and Ubuntu (one just has to create .deb packaging files).

To install it now select the proper subdirectory from here.

NOTE: I did NOT include the data to spare our mirrors the traffic so you simply have to put it bellow %{_libexecdir}/0ad/data (normally /usr/lib/0ad/data) so it is available from %{_libexecdir}/0ad/bin via ../data.

Also note that it is untested. But it is a debug build so your findings should be helpful.

@The devs:

1. I certainly love you for creating an interesting and nicely looking RTS, thanks for that.

But there are - currently - some short comings which I would like to bring to your attention:

2. You don't adhere to FHS which is plain bad.

Try to put the binary into /usr/bin, the libs into /usr/lib[64] and the data should go into /usr/share/data/0ad.

I'm happy to pass all those directories as arguments so if you respect those instead of hardcoding e.g. ../data I would be happy.

3. You don't give me any way to manipulate the compile flags (or at least I'm not sure how far a "export CPPFLAGS="%{optflags}"" prior to build/workspaces/update-workspaces.sh and make is respected.

Point being all the distros have their unique set of $RPM_OPT_FLAGS with which they compile their stuff so I would like to use said flags for compiling your game too (e.g. the openSUSE 11.2 ones are "-O2 -g -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables").

4. Your build log isn't really verbose - read as "doesn't tell a thing quite some times". Please give me an option to turn it verbose so it shows all run lines.

5. You are missing some make install command like "make install DESTDIR=$foo" - given with those 4 files it certainly is no biggie.

6. Your build system is a mess - please consider switching to autotools / configure or (prolly better for you) use cmake since it works cross plattform. Point just being that it would be much easier to properly package it when you use common standards instead of custom scripts.

Now why I am posting here? Because first I like the game and second I would like to give you the opportunity to easily distribute the game to your fans by using the openSUSE Build Service which allows you to build for CentOS, Debian, Fedora, Mandriva, openSUSE, RHEL, SLE, Ubuntu or even allows you to create your own LiveCD based on some of the former. So please be so kind to consider using OBS (I'm totally happy to work with you together) to make it easily installable and not only profit by a bigger user base that can test your work but also by automated code checks that prevent common errors. E.g. it would allow you to try builds in private via local builds and then release more often "approved" versions to the public from which you know that they compile and get more feedback from people by making it easier to install those.

If you have any questions I'll be more than happy to answer them

Thanks a lot for your time and once again for developing it,

Stephan

[bitshuffler]

ADD 1: Once the compilation failures for Fedora 13 and Mandriva are fixed and or even Debian / Ubuntu stuff got added it certainly could also provide SVN snapshots once in a while (read as ~weekly, depending on the load).

[Ykkrosh]

Thanks for this! OBS definitely looks like a useful service - if it's easy to use and maintain then I think it'd be great if we could use it to provide binary packages, and I'd be interested in getting that set up. (Currently we just have these, and the Ubuntu one is hosted on a site that doesn't seem to be very stable.)

Your build system is a mess - please consider switching to autotools / configure or (prolly better for you) use cmake since it works cross plattform.

I agree this is a pain, and it causes most of the other issues. The problem has always been that we don't have people with much expertise in build systems, and we have limited time which is usually better spent on writing the game than on rewriting the build system. (The current system works well enough for active developers, even if it's a bit rubbish for users and distro packages.)

Various people have suggested changes (particularly switching to CMake), and we've thought about smaller changes (moving from Premake 3.x to Premake 4.x), but nobody has taken the initiative and stuck at it long enough to get it basically working. I'm happy to discuss what's required, and to finish and adopt and maintain a new build system that works better than the current one - I just don't want to have to write the initial version myself, and don't want to spend much time on it until it's a clear improvement over the current system. It seems most people agree CMake is the least-bad option and I think I'm willing to go with that, but we need someone to get it all running properly.

I'm happy to pass all those directories as arguments so if you respect those instead of hardcoding e.g. ../data I would be happy.

We can easily change source/ps/GameSetup/Paths.cpp to initialise m_rdata from an externally-defined macro instead of the default ../data. Is there a standard name for a macro like that?

I'm not sure how far a "export CPPFLAGS="%{optflags}"" prior to build/workspaces/update-workspaces.sh and make is respected

The only thing that takes effect is setting CFLAGS before make.

Your build log isn't really verbose - read as "doesn't tell a thing quite some times". Please give me an option to turn it verbose so it shows all run lines.

Run "./update-workspaces.sh --verbose" and then make will print all the commands.

[bitshuffler]

First of all thanks a lot for your response

Thanks for this! OBS definitely looks like a useful service - if it's easy to use and maintain then I think it'd be great if we could use it to provide binary packages, and I'd be interested in getting that set up. (Currently we just have these, and the Ubuntu one is hosted on a site that doesn't seem to be very stable.)

If you run some linux distro we provide packages for it actually isn't harder than using basic svn ;D

First of all you have to go to the openSUSE:Tools repository and add the proper subdirectory as a repo (osc is just some python script but build et al require more magic so if there aren't proper builds for you perhaps running them in some VM is the easiest - given, building in a VM sucks speedwise).

Then it goes like this:

1. follow the openSUSE Build Service Tutorial to create an account and activate your home repository.

Don't worry when you get redirected to some novell.com site. This happens because openSUSE uses Novells iChain as SSO.

2. Install "osc" from the openSUSE:Tools repository.

3. Check out the current state from the "home:bitshuffler:0ad" project:

osc co home:bitshuffler:0ad 0ad

4. cd into the newly created subdirectory

5. now do a local build (don't worry, it will create a chroot so your system wont get poluted) - e.g.

for openSUSE 11.2:

osc build openSUSE_11.2 0ad.spec

or Mandriva 2010:

osc build Mandriva_2010 0ad.spec

or Fedora 12:

osc build Fedora_12 0ad.spec

(I think you got the basic idea by now ;D)

lean back and wait while it downloads the required dependencies. Once it is done it will ask you for your root password to create the chroot and start the build. If you don't want to enter that password all the time then simply enable "su-wrapper = sudo" in your ~/.oscrc and add "$your_login ALL = NOPASSWD: /usr/bin/build" to your "/etc/sudoers" file - do yourself a favor and use "visudo" to do that since it will prevent you from doing any typos.

Once that is done it should be building the stuff in your system within a chroot.

If you want to submit some fixes to the current content please see this. Basically you just do a "osc branch ..." before the checkout and later do a "osc sr ..." to submit your fixes ("osc --help" and "osc $command --help" is your friend" ). Once you know what you are doing I'm also certainly more than happy to add you as maintainers so you can directly fix / update it instead of having to create submit requests.

If you run into any problems please don't hesitate to contact me or even better simply ask via IRC in #opensuse-buildservice on irc.freenode.net. All the guys there will be happy to give you a hand.

Also I would like to ask you to have a look at the build logs, which can be viewn here to see if you know how to fix the currently failing stuff - e.g. Mandriva has some problem finding the wxWidgets stuff (it is installed). If you need more log than what is shown on the first click just click on the "Download raw logfile" link to get the complete one.

I agree this is a pain, and it causes most of the other issues. The problem has always been that we don't have people with much expertise in build systems, and we have limited time which is usually better spent on writing the game than on rewriting the build system. (The current system works well enough for active developers, even if it's a bit rubbish for users and distro packages.)

Totally understandable that you don't want to tamper with it then.

Various people have suggested changes (particularly switching to CMake), and we've thought about smaller changes (moving from Premake 3.x to Premake 4.x), but nobody has taken the initiative and stuck at it long enough to get it basically working. I'm happy to discuss what's required, and to finish and adopt and maintain a new build system that works better than the current one - I just don't want to have to write the initial version myself, and don't want to spend much time on it until it's a clear improvement over the current system. It seems most people agree CMake is the least-bad option and I think I'm willing to go with that, but we need someone to get it all running properly.

I'm sorry, but I'm prolly the wrong person for this. I barely know enough about CMake to fix some broken builds - personally I'm a Java guy so I fight with Maven ;D

We can easily change source/ps/GameSetup/Paths.cpp to initialise m_rdata from an externally-defined macro instead of the default ../data. Is there a standard name for a macro like that?

I'm not sure if I got you right here. I don't know if there are some macros to ask about the installed path but e.g. I would happily pass those as build arguments to some of your scripts - e.g. with autotools / configure we have stuff like --bindir=/usr/bin, --datadir=/usr/share, --libdir=/usr/lib64 and so on. So if you allow me to pass the path where binaries, libraries and data will be installed to one of your build scripts and thereby allow me to make it FHS conform I am happy - but I don't know how to do that actually within your build environment.

The only thing that takes effect is setting CFLAGS before make.

This worked pretty fine afaik, thanks for the hint.

Run "./update-workspaces.sh --verbose" and then make will print all the commands.

This also worked pretty good, the only "silent" thingy is the "FCollada" stuff. Any way to make this more verbose too?

E.g our automatic code checks currently come up with the following:

I: Program is using implicit definitions of  functions getting
   pointers or implemented by macros. These functions need to use their
   correct prototypes to allow correct argument passing on e.g. x86_64 .
     - Implicit memory/string functions need #include <string.h>.
     - Implicit *printf functions need #include <stdio.h>.
     - Implicit *printf functions need #include <stdio.h>.
     - Implicit *read* functions need #include <unistd.h>.
     - Implicit *recv* functions need #include <sys/socket.h>.
W: 0ad implicit-pointer-decl platform_posix.c:94

I: Program causes undefined operation
   (likely same variable used twiceand post/pre incremented in the same  expression).
   e.g. x = x++; Split it in two operations.
W: 0ad sequence-point path.c:243

I: Program returns random data in a function
E: 0ad no-return-in-nonvoid-function vs.c:180

I: Program returns random data in a function
E: 0ad no-return-in-nonvoid-function vs.c:180

The last one is prolly missing some "void" as return statement, the one before prolly should be split up into more lines since "foo = ++foo" is undefined (as said, I'm a java guy so .... ;D) and so on.

Point just being, IMHO you would profit from those checks just to prevent any obvious flaws, you were able to provide binary (as in easily installable) builds to the majority of linux users which then would result in more people testing and enjoying your creation and so on. OTOH it stands and falls with you (the developers) being willing to deal with build issues which means you have to dig through the logs of failed builds and fix the warnings for the automatic code checks.

Bottomline, I happily help you out as much as I can since I love what you created but it only happens if you look after it yourself too e.g. by trying to fix currently broken builds.

As said, for any questions just ask me or join #opensuse-buildservice via IRC on freenode.

Thanks for sticking with me

[Ykkrosh]

If you run some linux distro we provide packages for it actually isn't harder than using basic svn ;D

I'm using Gentoo so it seems a little harder since there's no standard packages for the OBS tools, but not too hard . Thanks for your instructions - I got it to do the openSUSE_11.2 local build and that all seemed to work as it should, which is nice! Haven't had time to look in much detail yet, but it seems good so far.

Mandriva has some problem finding the wxWidgets stuff (it is installed)

It looks like it's only got the ANSI build, and we need the Unicode build. Might it work better if some libwxgtku2.8 packages are added as dependencies?

the only "silent" thingy is the "FCollada" stuff. Any way to make this more verbose too?

The only way is modifying libraries/fcollada/src/Makefile and remove the "@" before some of the commands. (That's a third-party library (bundled with our code because it's slightly modified, and abandoned upstream) which originally did something extremely complex and broken using SCons, so this was just a quick ugly inflexible Makefile to get it to compile. It probably could do with rewriting.)

The last one is prolly missing some "void" as return statement, the one before prolly should be split up into more lines since "foo = ++foo" is undefined

Those are bugs in the old version of the Premake build tool we use, which by default seems to get compiled with most warnings disabled - we already try to enable all the useful diagnostics for our own code to avoid similar problems. Anyway, fixed in r7755 (though I'm not sure how to apply that patch to the code OBS compiles).

[Ykkrosh]

I've committed some changes that let you specify directories:

./update-workspaces.sh --bindir /usr/games/bin --datadir /usr/share/games/0ad --libdir /usr/games/lib

Then it'll look for files like /usr/share/games/0ad/mods/..., /usr/games/lib/libAtlasUI(_dbg).so, etc. Is that enough to work?

Also r7757 fixes the printf bugs.

[bitshuffler]

I'm using Gentoo so it seems a little harder since there's no standard packages for the OBS tools, but not too hard . Thanks for your instructions - I got it to do the openSUSE_11.2 local build and that all seemed to work as it should, which is nice! Haven't had time to look in much detail yet, but it seems good so far.

Great

It looks like it's only got the ANSI build, and we need the Unicode build. Might it work better if some libwxgtku2.8 packages are added as dependencies?

You are right, explicitly using libwxgtku2.8-devel instead of wxGTK-devel fixed it. Thanks for the hint. Now only Fedora 13 fails because you link against /usr/lib[64]/libbfd.a which doesn't exist anymore on Fedora 13. Could you simply link against libbfd.so instead since that exists everywhere?

The only way is modifying libraries/fcollada/src/Makefile and remove the "@" before some of the commands. (That's a third-party library (bundled with our code because it's slightly modified, and abandoned upstream) which originally did something extremely complex and broken using SCons, so this was just a quick ugly inflexible Makefile to get it to compile. It probably could do with rewriting.)

Thanks for the pointer, this patch makes it verbose and adds a $(CPPFLAGS) variable that allows me to specify wanted %{optflags}. This patch fixes some "error: format not a string literal and no format arguments" found by compiling the verbose version for Mandriva. Could you please be so kind to review them both and apply them to trunk?

Those are bugs in the old version of the Premake build tool we use, which by default seems to get compiled with most warnings disabled - we already try to enable all the useful diagnostics for our own code to avoid similar problems. Anyway, fixed in r7755 (though I'm not sure how to apply that patch to the code OBS compiles).

Thanks for that, your changes fix those errors. Applying a patch is pretty easy, you simply list it with "PatchX: foo.patch" in the header and then apply it in the %pre section by doing "%patchX". Just have a look at the spec file, it currently uses 3 patches.

I try to add Debian and Ubuntu builds too once I find some time and am happy to try any suggested fix for compiling on Fedora 13. Also it can easily be updated to a newer svn version, I'm just unsure if that would be recommended or not. Just let me know or create a submit request

[bitshuffler]

Heh, that overlapped

I've committed some changes that let you specify directories:

./update-workspaces.sh --bindir /usr/games/bin --datadir /usr/share/games/0ad --libdir /usr/games/lib

Then it'll look for files like /usr/share/games/0ad/mods/..., /usr/games/lib/libAtlasUI(_dbg).so, etc. Is that enough to work?

This looks good, thanks for that change

Also r7757 fixes the printf bugs.

Great, I missed the 3rd one.

[Ykkrosh]

Thanks for your work on this!

Patched that Makefile.

Now only Fedora 13 fails because you link against /usr/lib[64]/libbfd.a which doesn't exist anymore on Fedora 13. Could you simply link against libbfd.so instead since that exists everywhere?

We just link with "-lbfd", which I would have imagined ought to be the right thing to do. Per this bug, it sounds like binutils-static is needed in order to make libbfd.so actually work.

I try to add Debian and Ubuntu builds too once I find some time and am happy to try any suggested fix for compiling on Fedora 13.

There's already an Ubuntu package from PlayDeb around here, which hopefully does most of the work that's needed. It probably would be good if we could build packages ourselves (via OBS) without relying on them to do all the work, so that we can push updates quicker, if it's not too hard to get that working.

Also it can easily be updated to a newer svn version, I'm just unsure if that would be recommended or not. Just let me know or create a submit request

It's probably safest to stick with the current release tarball plus patches, since SVN may be unstable and the release isn't too old yet.

[bitshuffler]

Thanks for your work on this!

Patched that Makefile.

Thanks for patching it

We just link with "-lbfd", which I would have imagined ought to be the right thing to do. Per this bug, it sounds like binutils-static is needed in order to make libbfd.so actually work.

You are right, adding binutils-static for Fedora 13 fixes it. Lets see what they'll do for Fedora 14.

There's already an Ubuntu package from PlayDeb around here, which hopefully does most of the work that's needed. It probably would be good if we could build packages ourselves (via OBS) without relying on them to do all the work, so that we can push updates quicker, if it's not too hard to get that working.

Thanks to the current tropical nights when you can't sleep anyways I tried those but it didn't work out so well so I just reused some other deb packaging files I had laying around. I don't know much about packaging debs but at least they contain the proper files .

(for the record, I had to repackage the source archive to tar.gz since Debian can't handle tar.bz2)

The current state is that it builds for Debian 5.0 but for Ubuntu it requires loads of stuff from their Universe repo. I imported those but most fail - see here for details. All those packages are cleanly imported from Ubuntu so it is a bit beyond me why they don't build and I am not really inclined to hunt the errors down since I neither use it nor really have the time for this. Perhaps someone else creating some PPA would be better but I am certainly open to try any suggested fixes.

It's probably safest to stick with the current release tarball plus patches, since SVN may be unstable and the release isn't too old yet.

That's fine with me. Just give me a note when it should get updated to a new revision (and what revision) or do it yourself and send a submit request.

[Ykkrosh]

I experimented here and got it to apparently work on Ubuntu (by changing some dependencies to non-universe versions, disabling the map editor and associated dependencies, and adding the three that were still needed). Now it's broken on Debian and probably other versions of Ubuntu (I guess I need to learn how to write packages properly, so that it uses the right dependencies everywhere) but it looks like it should be possible to get this working nicely with some more time.

[bitshuffler]

I experimented here and got it to apparently work on Ubuntu (by changing some dependencies to non-universe versions, disabling the map editor and associated dependencies, and adding the three that were still needed). Now it's broken on Debian and probably other versions of Ubuntu (I guess I need to learn how to write packages properly, so that it uses the right dependencies everywhere) but it looks like it should be possible to get this working nicely with some more time.

Genius! It seems like I imported the wrong openal package and that made it fail. I set up home:bitshuffler:0ad:Ubuntu which builds 0ad with your changes for Ubuntu 9.10 & 10.04. Also I added you as maintainer there so feel free to poke it as you like (please delete your old repo if you don't need it anymore so it doesn't waste resources).

It still is very "hackish" since it requires stuff like "Build-Depends: libboost-signals1.38-dev | libboost-signals1.40-dev" but afaik there is no way around since the Ubuntu guys told me the proper meta package is in the universe repo for somce reason and OBS doesn't provide Universe for legal reasons so we prolly have to live with it.

From my POV I certainly would like to "unify" those builds so all the stuff gets properly build but OTOH it then would require more deps from Universe which are a PITA to import. Until that is fixed please keep in mind that the current Ubuntu packages just are a patch against the "full builds" so changing something in the later might screw up the former.

To make it short, thanks a lot for your work and feel free to play around with it as you like. Personally I have to think if there is a way to "unify" those builds but I somehow doubt that since there is no way on Debian to use some %if distro_version = foo $doo_bla %endif like there is on rpm based systems (e.g. to disable the libAtlasUI_dbg build only for Ubuntu) so we have to life with the 2 repo setup until we manage to import the required stuff for Ubuntu.

Once again thank you very much for your interest, it certainly isn't that natural for Upstream / Developers caring about packaging so it certainly is very appreciated

I try to look into it but if you need anything in the meantime just let me know

[Ykkrosh]

it certainly isn't that natural for Upstream / Developers caring about packaging so it certainly is very appreciated

It's fun to play with and it provides a helpful distraction from the writing that I'm meant to be doing

Build-Depends: libboost-signals1.38-dev | libboost-signals1.40-dev

Hmm... Won't this potentially cause dependency problems for users? They might already have the default Boost but the game might be compiled with a different version (since there's more than one available, at least if you include Universe), so they'd need two versions of Boost installed (or it'll link against an incorrect version). Then again, I suppose it should be okay when Universe versions of Boost are excluded, at least with Ubuntu's current arrangement of packages, but that doesn't seem like much of a guarantee.

Hmm... In any case, won't the importing of other Universe packages into OBS cause problems? It's only importing a single version of the package, so it can't possibly match all the packages provided by multiple versions of Ubuntu, so there's going to be conflicts.

Unless I'm missing something, this seems like a very dodgy way to generate Ubuntu packages. Maybe we should stick with OBS for non-Ubuntu distros (where it works without these hacks) but use something else (PPA?) for Ubuntu? Hopefully then we wouldn't have to be fighting against the system

A few random questions:

Is it conventional to run automated tests as part of the build process? (We have some if you run "./test_dbg" from binaries/system/ after compiling, though I'm not sure how it'll react with --libdir/--datadir builds.)

Presumably we should add an architecture-independent "0ad-data" package (and mark it as a runtime dependency of the architecture-dependent packages). Is there a good way to do that? (I guess OBS shouldn't be necessary since we aren't actually compiling anything?)

If we want to distribute the packages to users, should we (and can we) host the package files ourselves, rather than relying on download.opensuse.org? particularly when it includes ~100MB 0ad-data packages (it's probably not fair to stress openSUSE's mirrors with that)?

[bitshuffler]

Hmm... Won't this potentially cause dependency problems for users? They might already have the default Boost but the game might be compiled with a different version (since there's more than one available, at least if you include Universe), so they'd need two versions of Boost installed (or it'll link against an incorrect version). Then again, I suppose it should be okay when Universe versions of Boost are excluded, at least with Ubuntu's current arrangement of packages, but that doesn't seem like much of a guarantee.

The reason for having to explicitly name the version is that while they have a "libboost-dev" package their -signals and -filesystem ones are explicitly numbered for whatever reason (Ubuntu devs weren't able to explain it themself) which is, IMHO, a packaging bug on their side. (If I got them right there's a meta package that does the proper link in the Universe repo but since we can't use Universe besides explicitly importing a package into OBS ...). What that line does it trying to resolve deps by taking the first matching package (libboost-signals1.38-dev on 9.10 and libboost-signals1.40-dev 10.04) that comes from their respective main (as in non Multi-, Uni-, Whateververse) which is proper and doesn't create any problems as long as all their packages comply to common "packaging shared libs" rules (as in putting the stuff in /usr/lib with its full soname) so installing multiple versions in parallel is no problem and the one the binary needs is resolved at the end of the build.

To see what packages are available simply do for 9.10:

osc ls -b Ubuntu:9.10 -r standard -a i586 | grep boost

and for 10.04

osc ls -b Ubuntu:10.04 -r standard -a i586 | grep boost

Hmm... In any case, won't the importing of other Universe packages into OBS cause problems? It's only importing a single version of the package, so it can't possibly match all the packages provided by multiple versions of Ubuntu, so there's going to be conflicts.

It takes the imported source and builds packages from it for the specified Ubuntu versions so it should be pretty much the same as their PPA thingy does. Also it shouldn't trigger any conflicts if their packages comply to said shared libs packaging policies.

Unless I'm missing something, this seems like a very dodgy way to generate Ubuntu packages. Maybe we should stick with OBS for non-Ubuntu distros (where it works without these hacks) but use something else (PPA?) for Ubuntu? Hopefully then we wouldn't have to be fighting against the system

I think you misunderstood something here since I wouldn't call it "dodgy" in any way cause it is precisely what their PPA stuff does if I'm not mistaken. However, in consideration of the fact that importing some of the required stuff into OBS seems to be a PITA (don't ask me why) I have to agree that for creating complete packages (as in with the stuff we currently disabled for Ubuntu) you prolly are better of with PPA.

Is it conventional to run automated tests as part of the build process? (We have some if you run "./test_dbg" from binaries/system/ after compiling, though I'm not sure how it'll react with --libdir/--datadir builds.)

Yes, this is good practice but I currently disabled them cause they did fail. To see what I mean simply uncomment line 102 & 103 in the %check section in the 0ad.spec file and do a local build. Also installing ActorEditor_dbg & ColourTester_dbg made the build fail for some reason - iirc the code checks had some problem with those but I'm not sure atm.

Presumably we should add an architecture-independent "0ad-data" package (and mark it as a runtime dependency of the architecture-dependent packages). Is there a good way to do that? (I guess OBS shouldn't be necessary since we aren't actually compiling anything?)

If we want to distribute the packages to users, should we (and can we) host the package files ourselves, rather than relying on download.opensuse.org? particularly when it includes ~100MB 0ad-data packages (it's probably not fair to stress openSUSE's mirrors with that)?

I talked to the OBS guys and actually we already have quite some game data files on it that make your 100MB look pretty small so I'm gonna create and add it when I find some time (basically you prolly just have to extract the -data package and move its content into /usr/share/0ad).

[Ykkrosh]

It takes the imported source and builds packages from it for the specified Ubuntu versions so it should be pretty much the same as their PPA thingy does. Also it shouldn't trigger any conflicts if their packages comply to said shared libs packaging policies.

My current understanding is: In here you imported openal-soft 1.12.854. A typical Ubuntu user will have already installed the universe package based on openal-soft 1.11.753. That means either the game will be compiled against 1.12 but dynamically linked against 1.11 (which is bad since libraries are often not compatible in that direction); or the user will have to install both 1.12 and 1.11 versions of the same package (which is bad since they'll duplicate code and fight over the same config files etc). If you imported 1.11 into OBS instead, it would break for Karmic users with 1.8, so that wouldn't fix the problems.

It seems like the proper solution is that the 0ad package for Ubuntu version N should be compiled against exactly the same library package versions supplied by the normal (universe) repositories for version N, and anything else is liable to cause trouble, but OBS doesn't provide a good way to do that.

Am I mistaken somewhere here?

[bitshuffler]

Am I mistaken somewhere here?

As long as upstream does its job by changing the soname as soon as they break ABI compatibility it isn't a problem since all the different versioned packages containing the same libraries / files are exchangeable because their ABI is compatible.

Also, if the ABI changes and therefore the soname increases it doesn't matter because the library file names now are different and therefore wont conflict anymore (e.g. libopenal1.x vs libopenal2.x or so). But as long as the library package is called e.g. libopenal1 it must contain only libopenal1.x stuff which is exchangeable with any other package containing libopenal1.x. The reason I took the newest version is that I thought they had a reason for increasing the version - e.g. some bug fixes.

Further you surely can build different package versions for different Ubuntu versions by simply importing them under a different package name and only enabling them for the desired Ubuntu version. But IMHO it isn't worth the work and instead trusting upstream when their packages are exchangeable and when not is the better solution (until they screw it up and break the ABI without increasing the soname).

[bitshuffler]

FWIW, I added data packages to home:bitshuffler:0ad which should work but are untested (as in they work on openSUSE 11.2 but I have no other sys around).

Feedback is welcome

Edited July 22, 2010 by bitshuffler

[Ykkrosh]

I don't have any of the systems to test on - is anyone else around here able to try them out and report (hopefully) success?

As long as upstream does its job by changing the soname as soon as they break ABI compatibility it isn't a problem since all the different versioned packages containing the same libraries / files are exchangeable because their ABI is compatible.

I'm not sure that's true - e.g. this says

There are cases where the SONAME does not have to change when the source code changed. For example, when a new function symbol is introduced and existing symbols are not modified, it is a backward-compatible change. Old programs linked to the library will work with the new library. New programs compiled against the new library will not work with the old library, so this needs to be noted in the shared library dependency.

i.e. binary compatibility is only guaranteed in one direction, not in the direction that these packages would make us rely on.

[Ykkrosh]

I don't have any of the systems to test on

...but I can run their Live CDs in a VM easily enough. Tried the Debian one and found a few issues:

* Gamin (or FAM) needs to be added as a runtime dependency.

* Running pyrogenesis_dbg from $PATH doesn't work - our code wants to find the absolute path to the executable but isn't smart/crazy enough to search through $PATH. Running "/usr/bin/pyrogenesis_dbg" works better. (At least it works as far as failing to set up OpenGL; r7791 may help there.)

* It'd be better to run the game from a "0ad" command, since that's the name of the game. That could be a script that calls /usr/bin/pyrogenesis_dbg, perhaps. (Also adding icons into the Programs menu would be good.)

I'll see if I can fix some of these myself tonight, and test the other packages too.

[Ykkrosh]

(Changes here (it looks like I don't have permission to edit the original, only the :Ubuntu subproject, so I had to branch it again) - now it works in VMware which makes it much easier to test.)

[bitshuffler]

i.e. binary compatibility is only guaranteed in one direction, not in the direction that these packages would make us rely on.

Precisely, which is why it shouldn't create any problems when they get a newer lib from "our" repo than what is available from their Universe repo, not?

but I can run their Live CDs in a VM easily enough. Tried the Debian one and found a few issues:

That's pretty awesome, I had never thought it would work from some live cd.

Gamin (or FAM) needs to be added as a runtime dependency.

That is added (albeight it worked fine on openSUSE 11.2 so it might be Debian specific).

Running pyrogenesis_dbg from $PATH doesn't work - our code wants to find the absolute path to the executable but isn't smart/crazy enough to search through $PATH. Running "/usr/bin/pyrogenesis_dbg" works better. (At least it works as far as failing to set up OpenGL; r7791 may help there.)

Patch is added.

It'd be better to run the game from a "0ad" command, since that's the name of the game. That could be a script that calls /usr/bin/pyrogenesis_dbg, perhaps. (Also adding icons into the Programs menu would be good.)

I added a 0ad sym link but please add some .desktop file and an icon in your source (perhaps steal it from the other debian package since it has some ;D) so it gets a proper menu entry. (Albeight I am wondering why you call the binary pyrogenesis in the first case ;P)

(Changes here (it looks like I don't have permission to edit the original, only the :Ubuntu subproject, so I had to branch it again) - now it works in VMware which makes it much easier to test.)

I moved the stuff from my "home" repo to our more "official" "games" repo and added you as maintainer there so you should be free to poke it as you like.

The :Ubuntu repo is now linked against the games repo so it should pick up any changes but, considering the troubles needed to build the currently missing binaries, it is prolly better if you use some PPA for those (just be so kind to keep the packages in sync so the work doesn't duplicate )

The old packages will get removed, if you are looking for some binary repo please subscribe to the proper subdirectory of http://download.opensuse.org/repositories/games/

[Ykkrosh]

Precisely, which is why it shouldn't create any problems when they get a newer lib from "our" repo than what is available from their Universe repo, not?

Hmm, so they would overwrite their normal standard openal-soft (etc) with the newer version from OBS? It seems kind of rude to do that - the users just want to install a game, they don't want to unnecessarily upgrade some library packages used by other applications too. Also I don't want us to have the responsibility of checking for compatibility problems in those new packages, updating when there's security bugs, etc, so I don't think we should replace packages that are already being maintained by other people (even if all we're doing is copying their code and recompiling).

I added a 0ad sym link but please add some .desktop file and an icon in your source (perhaps steal it from the other debian package since it has some ;D) so it gets a proper menu entry.

Will do so.

(Albeight I am wondering why you call the binary pyrogenesis in the first case ;P)

The original reason was that you could change the game into a whole new game just by modifying data files, so the binary executable is the generic engine (Pyrogenesis) and not the game (0 A.D.). But making one game is already way too much work, so I don't think we'll start a second any time soon . But it seems like we currently need a shell script anyway to avoid PATH problems (at least until the engine's fixed), so I'm not sure if there's a better approach than using "0ad" for the script and "pyrogenesis" for the executable.

I moved the stuff from my "home" repo to our more "official" "games" repo and added you as maintainer there so you should be free to poke it as you like.

Thanks! I've added some instructions here pointing to the new repository - just need to test them all to make sure they actually work

[Ykkrosh]

Hmm, so I almost got the tests to work. The only apparent problem is it randomly fails half the time due to some issues in our CPU-detection code (presumably interacting badly with the build VM). I like having tests so I'll try to get that fixed soonish.

[Ykkrosh]

I like having tests

...and now I feel justified in spending so much effort on it, since it found an actual bug (in the ancient version of glibc used by Debian) (admittedly only triggered by code that we don't actually run in the game since it's been disabled for years). Anyway, looks like everything's back to building properly on all the platforms (except Fedora 12 for a reason I have no clue about), so that's nice.

[WhiteTreePaladin]

I want to like Fedora, but every release I've tried (10, 11, 12, 13) has always had something that didn't work correctly. Fedora releases expire so quickly, why is 12 even important?