[pkg-ggz-maintainers] Build problems

Josef Spillner josef at ggzgamingzone.org
Thu Jan 12 19:41:44 UTC 2006


Hello,

El Martes, 10. Enero 2006 18:11, Peter Eisentraut escribió:
> I've tried to build libggz, which works, but only the first time.  On
> the second time, the clean target does not work correctly so the build
> fails.
>
> The following patch fixes that:
[...]

Oh, thanks. But this was added for the reason, that lintian complained about 
these files still being present. So maybe there's another target to remove 
them?
Let me quote the lintian warning:

=====
W: libggz source: configure-generated-file-in-source config.status
N:
N:   Leaving config.cache/status causes autobuilders problems. config.cache
N:   and config.status are produced by GNU autoconf's configure scripts. If
N:   they are left in the source package, autobuilders may pick up settings
N:   for the wrong architecture.
N:
N:   The clean rule in debian/rules should remove this file. This should
N:   ideally be done by fixing the upstream build system to do it when you
N:   run the appropriate cleaning command (and don't forget to forward the
N:   fix to the upstream authors so it doesn't happen in the next release).
N:   If that is already implemented, then make sure you are indeed cleaning
N:   it in the clean rule. If all else fails, a simple rm -f should work.
N:
N:   Note that Lintian cannot reliably detect the removal in the clean
N:   rule, so once you fix this, please ignore or override this warning.
N:
=====

But in fact, this warning doesn't appear after applying the patch. It did 
appear though (maybe for another package).
In my opinion the autobuilders should run "make distclean", because they need 
to re-run configure anyway. And distclean removes these files.

> I see that the master copy of rules.common.mk is in ggz-utils, but
> where does the changelog go?  ggz-utils has its own changelog but
> is that actually a package of its own?

There is no "master copy", in fact the one in ggz-python is currently the 
latest version (with patch support). I agree these files should be synced. In 
GGZ SVN we have a script (playground/maintenance/synchroniser.py) which takes 
care of such commonly used files. The reason for its creation is that SVN 
does not support svn:externals on a file level yet, but only for directories.

And yes, ggz-utils is a package :-)
It contains ggz-cmd, telggz, a collection of MOTD files and the metaserver 
(for server admins) and ggzcomm (for developers). Since ggzcomm is written in 
Ruby, it depends on ruby, but otherwise only on GGZ libraries and libc.
(ggzcomm was written in C initially, but it's sort of an IDL compiler and 
writing such programs in C is a real pain...)

The metaserver is probably the next candidate for a rewrite. ggz-cmd and 
telggz are not actively maintained but they do their job so that's ok.

Josef

P.S. Tobias König told me that the OpenSync people are looking at libggz as a 
possible networking library they could use. So if the packaging is otherwise 
ok (except for the bug above), that would be great news.

-- 
The GGZ Gaming Zone - http://www.ggzgamingzone.org/



More information about the pkg-ggz-maintainers mailing list