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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
- 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 :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
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.
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
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,
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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,
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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 :).
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.
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.")
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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:
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
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.
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
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.
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.
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.")
There is no format called "X3DS". There is X3D, VRML, 3DS and many
others :) I corrected it everywhere.
OK
I don't think section Applications/Accessibility is correct. I
changed it to Applications/Graphics.
Agree
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,
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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,
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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 :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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,
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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,
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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,
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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,
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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,
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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,
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.
On Fri, 2013-04-26 at 23:22 +0000, Michalis Kamburelis wrote:
Nice to hear this!
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.
That is my goal too!
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.
I'll have a look to these
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.
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.
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.
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
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 :)
On Thu, 2013-05-09 at 18:50 +0000, Michalis Kamburelis wrote:
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
For svn access, I don't think I'll commit many things, but why not.
Cheers,
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.
On Sat, 2013-05-11 at 14:02 +0000, Michalis Kamburelis wrote:
I'm cc-ing you so that you can get it for sure.
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 :)
You're welcome. I'm really happy to see a so good game engine written in
Pascal and thank you for this great work.
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.
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
On Sat, 2013-05-11 at 19:25 +0000, Abou Al Montacir wrote:
I've pushed everything, can you please review?
Cheers,
Thanks!
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 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.
On Sun, 2013-05-12 at 20:46 +0000, Michalis Kamburelis wrote:
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.
fine with me
Great, I just wanted to go fast, but it is always better to have a most
complete man page.
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 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
Great! I also tried to be fast and dirty here.
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.
OK, sorry for this confusion.
OK
OK
Agree
For now it is packaged, but the menu uses xpm file as mandatory icon
format.
I'll have a look at that, but for me this could be part of a second
upload.
Cheers,
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.
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.
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.
On Mon, 2013-05-13 at 21:02 +0000, Michalis Kamburelis wrote:
Done, please try and let me know
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
Yes, this will only be used for path units, even if added them
to /etc/fpc.cfg may be also possible.
That could be an option. I'll see what Florian and others think about
this.
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,
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 :)
On Mon, 2013-05-13 at 22:29 +0000, Michalis Kamburelis wrote:
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.
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.
I think we can plan these changes for the next release. It won't be a
huge effort anyway.
Cheers,
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,
Great! I thought about it, but I was too shy to propose that to you :)
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,
On Tue, 2013-05-14 at 21:13 +0000, Michalis Kamburelis wrote:
Nice, so let's do it
Fine with me
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.
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,
I've pushed everything to
https://code.google.com/p/pascal-for-debian/source/browse/?repo=castle-game
Cheers,
Great, thanks, I will try to review the castle-game repo ASAP! Hopefully this weekend. I am a little busy lately :)
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.
On Sat, 2013-06-01 at 22:57 +0000, Michalis Kamburelis wrote:
Congratulations for the new job!
That looks indeed better
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/
Do you really need bash? Isn't /bin/sh enough?
OK
OK
Yes indeed: just like in the past Lazarus has been changed to
lazarus-ide to avoid conflicts with other packages.
Yes, I'd prefer to remove that function.
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,
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 :)
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.
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.
BTW, if you're interested about it, see lines
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.