Bug#1026277: ITP: quadrilateralcowboy -- first-person cyberpunk adventure game
Followup-For: Bug #1026277 On Sun, 28 May 2023 16:50:31 +0100, James wrote: > * 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). 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)
Processed: owner 1024683, retitle 1024683 to ITP: helix -- efficient console-based modal text editor
Processing commands for cont...@bugs.debian.org: > owner 1024683 ! Bug #1024683 [wnpp] RFP: helix -- A modal text editor, inspired by Kakoune/Neovim, written in Rust Owner recorded as Jonas Smedegaard . > retitle 1024683 ITP: helix -- efficient console-based modal text editor Bug #1024683 [wnpp] RFP: helix -- A modal text editor, inspired by Kakoune/Neovim, written in Rust Changed Bug title to 'ITP: helix -- efficient console-based modal text editor' from 'RFP: helix -- A modal text editor, inspired by Kakoune/Neovim, written in Rust'. > thanks Stopping processing here. Please contact me if you need assistance. -- 1024683: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024683 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: summary 1024683 10
Processing commands for cont...@bugs.debian.org: > summary 1024683 10 Summary recorded from message bug 1024683 message 10 > thanks Stopping processing here. Please contact me if you need assistance. -- 1024683: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024683 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1024683: ITP: helix -- efficient console-based modal text editor
Control: owner ! Control: retitle: ITP: helix -- efficient console-based modal text editor Release 23.05 succesfully builds as an unofficial draft package, embedding 68 crates (57 missing, 1 unwanted, 10 outdated) which needs to be packaged before this can officially enter Debian. Hi Laurent! I have taken the initiative to create a draft packaging of Helix. You are quite welcome to collaborate with me on maintaining it, and/or help by packaging some of the crates still missing in Debian. I am not in the Rust team, since we disagree on the style of packaging. That should not hold you back from working in that team on crates needed for Helix. If you - or anyone else reading this - is interested in collaborating directly on Helix packaging for Debian, then please join its Salsa project here: https://salsa.debian.org/debian/hx If you want to work on simpler tasks then please join the Rust team and work with them on packaging some of the crates needed for Helix: https://salsa.debian.org/debian/hx/-/blob/debian/latest/debian/TODO NB! If you choose to help by packaging needed crates, then please file an ITP bugreport for each crate that you package, as that helps coordinate our efforts. I mention this because the Rust team consider it superfluous to file ITPs for crates, but I disagree: It really is helpful for coordinating efforts. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1030835: [debian] ITP: ruff -- linter for Python, written in Rust
Hi James — yes of course, feel free to list me as the upstream contact. Thanks for checking. Best, Charlie > On May 28, 2023, at 12:09 PM, James Addison wrote: > > Followup-For: Bug #1030835 > X-Debbugs-Cc: charlie.r.ma...@gmail.com > > Hi Charlie, > > I'd like for 'ruff' to be packaged in Debian at some point, and am beginning > that process, although it could take some time (I'm not all that familiar with > Rust yet, and from what I've learned about the Debian rust utilities, > automated > packaging is available for cargo-installable codebases, but is a more manual > process otherwise. I've found and will follow the issuetracker item[1]). > > Would you be OK with being listed as the upstream contact for a Debian 'ruff' > package, if-and-when it becomes available? > > (as context: generally the Debian package maintainer will handle and filter > bugreports from Debian users without any need for your involvement (although > you could subscribe to activity if interested). In some cases they could then > contact you with details about problems found and/or fixes discovered. When > that process is working effectively, it should be mutually beneficial. > > Cheers, > James > > [1] - https://github.com/RustPython/RustPython/issues/4179
Bug#1030835: [debian] ITP: ruff -- linter for Python, written in Rust
Followup-For: Bug #1030835 X-Debbugs-Cc: charlie.r.ma...@gmail.com Hi Charlie, I'd like for 'ruff' to be packaged in Debian at some point, and am beginning that process, although it could take some time (I'm not all that familiar with Rust yet, and from what I've learned about the Debian rust utilities, automated packaging is available for cargo-installable codebases, but is a more manual process otherwise. I've found and will follow the issuetracker item[1]). Would you be OK with being listed as the upstream contact for a Debian 'ruff' package, if-and-when it becomes available? (as context: generally the Debian package maintainer will handle and filter bugreports from Debian users without any need for your involvement (although you could subscribe to activity if interested). In some cases they could then contact you with details about problems found and/or fixes discovered. When that process is working effectively, it should be mutually beneficial. Cheers, James [1] - https://github.com/RustPython/RustPython/issues/4179
Bug#1026277: ITP: quadrilateralcowboy -- first-person cyberpunk adventure game
Followup-For: Bug #1026277 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 MMDD) - 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).
Bug#1036863: ITP: perlnavigator -- language server (LSP) for Perl
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Javascript Maintainers , Debian Perl Group -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: perlnavigator Version : 0.5.5 Upstream Contact: bscan * URL : https://github.com/bscan/PerlNavigator * License : Expat Programming Lang: JavaScript, Perl Description : language server (LSP) for Perl Perl Navigator Language Server provides syntax checking, autocompletion, perlcritic, code navigation and hover for Perl. . Implemented as a Language Server in NodeJS using the Microsoft LSP libraries along with Perl doing the syntax checking and parsing. This package will be maintained collaboratively in the JavaScript team (since build framework is NodeJS), but with conventional "node-" prefix only in provided virtual package name as it is mainly an application. Cc'ing Perl team since its use relates there. It will be maintained at Salsa, here: https://salsa.debian.org/js-team/perlnavigator -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmRy+yAACgkQLHwxRsGg ASGsmhAAiDJ/2pYjjJhsUPly4nl3vracp7pIECwiq+mhVoHqbjyQc54BFm+kSznn ijDmdbpYWcSMkW5esQkAwNj6c6DFLQqDgVcDSHSPr6NJrh0yLMSBg5uveXsO11Aj a3N/uHt6Iq9m1yppS2B/yqffWfqFCn6CAWHV7Kfb+LIDniczExA0Kq5Gpk+v+/Y+ /gYj+qP0Y6dLrRt/DGVbH2dPuWiQb89EBShha3VZHE106REr4Xin5sqm0LRWvk3O TcDg/3bq1xkYcyMX3pi/mXiue1ewF2Udi3sKlHbH3NWwMF8S0TAzaNlF6ZhmKJlJ w+nRXGp83EqOrrsWRxhDh7pfWE2+y0p6PM+03Iq8eH9JDFRx8+dgUoOG6fUF6un1 Oa+i6uqCt15HHkENlf/iH8ChsIQxgaUM664AGe2MyqhTLIkaYX3VJd8WaptZ+x1h eODF4VZaS/27V4gaBMKiHnr+ugEVXQWQsxv6QmzmxedNAXdY6aeqEDFkL0PhBdL8 Fn4C3kG+I2mPnxa/GhFu/D1i/k1Xw+HLc+sDu02zBYzvxKOn3HddUvyr5UFjqN8s 7r6nPYGSbpAJs5dqYZvWPCUhqsrFmi3BGkVa6ZoFjrBln6VBWguhrGFWBmw+uZL8 hBbPgci53rA3jEgdZ8Pj/RgpExHCCBivKeYp1/sl0XrClKcQGJU= =hcck -END PGP SIGNATURE-
