bitshuffler

Congrats Fedora 12 not building is due to some hickup in OBS which enabled the debug packages 2 times. I disabled building them so it should build them only once (yes, I know this sounds stupid) so it should be fine. I had a similar issue with Code::Blocks in the past which was due to wx* being build with incompatible flags (some unicode issue iirc) with the version they got used with. AFAIK Fedora 13 enables their testing repos by default so it might be some packaging bug - if it isn't they would have to rebuild all of their packages using it so perhaps a bugreport might make sense since even Fedora should respect ABI compatibility within the same release. Besides that, is it ok with you if I remove the home:bitshuffler:0ad:Ubuntu repo and you build Ubuntu builds in some PPA?

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? That's pretty awesome, I had never thought it would work from some live cd. That is added (albeight it worked fine on openSUSE 11.2 so it might be Debian specific). Patch is added. 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) 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/

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

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).

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 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. 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. 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. 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).

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

Thanks for patching it You are right, adding binutils-static for Fedora 13 fixes it. Lets see what they'll do for Fedora 14. 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. 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.

Heh, that overlapped This looks good, thanks for that change Great, I missed the 3rd one.

Great 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? 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? 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

First of all thanks a lot for your response 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. Totally understandable that you don't want to tamper with it then. 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 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. This worked pretty fine afaik, thanks for the hint. 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

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).

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