Am 21.02.2016 um 16:40 schrieb Phil Morrell: > 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. [...] Hi, don't hesitate to commit updates, improvements, new upstream releases and patches. If you think you can provide a fix for a bug, just do it and push your changes and ask for review and sponsorship on this list. > 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? Yes importing the archives source is reasonable. gbp import-dsc simplifies this step. > 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 would keep the watch file but add a comment to it and explain the situation. Just remove the obsolete URL. > 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? I'm sure that's a good idea. No matter how small the change, it is good to include it now because someone else might miss this issue in the future. I usually run gbp dch to automatically create the changelog before uploading but you can also manually add your changes to the changelog to ensure that your update will be credited. > 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. No matter how small the change, if it is the right thing to do, do it. > 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. I think NetBSD is still improving bsdgames, so it's probably not completely dead. This package definitely needs some love. I would start with triaging the ~40 bug reports, sync with NetBSD and other BSD derivatives, clean up the Debian packaging and try to fix as many bugs as possible. It is your decision if you want to become the new upstream developer for bsdgames but it would also help to keep the existing sources and apply more Debian patches and then try to find out if it makes sense to forward them to NetBSD. Whatever you think is the better approach. Cheers, Markus
Attachment:
signature.asc
Description: OpenPGP digital signature