Packaging Castle Engine for Debian

2013-04-26
2013-06-04
1 2 > >> (Page 1 of 2)
  • Abou Al Montacir

    Hi,

    I found that Castle Engine is a great project, based on FPC and supporting Lazarus. I'm thinking to package it for Debian.

    Cheers,

     
  • Michalis Kamburelis

    That would be great! I use Debian myself (usually Debian testing) for most of my work, so I have a special fondness for Debian packages. Having packages for Debian like "view3dscene" (to make http://castle-engine.sourceforge.net/view3dscene.php application easily available to users) and/or something like "fp-units-castle-game-engine" (with Castle Game Engine units compiled for current FPC version) would make me very happy :) Personally, I would focus on packaging view3dscene (as the Castle Game Engine is an engine for developers, and developers are probably more capable of installing the engine without Debian packages as well), but that's just my personal preference.

    Of course the goal would be eventually make these packages available in official Debian repositories. That would be fantastic.

    I would also like to have a way to build and release Debian packages from SVN sources, to be able to release Debian packages as file downloads on http://castle-engine.sourceforge.net/ . Just like FPC and Lazarus projects do --- you can grab their (sometimes a little outdated) versions from official Debian/Ubuntu repository, or you can download .debs for latest version from the sourceforge project space.

    The bottom of the http://castle-engine.sourceforge.net/forum.php page contains some notes addressed to "For Linux distros package maintainers", be sure to read them. We include stuff like desktop and mime files for view3dscene, and we document view3dscene dependencies, so packaging view3dscene should be easy, hopefully :)

    Please write if you have any particular questions. Once you have something ready, I would gladly like to add it to our SVN and test myself, and if you're interested in maintaining these packages long-term (hopefully:) I would be very happy to give you SVN commit access.

     
    • Abou Al Montacir

      On Fri, 2013-04-26 at 23:22 +0000, Michalis Kamburelis wrote:

      That would be great! I use Debian myself (usually Debian testing) for
      most of my work, so I have a special fondness for Debian packages.
      Having packages for Debian

      Nice to hear this!

      like "view3dscene" (to make
      http://castle-engine.sourceforge.net/view3dscene.php application
      easily available to users) and/or something like
      "fp-units-castle-game-engine" (with Castle Game Engine units compiled
      for current FPC version) would make me very happy :) Personally, I
      would focus on packaging view3dscene (as the Castle Game Engine is an
      engine for developers, and developers are probably more capable of
      installing the engine without Debian packages as well), but that's
      just my personal preference.

      We can have a unique source package with multiple packages or we can
      have multiple source packages with multiple packages each. This depends
      on the svn organization and the upstream (you) release cycle. If
      View3DScene is tightly linked to the Castle Engine, then it is probably
      better to have 1 source package. Just like FPC or Lazarus.

      Of course the goal would be eventually make these packages available
      in official Debian repositories. That would be fantastic.

      That is my goal too!

      I would also like to have a way to build and release Debian packages
      from SVN sources, to be able to release Debian packages as file
      downloads on http://castle-engine.sourceforge.net/ . Just like FPC and
      Lazarus projects do --- you can grab their (sometimes a little
      outdated) versions from official Debian/Ubuntu repository, or you can
      download .debs for latest version from the sourceforge project space.

      I'm Debian maintainer for FPC/Lazarus packages and also used to be a
      FPC/lazarus core member, but now only looking at Debian packages issue
      du to lack of time. So I'm familiar with packaging pascal sources into
      Debian. This basically a very easy step once we decided how to split
      packages.
      FPC/Lazarus used to be quite up to date with latest upstream release.
      However Wheezy is taking too long to get out and unstable is frozen in
      order to ensure non regression. This make me not able to upload new FPC
      release. Maybe I'll try to upload to experimental, so that developers
      can already test the new versions.

      The bottom of the http://castle-engine.sourceforge.net/forum.php page
      contains some notes addressed to "For Linux distros package
      maintainers", be sure to read them. We include stuff like desktop and
      mime files for view3dscene, and we document view3dscene dependencies,
      so packaging view3dscene should be easy, hopefully :)

      I'll have a look to these

      Please write if you have any particular questions. Once you have
      something ready, I would gladly like to add it to our SVN and test
      myself, and if you're interested in maintaining these packages
      long-term (hopefully:) I would be very happy to give you SVN commit
      access.

      I'll try to have something before next WE. I'll keep you in touch.

      There is a final question about licencing. While I'm used to source code
      licensing, I need to check Debian policy about the artistic files. Just
      to be sure the ITP (Intent to package) request does not get refused.

       
      • Michalis Kamburelis

        If View3DScene is tightly linked to the Castle Engine, then it is probably better to have 1 source package. Just like FPC or Lazarus.

        view3dscene is tightly linked to the Castle Game Engine. New releases of them are almost always done together --- new Castle Game Engine version, and new view3dscene version using new features of new engine.

        There is a final question about licencing. While I'm used to source code licensing, I need to check Debian policy about the artistic files.

        The engine code is available under the same license as FPC RTL and Lazarus LCL: LGPL (version 2 or later) with static linking exception, details on http://castle-engine.sourceforge.net/engine.php#section_license . The view3dscene (and other programs) is under stricter GPL (version 2 or later).

        The assets of view3dscene and castle_game_engine --- they are covered by the same licenses (we don't use separate licenses, like Creative Commons, for them). 3D models (.x3d, .x3dv, .wrl) files were either written by hand or exported from Blender, in the latter case the .blend versions are in the SVN repository alongside. Things like images and icons were made with GIMP or Inkspace, the source .xcf and .svg are also in the repository.

         
        • Abou Al Montacir

          Hi,

          I've finished packaging Castle Game Engine for Debian. The packaging
          sources are available at [1]. Any review is welcome. I'm going to upload
          it once FPC 2.6.2 is uploaded which I won't upload before 8 days, to
          allow 2.6.0-12 to rich testing. This delay could be used to improve
          Castle Game Engine packaging.

          Cheers,

          https://code.google.com/p/pascal-for-debian/source/browse/?repo=castle-game-engine

           
          • Michalis Kamburelis

            1. I browsed the files under https://code.google.com/p/pascal-for-debian/source/browse/?repo=castle-game-engine :

            - watch file: Not sure if this is correct, unless there are some magic rules about how Debian scripts process it. http://sf.net/castle-engine/ is not a URL that exists. Our project is under https://sourceforge.net/projects/castle-engine/ and files are under https://sourceforge.net/projects/castle-engine/files/ and castle-game-engine releases are under http://sourceforge.net/projects/castle-engine/files/castle_game_engine/castle_game_engine-*-src.zip/download

            - castle-game-engine-doc.doc-base : seems to contain text (at least Title, Abstract) from some other project :)

            - two patches in patches/: I applied both these changes to the trunk source code. "X" is indeed better than XWindows nowadays, and cleaning pasdoc output is now moved to "make cleanmore" instead of "make clean" (I don't really have a preference about it, my packing scripts use "make cleanmore", so we can adjust "make clean" to whatever is more comfortable for your packaging).

            2. Can you give me short instructions how to build the package? I understand I should download my original release, like castle_game_engine-4.0.1-src.tar.gz, rename it to follow Debian rules to castle-game-engine_4.0.1.orig.tar.gz, and alongside there should be directory with your debian/ subdirectory inside. Then I can run "debuild -us -uc". Of course I should install all build dependencies, like quilt and fpc (2.6.2 unless I hack the packaging scripts to be satisfied with 2.6.0).

            However, I can't seem to get it work, looks like I need to rename/move some directories to make it working. I tried various weird ways and it seems there is always some name that doesn't satisfy the "debuild". I'm sure this is trivial for you, if you could write a couple of lines how to do it myself I would be very grateful :)

            3. Would you like SVN commit access to our repository? Will it be useful for you to commit your debian/ files to our repository? I want to give you SVN access, unless you definitely want to keep your debian/ packaging in a separate repo :)

             
            • Abou Al Montacir

              On Thu, 2013-05-09 at 18:50 +0000, Michalis Kamburelis wrote:

              1. I browsed the files under
                https://code.google.com/p/pascal-for-debian/source/browse/?repo=castle-game-engine :
                Thanks,

              2. watch file: Not sure if this is correct, unless there are some magic
                rules about how Debian scripts process it.
                http://sf.net/castle-engine/ is not a URL that exists. Our project is
                under https://sourceforge.net/projects/castle-engine/ and files are
                under https://sourceforge.net/projects/castle-engine/files/ and
                castle-game-engine releases are under
                http://sourceforge.net/projects/castle-engine/files/castle_game_engine/castle_game_engine-*-src.zip/download
                I just copied FPC's one and updated it. This seems to work for both FPC
                and Lazarus, so I assume it will also work for Castle Game Engine

              3. castle-game-engine-doc.doc-base : seems to contain text (at least
                Title, Abstract) from some other project :)
                Sorry, that was copy/paste error, fixed

              4. two patches in patches/: I applied both these changes to the trunk
                source code. "X" is indeed better than XWindows nowadays, and cleaning
                pasdoc output is now moved to "make cleanmore" instead of "make
                clean" (I don't really have a preference about it, my packing scripts
                use "make cleanmore", so we can adjust "make clean" to whatever is
                more comfortable for your packaging).
                That should be fine, thanks.

              5. Can you give me short instructions how to build the package? I
                understand I should download my original release, like
                castle_game_engine-4.0.1-src.tar.gz, rename it to follow Debian rules
                to castle-game-engine_4.0.1.orig.tar.gz, and alongside there should be
                directory with your debian/ subdirectory inside. Then I can run
                "debuild -us -uc". Of course I should install all build dependencies,
                like quilt and fpc (2.6.2 unless I hack the packaging scripts to be
                satisfied with 2.6.0).
                You can not use FPC 2.6.0 because I use a new feature in 2.6.2, added
                specially for Castle Game Engine, which is relpath. Please look at
                debian/rules file to see what I'm doing.

              However, I can't seem to get it work, looks like I need to rename/move
              some directories to make it working. I tried various weird ways and it
              seems there is always some name that doesn't satisfy the "debuild".
              I'm sure this is trivial for you, if you could write a couple of lines
              how to do it myself I would be very grateful :)
              You need to unpack sources, copy the debian directory on the top level
              source directory and run it.

              I personally prefer using my own debbuild script, here attached. It will
              unpack sources and do everything.
              mkdir castle-game-engine
              cp <orig sources=""> castle-game-engine_4.0.1.orig.tar.gz
              debbuild DEB_DIR=debian MENTORS=1 DEB_BUILD_DIR=castle_game_engine 2>&1 | tee build.log

              You may want to add NO_SIGN=1 or provide KEY_ID

              1. Would you like SVN commit access to our repository? Will it be
                useful for you to commit your debian/ files to our repository? I want
                to give you SVN access, unless you definitely want to keep your
                debian/ packaging in a separate repo :)
                According to Debian policy it is better to have packaging sources
                outside the original VCS. However, in practice, most projects embed a
                copy of debian packaging scripts. This is the case of FPC and Lazarus. I
                used the convention of having -0 sub version in order to differenciate
                from official debian uploads which start at -1. Please feel free to
                embed a copy if you want to release with debian packages included. In
                this case please commit also the following patch.

              For svn access, I don't think I'll commit many things, but why not.

              Cheers,

               
  • Michalis Kamburelis

    You mention attachments, but it doesn't seem you attached anything. Attachments should work here, but sometimes SourceForge forums have hickups and things don't work as smoothly as they should... Could you attach the mentioned files again?

    Or, even better: I added you as a developer of our Castle Game Engine, you should now be able to checkout SVN with write access (https or svn+ssh, URLa are listed on "Code" tab). It would be great if you would commit the debian stuff and scripts yourself, in a way that is comfortable to you (and that will allow me to build deb packages in the future too). In general, feel free to commit (to trunk) whatever is necessary, and you're of course welcome to work on the core engine too.

    Many thanks for taking time to prepare them! I'm very happy that we have Debian packages :)

    And BTW, I hope you will consider packaging view3dscene as well :)

    Oh, note about /debian/watch: to be clear, zip and tar.gz versions of our engine releases are always absolutely equal, you can take whichever you want.

     
    • Abou Al Montacir

      On Sat, 2013-05-11 at 14:02 +0000, Michalis Kamburelis wrote:

      You mention attachments, but it doesn't seem you attached anything.
      Attachments should work here, but sometimes SourceForge forums have
      hickups and things don't work as smoothly as they should... Could you
      attach the mentioned files again?

      I'm cc-ing you so that you can get it for sure.

      Or, even better: I added you as a developer of our Castle Game Engine,
      you should now be able to checkout SVN with write access (https or svn
      +ssh, URLa are listed on "Code" tab). It would be great if you would
      commit the debian stuff and scripts yourself, in a way that is
      comfortable to you (and that will allow me to build deb packages in
      the future too). In general, feel free to commit (to trunk) whatever
      is necessary, and you're of course welcome to work on the core engine
      too.

      Last time I've tried to get a git svn copy but failed with out of disk
      space. I'll try to create a debian directory directly with remote svn
      operation and then git svn it as unfortunately I don't have big space
      left on my laptop :)

      Many thanks for taking time to prepare them! I'm very happy that we
      have Debian packages :)

      You're welcome. I'm really happy to see a so good game engine written in
      Pascal and thank you for this great work.

      And BTW, I hope you will consider packaging view3dscene as well :)

      I've started today, however I mainly work on Open Source project while
      I'm on the train, so expect more progress in working days, than in WE.
      The repository for view3dscene will be
      https://code.google.com/p/pascal-for-debian.view3dscene
      The reason for using a separate repo is that view3dscene is a separate
      source package and this will avoid dependency issues. Also it is advised
      that programs and development libraries get packages separately which is
      here our case. This is usually because one want to have multiple
      libraries version to be co-installed while prefers latest version for
      tools and applications.

      Oh, note about /debian/watch: to be clear, zip and tar.gz versions of
      our engine releases are always absolutely equal, you can take
      whichever you want.

      Debian perfers .tar.{gz,bz2,xz}

      Please note that I've uploaded FPC 2.6.2-1 to mentors
      http://mentors.debian.net/debian/pool/main/f/fpc/ where you can pick it
      and build it. I'll wait for fpc-2.6.0-12 and Lazarus-0.9.30.4-7 to be in
      testing before pushing to unstable. This will take a few days as I
      already said.

      Cheers

       
      • Abou Al Montacir

        On Sat, 2013-05-11 at 19:25 +0000, Abou Al Montacir wrote:

            And BTW, I hope you will consider packaging view3dscene as
            well :)
        

        I've started today, however I mainly work on Open Source project while
        I'm on the train, so expect more progress in working days, than in WE.
        The repository for view3dscene will be
        https://code.google.com/p/pascal-for-debian.view3dscene
        The reason for using a separate repo is that view3dscene is a separate
        source package and this will avoid dependency issues. Also it is
        advised
        that programs and development libraries get packages separately which
        is
        here our case. This is usually because one want to have multiple
        libraries version to be co-installed while prefers latest version for
        tools and applications.

        I've pushed everything, can you please review?

        Cheers,

         
        • Michalis Kamburelis

          I'm cc-ing you so that you can get it for sure.

          Thanks!

          Last time I've tried to get a git svn copy but failed with out of disk space.

          Yeah, we have a long history and a large repository. Initially grabbing it to a git repository using git-svn does take ages :) You can omit some subdirectories, e.g. possibly www/ and castle/ are not interesting for you. Subdirectories castle_game_engine/, view3dscene/ and demo_models/ are probably most interesting (the last one does weight a little, but it's worth it :).

          I've pushed everything, can you please review?

          I created a clone of your repo on https://code.google.com/r/michaliskambi-view3dscene-debian/ , I made some fixes changes that you can pull.

          Some notes / reasoning for my changes:

          1. I almost always used the lowercase name "view3dscene" to refer to this program. Sometimes eventually "View3DScene", never "View 3D Scene". Unless you definitely think the alternative is better, I would suggest to keep "view3dscene".

          I changed the name to "view3dscene" in all places.

          2. Manpages: I created manpages that list all command-line options for view3dscene and tovrmlx3d . These list all options (documented on http://castle-engine.sourceforge.net/view3dscene.php and visible when you run them with --help).

          I added them to debian/patches/add-man-pages.patch , I also added them to castle-engine SVN repo, as they are generally useful. (So in the future the patch debian/patches/add-man-pages.patch can be dropped.)

          3. Your compilation script (after applying add-make-all-target.patch) doesn't include all compiler flags necessary/advices (for optimized build). All flags are inside castle_game_engine/castle-fpc.cfg.

          I updated debian/patches/add-make-all-target.patch to include all the flags. Although it would be best if the view3dscene compilation script just used castle-fpc.cfg, then you can do "-dRELEASE @castle-fpc.cfg" to include all necessary options, unless that's unhandy for other reasons.

          4. Description: I think it's more useful to tell users what the program is about. For example, we provide an alternative to http://packages.debian.org/unstable/gtklookat , also handling VRML (and much more), it would be nice if description was making it clear. So I think that talking (too much) about FreePascal or Castle Game Engine in the view3dscene description is not so important, it's more important to list the supported format names (X3D, VRML, Collada etc.) since that's what potential users will search for. Also, view3dscene is not used to export scenes for Casle Game Engine formats, there is no such thing. view3dscene is a viewer and converter between various standard 3D formats, most notably VRML / X3D.

          I changed debian/control description to reflect this.

          5. "Depends" probably should be extended, see http://castle-engine.sourceforge.net/view3dscene.php#section_depends and http://castle-engine.sourceforge.net/forum.php#section_distros . In short: OpenGL, libpng, zlib, GTK (2), GTKGLExt are necessary. OpenAL is stronly adviced. ffmpeg and ImageMagick are lightly recommended.

          I did not fix it myself, you probably know best how to express the above :)

          6. License: should be GPL >= 2 view3dscene is not LGPL, see http://castle-engine.sourceforge.net/engine.php#section_license ("LGPL stuff concerns only the engine, i.e. things inside castle_game_engine archive. The rest of the programs (view3dscene, castle etc.) are still strict GPL.")

          7. URL: should be http://castle-engine.sourceforge.net/view3dscene.php

          8. There is no format called "X3DS". There is X3D, VRML, 3DS and many others :) I corrected it everywhere.

          9. I don't think section Applications/Accessibility is correct. I changed it to Applications/Graphics.

          10. BTW, I hope that the nice SVG icon of vie3dscene will be used, we package it inside view3dscene/desktop/ . There are other things there, to add necessary MIME types and associate view3dscene with it, and to use view3dscene as nautilus thumbnailer.

          I'm not sure how to best package it, so I'm leaving it for you :) It would be great if the Debian package was installing all of this nice stuff out of the box :), especially I think that nautilus thumbnailer is a very nice feature to automatically have.

           
          • Abou Al Montacir

            On Sun, 2013-05-12 at 20:46 +0000, Michalis Kamburelis wrote:

                I've pushed everything, can you please review?
            

            I created a clone of your repo on
            https://code.google.com/r/michaliskambi-view3dscene-debian/ , I made
            some fixes changes that you can pull.

            Thank for these fixes, if you are interested, I can give you access to
            git repos of pascal-for-debian. I think this could be easier than
            maintaining your own clone.

            Some notes / reasoning for my changes:

            1. I almost always used the lowercase name "view3dscene" to refer to
              this program. Sometimes eventually "View3DScene", never "View 3D
              Scene". Unless you definitely think the alternative is better, I would
              suggest to keep "view3dscene".

            I changed the name to "view3dscene" in all places.

            fine with me

            1. Manpages: I created manpages that list all command-line options for
              view3dscene and tovrmlx3d . These list all options (documented on
              http://castle-engine.sourceforge.net/view3dscene.php and visible when
              you run them with --help).

            I added them to debian/patches/add-man-pages.patch , I also added them
            to castle-engine SVN repo, as they are generally useful. (So in the
            future the patch debian/patches/add-man-pages.patch can be dropped.)

            Great, I just wanted to go fast, but it is always better to have a most
            complete man page.

            1. Your compilation script (after applying add-make-all-target.patch)
              doesn't include all compiler flags necessary/advices (for optimized
              build). All flags are inside castle_game_engine/castle-fpc.cfg.

            Again I just picked necessary flags to make it compile. Some of them I
            think should go in sources like -MObjFPC and -Sh, but this is just my
            personal point of view.

            I updated debian/patches/add-make-all-target.patch to include all the
            flags. Although it would be best if the view3dscene compilation script
            just used castle-fpc.cfg, then you can do "-dRELEASE @castle-fpc.cfg"
            to include all necessary options, unless that's unhandy for other
            reasons.

            I need to think for a global way of solving this kind of issues with 3rd
            party fp-units. I'll check with FPC code developers team on the best way
            to have this. For now, one solution will be the castle-game-engine
            package adds some flags to /etc/fpc.cfg and then remove them upon purge.
            Looks however like a hack.
            An other solution would be support of /etc/fpc.cfg.d where libraries can
            register their own files.
            TBC

            1. Description: I think it's more useful to tell users what the
              program is about. For example, we provide an alternative to
              http://packages.debian.org/unstable/gtklookat , also handling VRML
              (and much more), it would be nice if description was making it clear.
              So I think that talking (too much) about FreePascal or Castle Game
              Engine in the view3dscene description is not so important, it's more
              important to list the supported format names (X3D, VRML, Collada etc.)
              since that's what potential users will search for. Also, view3dscene
              is not used to export scenes for Casle Game Engine formats, there is
              no such thing. view3dscene is a viewer and converter between various
              standard 3D formats, most notably VRML / X3D.

            I changed debian/control description to reflect this.

            Great! I also tried to be fast and dirty here.

            1. "Depends" probably should be extended, see
              http://castle-engine.sourceforge.net/view3dscene.php#section_depends
              and http://castle-engine.sourceforge.net/forum.php#section_distros .
              In short: OpenGL, libpng, zlib, GTK (2), GTKGLExt are necessary.
              OpenAL is stronly adviced. ffmpeg and ImageMagick are lightly
              recommended.

            I did not fix it myself, you probably know best how to express the
            above :)

            Libraries dependency is computed automatically with ${Shlibs:Depends}
            stanza. But in some rare case we need to add them manually. Anyway
            dependency is always hard to figure and could be fixed depending on
            users bug reports.

            1. License: should be GPL >= 2 view3dscene is not LGPL, see
              http://castle-engine.sourceforge.net/engine.php#section_license ("LGPL
              stuff concerns only the engine, i.e. things inside castle_game_engine
              archive. The rest of the programs (view3dscene, castle etc.) are still
              strict GPL.")

            OK, sorry for this confusion.

            1. URL: should be http://castle-engine.sourceforge.net/view3dscene.php

            OK

            1. There is no format called "X3DS". There is X3D, VRML, 3DS and many
              others :) I corrected it everywhere.

            OK

            1. I don't think section Applications/Accessibility is correct. I
              changed it to Applications/Graphics.

            Agree

            1. BTW, I hope that the nice SVG icon of vie3dscene will be used, we
              package it inside view3dscene/desktop/ . There are other things there,
              to add necessary MIME types and associate view3dscene with it, and to
              use view3dscene as nautilus thumbnailer.

            For now it is packaged, but the menu uses xpm file as mandatory icon
            format.

            I'm not sure how to best package it, so I'm leaving it for you :) It
            would be great if the Debian package was installing all of this nice
            stuff out of the box :), especially I think that nautilus thumbnailer
            is a very nice feature to automatically have.

            I'll have a look at that, but for me this could be part of a second
            upload.

            Cheers,

             
            • Michalis Kamburelis

              Thank for these fixes, if you are interested, I can give you access to git repos of pascal-for-debian.

              Sure, I'd use that. Since you accept all my changes, the first thing I would do is to merge my changes from https://code.google.com/r/michaliskambi-view3dscene-debian/ :), and remove my own repo clone.

              Again I just picked necessary flags to make it compile. Some of them I think should go in sources like -MObjFPC and -Sh, but this is just my personal point of view.

              Note that some of the flags, like optimizations, may not seem necessary but they make a huge speed difference is some use cases :) And not everything can be expressed using directives in the source code, that's why I decided to not even try.

              I need to think for a global way of solving this kind of issues with 3rd party fp-units. I'll check with FPC code developers team on the best way to have this. For now, one solution will be the castle-game-engine package adds some flags to /etc/fpc.cfg and then remove them upon purge. Looks however like a hack.

              Yeah, I think that modifying global /etc/fpc.cfg would be bad, I wouldn't like it myself. Various projects want different things. I'm also not sure about /etc/fpc.cfg.d/ idea (I guess you mean something similar to /etc/apache/conf.d/ or /etc/apt/sources.list.d/) --- in this case you don't want to just "sum" all the settings, you want to cherry-pick them for a particular project.

              Maybe something like /etc/fpc/paths.cfg (with all -Fu to standard RTL units), and /etc/fpc/default.cfg (that #INCLUDES the /etc/fpc/paths.cfg and adds standard FPC config options). These two files would be installed with FPC packages. And then castle-game-engine could install /etc/fpc/castle-game-engine.cfg that also #INCLUDES the /etc/fpc/paths.cfg and adds our own adviced options. This would be a nice improvement of FPC config system, splitting the config into "paths to standard units" (/etc/fpc/paths.cfg) and "other options" (/etc/fpc/default.cfg). This would be something generally useful IMHO. In any case, this is just an idea for the future :)

              FPC team will probably suggest using fpmake for compilation, which may not be a bad idea. There is fpmake compilation method for castle_game_engine (although right now it just uses "P.Options.Text := '@castle-fpc.cfg';", so eventually the compiler options are taken anyway from castle-fpc.cfg). If you would like to go this way to the end, that is: compile everything by fpmake approach (castle-game-engine and view3dscene), and without any @castle-fpc.cfg, let me know. I can create view3dscene/fpmake.pp, and I can make sure to just list inside fpmake.pp all the necessary compiler flags.

               
              • Abou Al Montacir

                On Mon, 2013-05-13 at 21:02 +0000, Michalis Kamburelis wrote:

                    Thank for these fixes, if you are interested, I can give you
                    access to git repos of pascal-for-debian.
                

                Sure, I'd use that. Since you accept all my changes, the first thing I
                would do is to merge my changes from
                https://code.google.com/r/michaliskambi-view3dscene-debian/ :), and
                remove my own repo clone.

                Done, please try and let me know

                    Again I just picked necessary flags to make it compile. Some
                    of them I think should go in sources like -MObjFPC and -Sh,
                    but this is just my personal point of view.
                

                Note that some of the flags, like optimizations, may not seem
                necessary but they make a huge speed difference is some use cases :)
                And not everything can be expressed using directives in the source
                code, that's why I decided to not even try.

                In this case you may need to provide a fpc.cfg file for each project.
                Please remember that castle-game-engine units were compiled and are
                available as binaries only. So you they are not going to be recompiled
                as /usr/lib/* is read only. In that case it makes sens to have
                view3dscene/fpc.cfg file which will only affects veiw3dscene sources.
                Of course I'm not speaking about untis path here. That would be handled
                separately, probably using /etc/fpc.cfg.d

                    I need to think for a global way of solving this kind of
                    issues with 3rd party fp-units. I'll check with FPC code
                    developers team on the best way to have this. For now, one
                    solution will be the castle-game-engine package adds some
                    flags to /etc/fpc.cfg and then remove them upon purge. Looks
                    however like a hack.
                

                Yeah, I think that modifying global /etc/fpc.cfg would be bad, I
                wouldn't like it myself. Various projects want different things. I'm
                also not sure about /etc/fpc.cfg.d/ idea (I guess you mean something
                similar to /etc/apache/conf.d/ or /etc/apt/sources.list.d/) --- in
                this case you don't want to just "sum" all the settings, you want to
                cherry-pick them for a particular project.

                Yes, this will only be used for path units, even if added them
                to /etc/fpc.cfg may be also possible.

                Maybe something like /etc/fpc/paths.cfg (with all -Fu to standard RTL
                units), and /etc/fpc/default.cfg (that #INCLUDES
                the /etc/fpc/paths.cfg and adds standard FPC config options). These
                two files would be installed with FPC packages. And then
                castle-game-engine could install /etc/fpc/castle-game-engine.cfg that
                also #INCLUDES the /etc/fpc/paths.cfg and adds our own adviced
                options. This would be a nice improvement of FPC config system,
                splitting the config into "paths to standard
                units" (/etc/fpc/paths.cfg) and "other
                options" (/etc/fpc/default.cfg). This would be something generally
                useful IMHO. In any case, this is just an idea for the future :)

                That could be an option. I'll see what Florian and others think about
                this.

                FPC team will probably suggest using fpmake for compilation, which may
                not be a bad idea. There is fpmake compilation method for
                castle_game_engine (although right now it just uses "P.Options.Text :=
                '@castle-fpc.cfg';", so eventually the compiler options are taken
                anyway from castle-fpc.cfg). If you would like to go this way to the
                end, that is: compile everything by fpmake approach
                (castle-game-engine and view3dscene), and without any @castle-fpc.cfg,
                let me know. I can create view3dscene/fpmake.pp, and I can make sure
                to just list inside fpmake.pp all the necessary compiler flags.

                I've not followed well the fpmake stuff and still have 5810 unread mail
                in my fpc-core mail account! I should probably look for discussions
                about it and then ask some question on the core mailing list.
                However, the compilation method should be decided be the developers
                (you) not by the packagers (me), so I think here you need to decide and
                I need to point the weaknesses!
                Anyway, as FPC core team and Lazarus team are going in the direction of
                fpmake, I think it could only be the right direction.

                Cheers,

                 
                • Michalis Kamburelis

                  Done, please try and let me know

                  Thanks, all is good :) I merged all my fixes to your repository on https://code.google.com/p/pascal-for-debian/source/list?repo=view3dscene . My own clone https://code.google.com/r/michaliskambi-view3dscene-debian/ is now scheduled for deletion.

                  As for compilation with fpmake, I will play with it more in the future. Possibly, I will just drop using castle-fpc.cfg, as the fpmake method seems mature enough now. So we would have only 2 methods of compilation: 1 using fpmake, or 2. using Lazarus lpi/lpk. Most of the information about fpmake that I know comes from wiki http://wiki.freepascal.org/FPMake and reading fpc- mailing lists.

                  For now, the view3dscene compilation using options listed in add-make-all-target.patch will work Ok, so probably there's no rush :) Thanks for all the info, discussing this is good --- I'm choosing the compilation method, but I want it to be comfortable for others, especially for packagers :)

                   
                  • Abou Al Montacir

                    On Mon, 2013-05-13 at 22:29 +0000, Michalis Kamburelis wrote:

                        Done, please try and let me know
                    

                    Thanks, all is good :) I merged all my fixes to your repository on
                    https://code.google.com/p/pascal-for-debian/source/list?repo=view3dscene . My own clone https://code.google.com/r/michaliskambi-view3dscene-debian/ is now scheduled for deletion.

                    I've checked you changes, and I think we are ready for upload. So just
                    need to wait for FPC-2.6.2 upload and then we can go.

                    As for compilation with fpmake, I will play with it more in the
                    future. Possibly, I will just drop using castle-fpc.cfg, as the fpmake
                    method seems mature enough now. So we would have only 2 methods of
                    compilation: 1 using fpmake, or 2. using Lazarus lpi/lpk. Most of the
                    information about fpmake that I know comes from wiki
                    http://wiki.freepascal.org/FPMake and reading fpc- mailing lists.

                    Please note that we can stick to lazbuild compilation, it works well in
                    Debian and I have already projects that build Debian package just using
                    lazbuild. This way we can avoid having 2 build methods to maintain. Of
                    course this implies having Lazarus installed on other platfors, but in
                    debain, lazbuild is packaged in a separate package: lcl-utils.

                    For now, the view3dscene compilation using options listed in
                    add-make-all-target.patch will work Ok, so probably there's no rush :)
                    Thanks for all the info, discussing this is good --- I'm choosing the
                    compilation method, but I want it to be comfortable for others,
                    especially for packagers :)

                    I think we can plan these changes for the next release. It won't be a
                    huge effort anyway.

                    Cheers,

                     
                    • Abou Al Montacir

                      Hi,

                      I'm interested in packaging the Castle Game. I've almost finished that,
                      but won't publish it unless you accept to support it.
                      I've red in you web site that this is considered legacy and will be
                      replace by a newer one, but I really find it nice game and think we can
                      package it at least until a next game is releasable.
                      Most end users are more interested in the game than in the engine, which
                      is for interest only for few developers that want to develop their own
                      game.
                      Also, packaging the game will provide a concrete example of the
                      capabilities of the engine and will be the best publicity for it.
                      Of course this implies some effort to improve the game, but I think this
                      should not be huge, is it?

                      If you accept, I'll create a new repo caste-game and push my packaging.

                      Cheers,

                       
                      • Michalis Kamburelis

                        I'm interested in packaging the Castle Game.

                        Great! I thought about it, but I was too shy to propose that to you :)

                        If you accept, I'll create a new repo caste-game and push my packaging.

                        Of course I accept. "The Castle" game will be supported (for infinity, as far as I'm concerned) --- in the sense that it's always updated to work with latest engine version, and bugfixes are done.

                        I don't plan to extend this game, i.e. no new levels/creatures/gameplay are planned (well, unless someone else will decide to contribute and take it over, which I would be very happy with). I prefer to concentrate the efforts on new games. Also, "The Castle" graphics is a little old, it uses ancient VRML 1.0 format and it doesn't showcase the latest features of the engine --- things like mirrors, shadow maps, bump mapping, more interactivity/animations in the 3D world. But if you think it's a nice game, and I heard others like it too :), it would be great to have this in Debian too.

                        Oh, one important thing: note that the DOOM level inside "The Castle" isn't really open-source. See the bottom of http://castle-engine.sourceforge.net/castle-credits.php . Essentially, we use 3D data and textures and sounds that are copyright by Id Software, and we don't have any official permission to use them. I don't think that Id Software has any problems with it, but to be on the safe side --- it may be necessary to remove this level in Debian packaging. I designed the data to easily allow this, you can essentially just remove some subdirectories.

                        Thanks,

                         
                        • Abou Al Montacir

                          On Tue, 2013-05-14 at 21:13 +0000, Michalis Kamburelis wrote:

                              I'm interested in packaging the Castle Game.
                          

                          Great! I thought about it, but I was too shy to propose that to you :)

                          Nice, so let's do it

                              If you accept, I'll create a new repo caste-game and push my
                              packaging.
                          

                          Of course I accept. "The Castle" game will be supported (for infinity,
                          as far as I'm concerned) --- in the sense that it's always updated to
                          work with latest engine version, and bugfixes are done.

                          Fine with me

                          I don't plan to extend this game, i.e. no new
                          levels/creatures/gameplay are planned (well, unless someone else will
                          decide to contribute and take it over, which I would be very happy
                          with). I prefer to concentrate the efforts on new games. Also, "The
                          Castle" graphics is a little old, it uses ancient VRML 1.0 format and
                          it doesn't showcase the latest features of the engine --- things like
                          mirrors, shadow maps, bump mapping, more interactivity/animations in
                          the 3D world. But if you think it's a nice game, and I heard others
                          like it too :), it would be great to have this in Debian too.

                          I've played with it a little bit and looks good. Let's package it and
                          then depending on its popularity see if it is worth to improve graphics.

                          Oh, one important thing: note that the DOOM level inside "The Castle"
                          isn't really open-source. See the bottom of
                          http://castle-engine.sourceforge.net/castle-credits.php . Essentially,
                          we use 3D data and textures and sounds that are copyright by Id
                          Software, and we don't have any official permission to use them. I
                          don't think that Id Software has any problems with it, but to be on
                          the safe side --- it may be necessary to remove this level in Debian
                          packaging. I designed the data to easily allow this, you can
                          essentially just remove some subdirectories.

                          This is problematic indeed. Either we contact Id Software to ask for
                          explicit written permission, or we remove all the problematic data. But
                          this should not stop us from packaging the GPL part.

                          I'm pushing my work and sending ITP request.

                          Cheers,

                           
                          • Abou Al Montacir

                             
                            • Michalis Kamburelis

                              Great, thanks, I will try to review the castle-game repo ASAP! Hopefully this weekend. I am a little busy lately :)

                               
                            • Michalis Kamburelis

                              I finally had the time to browse the pascal-for-debian.castle-game repo and commit small fixes. Sorry for delay, my new daily job (also as a game programmer :) ate my time lately.

                              As for patches inside debian/patches/:

                              - add-man-pages.patch - As with view3dscene/tovrmlx3d, I extended the manpage with a complete list of command-line options (visible also when you run the game with --help). I also added the manpage to our (upstream) trunk SVN.

                              - add-make-all-target.patch - As with view3dscene/tovrmlx3d, I extended the FPC options to make more optimized build.

                              - add-script-shebang.patch - I also added shebang to scripts in our trunk (with bin/bash and "set -eu").

                              - fix-data-path.patch - In trunk this is already fixed, in a cleaner way. See CastleFilesUtils.ApplicationData function in SVN, it returns and gets URLs. The "data" subdirectory will be automatically used when searching for base data in current dir, but it will not be used when looking inside system-wide /usr/share/castle/ . So the need for this patch should disappear with next castle-game release, and things are generally simpler and better.

                              - add-desktop-files.patch - I committed small fixes to desktop file, and committed both desktop and xpm to our SVN repository too. I'll see about creating a nicer scalable icon in the future, but for now this one is OK :)

                              I understand that you changed "castle" binary to "castle-game" to make it more unique, right? I'm thinking about doing it inside our SVN too, but I didn't do it yet.

                              Note: you should probably introduce another Debian patch to modify castle/source/castle.lpr to change function MyGetApplicationName into "Result := 'castle-game';". This way configuration will be saved to a filename like ~/.config/castle-game/castle-game.conf instead of ~/.config/castle/castle.conf , I think this is consistent if we name the binary and package "castle-game". Alternatively, you can just remove MyGetApplicationName and "OnGetApplicationName := @MyGetApplicationName" line, then the ParamStr(0) will be used, which in practice (when the game is called in a normal fashion) should already be 'castle-game'.

                              I also pushed tiny improvements to castle-game-engine packaging.

                               
                              • Abou Al Montacir

                                On Sat, 2013-06-01 at 22:57 +0000, Michalis Kamburelis wrote:

                                I finally had the time to browse the pascal-for-debian.castle-game
                                repo and commit small fixes. Sorry for delay, my new daily job (also
                                as a game programmer :) ate my time lately.

                                Congratulations for the new job!

                                As for patches inside debian/patches/:

                                • add-man-pages.patch - As with view3dscene/tovrmlx3d, I extended the
                                  manpage with a complete list of command-line options (visible also
                                  when you run the game with --help). I also added the manpage to our
                                  (upstream) trunk SVN.

                                That looks indeed better

                                • add-make-all-target.patch - As with view3dscene/tovrmlx3d, I
                                  extended the FPC options to make more optimized build.

                                About compilation, I've finally found that 3rd party units (like
                                castle-game-engine) should use a standard, multi-arch compatible, path
                                that fp-compiler package is aware about. This will
                                be /usr/lib/${DEB_BUILD_MUTIARCH}/fp-units-${FPC_VERSION}/${PACKAGE_NAME}-{PACKAGE_VERSION}. This allows using all 3rd part units with 1 line added to /etc/fpc.cfg: -Fu/usr/lib/$fpctarget-/fp-untis-$fpcversion/

                                • add-script-shebang.patch - I also added shebang to scripts in our
                                  trunk (with bin/bash and "set -eu").

                                Do you really need bash? Isn't /bin/sh enough?

                                • fix-data-path.patch - In trunk this is already fixed, in a cleaner
                                  way. See CastleFilesUtils.ApplicationData function in SVN, it returns
                                  and gets URLs. The "data" subdirectory will be automatically used when
                                  searching for base data in current dir, but it will not be used when
                                  looking inside system-wide /usr/share/castle/ . So the need for this
                                  patch should disappear with next castle-game release, and things are
                                  generally simpler and better.

                                OK

                                • add-desktop-files.patch - I committed small fixes to desktop file,
                                  and committed both desktop and xpm to our SVN repository too. I'll see
                                  about creating a nicer scalable icon in the future, but for now this
                                  one is OK :)

                                OK

                                I understand that you changed "castle" binary to "castle-game" to make
                                it more unique, right? I'm thinking about doing it inside our SVN too,
                                but I didn't do it yet.

                                Yes indeed: just like in the past Lazarus has been changed to
                                lazarus-ide to avoid conflicts with other packages.

                                Note: you should probably introduce another Debian patch to modify
                                castle/source/castle.lpr to change function MyGetApplicationName into
                                "Result := 'castle-game';". This way configuration will be saved to a
                                filename like ~/.config/castle-game/castle-game.conf instead of
                                ~/.config/castle/castle.conf , I think this is consistent if we name
                                the binary and package "castle-game". Alternatively, you can just
                                remove MyGetApplicationName and "OnGetApplicationName :=
                                @MyGetApplicationName" line, then the ParamStr(0) will be used, which
                                in practice (when the game is called in a normal fashion) should
                                already be 'castle-game'.

                                Yes, I'd prefer to remove that function.

                                I also pushed tiny improvements to castle-game-engine packaging.

                                I have a minor request: can we make it full screen? It throws some error
                                message, but not fps-game.
                                Can't change display settings to:
                                Screen size : 800x600

                                I will set "Allow screen settings change on startup" option to "No". You
                                may want to review settings in "Video options" menu and then set "Allow.

                                Now I will just continue with default system settings.

                                Cheers,

                                 
  • Michalis Kamburelis

    Do you really need bash? Isn't /bin/sh enough?

    No, not for these trivial scripts. But I got accustomed to /bin/bash and not worrying what is standard in /bin/sh and what is bash-specific :), so I use /bin/bash as standard for all of my scripts. These are not system scripts where speed benefits of /bin/sh will ever matter :)

    I have a minor request: can we make it full screen?

    The problem is that the default backend of CastleWindow unit is GTK, which uses GtkGLExt and cannot resize the screen. Switching window to fullscreen (to use full current screen resolution) works, but resizing the screen to change resolution doesn't. fps_game happily runs in any resolution (it does not try to resize the screen), that's why you don't see any warning. But "The Castle" prefers 800x600 (for 2D graphic to look best), and when it can't get it --- it fallbacks to windowed mode.

    When you look at "The Castle" compilation scripts, you will notice it recompiles the CastleWindow unit with -dCASTLE_WINDOW_XLIB, to use Xlib backend that doesn't require GTK and that has working resolution-switching (OTOH it doesn't show native menu bar or dialogs, but "The Castle" doesn't use them anyway).

    I'm not sure what's the proper way to fix this for Debian packages.

    • Clearly, our approach to switch backends (the need to recompile CastleWindow unit with -dCASTLE_WINDOW_xxx symbol defined) is not nice. Especially when Castle Game Engine is installed in system-wide locations and normal user may not be able to recompile the engine units. But fixing this is quite a lot of work.

    • Simpler solution could be to fix GTK backend to be able to switch screen resolutions. I tried that, but it didn't work reliably in my tests (see src/window/castlewindow.pas comments), but maybe I just didn't put enough effort into it.

    • Eventually, just allow "The Castle" to run in any screen resolution. Some 2D GUI will not look perfect, but I can live with it :) This is the easiest solution.

     
    • Michalis Kamburelis

      Eventually, just allow "The Castle" to run in any screen resolution. Some 2D GUI will not look perfect, but I can live with it :) This is the easiest solution.

      With a little work, I did it. "The Castle" now happily works in fullscreen even when screen resize failed, and 2D GUI looks good in all resolutions. This is generally a change for the better, I also managed to simplify some (really old) code, so this was a good thing to do anyway.

      The change is in our trunk, https://sourceforge.net/p/castle-engine/code/12841/ . I did not try can it be backported to existing castle 1.0.0 sources. Possibly.

      Simpler solution could be to fix GTK backend to be able to switch screen resolutions.

      BTW, if you're interested about it, see lines

      {$ifdef CASTLE_WINDOW_GTK_ANY}
        {$ifdef UNIX}
          { Hmm. This compiles and basically works, but the new screen is still
            virtual. For now this is disabled. TODO. }
          { $define CASTLE_WINDOW_HAS_VIDEO_CHANGE}
          { $define CASTLE_WINDOW_USE_XF86VMODE}
        {$endif}
      {$endif}
      

      inside castle_game_engine/src/window/castlewindow.pas . Change it to actually make two defines (replace "{ $define" with "{$define") and allow "The Castle" to resize screen --- you will see the problems with screen resizing and GTK. If you have an idea how to fix this, it would be great :), it would allow screen resizing to work with GTK backend.

       
1 2 > >> (Page 1 of 2)


Anonymous

Cancel  Add attachments