Contribution help and advice
Hi all, I'd like to help out with packaging tasks, but I'm a lurker by
habit, so I thought I'd post my partial actions so far and hope for
some advice on next steps/debian etiquette. Please feel free to answer
just a part of my email, that would be very useful in making progress
in even one area as I'm a bit frustrated.
corsix-th 0.50: This is where I started, it's still in the new queue,
but I run Jessie so I backported and built it with gbp, needed to
change dependencies to use ffmpeg rather than libav, committed and
pushed to branch - success!
game-data-packager 44: I needed to install the media, but version in
Jessie is just older than the massive refactor with heavy development
in the last year, so again backported it locally. After downloading
from GOG.com, I had a 2.1.0.8.exe, but g-d-p expected v2.0.0.5, so I
manually extracted its contents and pointed g-d-p at the directory
instead, which built the media deb fine and I could now play the game
with corsix-th. I have the hashes etc. for theme-hospital.yaml, should
I add it as an alternative in `files:`, or simply replace the 2.0.0.5
lines, or is that even a contribution the project welcomes given that
once you have the deb, you're unlikely to need to re-download the exe?
lgogdownloader 2.26: backported, useless to me due to upstream #70,
but fixed in a single commit 8780b9c, which I put in debian/patches
and rebuilt. Upstream have not made a release since October, though
their usual cadence is a couple of months. Should I report this bug
against the debian package, commit and push the debian patch (to be
removed after next release) or simply ask upstream nicely to tag
another release and bump the version?
At this point I started looking for some small thing I could do
successfully (I even like simple tidying work) and I really like
tracker.d.o. Once I ran out of the above three packages, I perused the
debian team qa ordered by popcon, is this just an unhelpful approach
to take as I had a lot of questions about various packages or is it
just I should have more confidence? If I come across a package with
recent activity, is it polite to email them direct with proposed
changes/notify after committing, cc debian-devel-games?
https://qa.debian.org/developer.php?email=pkg-games-devel%40lists.alioth.debian.org
game-data-packager:
* lintian - dep5-copyright-license-name-not-unique line 790 is
CC-BY-SA-3.0-US which is only referenced on line 191 with an "or
LGPL-3" and a summary paragraph - not sure what this means, is it a
conflict between the "or" and the paragraph, or would it normally be
ignored?
* patch - 798816 pretty sure this is just an oversight during cloning
(#75) and so I should email the bug with `control: tag -1 -newcomer
-patch` but I only though of this today while writing this email, so a
quick confirmation that's correct would be welcome.
* help - can't help with either of these
* freespace2 - 784953 both URLs download fine with a fresh IP 784952
appears to be fixed in (at least) v44, but maintainer is asking for a
better long term solution (no response for 6 months), should the bug
still be closed? Is it expected that maintainers will stop bugs
closing if they want, or would it be better to clone it? Additionally
running `game-data-packager freespace2` fails immediately after on
mod.ini "Response was not JSON", should I raise a fresh bug for this?
openal-soft: new upstream - only needs a package upload, changelog
up-to-date in Dec so ignore for now, presumably maintainer is still
getting round to it
fairymax/xboard: git is behind jessie, untouched since freeze, is it
reasonable to use the archives source to update the git repo, then
look into new upstream?
freealut: uscan dead upstream (6yrs), a discussion for homebrew now
uses debian sources as the latest mirror. What normally happens in
this scenario (the software still obviously works), should the watch
file be removed from SVN or is there a way to mark it as gone? I
realise that's also too small an issue to trigger a new version
upload, so will it just remain action needed forever? Would it still
be best to make the change in SVN anyway, so if a larger issue did
come up, this minor thing would be automatically fixed for the
maintainer?
enet: lintian package-needs-versioned-debhelper-build-depends seems a
trivial fix overlooked during multiarch, but by this point I'm too
scared of making simple changes in VCS in case that's annoying for the
maintainer.
bsdgames:
* new upstream - dead link, again debian seems to have become the
upstream for many years, so same questions as for freealut?
* patch - a lot of these are due to a lack of upstream, with the
previous maintainer avoiding putting the functional changes in debian
packaging, would it be reasonable to fork the code, publish it to
github, tell the original porter and maintainer, declare myself as
upstream, merge some non-breaking changes and create a new watch file?
Alternatively, the debian package already contains a number of patches
which belong upstream, so could just keep extending the series
forever? Here's a very concrete example:
234107 I can solve the two blockers mentioned by upstream - I could
re-write the patch against latest master and I found the official
character list, which includes the '@' proposed by the patch. It was
at this point I decided to stop and email debian-devel-games asking
for help.
If you've reached this far, sorry for the long email, I would
appreciate any guidance you can give on any of the points above.
--
Phil Morrell
Reply to: