Debian package(s) for GemRB

[Guest Drizzt]

Today I had a little bit free time and used it to start the packaging of GemRB for Debian (as "announced" here).

 

Right now I'm about to make Lintian happy But that will take time. At the moment it's just one binary package that is build - which might be wrong, as it seems like there are development files build too, so a gemrb-dev package might be required. Also the gemrb_core*.so-stuff might be moved to a package that is named accordingly (that would save me a Lintian override). The code and I must first know each other better.

 

So, to make a long story short: work has started but there are defenitly a lot things, that need to be done, before this package can become official. Before that I will release it into the wild and ask here for fellow Debian user to check the package. Around that time I'll file the ITP (I'd like to keep the ITP and the first RFS as close to eachother as possible, nothing is more annoying then an years old ITP). And finally ask for sponsoring on debian-mentors.

 

If you are a Debian user waiting for such a package, I'd certainly like to know

 

Greetings,

Drizzt

[billb]

I was thinking of making an RPM package ... could you post a list of the required dependencies? Though I realize my library names will be different, that would save me some time.

[Guest Drizzt]

Hello,

of course I can post my dependencies (C&P from »debian/control« source section):

Build-Depends: debhelper (>= 5), autotools-dev, zlib1g-dev, libpng12-dev, libsdl1.2-dev, python2.5-dev, libopenal-dev

That allows building with pbuilder (which creates a fakeroot environment with only the build-essential packages and the one mentioned in the Build-Depends line present).

 

But be aware of the following issiues/points:

1. the build is done right now with gcc 4.2, I don't know whether it would also work with 4.3
   
2. the configure script is checking for a vorbisfile-function but proceeds without complaining if it isn't present; to satisfy that, one must add »libvorbis-dev« to the Build-Depends
   
3. I had to remove the »-Werror« option for an successful build because of some warnings generated while compiling PluginMgr.cpp [0] (in the constructor a non-ISO-C++-cast is used)
   

Now I have to apologize for the long delay in answering your request, but I had a very busy weekend and didn't have time to do anything Debian-related (so no progress on the packaging*).

 

Kind regards,

Drizzt

 

[0] the complete output is:

PluginMgr.cpp: In constructor ‘PluginMgr::PluginMgr(char*)’:

PluginMgr.cpp:145: warning: ISO C++ forbids casting between pointer-to-function and pointer-to-object

PluginMgr.cpp:146: warning: ISO C++ forbids casting between pointer-to-function and pointer-to-object

PluginMgr.cpp:147: warning: ISO C++ forbids casting between pointer-to-function and pointer-to-object

