OpenTTD in Squeeze
Dear Debian release team,
I'm Remko 'Rubidium' Bijker, the release manager of (upstream) OpenTTD.
I've got good contact with the Debian package maintainer of OpenTTD;
he has actually read and commented on this before sending it to you.
As I am not the Debian package maintainer the diffs and diffstats that
I give/link to do not include changes to the packaging.
As it stand now you are to release OpenTTD 1.0.3 with Squeeze [1]. The
problem with this release is that there are two small, but easily
triggerable, regressions in 1.0.3 over 1.0.2. On the other hand 1.0.3
fixes as (CVE) vulnerability. Due to the design of OpenTTD (the client
performs the exact same tasks as the server and only the actions of
the players are send over the internet) the fixes for these
regressions in 1.0.3 require a modification of both the server and
client side of OpenTTD which means that patching 1.0.3 is not
advisable; such a patch would mean that the Debian patched OpenTTD is
unable to keep in-sync with a non-patched version regardless of which
is the server. So we hope that you are willing to release with OpenTTD
1.0.4.
After reading the "Non-recompilable binaries in source and binary
packages" thread of debian-devel [2] I came to the conclusion that we
(upstream) do not package the sources of two of our binary files
together with the rest of the sources. This means that two binary
files are not compiled by the Debian package and that you are, in
effect, shipping a non-recompilable binary. We maintained the source
of these two binary files in a separate branch of our vcs as most
users did not have the tools, GRFCodec and NFORenum, to compile these.
We will ship the sources of these binary files starting from the 1.0.4
release. The binary files will be automatically recompiled whenever
they are removed as e.g. make distclean does. This will require that
GRFCodec and NFORenum need to be added as build-dependencies.
One big caveat is that we have not released OpenTTD 1.0.4 yet, or
started with release candidates, which means that it will take at
least two weeks before the final 1.0.4 release will be made. Given
that we like to maintain somewhat regular interval in release cycles
1.0.4 is currently planned for 2010-10-01, which I reckon might be too
late to consider including this release into Squeeze. However, for us
releasing before 2010-09-01 is out of the question due to the need of
a release candidate and testing. The question therefore that if you
allow the OpenTTD 1.0.4 release to migrate to Squeeze what the latest
moment for us to release would be, assuming that once released it gets
immediately added to unstable by the Debian package maintainer? I'm
asking this because I don't want to unnecessarily rush the release of
OpenTTD 1.0.4 and thus possibly introduce more regressions, but I
would like to have the fixes into Debian Squeeze and as such I'm
looking for some break-even point where all parties can agree on.
The diffstat [3] from 1.0.3 in the 1.0 branch is already quite huge:
145 files changed, 14829 insertions(+), 1948 deletions(-)
However, much of this are translation updates changes:
56 files changed, 6646 insertions(+), 1576 deletions(-)
and the addition of the sources of the binary files:
39 files changed, 7575 insertions(+), 21 deletions(-)
leaving not much for the actual fixes [4] as can be seen in the
summary of the diffstat [5]:
50 files changed, 608 insertions(+), 351 deletions(-)
This the above data is a snapshot as the final release of 1.0.4 has
not been made.
The upstream changelog for 1.0.4 currently contains 35 fixes, 1
addition (i.e. the missing source code) and the translation updates
are not mentioned. We generally use the point releases for bug fixes
only, although sometimes very small features (by some seen as bug
fixes) get in. For the 1.0.4 we do not intend to include these very
small features.
My next request is about openttd-openmsx [6]. This is a (small) set of
MIDI files that can be played from within OpenTTD. This set was
dual-licensed under GPLv2 and Creative Commons Sampling Plus (i.e.
non-free), with the "note" that if not enough GPLv2 material could be
found the set would use Creative Commons Sampling Plus material and
thus drop the GPLv2 license. This lead to the decision to not package
the set until a clear choice regarding the license was made. The set
is now complete and has had a few GPLv2-only licensed releases. We
would like that openttd-openmsx becomes a Recommends of the OpenTTD
package, which would mean allowing the migration of openttd-openmsx
into Squeeze and OpenTTD. Hopefully the latter can be combined with
the upload of 1.0.4.
openttd-openmsx resides at the moment of writing in NEW.
My final requests are about the packages grfcodec and nforenum. These
packages had their last stable releases in 2007. Those versions were
totally unable to compile the openttd-opengfx and as such nightlies
were put into Debian's archives. The original upstream developer did
not have time any more since begin of 2010, so after our own "MIA"
procedure we got the green light to take over its development. What we
did was test and apply all fixes that were pending for review and
commit by the upstream developer and ask several distributions whether
they had patches and requests for packaging improvements. For example
all downstreams renamed the 'renum' binary to 'nforenum' and the new
upstream adopted that, Debian had some stub man pages so we wrote
proper man pages, and we made a proper "make install" so packagers
don't need to code that themselves.
The releases are respectively 1.0.0 and 4.0.0, however this is done
because of the new maintainers. Feature wise they are way more like a
point release than a major release.
After stripping away the file renames/moves and related include
changes the diff [7] for NFORenum looks with diffstat [8] summarises
to:
20 files changed, 483 insertions(+), 211 deletions(-)
For GRFCodec the diff [9] and diffstat [10] can be summarised as:
28 files changed, 799 insertions(+), 373 deletions(-)
The majority of the NFORenum changes are updates to the current NewGRF
specifications. NFORenum is the tool to check "nfo" files against
those NewGRF specifications. The majority of the changes in GRFCodec
have to do with the "not checking the return type of X" warnings that
some of the newer GCCs like to produce, as such a wrapper for fread
and write checking the return type with the expected return type is
added and that is the majority of those source changes.
Both NFORenum and GRFCodec have been checked on a large range of NFOs
and NewGRFs and in all cases it returned (significantly) less bogus
or wrong warnings than the versions that are currently in Squeeze and
unstable.
A long story short, the questions/requests summarised:
- would you allow the upcoming OpenTTD 1.0.4 to migrate to Squeeze to
fix a few regressions and the omission of several source files? If
so by which date must it have reach unstable?
- would you allow openttd-openmsx to migrate to Squeeze so that
together with (already included) opensfx and opengfx Squeeze will
provide a complete out-of-the box game? (This implies a migration
of a 1.0.3 or 1.0.4 with Recommends: openttd-openmsx set)
- would you allow nforenum 4.0.0 to migrate to Squeeze to include a
normally versions stable release?
- would you allow grfcodec 1.0.0 to migrate to Squeeze to include a
normally versions stable release?
Thanks for your reply,
Remko 'Rubidium' Bijker
[1] http://qa.debian.org/excuses.php?package=openttd
[2] http://lists.debian.org/debian-devel/2010/08/msg00277.html
[3]
http://devs.openttd.org/~rubidium/debian/openttd_1.0.2-1.0.r20521-full.diffstat.txt
[4] http://devs.openttd.org/~rubidium/debian/openttd_1.0.2-1.0.r20521.diff
[5]
http://devs.openttd.org/~rubidium/debian/openttd_1.0.2-1.0.r20521.diffstat.txt
[6] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591930
[7] http://devs.openttd.org/~rubidium/debian/nforenum_r2309-4.0.0.diff
[8]
http://devs.openttd.org/~rubidium/debian/nforenum_r2309-4.0.0.diffstat.txt
[9] http://devs.openttd.org/~rubidium/debian/grfcodec_r2306-1.0.0.diff
[10]
http://devs.openttd.org/~rubidium/debian/grfcodec_r2306-1.0.0.diffstat.txt
Reply to: