Debian Bug report logs - #793057
ITP: godot -- open source MIT licensed game engine

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Bruno Ramos <brunoramos.lu@gmail.com>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: ITP: godot -- open source MIT licensed game engine

Date: Mon, 20 Jul 2015 23:29:14 +0200

Package: wnpp
Severity: wishlist
Owner: Bruno Ramos <brunoramos.lu@gmail.com>

* Package name    : godot
  Version         : 1.1-stable
  Upstream Author : Juan Linietsky, Ariel Manzur
* URL             : http://www.godotengine.org
* License         : MIT
  Programming Lang: C++
  Description     : open source MIT licensed game engine

 Godot is an advanced, feature packed, multi-platform 2D and 3D game engine.
 It provides a huge set of common tools, so you can just focus on making
 your game without reinventing the wheel.

 Godot has been in development and used in-house by OKAM as early as 2001.
 In February of 2014 the source code for Godot was released to the public
 on GitHub under the MIT License.
 On 15 December 2014 Godot reached 1.0, first Stable release.

- Package to be maintained as part of the Debian Games team
  (http://anonscm.debian.org/cgit/pkg-games/godot.git/)

Message #10 received at 793057@bugs.debian.org (full text, mbox, reply):

From: Julien Cristau <jcristau@debian.org>

To: Bruno Ramos <brunoramos.lu@gmail.com>, 793057@bugs.debian.org

Cc: debian-devel@lists.debian.org

Subject: Re: Bug#793057: ITP: godot -- open source MIT licensed game engine

Date: Tue, 21 Jul 2015 11:05:31 +0200

[Message part 1 (text/plain, inline)]

On Mon, Jul 20, 2015 at 23:29:14 +0200, Bruno Ramos wrote:

>   Description     : open source MIT licensed game engine
> 
That's not a terribly useful short description.  Only the last two words
belong there, IMO.  The "open source" bit is kind of implied by it being
in Debian, and the exact license is what debian/copyright is for.

Cheers,
Julien

[signature.asc (application/pgp-signature, inline)]

Message #15 received at 793057@bugs.debian.org (full text, mbox, reply):

From: e est <mtest31@yandex.com>

To: 793057@bugs.debian.org

Subject: Godot packaging

Date: Tue, 26 Jan 2016 21:18:01 +0100

Hello,

Seeing that this ITP is dead for some time already, what has happened with it? I'd love to see the godot engine in Debian.

Thanks a lot,

est

Message #20 received at 793057@bugs.debian.org (full text, mbox, reply):

From: eylul <eylul@ubuntustudio.org>

To: 793057@bugs.debian.org

Subject: Re: Bug#793057: ITP: godot -- open source MIT licensed game engine

Date: Wed, 2 Nov 2016 17:33:22 +0300

Hi,
I would like to try to help out with this, if possible. Is anyone
actively working on this package?

Thanks

Message #25 received at 793057@bugs.debian.org (full text, mbox, reply):

From: Bruno Ramos <brunoramos.lu@gmail.com>

To: eylul <eylul@ubuntustudio.org>, 793057@bugs.debian.org

Subject: Re: Bug#793057: ITP: godot -- open source MIT licensed game engine

Date: Sat, 17 Dec 2016 20:05:24 +0100

[Message part 1 (text/plain, inline)]

Hello,

I'm sorry for the late reply.

I'm currently not actively working on this, after several tries I always
blocked on some point.
Please take over if you want.

If you need help let me know, maybe I can help you.

Thank you.

Regards,

Bruno

On Wed, Nov 2, 2016 at 3:33 PM, eylul <eylul@ubuntustudio.org> wrote:

> Hi,
> I would like to try to help out with this, if possible. Is anyone
> actively working on this package?
>
> Thanks
>

[Message part 2 (text/html, inline)]

Message #30 received at 793057@bugs.debian.org (full text, mbox, reply):

From: Kienan Stewart <kienan.stewart@burntworld.ca>

To: 793057@bugs.debian.org

Subject: Re: Bug#793057: ITP: godot -- open source MIT licensed game engine

Date: Fri, 4 Aug 2017 15:30:42 -0400

[Message part 1 (text/plain, inline)]

I'm also interested in helping to package godot for debian.

With the current stable of godot (2.1.3-stable), there's an incompatibility with the SSL version shipped in stretch (upstream issue: https://github.com/godotengine/godot/issues/8624)

I was able to build with: scons platform=x11 target=release_debug bits=64 use_llvm=yes builtin_openssl=yes but I'm not sure if this will cause problems

Thanks,
Kienan

[signature.asc (application/pgp-signature, inline)]

Message #35 received at 793057@bugs.debian.org (full text, mbox, reply):

From: Kienan Stewart <kienan.stewart@burntworld.ca>

To: 793057@bugs.debian.org

Subject: Re: Bug#793057: ITP: godot -- open source MIT licensed game engine

Date: Mon, 7 Aug 2017 21:43:43 -0400

[Message part 1 (text/plain, inline)]

I've had a first pass at creating a package for godot : https://mentors.debian.net/package/godot

There are some lintian warnings to clear up, and I was wondering a bit about the following

 * builds only support amd64 at the moment
 * how to handle packaging godot 3.0 when it's available (an alpha is currently out)

Once I find some time to clear up the lintian warnings, I'll do the RFS procedure following the mentor's guide and https://wiki.debian.org/Games/Sponsors/Queue

[signature.asc (application/pgp-signature, inline)]

Message #40 received at 793057@bugs.debian.org (full text, mbox, reply):

From: Francesco Poli <invernomuto@paranoici.org>

To: Kienan Stewart <kienan.stewart@burntworld.ca>

Cc: 793057@bugs.debian.org

Subject: Re: Bug#793057: ITP: godot -- open source MIT licensed game engine

Date: Fri, 25 Aug 2017 19:25:19 +0200

[Message part 1 (text/plain, inline)]

On Mon, 7 Aug 2017 21:43:43 -0400 Kienan Stewart wrote:

> I've had a first pass at creating a package for godot :
> https://mentors.debian.net/package/godot
[...]
> Once I find some time to clear up the lintian warnings, I'll do
> the RFS procedure
[...]

Hello Kienan,
I am a Debian user and contributor interested in seeing Godot packaged
for Debian.

I am afraid I won't have time to actively helping you out in the
packaging effort, but I would like to throw some suggestions in...


I read your three comments on the above-cited mentors.d.o page.


As far as the possible-gpl-code-linked-with-openssl Lintian warning
is concerned, I guess it's really caused by the debian/* licensing.
The general suggestion here is to license debian/* files not only in a
DFSG-free manner, but also at least as permissively as the upstream
software package.
Since Godot is mainly released under the terms of the Expat (MIT)
license, I would recommend you to re-license the debian/* files under
those same terms.

Moreover, I noticed that the upstream github repository includes
a file (named COPYRIGHT.txt) which (except for an initial comment)
seems to be formatted following the machine readable debian/copyright
file specification.
That file could be a good starting point to build the actual
debian/copyright file for the Debian package, of course without
forgetting to check against the actual package content!

I think that thirdparty/* projects should be purged from the orig.tar
archive (after making them unused, obviously!).
If you manage to do so, then you should not need to document their
licensing status. You should just document that they have been removed
by repacking the orig.tar archive...


Regarding the godot2 / godot3 split: if the two are installable side
by side, with no conflict whatsoever, and they are mutually
incompatible, then I think they should be packaged separately as godot2
and godot3, with distinct executable binaries.
But I would first concentrate on one version only (the stable one,
or maybe the alpha one, assuming it is usable enough: you get to
decide...).


Regarding the man pages, I would recommend you report upstream that
they are missing. If upstream developers do not consider this to be
a bug, I would suggest you to write the man pages on the basis of
upstream documentation and to contribute them back upstream
(under the same licensing terms as Godot).
Please see
https://www.debian.org/doc/debian-policy/#manual-pages


That's all, I hope my comments may be of some help.

Thank you for your effort to package Godot for Debian!
Looking forward to seeing the package uploaded to unstable
and ready to be tested.

Bye!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

[Message part 2 (application/pgp-signature, inline)]

Message #45 received at 793057@bugs.debian.org (full text, mbox, reply):

From: Rémi Verschelde <rverschelde@gmail.com>

To: 793057@bugs.debian.org

Subject: Upstream advice on packaging Godot

Date: Thu, 28 Sep 2017 09:51:35 +0200

Hi there,

Godot upstream maintainer here [0], as well as its packager for Mageia
[1] and (soon, pending review) Fedora/RHEL [2] [3]. I thought I'd
chime in to give some more tips about packaging Godot from a fellow
packager's point of view with a good understanding of the upstream
setup :)

Sorry, it's going to be a long post, but Godot is a complex
cross-platform project and packaging it efficiently requires some
explanations on how things are setup.

## Things to build and package

For the reference, here are some tips I sent to debian-devel-games and
fedora-games last year [4]. The packaging structure I proposed back
then is still relevant, albeit I decided to drop the idea to package
the Linux export templates as it's too much hassle for little gain,
when users need to download the upstream templates anyway for other
platforms.

So I suggest that you package Godot this way:
- "godot" package, optimized build of the editor (`p=x11 tools=yes`);
- "godot-runner" package, optimized build of the Linux export template
(`p=x11 tools=no`) - it can then be used directly to run any Godot
game (both from source or from a data pack), which is the best way to
package libre Godot games in the future like Tanks of Freedom,
Minilens or The Diasporic Crypt;
- (optionally) "godot-server" package (`p=server tools=yes`), which is
a headless build of the editor which can be used to do command line
operations in a non-graphical environment (e.g. automating exports to
various platforms), but more importantly power a game's server (as of
Godot 2.1.x I don't know of libre multiplayer game which would need it
though).
- (optionally) "godot-demos" with the upstream demos [5], all MIT licensed.

Regarding your discussion on what version to package, I encourage to
package the stable version (2.1.4), potentially with some backported
patches from the 2.1 branch (see below).
When Godot 3.0 comes out, it might make sense to provide both
(especially if you're packaging some libre games which are not ported
to Godot 3.0+ yet).
How to name the packages is up to you, for Mageia and Fedora my Godot
2.1.4 packaged is "godot". When Godot 3.0 is released, I'll fork it to
a new "godot2" package, and will upgrade the main "godot" package to
version 3.0.

## Licensing and copyright

For the current Godot 2.1.4 release, I've done a lot of work to
properly document the licenses and copyright statements of all source
files included in Godot's source repository. This is all listed in
COPYRIGHT.txt [6] using the Debian machine-readable format spec, and
should be a good base for your own debian/copyright after editing it
to reflect unbundling of vendored libraries (see below).

Note that for vendored thirdparty libraries, I stopped at their "main"
copyright statement and license (typically from COPYING, LICENSE.txt
or the header of their main code files), and did not try to redo all
the work they should be doing themselves to documented code snippets
they took from other license-compatible sources.

## Unbundling thirdparty libraries

For convenience, both to be able to build out of the box for all the
platforms it supports, and to be able to make portable Linux binaries
as export templates, we vendor the libraries that Godot relies upon
[7].

You cannot however simply delete this folder, as some of the
thirdparty code included there is not packaged in Debian (and probably
doesn't need to be). Everything that can be unbundled has a
`builtin_${name}=no` SCons option (you can list them all with `scons
--help`, or check the SConscript [8]).
As we use the bundled stuff by default so that Godot users who build
their own templates from source can have portable binaries, you'll
have to specify the various "builtin_${name}=no" arguments manually.
In the future I intend to add a "packaging" option that will do it
automatically, but haven't got to doing it yet.

Here's how I do it for Mageia/Fedora:
```
# Windows-specific
rm -rf thirdparty/rtaudio
# Use system libraries when available
system_libs=""
for lib in freetype glew libogg libpng libtheora libvorbis libwebp
openssl opus zlib; do
    system_libs+="builtin_"$lib"=no "
    rm -rf thirdparty/$lib
done
```
Then build Godot binaries with `scons $system_libs <other options>`.

### Caveats

After the above step, there are still some vendored MIT-compatible
libraries. See this comment [9] for details about each of them. In
particular:

- libmpcdec and speex could be unbundled, but would require some dev
work. Since they've been removed from the master branch (upcoming
Godot 3.0), I didn't bother. You are however free to remove them and
disable the modules that use them with `module_mpc_enabled=no
module_speex_enabled=no`.
- minizip sadly has some custom modifications which I haven't managed
to get rid of yet, so it's advised to build against the custom code
(the changes are documented in patches included in the source folder)
- the certs bundle needs an update upstream, but it's basically just
the regular Mozilla certs bundle as packaged by distros. It's needed
at built time as it's converted to a header and included directly in
the Godot binaries (which are self-contained), so you can remove it
and symlink it to the corresponding openssl-friendly Debian certs
bundle before building.

I'm of course interested in any feedback or patches that you may have
to improve the current state - the more stuff we can unbundle without
causing troubles for self-compiling users and other OSes, the better.

## Building

Up to the current 2.1.4 release, Godot has three noteworthy caveats
for building:
- Compiling release builds with GCC 6+ leads to potential crashes -
this was a complex issue involving improvement alignment and
preventing any kind of null pointer dereferencing, and it was recently
fixed in the master branch. The changes are quite complex and we
decided not to try to backport them to the 2.1 branch as the focus is
on master and the upcoming 3.0 release.
In the meantime, the 2.1.x releases should be compiled either with GCC
5, or with any version of Clang - only GCC 6+ got stricter about what
we were doing wrong.
- OpenSSL 1.1.0 was not supported in 2.1.4, but there's a later patch
that adds support for it, so you should probably cherry-pick it [10].
- The misnomer `debug_release=yes` option (not to confuse with the
`target=release_debug` which is an optimized binary with -DDEBUG) adds
debugging symbol to the binary - if you handle stripping manually to
extract debuginfo during packaging, you should probably define it.

When building, you can define the `BUILD_REVISION` environment
variable to override the default `custom_build`.
`BUILD_REVISION=debian` is probably a good pick, the resulting version
string will be "2.1.4.stable.debian".

## Dist stuff

The 2.1.4 release lacked an upstream .desktop file, .appdata.xml and
man page. I've added them recently to the master and the 2.1 branches,
you can cherry-pick these commits to get them (in `misc/dist/linux`):
[11] [12] [13]. To apply [11] you'd need to fix a merge conflict, but
you can instead use the patches from my Fedora package [14] which are
already rediffed against the 2.1.4 release.

## Asset Library

I know this might be against Debian policies, so I prefer to mention
it upfront. Godot "calls home" for its Asset Library feature [15],
which is a repository of libre licensed assets, plugins, code
snippets, demos, etc. which can be downloaded directly from the
editor. The downloads themselves are not hosted by Godot Engine, but
retrieved directly from public forges such as GitHub, GitLab, Gogs,
etc. - the content is moderated manually and validated using the
sha256 of the zip archive for a given commit/tag, so if the remote
repo changes after moderation, the download is invalidated.

If this is an issue, the Asset Library can easily be disabled with a
simple patch, I can provide one upon request.

--

That's about it for this already pretty long email :)

As mentioned above, I'm a packager myself and quite aware of Linux
packaging policies (I actually came to Godot initially with the intent
to package it for Mageia, and ended up as the project manager and
releng :)), so I'd be glad to discuss what needs to be improved and to
review patches.
Feel free to contact me either via this bug report, or on the
debian-devel-games ML, or in private if need be.

Librement,

Rémi Verschelde / Akien

[0] https://github.com/akien-mga
[1] https://madb.mageia.org/package/show/source/1/name/godot
[2] https://gitlab.com/snippets/1676357
[3] https://copr.fedorainfracloud.org/coprs/akien/godot/
[4] https://lists.debian.org/debian-devel-games/2016/02/msg00016.html
[5] https://github.com/godotengine/godot-demo-projects
[6] https://github.com/godotengine/godot/blob/2.1/COPYRIGHT.txt
[7] https://github.com/godotengine/godot/tree/2.1/thirdparty
[8] https://github.com/godotengine/godot/blob/2.1/SConstruct#L151
[9] https://gitlab.com/snippets/1676357#note_41250096
[10] https://github.com/godotengine/godot/commit/8d246dfc1d787756d42b3026cb4935bb37d0e49b
[11] https://github.com/godotengine/godot/commit/893ebc54fceae13fe7a0427be5a11601ef30e601
[12] https://github.com/godotengine/godot/commit/514c8ab66cd3137c5d8f0f4f1ea045e12876685e
[13] https://github.com/godotengine/godot/commit/e25c37afa12d96b58a6a2f923d6b077905247f46
[14] http://copr-dist-git.fedorainfracloud.org/cgit/akien/godot/godot.git/tree/
[15] https://godotengine.org/asset-library/

Message #50 received at 793057@bugs.debian.org (full text, mbox, reply):

From: Kienan Stewart <kienan.stewart@burntworld.ca>

To: 793057@bugs.debian.org

Subject: Re: Bug#793057: ITP: godot -- open source MIT licensed game engine

Date: Wed, 27 Dec 2017 13:34:00 -0500

[Message part 1 (text/plain, inline)]

Hi,

I've had a bit of free time to work on this and I've uploaded another version (based on 2.1.4) to mentors.debian.net : https://mentors.debian.net/package/godot

Thank both Francesco and Rémi for your advice in preceeding comments! I've made a number of changes, including having 3 packages as suggested by Rémi.

There are still a couple of small warnings to clear up, in particular I'd like to tackle the debug symbols warning and get the build to use the hardening flags next. I also haven't cherry-picked the desktop/appdata files from upstream yet.

All the changes I made are also available here: https://github.com/kienanstewart/godot/tree/2.1.4-stable-debian

Thanks,
Kienan

[signature.asc (application/pgp-signature, inline)]

Message #55 received at 793057@bugs.debian.org (full text, mbox, reply):

From: Kienan Stewart <kienan.stewart@burntworld.ca>

To: 793057@bugs.debian.org

Subject: Re: Bug#793057: ITP: godot -- open source MIT licensed game engine

Date: Fri, 29 Dec 2017 18:58:02 -0500

[Message part 1 (text/plain, inline)]

I've uploaded an updated package to mentors.debian.net. I think it's ready for more review/testing. I'm also looking for a sponsor if anyone is willing.

Thanks,
Kienan

[signature.asc (application/pgp-signature, inline)]

Message #62 received at 793057@bugs.debian.org (full text, mbox, reply):

From: Tobias Frost <tobi@debian.org>

To: 793057@bugs.debian.org

Subject: Re: Bug#793057: ITP: godot -- open source MIT licensed game engine

Date: Thu, 04 Jan 2018 18:32:35 +0100

Hallo Kienan,

you should also claim ownership of the ITP package
(is it still owned by Bruno, but he said that he is ok
that someone taking over)

Thanks!

Message #69 received at 793057@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupre <anarcat@debian.org>

To: Kienan Stewart <kienan.stewart@burntworld.ca>

Cc: 793057@bugs.debian.org

Subject: Re: Bug#793057: ITP: godot -- open source MIT licensed game engine

Date: Thu, 18 Jan 2018 20:39:09 -0500

[Message part 1 (text/plain, inline)]

On Fri, Dec 29, 2017 at 06:58:02PM -0500, Kienan Stewart wrote:
> I've uploaded an updated package to mentors.debian.net. I think it's
> ready for more review/testing. I'm also looking for a sponsor if
> anyone is willing.

Hi!

I've done a thorough review of the package. I haven't reviewed the
upstream source code or attempted to rebuild the package myself. Here
are the issues I could find by looking in the debian/ directory:

 1. the version number is a little strange: "2.1.4-stable-1" I also
    believe it violates policy (§5.6.12: version), because there is a
    "debian revision" ("-1") so there can't be a dash in the upstream
    revision ("2.1.4-stable"). In general, I believe it is not permitted
    to have two dashes in version numbers: I'm surprised lintian let
    that through, maybe a bug there!

    https://www.debian.org/doc/debian-policy/#version

    i understand you may have chosen the version number to match the
    tarball name from upstream, but we should help upstream to do the
    right thing here. you can introduce them to semantic versioning, for
    example. you can also "mangle" the url in uscan to remove the
    "-stable" string, with something like "versionmangle=s/-stable//".

 2. The VCS fields are present (good) but they point to the upstream
    repository (?) which is fine if you are the upstream, but in this
    case there is a "debian revision", which means this is not a native
    package, which I assume means you are not the upstream. The Vcs-*
    fields should point to a repository where we can find the *debian*
    packaging files, not the upstream repository. That is what the
    Homepage field is for. I would recommend you try out the new GitLab
    instance setup by the Debian project to host that repository, at
    https://salsa.debian.org/

 3. not sure the "this is my first package" note is necessary in the
    changelog :)

 4. debhelper is now at version 11, you might want to take a look at the
    features (in the debhelper(7) manpage) and bump the compatibility level
    in debian/compat and the dependency in debian/control

 5. purely cosmetic, but i like to align the dependencies in
    debian/control. instead of:

       Build-Depends: debhelper (>= 9), clang, scons, libx11-dev, libxinerama-dev, libxcursor-dev, libxrandr-dev, libfreetype6-dev, libpng-dev, libasound2-dev, libpulse-dev, zlib1g-dev, libgl1-mesa-dev, libstdc++-6-dev, libgcc-6-dev, libssl-dev, libglu1-mesa-dev, libwebp-dev, libtheora-dev, libvorbis-dev, libopus-dev, libopusfile-dev, libglew-dev, ca-certificates

    i find the following more readable:

       Build-Depends: debhelper (>= 9),
                      clang,
                      scons,
                      libx11-dev, 
                      [...]

    this makes diffs easier to read for future changes and allows the
    packages to be sorted easily.

 6. in the control file again, i would split the description in
    paragraphs. for example, this:

         Godot is an advanced, feature packed, multi-platform 2D and 3D
         game engine.
         This package allows games to be run from source or data-pack.

    should instead be:

          Godot is an advanced, feature packed, multi-platform 2D and 3D
          game engine.
          .
          This package allows games to be run from source or data-pack.

    also consider having *exactly* the same common description in all
    three packages and just change the last paragraph according to the
    package.

 7. the manpage symlinks in debian/ are strange. why not just list
    "misc/dist/linux/godot.6" in godot2.manpages? i'm not sure how to
    setup manpage symlinks however, but i would suggest finding another
    package that does it and looking at *how* it does so.
    http://sources.debian.net has all the answers once you find the right
    package. :)

 8. debian/godot.manpages probably does nothing and should be removed

 9. now for the patches. the add-openssl-1.1 patch has some template
    stuff that should be removed. it should also explain why the patch
    is necessary (e.g. why isn't it in the upstream release? will it
    ever be?)

 10. the manpage patch has similar issues: is it from upstream? why
     isn't it in the release?

 11. the change-ca-cert-sources-path has the above, plus: isn't it
     possible to use the #thirdparty pattern to do such a replacement
     instead of using a patch? it looks like this is *designed* to be
     configurable from the outside

 12. the remove-thirdparty-ca-certificates patch is a big wth for me...
     if we change the path, why do we need to remove the certs? what's
     that thing with the symlink?

 13. the remove-unneeded-thirdparty-libraries patch is just scary. 32MB
     is just plain wrong. if you want to remove code, you need to
     repackage the tarball. it's nasty and weird, but basically, you
     rebuild the original tarball without all that crap, period. you
     also try to convince upstream to do the same, for example by using
     submodules instead of embedding the code directly. then you explain
     that change in README.Debian (which you partly did). removing those
     libraries in a patch is *worse* than keeping them there: they are
     *still* in the original source and *twice* because they're also in
     that patch! if you want to just disable those things from being
     built, there should be a better way...

 14. debian/rules has some ... interesting things. this is strange, for
     example:

        install -m 755 bin/godot.x11.opt.tools.64.llvm $(CURDIR)/debian/tmp/usr/bin/godot2

     here i would list bin/godot.x11.opt.tools.64.llvm in debian/install
     and then rename the files after dh_auto_install. i would also open
     an issue upstream to propose they install sane binary names.

 15. dh_clean definitly needs work as well. isn't scons -c supposed to
     do all that stuff? if not, there's probably something wrong in the
     upstream and yet another bug can be filed there (and mentioned in
     the rules file). also, use dh_auto_clean there, it may do scons -c
     on its own!

I understand this may be more than you bargained for. It's a lot of
stuff! Not all of those are absolutely essential: some are personal
cosmetic things or missing documentation. But others (like the version
number) are essential.

Think about finding this package in 5 years: you completely forgot how
all of that stuff works and why you did those things. Could you figure
it out again based on what's there? Because that's what someone will end
up doing eventually, if only to help you with package maintenance at
some point... :)

I know this is your first package, and it's already really impressive
work. This is a hard package to start with, and you've already done an
amazing job at getting the thing to build at all and making lintian
happy. Now you need to make FTP-masters and other Debian developers
(like me!) happy, which is, arguably, a little harder when you start
(partly because some rules are unwritten or just written down somewhere
impossible to find). Don't get discouraged, you're doing great, and
you'll get through this. :)

Good luck!

A.

PS: I assume you actually run the thing using the package now? If so,
try to do that as well...

[signature.asc (application/pgp-signature, inline)]

Message #74 received at 793057-close@bugs.debian.org (full text, mbox, reply):

From: Federico Ceratto <federico@debian.org>

To: 793057-close@bugs.debian.org

Subject: Bug#793057: fixed in godot 3.0.6-1

Date: Sat, 24 Nov 2018 23:00:11 +0000

Source: godot
Source-Version: 3.0.6-1

We believe that the bug you reported is fixed in the latest version of
godot, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 793057@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Federico Ceratto <federico@debian.org> (supplier of updated godot package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Sun, 26 Aug 2018 20:42:31 +0100
Source: godot
Binary: godot3 godot3-runner godot3-server
Architecture: source amd64
Version: 3.0.6-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Games Team <pkg-games-devel@lists.alioth.debian.org>
Changed-By: Federico Ceratto <federico@debian.org>
Description:
 godot3     - Full 2D and 3D game engine with editor
 godot3-runner - Godot game engine run-time
 godot3-server - Headless Godot game engine run-time
Closes: 793057
Changes:
 godot (3.0.6-1) unstable; urgency=medium
 .
   [ Federico Ceratto ]
   * Initial release (Closes: #793057)
Checksums-Sha1:
 3d5273776147b31ed32266e4402b9cd32671f1bb 2443 godot_3.0.6-1.dsc
 146f01242fbce9fdab92a5cf3bb185de546dfc76 18958766 godot_3.0.6.orig.tar.gz
 d6ce920b9d8b52946fbf4b4b676b83ef24aaac87 15793 godot_3.0.6-1.diff.gz
 948cfeaad1931739a843e12ec0bf71c678609c9d 120454136 godot3-dbgsym_3.0.6-1_amd64.deb
 a435dbbb9b2d8681d1b18061cbfe50f6ec0e7936 75453032 godot3-runner-dbgsym_3.0.6-1_amd64.deb
 18a6f5b12bf0c49e0166057eb236bac12720ff35 6246476 godot3-runner_3.0.6-1_amd64.deb
 0d5f71a4e852de035a744d64804a63ee0124f13f 117503072 godot3-server-dbgsym_3.0.6-1_amd64.deb
 bf32d64ace85c9097fb3815bbc2bdd12235df8dd 14381000 godot3-server_3.0.6-1_amd64.deb
 d4516fc18616d354d3c61ede098b7582d115d5e3 14703936 godot3_3.0.6-1_amd64.deb
 a4b270a60bba048497af8f440b7d7b2605f704e0 12193 godot_3.0.6-1_amd64.buildinfo
Checksums-Sha256:
 b08a72fcf985136ff1f2f52bb973fe6019a76640bdbb99f70530bed0f0ae2e21 2443 godot_3.0.6-1.dsc
 50431e021ee5ec21002cc23435f530f8fde518c6eb7085c9f7f1027abaae2581 18958766 godot_3.0.6.orig.tar.gz
 1b5a111a4721d0c6ebfa0c34727faa9e8781afa1471e6b152f6a39af27a8e443 15793 godot_3.0.6-1.diff.gz
 ae64ed1d6ae72e0c23def96c6b31d844e10b1da551d154891d4293a2f6ae326a 120454136 godot3-dbgsym_3.0.6-1_amd64.deb
 387628e6e2eeb0d6d6a7e13e98583feb11c22c7f97bcb69cd8e817edd540b501 75453032 godot3-runner-dbgsym_3.0.6-1_amd64.deb
 eaa632257a281d1b2d081245cb084dbf618682259a7704b953c5bd1940662a0f 6246476 godot3-runner_3.0.6-1_amd64.deb
 dcb90eca2fb7563de9714d6e4b1c8f926710be748cd0d1530b55102ff1b155dd 117503072 godot3-server-dbgsym_3.0.6-1_amd64.deb
 bd1faa255d5310a53e17d13fb16bc6242417df033b2fd79f0f7e78e3e219d530 14381000 godot3-server_3.0.6-1_amd64.deb
 03a789ab5af981da54dcbdc4705eb2c601e76080d44b640f4ca128a2c135d092 14703936 godot3_3.0.6-1_amd64.deb
 5db2deb51070e103bf7d3ea0c2174b9ea16f7c1892e550cbd23a008deae1c025 12193 godot_3.0.6-1_amd64.buildinfo
Files:
 193026820f0e75d10b3331dcb3f91ec1 2443 devel optional godot_3.0.6-1.dsc
 65a5951fab5f7404105030b14457618a 18958766 devel optional godot_3.0.6.orig.tar.gz
 63534a299f079fa6231f07b184433be8 15793 devel optional godot_3.0.6-1.diff.gz
 48494fc14fee62a88340aaec8b3cb534 120454136 debug optional godot3-dbgsym_3.0.6-1_amd64.deb
 973f2d1f6ae48375c93a687698ffb4f5 75453032 debug optional godot3-runner-dbgsym_3.0.6-1_amd64.deb
 9df014f66ccc22a4573c3a3f47ea58a1 6246476 devel optional godot3-runner_3.0.6-1_amd64.deb
 1f2128a3a696937ef34946ab3e102466 117503072 debug optional godot3-server-dbgsym_3.0.6-1_amd64.deb
 423f73c06355ea6c1bf161b0ed881391 14381000 devel optional godot3-server_3.0.6-1_amd64.deb
 fedfa0b7c89e91d1ccd5a241a5510089 14703936 devel optional godot3_3.0.6-1_amd64.deb
 d90b2a11a7aa3d0e41bdab3c858f468f 12193 devel optional godot_3.0.6-1_amd64.buildinfo

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEfKfd+zM5IUCMbyuWbzG8RPUXfaoFAluD3n8ACgkQbzG8RPUX
fapU3Q//Txe02nQcS2yc0eLvJhyrzB4je8VOFAMQbcw3G2eGyTJGpsSKyUu5vRgj
9XEX+IJJsQ0JI2mM9YwFIR7MrVCzd78vJYN8FQ3CWVImOI8IaWl2zcwiwfm9f0S3
fFOde4+K0CcMB+pgCYXucvfHa6vl2hfpVKWyA0PqM0cVu7Gh0NTOxhWD6arLMmrZ
X1+hUszaZ0uGHe+rWoBZsiJbG8XLWUhwfTcEk1/mx9Xg1oPeA2br4XiboKEz8I8k
xTxiK3GAlKsWBFBcRiDYjg1mvMrYA/aJNwXoPyCDwM7AXocrYLENeqH79hWAgan9
dXuMBmk7ufnkR1eafG7IRSQvyecqGrBLi7/AjwZq+mTSwy4mxG1bHLbHrqo8foMM
Ypfz9xLGk/Cb0P838z52GohCm729wHYyUACyL/llxjFKfp8BNSy28YNJI3qkgsMV
9fG22MvQaKkJbkgAku3j+FpSoNclyaYAQJi/195/KZx6JxL9KGb2wmFV13PUhB2R
C9RJcYVuWEatYUYCz7DbwOPb2BdCXpNmIGsvR2EodgfiXTCl23pnUrr89G+Bmzub
h19UZBLwI+io/TmLlQ/Ob7/HPK7vVuQok0JxGdh/kJx3Bg+Y2GXc0QrIm3K2rCAW
RxMRpPkdvovuKeokEKxCnX/8BflWIKwukJ/Lc2IEHFTUVdK+8Qg=
=q5Bz
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.