* But I think I'll aim for several binary-packages in the end. First: there is no need to ship the complete documentation for using GUIScript for normal users. Second: there are a lot of development files I've spotted during compilation/package creation, they will have to go to a *-dev package (but haven't time to check the built package in detail). Third: there is no need to ship the UI files for all supported games, if the user only wants to play one, so I'll probably split them into several parts. And last but not least: if I ship the core-lib in an extra-package I save myself probably all remaining Linitian overrides.

[Guest Guest]

gcc 4.3 works only with a post-0.3 svn version.

What are the "development files" you refer to? I can only think of the few test/ guiscripts and overrides.

 

-lynx

[billb]

Now I have to apologize for the long delay in answering your request, but I had a very busy weekend and didn't have time to do anything Debian-related (so no progress on the packaging*).

 

No problem -- thanks for posting the info!

[Guest Drizzt]

gcc 4.3 works only with a post-0.3 svn version.

What are the "development files" you refer to? I can only think of the few test/ guiscripts and overrides.

Thanks for the note on gcc 4.3!

 

As for the development files: I've spoted a lot *.la files which I would normally try to get into a *-dev package as it is notrious difficult to get rid of them.

To be sure, how to do it right for Debian, I asked for advise on #debian-mentors. The mentors said, that I shouldn't install any *.la files at all and go for the pkg-config approach if upstream (that's you ) would do that too. Otherwise (you do not want to use pkg-config), I still should not ship the *.la files.

The other files I would right now move into a *-dev or *-doc package, are the files for the GUIScript documentation, since that is only of interest to people who want to create or modify new/existing GUIScripts.

If the *.la files are dropped (and no pkg-config instead) then it would be a *-doc package more then a *-dev package. But as I said in my post from tonight: I only had a brief look at all and no real time to check it thoroughly. So don't assume to much.

 

Now I have a second question for you: the test-stuff in the override and the GUIScripts folder isn't needed for normal operation, right?

 

No problem -- thanks for posting the info!

Well, normally I'd like to answer faster.

Please note, that the Build-Depends given where only the ones I needed without deactivating something, and are not final (by now quilt and libvorbis-dev have gone into that line too).

 

Hopefully I'll get a few things done this week, like setting up an SVN for the debian stuff.

 

Greetings,

Drizzt

[Guest Drizzt]

First a note to myself: I should take more time and use the preview function, so I can spot mistakes like the "where"....

 

Today I made some progress for the multi-binary-package, the debian/rules file gets into shape. Now I need to ensure the created packages contain only what they should. Then I can concentrate on dependency checking (i.e. if for example package gemrb-bg1 is installed, Baldur's Gate 1 is playable in the end).

Last but not least I corrected my watch file (stupid mistake). uscan can tell me now if you've released a new version (at least if it hits sf.net).

 

I have now a local SVN, a web-accessible one will hopefully be created on Alioth very soon. Right now that is not possible because of some error in the backend (another DM had the same problem, so I guess, it's nothing specific to me).

 

@-lynx: do you - by chance - know the commit(s), which allowed building with gcc 4.3? *g*

 

Greetings,

Drizzt

[Guest Guest]

one of mine was specifically targeted at it, I don't know if anything was fixed before that by chance. It is trivially retrievable from the log. But perhaps we'll do a minor release just to propagate that fix forward. If you need anything for packaging that could be done too.

 

What's this about pkg-config/.la? I don't know much about it, so how would pkg-config help?

[Guest Drizzt]

PART 1 OF THE POST, SEE BELOW FOR EXPLANATION

I have now a local SVN, a web-accessible one will hopefully be created on Alioth very soon. Right now that is not possible because of some error in the backend (another DM had the same problem, so I guess, it's nothing specific to me).

The idea with an Alioth-project was nice, but I suspect it will not happen very soon, because of Alioth's policy (I'm not a Debian Developer and for the other options this package project is right now to small). Maybe I can get some space under the pkg-games umbrella on Alioth, but befor that is going to happen I need a working package first which is suitable for inclusion into Debian. So, at the moment no Alioth for me. Until then you can have a look at what is happening under svn://svn.carbon-project.org/deb-pkg/gemrb/trunk.

 

Greetings,

Drizzt

 

WHY MULTIPLE POSTS?

Because I'm (as a non-registered user) not allowed to have more than one link in my posts even if the system tells me something about two...

[Guest Drizzt]

PART 2 OF THE POST, SEE BELOW FOR EXPLANATION

And before someone asks (*g*): you'll find no GemRB sources there. Only the debian directory is kept in the repository. The orig.tar.gz can be found at http://www.carbon-project.org/dev/debian/g...3.0.orig.tar.gz.

You might even be able to build the package partially already (not all binary packages will have content, some stuff like debconf is missing). In any case generating the source package (using svn-buildpackage makes that simple) is possible.

 

one of mine was specifically targeted at it, I don't know if anything was fixed before that by chance. It is trivially retrievable from the log. But perhaps we'll do a minor release just to propagate that fix forward. If you need anything for packaging that could be done too.

There is (currently) no need, to release a new version for me (not until I've finished the package and can incorporate upstream changes easily. ). I think I can get along with the current source tree. If I should find something, which is interesting for upstream inclusion, I'll let you know.

I'll found your commit (it was r5124). I'll integrate it and test it.

 

WHY MULTIPLE POSTS?

Because I'm (as a non-registered user) not allowed to have more than one link in my posts even if the system tells me something about two...

[Guest Drizzt]

PART 3 OF THE POST, SEE BELOW FOR EXPLANATION

What's this about pkg-config/.la? I don't know much about it, so how would pkg-config help?

First I must give a warning: I'm not an *.la/pkg-config-expert myself. That is why I asked for help on #debian-mentors. And as I said before I was advised by the mentors there to avoid *.la-files if possible.

Now a few points on *la/*.pc:

1. Currently GemRB ships a lot of libtool library files (*.la) which aren't required. As far as I understand that, you only need those files to link against the respective library. So problably the only one needed is the libgemrb_core.la file. (a list of all *.la files currently installed by GemRB can be found below).
   
2. The *.la files tend often to increase the number of dependencies significantly (especially unused ones (displayable with ldd --unused) or dependencies only needed for static linking (¹)). Which makes it difficult to get a small system. pkg-config allows a finer adjustment of dependencies. It allows to define private dependencies, which are only used when you link statically. You can define dependencies for a library and pkg-config will add them accordingly. If you pass all the highest-level requirements of your code to pkg-config it will output the shortest list of dependencies possible (they call it compressed). When used in conjunction with "-Wl,--as-needed" »ldd --unused« shouldn't have much to report.
   
3. pkg-config is platform-independent (it can be used on Linux, Windows, Mac OS X) while the GNU libtool is more at home on Unix environments.
   

That is probably a very incomplete list. I'll promise to write down something more conclusive. But now I need to go to bed.

 

¹ la files contain the name of the library and some information on the version, so the dependencies must be figured out by getting the information from the library itself.

For example if you have a look at the pc-file for libfontconfig, you find, that the expat dependency is declared private. If you ask ldd (or objdump -p /path/to/lib | grep NEEDED), it's just another dependency. So pkg-config would spare us at least one dependency if linked dynamically to libfontconfig.

 

And before I forget to mention it: I filed the ITP (Intent To Package) today, you can have a look at it under http://bugs.debian.org/477376. The other progress can be seen in the SVN (for links see Part 1 & 2).

 

Greetings,

Drizzt

 

The list of *.la files:

./usr/lib/libgemrb_core.la

./usr/lib/gemrb/libGUIScript.la

./usr/lib/gemrb/libSDLVideo.la

./usr/lib/gemrb/libZLibMgr.la

./usr/lib/gemrb/lib2DAImporter.la

./usr/lib/gemrb/libACMImporter.la

./usr/lib/gemrb/libNullSound.la

./usr/lib/gemrb/libAREImporter.la

./usr/lib/gemrb/libBAMImporter.la

./usr/lib/gemrb/libBIFImporter.la

./usr/lib/gemrb/libBMPImporter.la

./usr/lib/gemrb/libPNGImporter.la

./usr/lib/gemrb/libCHUImporter.la

./usr/lib/gemrb/libCREImporter.la

./usr/lib/gemrb/libDLGImporter.la

./usr/lib/gemrb/libEFFImporter.la

./usr/lib/gemrb/libFXOpcodes.la

./usr/lib/gemrb/libIWDOpcodes.la

./usr/lib/gemrb/libPSTOpcodes.la

./usr/lib/gemrb/libGAMImporter.la

./usr/lib/gemrb/libIDSImporter.la

./usr/lib/gemrb/libINIImporter.la

./usr/lib/gemrb/libITMImporter.la

./usr/lib/gemrb/libKEYImporter.la

./usr/lib/gemrb/libMOSImporter.la

./usr/lib/gemrb/libMUSImporter.la

./usr/lib/gemrb/libMVEPlayer.la

./usr/lib/gemrb/libPLTImporter.la

./usr/lib/gemrb/libPROImporter.la

./usr/lib/gemrb/libSPLImporter.la

./usr/lib/gemrb/libSTOImporter.la

./usr/lib/gemrb/libTISImporter.la

./usr/lib/gemrb/libTLKImporter.la

./usr/lib/gemrb/libWEDImporter.la

./usr/lib/gemrb/libWMPImporter.la

WHY MULTIPLE POSTS?

Because I'm (as a non-registered user) not allowed to have more than one link in my posts even if the system tells me something about two...

[Avenger]

The *.la files are not used by the binary.

If they are in the binary download, then you may remove them, but i always thought they are only a side-effect of compilation.

[billb]

The *.la files are not used by the binary.

If they are in the binary download, then you may remove them, but i always thought they are only a side-effect of compilation.

 

I was looking into making an RPM again last night and found someone had recently updated a spec file for 0.3.0 -- it can be found here.

 

It uses two patches:

gemrb-useless_files.patch

gemrb-config_file.patch

 

So ... this should make the job of getting an RPM built for YDL 6 / PS3 easier...

 

I thought I'd post the info in this thread in case any of it is useful for making the Debian package as well.

[Guest Drizzt]

The *.la files are not used by the binary.

If they are in the binary download, then you may remove them, but i always thought they are only a side-effect of compilation.

I can't say anything for the binary download. I was speaking of the results of calling make & make install. So it would have been in the Debian package. But as I said before, they are only used by the linker and thus were (in my opinion) only suitable for a *-dev package.which resulted in the advise of the mentors. And thinking about it: if I should want to write a new plugin for GemRB, then I would normally have to link against libgemrb_core, right? If so, it would be certainly nice to ship a *.pc file in a *-dev package.

 

I was looking into making an RPM again last night and found someone had recently updated a spec file for 0.3.0 -- it can be found SPEC-LINK REMOVED

 

It uses two patches:

LINK TO PATCH »gemrb-useless_files.patch« REMOVED

LINK TO PATCH »gemrb-config_file.patch« REMOVED

 

So ... this should make the job of getting an RPM built for YDL 6 / PS3 easier...

 

I thought I'd post the info in this thread in case any of it is useful for making the Debian package as well.

Thank you very much, I appreciate it. If you like to see (my commited) stuff, have a look at the aforementioned SVN. It's very small, as it contains only the debian directory.

I'll don't use the »useless_files« patch, because I'll ship the documentation in an extra package.

The other one I'll might use partially/modified. Because, the in-detail configuration shall be handled per game by debconf.

 

Greetings,

Kai

 

P.S.: Hopefully today or tomorror you'll find the gcc 4.3 patch in the SVN. But today I have little time to work on the package.

P.P.S.: If some forum moderator/administrator can change the title of the topic, than I would be happy to reflect it, that you can get also information on the RPM here.

[Guest Drizzt]

A few updates:

• Unfortunatly I had a very busy week(-end), so not much was done to get GemRB in shape, but I'm on it. I'm currently testing locally the gcc-4.3.-patch to enable building with gcc 4.3
  
• As you may know, the Debian project plans to release its next version in September, so we're now likely to enter the freeze for non-build-essential packages every day (as soon as the Python (2.4 -> 2.5) and the Perl (5.8 -> 5.10) transistion has finished). You'll certainly understand, that the Release Team doesn't like late entrants, which means, I'll probably hold my upload to mentors.debian.net* a while back (or change the distribution to experimental) to not disrupt the release in any possible way.
  
• I've spotted a few fixes for PPC in the SVN, so I'll backport them to get as much architectures supported as possible with the latest GemRB release (don't mind, that is common Debian practice, so until there will be a new release, I'll backport patches to the current upstream release in Debian).
  

* As I'm no Debian Developer, I'm not allowed to upload any package directly to the Debian Archives. Which means I must ask for sponsorship on debian-mentors. And the preferred way to make your source packages available is to upload them to http://mentors.debian.net/.

 

Greetings,

Kai aka Drizzt