Bug#1012289: Bug #1012289: Following up on Lintian
Hello, On Wed, 27 Dec 2023 18:54:14 + Simon Quigley wrote: > In most recent Ubuntu cycles, I've taken on the "archive bootstrapping" > responsibility of adding the new Ubuntu codename to Lintian. I remember > having some deeper conversations with the former Lintian maintainer > regarding further contributions and maintenance, but I also recall some > politics, and quite frankly, *I don't care*. Regardless, Lintian is > something I look at every cycle. Same. > I'm writing today to express my concern about the current state of > Lintian maintenance. I already understand that there is an RFH filed > against Lintian, but that has not received any sort of followup since > 2022. The most recent Lintian upload is from March 2023, and as of the > time of writing, there are 26 open merge requests[1]. Currently, there are quite a few merged patches ready in VCS as well, including the one I'm interested in (added support for loong64). Just being able to actually release new version of lintian would be nice. > I also understand that this is a volunteer team. My goal here is not to > diminish the work of the current maintainers in any way, quite the > opposite. I would simply like to ask, "do you need help?" I'm pretty sure we need hands on lintian and I'm willing to help as well. > I'm not volunteering to take over Lintian entirely, nor do I want to. > That being said, I would be motivated to sort through the current MR > list and at least shave off some technical debt. If this is something > you are open to, or if anyone else would be open to this as well, I > think it is a worthwhile effort. Same. My perl-fu isn't strong enough to take over maintainership of core package in perl. > Lintian is crucially important for Debian development as it stands > today. Before sponsoring a package, before uploading our own packages, > and even once in the archive, we run Lintian all the time. I do not > believe it is too late to put some additional minds behind this, to > ensure Lintian survives for years to come. I simply feel as if *someone* > should bump this thread, so we do not lose sight of it. Agreed, lintian is crucially important. What we need is a perl magician willing and able to do the actual lintian release. Who wants to get blamed for breaking a core tool? :) Then folks like you and me can help with fixing individual issues and/or merging MRs. > Thank you for your time. Please do let me know if you have any > questions, or if I can do anything else to help. Thank you for bumping this, we need to get this sorted one way or another. Cheers, Jakub Ružička signature.asc Description: PGP signature
Bug#1054236: ITP: python-nvchecker -- new version checker
Package: wnpp Severity: wishlist Owner: Jakub Ružička X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-nvchecker Version : 2.12 Upstream Contact: lilydjwg * URL : https://github.com/lilydjwg/nvchecker * License : Expat Programming Lang: Python Description : new version checker nvchekcer (short for new version checker) is a Python library and CLI for checking if a new version of some software has been released. It's a handy tool for querying various sources (such as deb/rpm repos or repology) for software versions. Individual version sources are modular and can be easily reused from python code, making nvchecker useful both as a CLI and as a reusable library. Upstream is friendly and active. I plan to maintain this as a part of PythonTeam.
Bug#1043360: Any progress on ITP: python-poetry-dynamic-versioning?
Hi Roland, in the end, I've replaced poetry by hatchling due to various issues and/or I use dunamai manually in affected projects so I no longer have an incentive/opportunity to package and test poetry-dynamic-versioning. Sorry for not following up on my intent, I'm not sure how to properly indicate this on the wnpp bug I haven't really started with the packaging so feel free to start from scratch. At least python-dunamai made it to testing and I've uploaded latest 1.19.0 to sid today so that you can work with the latest and greatest version. If you need an extra pair of eyes for review or something, let me know. Cheers, Jakub Ružička On 10/10/23 15:09, Roland Mas wrote: Hi Jakub, Is there any progress on the package? A package of mine (dioptas) has started depending on it, so it would be nice to have in Debian. Can I help somehow? Is there any beta code somewhere that I could test and help with? Thanks, Roland. OpenPGP_signature Description: OpenPGP digital signature
Bug#1043360: ITP: python-poetry-dynamic-versioning -- dynamic versioning plugin for Poetry
On 23-08-09 15:08, Colin Watson wrote: > How will this sort of thing work when a git tree isn't necessarily > available at binary package build time, since buildds build binary > packages from a source package rather than directly from git and the > source package doesn't usually include a git tree? Is it just a matter > of causing the plugin to exist so that pybuild doesn't fail, but in > practice the version is still going to be set by something that's > actually in the source package? A primary objective is to provide the plugin so that python3 -m build works in general, not limited to package builds. Supporting pybuild correctly out of the box for projects using the plugin is a next step. I'm not sure how it will behave when no VCS is available as in source package. IIRC it replaces version in pyproject.toml during build. So possibly a mechanism that does the same during package build but from d/changelog version might solve this... Hmmm, sounds non-trivial. This will certainly require some testing.
Bug#1043360: ITP: python-poetry-dynamic-versioning -- dynamic versioning plugin for Poetry
Package: wnpp Severity: wishlist Owner: Jakub Ružička X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-poetry-dynamic-versioning Version : 0.25.0 Upstream Contact: Matthew T. Kennerly * URL : https://github.com/mtkennerly/poetry-dynamic-versioning * License : Expat Programming Lang: Python Description : dynamic versioning plugin for Poetry This is a Python plugin for Poetry and Poetry Core to enable dynamic versioning based on tags in your version control system, powered by Dunamai. Many different version control systems are supported, including Git and Mercurial. Poetry is very popular in the Python world and this plugin makes it easy to use dynamic versioning in Poetry-managed projects. Having this in Debian is a prerequisite for packaging of any projects using poetry-dynamic-versioning. Some of existing packages require this in order to update to latest upstream version which started using the plugin. I plan to maintain the package as a part of the PythonTeam alongside its requirement python-dunamai by the same upstream author. I don't expect this package to be maintenance heavy. signature.asc Description: PGP signature
Bug#1033361: ITP: dunamai -- dynamic versioning library and CLI
Package: wnpp Severity: wishlist Owner: Jakub Ružička X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: dunamai Version : 1.16.0 Upstream Contact: Matthew T. Kennerly * URL : https://github.com/mtkennerly/dunamai * License : MIT Programming Lang: Python Description : dynamic versioning library and CLI Dunamai is a Python library and command line tool for producing dynamic, standards-compliant version strings, derived from tags in your version control system. This facilitates uniquely identifying nightly or per-commit builds in continuous integration and releasing new versions of your software simply by creating a tag. I plan to maintain this nice tool along with poetry-dynamic-versioning from the same author which integrates Dunamai into Poetry as a plugin. I have the packaging ready for review in Salsa repo: https://salsa.debian.org/jruzicka/dunamai Salsa CI is green including lintian and simple autopkgtest. I've wrote a manpage as well. Note that this is the first time I've used poetry-core with pyproject pybuild system and it seems to work, awesome stuff! I'd like to join PythonTeam and maintain this alongside other python projects. FYI at the time of writing, Dunamai is packaged for: * Arch/Manjaro * Fedora >= 36 * nixpkgs >= 22.05 signature.asc Description: PGP signature
Bug#974080: ITP: lua-binaryheap -- Binary heap implementation in lua
On 11/20/20 10:34 AM, Santiago Ruano Rincón wrote: > El 19/11/20 a las 22:04, Santiago Ruano Rincón escribió: >> El 19/11/20 a las 17:56, Santiago Ruano Rincón escribió: >> Before uploading a wanted to take a look at the debian/watch file. >> Attached you can find a work-in-progress version. I cannot work more on >> it today. There is still an error after downloading the file. Would you >> like to fix it? (c.f. man uscan) >> >> Cheers, >> >> -- S >> version=4 >> opts="filenamemangle=s/.+\/v?(\d\S*)\.tar\.gz/-$1\.tar\.gz/,uversionmangle=s/v/./" >> \ >> https://github.com/Tieske/binaryheap.lua/tags .*/version_?(\d\S*)\.tar\.gz > Somehow I messed up my working files (*). The attached (simpler) d/watch > seems to work. Could you please test it? Thanks, it works for me too so I added this to salsa and CI confirms we're free of lintian warnings/infos ᕕ( ᐛ )ᕗ https://salsa.debian.org/jruzicka/lua-binaryheap/-/jobs/1178434#L27 I also signed all commits in debian/master as you suggested elsewhere. > Cheers, > > -- Santiago > > (*) I need to stop working late. I concur, workaholism is dangerous you know... Cheers, Jakub signature.asc Description: OpenPGP digital signature
Bug#974080: ITP: lua-binaryheap -- Binary heap implementation in lua
On 11/17/20 4:41 PM, Santiago Ruano Rincón wrote: > El 09/11/20 a las 13:31, Jakub Ružička escribió: >> Package: wnpp >> Severity: wishlist >> Owner: Jakub Ružička >> >> * Package name: lua-binaryheap >> Version : 0.4 >> Upstream Author : Thijs Schreijer >> * URL : https://github.com/Tieske/binaryheap.lua >> * License : MIT >> Programming Lang: lua >> Description : binary heap implementation in lua >> >> binaryheap.lua is a binary heap (binary tree) implementaion in lua. >> > ... > > Jakub, thanks for packaging lua-binaryheap. Thanks for fast respone, Santiago :) > > Two lintian "major" comments from your current repo: > > W: lua-binaryheap source: ancient-standards-version 3.9.8 (released > 2016-04-06) (current is 4.5.0) > W: lua-binaryheap source: package-uses-deprecated-debhelper-compat-version 9 > > Do you have any reason for that standards-version and > debhelper-compat-version? Upstream packages support older distros including ubuntu xenial so it's just a leftover - I've updated these to current. > > These other lintian minor warnings could be easily fixed: > > I: lua-binaryheap: capitalization-error-in-description lua Lua > I: lua-binaryheap source: debian-watch-file-is-missing > I: lua-binaryheap source: vcs-field-not-canonical Vcs-Git > > Could you please consider them? I've fixed all of them except debian-watch-file-is-missing because upstream is using one the weirdest version tag scheme I've witnessed (version_0v4) and I'm not familiar with watch files enough to solve this efficiently. I've pushed fixed debian/master and you can see lintian output in CI: https://salsa.debian.org/jruzicka/lua-binaryheap/-/jobs/1176088#L27 Thank you for Salsa CI suggestion and help with enabling it. I like it and I'll probably use it for other packages too. Cheers, Jakub signature.asc Description: OpenPGP digital signature
Bug#974080: ITP: lua-binaryheap -- Binary heap implementation in lua
Package: wnpp Severity: wishlist Owner: Jakub Ružička * Package name: lua-binaryheap Version : 0.4 Upstream Author : Thijs Schreijer * URL : https://github.com/Tieske/binaryheap.lua * License : MIT Programming Lang: lua Description : binary heap implementation in lua binaryheap.lua is a binary heap (binary tree) implementaion in lua. - lua-binaryheap package is a missing requirement of lua-http package which is already included in Debian as described in bug #958665 - this package is an indirect requirement of Knot Resolver which I intend to package for Debian. upstream Knot Resolver package repos currntly use custom lua-binaryheap package which I use as a base for the Debian package. - binaryheap.lua is a small and focused project which started in 2015 with last activity in 2019 so I assume it's stable/mature with changes unlikely thus it should be easy to maintain. - I'm not a debian Dev but I try to become Maintainer with active sponsor as a part of Debian DNS team. I'm willing to maintain the package in forseeable future, especially as I expect minimal or no changes.
