Re: RFC: beat harvester
Hi :)
first of all, sorry for not replying any sooner. I have been to FOSDEM
and am only slowly catching up with stuff..
On Thu, Feb 21, 2008 at 4:58 PM, Alexander Schmehl <tolimar@debian.org> wrote:
> * Richard Hartmann <richih.mailinglist@gmail.com> [080221 03:02]:
> Your versions source versions are 0.4.1 and 0.4.5, but you named the
> orig.tar.gzs beatharvester_b041.orig.tar.gz and
> beatharvester_b045.orig.tar.gz (and least that's how I got them when
> rsync the pkg-games tarballs directory). So dpkg-buildpackage / svn
> buildpackage didn't found it. I created proper symlinks on the tarballs
> directory on alioth for you.
Thanks. I wanted to keep the b out of Debian naming, and apparently
failed at doing so in a good way :/
> You have multiple changelog entries; while there is nothing wrong with
> that, you should always point that out. Backbround is, that unless
> stated otherwise the "changes file" (which is in the end responsible for
> closing bugs) is only generated using the last changelog entry. So if
> you close a bug in a package revision, which isn't uploaded, and create a
> new one, which get's uploaded, the bug fixed with the previous package
> revision isn't closed automatically, unless you tell dpkg-buildpackage /
> svn-buildpackage to include older changelog entries, too.
>
> In general, I would avoid having changelog entries for not uploaded
> package revisions.
I didn't know that. Thanks, I will change it accordingly and keep it in
mind, from now on.
> An other problem might be, if you create a new package revision (e.g.
> -2), while -1 didn't get uploaded, since normally the orig.tar.gz isn't
> included in uploades with package revisions greater -1 (since the
> package systems assumes the orig.tar.gz to be present).
Ouch. Noted.
> According to the upstream changelog, this versions are still beta
> versions; not a problem to have beta versions in the archive, but your
> version number should reflect this. Image the situation, that upstreams
> decided to release a "real" version 0.4.5, while you allready useed that
> version number for a beta version... Beside: I think it's only honnest
> to reflect the "beta" status in the version for our users.
Upstream does not plan to re-use the 0 major number for stable releases
and traditionally keeps stuff in Beta for longer than necessary (the
google definition of Beta).
> Perhaps rename the version to 0.4.5~beta1-1 ?
Upstream might lose the beta with the next release, but if not, yes, sure.
Wouldn't 0.4.5~beta-1 make more sense, though?
> debian/control:
> - your package description is quite short; isn't there anything else
> worthwhile to be mentioned?
Yes and no. It has nice sound effects, but asteroid-clones only have that
much functionality.
> debian/copyright:
> - NO need to point to http://www.gnu.org/licenses/gpl.html, since you
> are allready pointing to /usr/share/common-licenses/GPL-2
> - No need to point to http://creativecommons.org/licenses/by/3.0/,
> since you add the full license text bellow
Does it hurt, though?
> - "All game code, content, sounds and graphics are licenced under CC
> 3.0 BY" I think that's wrong. If I read README.txt correctly, game
> code is GPL 2, not CC 3.0 BY.
Argh, copy & paste failure. Thanks.
> - License for bin/data/Vera.ttf is missing (Do you know you can just
> use "less" on ttf-files, and might be able to extract license
> agreements?)
I am not actually packaging that font, I depend on the package. Do I
still need to add the licence? Or is that because the font appears in
the orig tarball?
> debian/watch:
>
> Doesn't work as expected (but needs to adjusted anyway depending on your
> solution for the beta versions):
> $ uscan --report-status
> Processing watchfile line for package beatharvester...
> Newest version on remote site is 0.45, local version is 0.4.5
> beatharvester: Newer version (0.45) available on remote site:
> http://hectigo.net/puskutraktori/beatharvester/beatharvester_b045.zip
> (local version is 0.4.5)
Will change that, thanks.
> debian/rules:
> - You install your script to /usr/share/games/beatharvester/game.sh ,
> just to symlink it in /usr/games. Would it be easier to just
> install the script to /usr/games?
Sure, no problem. I just copied that approach from other packages and am
not particular about how to do this.
> The game doesn't work at all:
> ============================
> $ /usr/games/beatharvester
> Error: Image file not found: menu-background.png
> Traceback (most recent call last):
> File "run_game.py", line 16, in ?
> main.main()
> File "/usr/share/games/beatharvester/lib/main.py", line 50, in main
> main_menu()
> File "/usr/share/games/beatharvester/lib/main.py", line 28, in main_menu
> selection = m.run()
> File "/usr/share/games/beatharvester/lib/menu.py", line 151, in run
> draw_text(m, rect.center, FONT_SIZE, COLOR_GUI_HILIGHT)
> File "/usr/share/games/beatharvester/lib/gl_render_util.py", line 285, in draw_text
> ret = draw_surface("text_" + string + str(color) + str(bgcolor) + ' ' + str(size), coords, 0, string_image, is_new)
> File "/usr/share/games/beatharvester/lib/gl_render_util.py", line 92, in draw_surface
> GL_RGBA, GL_UNSIGNED_BYTE, surface );
> File "/usr/lib/python2.4/site-packages/OpenGL/wrapper.py", line 924, in wrapperCall
> raise err
> OpenGL.error.GLError: GLError(
> err = 1281,
> description = 'invalid value',
> baseOperation = glTexImage2D,
> pyArgs = [
> GL_TEXTURE_2D,
> 0,
> GL_RGBA,
> 101,
> 24,
> 0,
> GL_RGBA,
> GL_UNSIGNED_BYTE,
> '\x00\x00\x00\x00\x00\x00\x00\x00\x00...
> ],
> cArgs = [
> GL_TEXTURE_2D,
> 0,
> GL_RGBA,
> 101,
> 24,
> 0,
> GL_RGBA,
> GL_UNSIGNED_BYTE,
> '\x00\x00\x00\x00\x00\x00\x00\x00\x00...
> ],
> cArguments = (
> GL_TEXTURE_2D,
> 0,
> GL_RGBA,
> 101,
> 24,
> 0,
> GL_RGBA,
> GL_UNSIGNED_BYTE,
> c_void_p(139007156),
> )
> )
> ============================
>
> Note the first line, the rest seems to be errors based upon it. Not also, that
> /usr/share/games/beatharvester/data/pictures/menu-background.png exists.
That is strange, it did not happen on my local box. Will look at that
with a clean root fs.
> I think that's about it. At least the starting problem and the
> copyright must be fixed, before the package can be uploaded. The other
> points are "shoulds".
Thanks a lot! I will do it all asap :)
Richard
Reply to: