Oh, sorry, I have another question... The Gosu library is not owned by me, so how would I proceed to have it packaged for Debian? Is it really necessary, considering that it's a Ruby gem, publicly available from rubygems.org?
Thanks again, Victor Em seg., 1 de fev. de 2021 às 08:36, Victor David Santos < [email protected]> escreveu: > Hi Paul, > > Thanks for the detailed feedback. Just to make sure, not all of these > items you pointed out are mandatory for the package to be accepted, right? > For example, the fact that my font image doesn't support all character > sets. It's not viable for me to make it support all of them, instead I > would update it on demand as new translations were made... > If you could point out to me which of these are changes I must do, that > would help a lot... I don't have as much time to dedicate to this project > as I would like. :/ > > Thanks, > Victor > > > Em seg., 1 de fev. de 2021 às 01:55, Paul Wise <[email protected]> escreveu: > >> On Sun, Jan 31, 2021 at 8:36 PM Victor David Santos wrote: >> >> > I would like to distribute my open source platformer game in the >> official Debian repositories. >> >> Please review our guide for new package maintainers: >> >> https://mentors.debian.net/intro-maintainers >> >> Some things you might want to think about before working on this: >> >> The game appears to be GNU GPLv3 and CC-BY-SA-4.0 rather than MIT >> licensed. >> >> I thought Ruby could load code from multiple files, maybe using >> modules or similar, so deb.sh and bundle.rb probably are unnecessary? >> >> gosu and minigl aren't yet in Debian, so you would need to package >> those for Debian first. >> >> It might be interesting to package the editor too so people can add >> their own levels. >> >> If you update the code/data and release a new version, the screenshots >> could get outdated, creating them at build time can avoid this. >> >> You might want to switch from your custom i18n/l10n to a more standard >> format like gettext, since that is what most translators are used to. >> >> The images in deb/ and data/ are built from the *.svg and *.aesprite >> files. Some of the *.aesprite files seem to be created from *.svg >> files. That should happen at build time instead of storing the >> prebuilt files in the git repository. >> >> I wonder about where the res/alevaLogo.svg file came from, what it >> refers to and what the license is. It also doesn't appear to be used >> anywhere in the codebase? >> >> I note that data/img/ui/minigl.png was rendered from Inkscape but >> there is no corresponding minigl.svg file. It also doesn't appear to >> be used anywhere in the codebase? >> >> How were the audio files in data/sound/ created? >> How were the audio files in data/song/ created? >> How were the audio files in res/song/ created? >> >> Some of the images contain pre-rendered text, which means that text >> won't be translatable. Also the font image only supports a limited set >> of characters, so the game won't be translatable to non-Latin >> alphabets. >> >> I note that several (res/bombie2.svg, res/BombaAzul.svg, >> res/Fureel.svg, res/tileset/2.svg) of the SVG images contain bitmaps, >> so that means they won't be scalable if you want to make a >> higher-resolution version. >> >> deb.sh does not contain any bashisms, so it could be POSIX shell >> instead of bash. >> >> There is a typo in elements.rb, replace "seciton" with "section". >> >> There are a few duplicate files, run this command to find them: fdupes -q >> -r . >> >> The path in the .deb should be /usr/share rather than /opt. >> >> The data/*/README.md files have some http links that could be turned into >> https. >> >> The roodi and rubocop Ruby code checkers report some issues at different >> levels. >> >> -- >> bye, >> pabs >> >> https://wiki.debian.org/PaulWise >> >
