* Package name : quadrilateralcowboy Version : 1.0.0 Upstream Contact: Brendon Chung <brendon@blendogames.com> * URL : https://www.blendogames.com/qc/ * License : GPLv3 Programming Lang: C++ Description : first-person cyberpunk adventure game Quadrilateral Cowboy is self-described as "a first-person hacking adventure in a cyberpunk world". The game features elements of programming, automation and puzzle-solving in a variety of 3D environments. Data files for the game are not included in this package and can be purchased from the game's website at https://www.blendogames.com/qc/
Hi folks, This is my first attempt at Debian packaging: I've begun an effort to package the GPLv3-licensed game "Quadrilateral Cowboy"[1][2], and would appreciate help from potential sponsors. It's possible that preparing the package could take a reasonably long amount of time. I've encountered a few build issues[3] and am hoping to resolve those with upstream. The package won't contain any game data -- only the game engine -- and so I'd also welcome best practices around how to make it easy for players to get the game up-and-running after the package is installed. Thank you, James [1] - https://www.blendogames.com/qc/ [2] - https://github.com/blendogames/quadrilateralcowboy/ [3] - https://github.com/blendogames/quadrilateralcowboy/pull/4
If it's a DFSG engine with non-redistributable data, then it will
need to go in the contrib archive area, and please look into teaching
game-data-packager to make an accompanying non-redistributable -data
package on users' systems. Quake 1/2/3, Return to Castle Wolfenstein
and Tyrian are some good examples of games in this situation.
game-data-packager has a declarative language for how to unpack common
archive file types and which data files need to be extracted from them.
If the game data is free to download and there is a convenient download
URL (like Tyrian and the shareware/demo versions of Quake 1 and 2),
then it can do the download and repackaging automatically. If the
game data costs money (like RTCW, Quake 3, and full versions of Quake
1 and 2), g-d-p can extract it from a Steam installation or download
from GOG with lgogdownloader, if applicable. Either way, if the user
has a pre-downloaded copy, they can pass that into g-d-p as a command
line argument.
I see QC is on Steam (should be straightforward) and itch.io (I don't
think we have built-in support for that the way we do for Steam and GOG,
but if someone wants to contribute it...)
<https://salsa.debian.org/games-team/game-data-packager>
The other good way to handle proprietary game data is for the game
to be able to load it from a designated place in the user's home
directory, ideally taking into account freedesktop.org $XDG_DATA_HOME
and $XDG_DATA_DIRS. If the engine has the concept of a search path for
data (like the Quake series do) then the same engine can support both
"install for just me" and "install into /usr" transparently.
smcv
request[1] to add a quadrilateralcowboy-data package entry, and that change has been accepted (although I would still like to confirm that the game data checksums are consistent across the available distribution channels). Packaging for the game's engine (using section: contrib/games) is coming together in a separate Salsa repository[2], and I'll follow some of the Debian mentorship guidelines to progress that. [1] - https://salsa.debian.org/games-team/game-data-packager/-/merge_requests/55 [2] - https://salsa.debian.org/jayaddison/quadrilateralcowboy/
Package: wnpp Followup-For: Bug #1026277 Please note: During the packaging process I've learned that the licensing terms for games derived from Doom3 are an extension/modification of GPLv3 that include additional terms specified by the authors, iD Software. Those licensing terms are included in the work-in-progress package that is pending sponsorship[1] and mentoring. [1] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029409
Based on developing a better understanding of Debian's usertags, I don't think
that the 'help' and 'pending' tags currently apply here, so I'm going to remove
them from the bug. Reasoning below:
* my interpretation of 'pending' is that a package has been prepared and is
ready for an upload, but that an upload hasn't taken place yet for reasons
that are up to the maintainer. I don't think that 'pending' is intended to
apply to packages that don't exist in Debian yet and require review.
* I think that the 'help' tag exists to request additional assistance with a
bug, especially when progress would benefit from extra expertise. I did
think that that is true for my package -- review would help -- but that's
equally true for any other package that is pending review/sponsorship.
Hi Brendon (and with the relevant Debian bug thread on cc), I've uploaded a copy of the packaged quadrilateralcowboy game source - with some small modifications and fixes, including ARM64 support - to the 'mentors.debian.net' pre-review site at https://mentors.debian.net/package/quadrilateralcowboy/ It isn't eligible for inclusion in the upcoming Debian 12 "bookworm" release, but it's possible it could be included in Debian "trixie" (the next release.. each is named after a Toy Story character), if it or another packaging attempt passes review. To confirm: the package contains only the game engine, without any game data; there is, however, separate support provided to make it easier for users with Steam accounts to install the game data if they have already purchased it. Thanks, James
There are a bunch of mistakes that I've made along the way while attempting to
package this game. Some that I'd note are:
* I could've made more of an effort and waiting longer for upstream contact
before listing an upstream email address (sorry for any resulting spam
received at the Blendo Games domain!).
* Related, I could've made clear that I was the upstream source code provider
instead of leaning on an ambiguous Salsa-as-both-origin-and-package-VCS for
a while.
* The number of package uploads to mentors.debian.net was large and noisy;
I was iterating fairly quickly on improvements and adjustments, and had not
yet discovered all the linting utilities available and how to run them
locally.
* Version history is somewhat unclear - there is a mix of what I would call
the 'upstream' version numbers (timestamps in the format YYYYMMDD) - these
are what I have used to tag upstream versions of the code (where no
packaging information exists) and 'package' version numbers (these include
single-digit prefixes, plus a package-version suffix).
This is most relevant in the case of the 20160725 release, which I think
could be the point at where my upstream version begins to more-clearly
diverge from the original Blendo Games codebase (by the addition of a
second architecture).
As part of the packaging process, upstream version 20160725 became version
0~20160725-1 of the package, and I'd consider the changes between there and
1~20160725-1 to be Debian-related: they weren't particularly relevant to my
identity as upstream developer, but they did help the package become more
applicable to Debian's architectures (not all, unfortunately, but I think
that adding support for a second runtime architecture can be a big step
for compiled software).
That change, and the change to add a manual, have been included into the
'upstream' codebase. Strictly speaking, the additional architecture
support probably should've been a patch, followed by merge upstream,
followed by inclusion and then patch-drop in the package. They have been
offered to the 'original upstream' codebase, for possible integration there
if that's something that Brendan / Blendo Games would find useful.
I guess that some remaining confusion arises from the fact that despite
me managing both upstream and Debian packages currently, there are still
patches in the 'debian/patches' directory. That does seem odd to me and I
should probably take another look at including those into the upstream
codebase. I think my original plan with those was to gradually offer them
to 'original upstream' and drop them from the Debian package if-and-when
accepted. Trying to remember/figure out my logic for why not all of them
are offered upstream.. my best guess is that I've only offered ones that I
think were unlikely to cause compatibility difficulties (so changing file
paths, for example, is _not_ offered upstream) with the original. But I
could be retroactively making that up.
* Insufficient testing on the second architecture port - I got it running
incredibly slowly in an emulator -- enough to confirm that it runs,
basically, but not more than that.
* My release signing has been inconsistent, partly because I'm not sure I
have a long-term commitment to being a Debian Maintainer/Developer, and
partly because I'm not sure I can reliably keep those keys secure (so, at
best I think they would provide some integrity verification support, but
I don't think they really attest highly that I'm the sole or uncompromised
author). Not a particularly useful mindset to have, some might argue, but
it does lead to me towards using ephemeral keypairs (somewhere, once, I had
some web-of-trust identity, but I haven't continued to use or maintain it).
All of these are avoidable problems - and in fact most of them are documented,
but I found it tricky to find all of those details and to keep them in mind;
even now I expect I would notice and learn more when reading through the
packaging guidelines again. Generally it's been a good learning experience
though. If any of the problems with the package make it ineligible for some
reason, that's a shame, but I can manage. Otherwise, I'll be glad to fix
things up where required and think about ideas to make those problems less
likely for others to encounter (without reducing resulting package quality).
Followup-For: Bug #1026277 In retrospect, I think this is probably an argument for exploring and learning better signing practices rather than a packaging problem. (also, to nitpick / clarify: when referring to authorship there, that was only in reference to the packaging and edits made from the existing published open source game engine code)
Hi folks, I've been fairly inactive re: Debian contributions since bookworm was released, but would like to get involved again. Would anyone be willing to sponsor my package 'quadrilateralcowboy'? I'd spent a bit of time earlier this year packaging it for Debian, a process that resulted in creation of a fork[1] and a corresponding Salsa repo[2]. The game data is available using game-data-packager, and I've playtested the amd64 build. Theoretically arm64 is available too, but I haven't playedtested that. Cheers, James [1] - https://github.com/jayaddison/quadrilateralcowboy/ [2] - https://salsa.debian.org/jayaddison/quadrilateralcowboy/
Hi folks, I'm looking for sponsors for my package 'quadrilateralcowboy' - the source package is available on Salsa[1] and for inspection on mentors.debian.net[2]. The package is a first-person game that involves elements of programming, and the game data for it is available using Debian's game-data-packager system. (there was an RFS[3] open for this, but it's been archived and I can't seem to unarchive that. I thought reporting against the ITP might be preferable to a duplicate RFS) Thank you, James [1] - https://salsa.debian.org/jayaddison/quadrilateralcowboy/ [2] - https://mentors.debian.net/package/quadrilateralcowboy/ [3] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029409
Package: wnpp Followup-For: Bug #1026277 The ARM64 support mentioned here has been removed, for now; two commits/patches I'd selected to enable it are from a developer (Oliver) who passed away around the end of the year 2012. Based on their written enthusiasm about the game engine and their fork of it that supports ARM64, at the time I felt it acceptable to include those patches, but subsequently I've had moral doubts and am going to try to confirm whether they have next-of-kin or an estate that could indicate whether using those patches is OK from their perspective.
Package: wnpp Followup-For: Bug #1026277 support, but not ARM64 (64-bit ARM) support.