Bug#1055242: pkg-config files have empty Version
Package: libsvn-dev Version: 1.14.2-4+b3 Severity: normal The pkg-config files for the libsvn libraries have an empty Version string. E.g.: ... Name: libsvn_client Description: Subversion Client Library Version: Requires: apr-util-1, apr-1 Requires.private: libsvn_wc, libsvn_ra, libsvn_delta, libsvn_diff, libsvn_subr ... (in /usr/lib/x86_64-linux-gnu/pkgconfig/libsvn_client.pc) This makes it hard to e.g. check for what version is present. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libsvn-dev depends on: ii libapr1-dev 1.7.2-3 ii libaprutil1-dev 1.6.3-1 ii libsvn1 1.14.2-4+b3 libsvn-dev recommends no packages. Versions of packages libsvn-dev suggests: pn libserf-dev pn libsvn-doc ii zlib1g-dev 1:1.2.13.dfsg-3 -- debconf-show failed
Bug#1054568: breezy - broken rust regex build-dependency
Hi Peter, Please do go ahead and NMU this. Thanks! Cheers, Jelmer On Thu, Oct 26, 2023 at 04:19:28AM +0100, Peter Green wrote: > Package: breezy > Version: 3.3.4-1 > Severity: serious > Tags: patch > > Breezy build-depends on librust-regex+aho-corasick-dev which is no longer > provided (in either physical or virtual form) by rust-regex. > > Looking at the Cargo.toml files I belive the correct build-dependency is > librust-regex-1+default-dev (>= 1.5.4), after changing the build-dependency > I was able to get a succesful build. > > If there are no objections I will likely NMU this in the not too distant > future. > diff -Nru breezy-3.3.4/debian/changelog breezy-3.3.4/debian/changelog > --- breezy-3.3.4/debian/changelog 2023-09-04 17:39:38.0 + > +++ breezy-3.3.4/debian/changelog 2023-10-26 02:55:52.0 + > @@ -1,3 +1,12 @@ > +breezy (3.3.4-1.1) UNRELEASED; urgency=medium > + > + * Non-maintainer upload. > + * Replace broken build-dependency on "librust-regex+aho-corasick-dev" > +with build-dependency on "librust-regex-1+default-dev (>= 1.5.4)" > +based on the contents of Cargo.toml. > + > + -- Peter Michael Green Thu, 26 Oct 2023 02:55:52 > + > + > breezy (3.3.4-1) unstable; urgency=low > >* New upstream release. > diff -Nru breezy-3.3.4/debian/control breezy-3.3.4/debian/control > --- breezy-3.3.4/debian/control 2023-09-04 17:39:38.0 + > +++ breezy-3.3.4/debian/control 2023-10-26 02:55:40.0 + > @@ -31,7 +31,7 @@ > debhelper-compat (= 13), > librust-pkg-version-dev, > librust-pyo3-dev, > - librust-regex+aho-corasick-dev, > + librust-regex-1+default-dev (>= 1.5.4), > rustc > Standards-Version: 4.6.2 > Rules-Requires-Root: no
Bug#1052319: ITP: rust-analyzer -- LSP server for Rust
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij * Package name: rust-analyzer Version : 0.3.1631 Upstream Contact: Rust Analyzer Developers * URL : https://github.com/rust-lang/rust-analyzer * License : MIT or Apache-2.0 Programming Lang: Rust Description : LSP server for Rust rust-analyzer is an implementation of Language Server Protocol for the Rust programming language. It provides features like completion and goto definition for many code editors, including VS Code, Emacs and Vim.
Bug#1052286: please re-enable building against pkcs5 crate
Source: rust-pkcs8 Version: 0.10.2+ds-7 Severity: wishlist Hello, The pkcs5 crate has entered unstable. Please consider dropping the 2002_pkcs5.patch patch. I've verified that the package still builds without it. This will enable building of the rsa crate. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1051501: provide subcommand that lists debian dependencies for a crate
Package: debcargo Severity: wishlist I've packaged a few Python packages that include rust code. Since they're python packages, I can't just use debcargo. However, it would be great if I somehow use debcargo to extract Debian dependency information from Cargo.toml. Perhaps a subcommand for debcargo that just dumps out a list of Debian dependencies and the features they are relevant for? -- System Information: Debian Release: 12.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debcargo depends on: ii libc62.36-9 ii libcurl3-gnutls 7.88.1-10 ii libgcc-s112.2.0-14 pn libgit2-1.5 ii libssh2-11.10.0-3+b1 ii libssl3 3.0.9-1 ii quilt0.67+really0.66-1 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages debcargo recommends: pn dh-cargo debcargo suggests no packages.
Bug#1043391: debianize crash
Package: lintian-brush On Sun, Jun 25, 2023 at 05:42:11PM +0200, Alexandre Detiste wrote: > I know it's experimental :-) > > url = g...@github.com:dcarp/cmake-d.git > > > > debianize > debianize is experimental and often generates packaging that is incomplete > or does not build as-is. If you encounter issues, please consider filing a > bug. > No upstream repository specified, using upstream source in > /home/tchet/git/cmake-d/ > Switching to packaging branch debian/main. > No upstream releases found, falling back to snapshot. > No upstream releases found, falling back to snapshot. > found 457 deltas to reuse > > > found 457 deltas to reuse > No support in debianize for build system cmake, falling back to default. > Creating core packaging using process_default > Kickstarting from dist tarball. Using upstream version > 0+git20210905.1.34095f2 > Looking for upstream 0+git20210905.1.34095f2 in upstream branch > file:///home/tchet/git/cmake-d/,branch=debian%2Fmain. > Looking for upstream 0+git20210905.1.34095f2 in upstream branch > file:///home/tchet/git/cmake-d/,branch=debian%2Fmain. > Traceback (most recent call last): > > > File "/usr/bin/debianize", line 8, in > sys.exit(main()) > ^^ > File "/usr/lib/python3/dist-packages/lintian_brush/debianize.py", line > 1660, in main > debianize_result = debianize( >^^ > File "/usr/lib/python3/dist-packages/lintian_brush/debianize.py", line > 1098, in debianize > control = process( > > File "/usr/lib/python3/dist-packages/lintian_brush/debianize.py", line > 688, in process_default > kickstart_from_dist(wt, subpath) > File "/usr/lib/python3/dist-packages/lintian_brush/debianize.py", line > 1016, in kickstart_from_dist > result.tag_names) = import_upstream_dist( > ^ > File "/usr/lib/python3/dist-packages/lintian_brush/debianize.py", line > 822, in import_upstream_dist > upstream_branch_name) = import_upstream_version_from_dist( > ^^ > File "/usr/lib/python3/dist-packages/lintian_brush/debianize.py", line > 336, in import_upstream_version_from_dist > locations = upstream_source.fetch_tarballs( > ^^^ > File > "/usr/lib/python3/dist-packages/breezy/plugins/debian/upstream/branch.py", > line 614, in fetch_tarballs > fn = self.create_dist( > ^ > File "/usr/lib/python3/dist-packages/lintian_brush/debianize.py", line > 290, in default_create_dist > return ogni_create_dist( >^ > File "/usr/lib/python3/dist-packages/ognibuild/dist.py", line 162, in > create_dist > return dist(session, os.path.join(export_directory, subpath), >^^ > File "/usr/lib/python3/dist-packages/ognibuild/dist.py", line 81, in dist > from .fixers import ( > File "/usr/lib/python3/dist-packages/ognibuild/fixers.py", line 22, in > > from buildlog_consultant.common import ( > ImportError: cannot import name 'MissingGoSumEntry' from > 'buildlog_consultant.common' > (/usr/lib/python3/dist-packages/buildlog_consultant/common.py)
Bug#1030734: link to upstream bug tracker and repository
Hi Raphael, On Sat, Feb 25, 2023 at 03:53:28PM +0100, Raphael Hertzog wrote: > On Mon, 06 Feb 2023, Jelmer Vernooij wrote: > > A large number of Debian packages now has upstream metadata, including > > links to > > upstream repositories (Repository-Browse) and bugtrackers (Bug-Database / > > Bug-Submit). Would it be possible to link to those from tracker? > > It's of course possible but is there something already extracting all > those values and making them available in a convenient way? Maybe UDD? They're actually already available in UDD: udd=> select key, value from upstream_metadata where source = 'dulwich'; key| value ---+-- Bug-Database | https://github.com/dulwich/dulwich/issues Bug-Submit| https://github.com/dulwich/dulwich/issues/new Repository| https://github.com/dulwich/dulwich.git Repository-Browse | https://github.com/jelmer/dulwich Security-Contact | https://github.com/dulwich/dulwich/tree/HEAD/SECURITY.md (5 rows) udd=> > Otherwise we first need to implement something like that which can be a > bit of a pain. > > Usually the tracker fetches some external file and turns it into PackageData > entries that can then be easily displayed for example with a > LinksPanel.ItemProvider to add links in the "Links" panel on the right. > > If we have to extract the upstream metadata on our own, then we should > modify distro_tracker/extract_source_files/ to extract it and add some > new Task to parse those files after they have been extracted (or do it > directly in extract_source_files but that would be a scope expansion for > that Django application). > > FWIW, I don't plan to work on this (at least not in the short term) but > I'll happily review MR and answer questions. I might spend some time on this, but would appreciate any further hints on where to add this if the information is available in UDD. Jelmer
Bug#1031944: ITP: python-aioredlock -- asyncio implementation of the redlock algorithm
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij * Package name: python-aioredlock Version : 0.7.3 Upstream Contact: Joan Vilà Cuñat * URL : https://github.com/joanvila/aioredlock * License : MIT Programming Lang: Python Description : asyncio implementation of the redlock algorithm This Python module provides an async implementation of the redis Redlock algorithm, which provides a Distributed Lock Manager.
Bug#1021582: closed by Piotr Ożarowski (fixed in 1.0.4-1)
On Tue, Feb 21, 2023 at 06:12:30PM +, Debian Bug Tracking System wrote: > Date: Tue, 21 Feb 2023 19:10:43 +0100 > From: Piotr Ożarowski > To: 1021582-d...@bugs.debian.org > Subject: fixed in 1.0.4-1 > > Source: pytest-aiohttp > Source-Version: 1.0.4-1 > > ups, looks like I hijacked your ITP. Sorry. > If you want to comaintain or take over this package, just update it in > DPT repo. > > I needed this package as a build dependency for another package and > apparently didn't check WNPP close enough No worries, all good - thanks for packaging it! Your package ended up in the archive before I managed to do duplicate work on it. Cheers, Jelmer
Bug#1031679: lintian: d/rules: should suggest using `execute_before/_after_dh_command` instead of `override_dh_command`
On Mon, Feb 20, 2023 at 03:48:00PM +0100, Christoph Berg wrote: > Re: Gioele Barabucci > > execute_after_dh_clean: > > touch this_strange_file > > The downside of this is that it makes backporting to buster-and-older > harder since it doesn't have the required debhelper version yet. It might make sense to only give this warning for packages that are already on >= 13? Jelmer
Bug#1030382: encourage Vcs-Git over other Vcs-* headers
On Thu, Feb 09, 2023 at 02:15:42PM -0700, Sean Whitton wrote: > Hello, > > On Fri 03 Feb 2023 at 05:24PM GMT, Jelmer Vernooij wrote: > > > Package: debian-policy > > Severity: wishlist > > > > Policy currently describes Vcs-* headers as something optional, but stops to > > endorse a particular Vcs. > > > > At this point, it seems uncontroversial to encourage use of Vcs-Git > > specifically here. Apart from technical arguments, it's the vcs that the > > majority of packages in the archive uses - and thus will have the better > > tooling, less of a learning curve for other contributors, etc. > > > > There are very few holdouts of other vcses in the archive. I count 62 > > (ignoring those with an alioth URL): > > > > * 26 on Svn > > * 3 on Cvs > > * 4 on Hg (2 are hg/hg-buildpackage) > > * 39 on bzr (half of these are actually bzr and related packages, which I > > maintain) > > This strikes me as a matter for devref not Policy? I've created a PR for devref - https://salsa.debian.org/debian/developers-reference/-/merge_requests/41 Are you saying that it doesn't belong in policy because it'd be a recommendation rather than a must/should (at this point?), or because it's more about the workflow inside of Debian than package contents? Cheers, Jelmer
Bug#1030734: link to upstream bug tracker and repository
Package: tracker.debian.org Severity: wishlist A large number of Debian packages now has upstream metadata, including links to upstream repositories (Repository-Browse) and bugtrackers (Bug-Database / Bug-Submit). Would it be possible to link to those from tracker?
Bug#1030382: encourage Vcs-Git over other Vcs-* headers
On Fri, Feb 03, 2023 at 06:48:13PM +0100, Bill Allombert wrote: > On Fri, Feb 03, 2023 at 05:24:36PM +0000, Jelmer Vernooij wrote: > > Package: debian-policy > > Severity: wishlist > > > > Policy currently describes Vcs-* headers as something optional, but stops to > > endorse a particular Vcs. > > > > At this point, it seems uncontroversial to encourage use of Vcs-Git > > specifically here. Apart from technical arguments, it's the vcs that the > > majority of packages in the archive uses - and thus will have the better > > tooling, less of a learning curve for other contributors, etc. > > > > There are very few holdouts of other vcses in the archive. I count 62 > > (ignoring those with an alioth URL): > > > > * 26 on Svn > > * 3 on Cvs > > * 4 on Hg (2 are hg/hg-buildpackage) > > * 39 on bzr (half of these are actually bzr and related packages, which I > > maintain) > > I do not quite understand. Surely the package need to use the VCS-* header > corresponding to the VCS used by the repository, whathever it is ? This is not > a matter of preference. Sorry, to be clear I also meant encouraging the use of Git as a Vcs - rather than just of the Vcs-Git header. Jelmer
Bug#1030382: encourage Vcs-Git over other Vcs-* headers
On Fri, Feb 03, 2023 at 06:43:06PM +0100, Jérémy Lal wrote: > Le ven. 3 févr. 2023 à 18:27, Jelmer Vernooij a écrit : > > > Package: debian-policy > > Severity: wishlist > > > > Policy currently describes Vcs-* headers as something optional, but stops > > to > > endorse a particular Vcs. > > > > At this point, it seems uncontroversial to encourage use of Vcs-Git > > specifically here. Apart from technical arguments, it's the vcs that the > > majority of packages in the archive uses - and thus will have the better > > tooling, less of a learning curve for other contributors, etc. > > > > There are very few holdouts of other vcses in the archive. I count 62 > > (ignoring those with an alioth URL): > > > > * 26 on Svn > > * 3 on Cvs > > * 4 on Hg (2 are hg/hg-buildpackage) > > * 39 on bzr (half of these are actually bzr and related packages, which I > > maintain) > > > > Could this remark also address the fact that in most cases, > Vcs-Git == Vcs-Browser, > and thus Vcs-Browser is irrelevant ? I do agree that it is silly to have to have to set nearly the same header for the 90% of packages that are on salsa. It does seem like an orthogonal issue and perhaps best kept separate - there are quite a few Vcs-Git headers set to something other than salsa.debian.org or github.com, which means that Vcs-Browser isn't necessarily always predictable even for Vcs-Git headers. Jelmer
Bug#1030382: encourage Vcs-Git over other Vcs-* headers
Package: debian-policy Severity: wishlist Policy currently describes Vcs-* headers as something optional, but stops to endorse a particular Vcs. At this point, it seems uncontroversial to encourage use of Vcs-Git specifically here. Apart from technical arguments, it's the vcs that the majority of packages in the archive uses - and thus will have the better tooling, less of a learning curve for other contributors, etc. There are very few holdouts of other vcses in the archive. I count 62 (ignoring those with an alioth URL): * 26 on Svn * 3 on Cvs * 4 on Hg (2 are hg/hg-buildpackage) * 39 on bzr (half of these are actually bzr and related packages, which I maintain) Cheers, Jelmer -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-5-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled debian-policy depends on no packages. Versions of packages debian-policy recommends: ii libjs-sphinxdoc 5.3.0-3 Versions of packages debian-policy suggests: pn doc-base
Bug#1029966: ITP: aiojobs -- Python jobs scheduler for managing asyncio background tasks
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: aiojobs Version : 1.1.0 Upstream Contact: Andrew Svetlov. * URL : https://github.com/aio-libs/aiojobs * License : Apache2 Programming Lang: Python Description : Python jobs scheduler for managing asyncio background tasks Job scheduler for managing background tasks (asyncio) in Python The library gives a controlled way for scheduling background tasks for asyncio applications.
Bug#1029727: python-debian: please depend on zstd
On Thu, Jan 26, 2023 at 07:49:28PM +0100, Gianfranco Costamagna wrote:
> Hello, I see dh-cmake FTBFS in Ubuntu due to this:
>
> test_run_debian_rules
> (dhcmake.tests.cmake.DHCMakeTestCase.test_run_debian_rules) ... ok
> test_autopep8 (dhcmake.tests.source_check.SourceCheckTestCase.test_autopep8)
> ... ok
> test_pyflakes (dhcmake.tests.source_check.SourceCheckTestCase.test_pyflakes)
> ... ok
>
> ==
> ERROR: test_run_debian_rules
> (dhcmake.tests.cpack.DHCPackTestCase.test_run_debian_rules)
> --
> Traceback (most recent call last):
> File "/usr/lib/python3/dist-packages/debian/debfile.py", line 121, in
> _custom_decompress
> proc = subprocess.Popen(
>^
> File "/usr/lib/python3.11/subprocess.py", line 1024, in __init__
> self._execute_child(args, executable, preexec_fn, close_fds,
> File "/usr/lib/python3.11/subprocess.py", line 1901, in _execute_child
> raise child_exception_type(errno_num, err_msg, err_filename)
> FileNotFoundError: [Errno 2] No such file or directory: 'unzstd'
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
> File "/<>/dhcmake/tests/cpack.py", line 200, in
> test_run_debian_rules
> packages = deb822.Packages(f.debcontrol())
>^^
> File "/usr/lib/python3/dist-packages/debian/debfile.py", line 493, in
> debcontrol
> return self.control.debcontrol()
>^
> File "/usr/lib/python3/dist-packages/debian/debfile.py", line 367, in
> debcontrol
> return Deb822(self.get_content(CONTROL_FILE))
> ^^
> File "/usr/lib/python3/dist-packages/debian/debfile.py", line 308, in
> get_content
> f = self.get_file(
> ^^
> File "/usr/lib/python3/dist-packages/debian/debfile.py", line 260, in
> get_file
> fobj = self.tgz().extractfile(fname)
>^^
> File "/usr/lib/python3/dist-packages/debian/debfile.py", line 146, in tgz
> buffer = _custom_decompress(['unzstd', '--stdout'])
> ^^
> File "/usr/lib/python3/dist-packages/debian/debfile.py", line 129, in
> _custom_decompress
> raise DebError("error while running command '%s' as subprocess: '%s'" %
> debian.debfile.DebError: error while running command 'unzstd --stdout' as
> subprocess: '[Errno 2] No such file or directory: 'unzstd''
python3-debian has zstd as a Recommends since it work fine without it
and with any package found in Debian. The ch-cmake tests pass fine here without
zstd installed.
On Ubuntu, I believe zstd compression is the default, so it might make
sense for Ubuntu to move zstd from Recommends to Depends.
Cheers,
Jelmer
Bug#1025984: watch: add json output
On Fri, Dec 23, 2022 at 11:10:18AM +0100, Lucas Nussbaum wrote: > On 12/12/22 at 21:26 +0000, Jelmer Vernooij wrote: > > Package: qa.debian.org > > Severity: wishlist > > > > It would be great if watch had a json mode, like vcswatch does. > > > > E.g. allowing the retrieval of > > https://qa.debian.org/cgi-bin/watch?package=foo=1 to get the watch > > status for package foo. > > Hi, > > Note that this CGI just queries UDD. If this request is related to your > work on Janitor, I wonder if it would be better for you to run a private > UDD mirror, or query the public UDD mirror using SQL? Yeah, the Janitor uses UDD for most of its scheduling. :) I'm planning to use this for one-off fetches. Jelmer
Bug#1019457: lintian-brush: Is deb-scrub-obsolete worth it?
Hi Jeremy, On Fri, Sep 09, 2022 at 01:55:46PM -0400, Jeremy Bicha wrote: > The Debian Janitor service is opening merge proposals to drop > "obsolete" dependency relations. I'm wondering what the justification > is for this? Does it significantly speed up apt upgrades? > > It's useful for packages to match dependencies and their versions in > debian/control with what's provided in the upstream build system > (meson.build, configure.ac, CMakeLists.txt etc.). > > It's perhaps more developer work to think about whether the versions > are so old that the Janitor will recommend their removal. So if the > Janitor is potentially requiring more developer mental energy, then > it's worth questioning whether it should be making these merge > proposals by default. > > I'm not sure that it's actually "best practice" to be dropping those > package version relationships. > > > For reference, I guess you can add 'gnome-shell' to your ignore list > for this feature. See > https://salsa.debian.org/gnome-team/shell-extensions/gnome-shell-extension-hide-activities/-/merge_requests/4 > for a brief explanation. Sorry for the slow response. Some background: deb-scrub-obsolete "scrubs" a bunch of different things that have become unnecessary with newer Debian versions. By default, it'll drop things that have become unnecessary since $DEB_COMPAT_RELEASE (which defaults to stable - but can be overridden to older versions to ease backporting). There are different categories of changes: * obsolete maintscript entries for upgrades from versions older than that in $compat_release * depends on packages that are essential since $compat_release * build-depends on packages that are build-essential since $compat_release * replacing dependencies on "transitional dummy packages" with the real thing (if satisfiable since $compat_release) * conflicts with packages that are gone since before $compat_release * version constraints in build-depends or depends that are met by the package in $compat_release I think your comments are specifically about the last category, which are admittedly also the most common. (This does remind me that I should probably update the deb-scrub-obsolete manpage with this information) On dropping versioned constraints: The motivation for removing the obsolete version constraints is that for a lot of packages, the version constraint is meaningless (because incorrect) when the minimum version is ancient - and that's arguably worse than no minimum version being specified If you bump minimum versions as you run into build problems and you depend on a minimum version that's not been seen in the wild for years, it's likely the true minimum version is actually more recent, but you wouldn't know if the version in unstable is newer. This means that when e.g. backporting, you can't really rely on the minimum version. While the above may be true for some packages (certainly for a quite a lot of mine), there is another set of packages where these version constraints are better curated to always match whatever upstream defines. The premise that they're meaningless doesn't hold there (assuming upstream keep their dependencies list up to date - but that's a different problem), and they can be helpful in e.g. backporting. My impression is that the packages in e.g. the GNOME team fall into this category. As you may have seen, there is now a --keep-minimum-depends-version flag for deb-scrub-obsolete that disables this last category of changes. Going forward: Two things I will do: * update the deb-scrub-obsolete manpage to document the * add an FAQ item to the janitor page about this Perhaps --keep-minimum-depends-version should be the default, with an option to drop unnecessary minimum depends versions? It would be ideal if there was some way of determining whether a package's minimum version depends were curated in some way (e.g. synced with upstream) so we don't a flag, but I can't think of a good way of doing that. Another approach would be to somehow verify that the minimum versions are correct (by building on a much older Debian and pulling in new packages as necessary? Seems challenging, but perhaps not impossible). Let me know what you think. Cheers, Jelmer
Bug#1025984: watch: add json output
Package: qa.debian.org Severity: wishlist It would be great if watch had a json mode, like vcswatch does. E.g. allowing the retrieval of https://qa.debian.org/cgi-bin/watch?package=foo=1 to get the watch status for package foo.
Bug#1024788: ITP: setuptools-protobuf -- protocol buffer compilation for setuptools
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij * Package name: setuptools-protobuf Version : 0.1.3 Upstream Author : Jelmer Vernooij * URL : https://github.com/jelmer/setuptools-protobuf * License : Apachev2 Programming Lang: Python Description : protocol buffer compilation for setuptools Plugin for setuptools that adds support for compiling protobuf files. . It can optionally also generate mypy interface files if mypy-protobuf is present.
Bug#1024450: ITP: setuptools-gettext -- Compile .po files into .mo files
On Wed, Nov 23, 2022 at 08:09:36AM +0100, Roland Clobus wrote:
> Hello Jelmer,
>
> On 22/11/2022 00:49, Jelmer Vernooij wrote:
> > On Mon, Nov 21, 2022 at 09:19:41PM +0100, Roland Clobus wrote:
> > > On 19/11/2022 18:20, Jelmer Vernooij wrote:
> > > > Package: wnpp
> > > > Severity: wishlist
> > > > Owner: Jelmer Vernooij
> > > > X-Debbugs-Cc: debian-de...@lists.debian.org
> > > >
> > > > * Package name: setuptools-gettext
> > > > Version : 0.0.1
> > > > Upstream Author : Breezy Team
> > > > * URL : https://github.com/jelmer/setuptools-gettext
> > > > * License : GPL
> > > > Programming Lang: Python
> > > > Description : Compile .po files into .mo files
> > > >
> > > > This extension for setuptools compiles gettext .po files
> > > > found in the source directory into .mo files and installs them.
> > >
> > > How does this tool differ from 'msgfmt' from 'gettext'?
> >
> > It's a wrapper around msgfmt, but making it convenient to run from
> > setuptools.
> > I'll clarify that in the final description.
>
> Sorry to bother you again.
>
> Today I found the following post:
> https://www.redhat.com/sysadmin/python-subprocess-module
>
> Wouldn't this package effectively be 'subprocess.run("msgfmt")'?
> Or would the package name 'python3-gettext' be more suitable?
It's specifically an extension to setuptools to do these things and integrate
with the python ecosystem. It's /not/ a generic module for compiling gettext
files.
For the latter, the name python3-gettext would indeed be more appropriate and
I'm not sure whether it would be more than a wrapper around subprocess.
Jelmer
Bug#1024450: ITP: setuptools-gettext -- Compile .po files into .mo files
Hi Roland, On Mon, Nov 21, 2022 at 09:19:41PM +0100, Roland Clobus wrote: > On 19/11/2022 18:20, Jelmer Vernooij wrote: > > Package: wnpp > > Severity: wishlist > > Owner: Jelmer Vernooij > > X-Debbugs-Cc: debian-de...@lists.debian.org > > > > * Package name: setuptools-gettext > >Version : 0.0.1 > >Upstream Author : Breezy Team > > * URL : https://github.com/jelmer/setuptools-gettext > > * License : GPL > >Programming Lang: Python > >Description : Compile .po files into .mo files > > > > This extension for setuptools compiles gettext .po files > > found in the source directory into .mo files and installs them. > > How does this tool differ from 'msgfmt' from 'gettext'? It's a wrapper around msgfmt, but making it convenient to run from setuptools. I'll clarify that in the final description. Jelmer
Bug#1024570: RM: sphinxcontrib-rubydomain -- ROM; broken since 2018, low popcon score, dead upstream
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: 896...@bugs.debian.org Please remove the sphinxcontrib-rubydomain source package. The package has failed to work since at least April 2018 (see bug 896395), it has a popcon score of 3 and is dead upstream (no commits for >10 years). It has no reverse dependencies.
Bug#1024450: ITP: setuptools-gettext -- Compile .po files into .mo files
On Sat, Nov 19, 2022 at 06:43:01PM +0100, Niels Thykier wrote: > Jelmer Vernooij: > > Package: wnpp > > Severity: wishlist > > Owner: Jelmer Vernooij > > X-Debbugs-Cc: debian-de...@lists.debian.org > > > > * Package name: setuptools-gettext > >Version : 0.0.1 > >Upstream Author : Breezy Team > > * URL : https://github.com/jelmer/setuptools-gettext > > * License : GPL > >Programming Lang: Python > >Description : Compile .po files into .mo files > > > > This extension for setuptools compiles gettext .po files > > found in the source directory into .mo files and installs them. > > > > FYI: The upstream URL is a 404. Maybe there is a typo or the repo is still > private? Ah, thanks. It's actually https://github.com/breezy-team/setuptools-gettext
Bug#1024450: ITP: setuptools-gettext -- Compile .po files into .mo files
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: setuptools-gettext Version : 0.0.1 Upstream Author : Breezy Team * URL : https://github.com/jelmer/setuptools-gettext * License : GPL Programming Lang: Python Description : Compile .po files into .mo files This extension for setuptools compiles gettext .po files found in the source directory into .mo files and installs them.
Bug#1023505: include verification steps in commit message for out-of-date-standards-version
Package: lintian-brush Version: 0.133 Severity: wishlist lintian-brush will verify that all conditions documented in the Debian policy upgrade checklist (https://www.debian.org/doc/debian-policy/upgrading-checklist.html) have been met before bumping the Standards-Version. However, this isn't made clear in any way in the Janitor merge proposals or the commits/changelog entries that it creates. It might make sense to list all the individual verification steps in the commit message. I think it'd be a bit verbose to list all the verifications in the changelog message, but perhaps we could at least mention that verification has taken place. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-2-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian-brush depends on: ii devscripts 2.22.2 ii python3 3.10.6-1 ii python3-asyncpg 0.26.0-1 ii python3-breezy 3.3.0+bzr7661-2 ii python3-debian 0.1.48 ii python3-debmutate0.61 ii python3-distro-info 1.2 ii python3-dulwich 0.20.46-2 ii python3-iniparse 0.5-1 ii python3-iso8601 1.0.2-1 ii python3-levenshtein 0.12.2-2+b2 ii python3-pyinotify0.9.6-2 ii python3-ruamel.yaml 0.17.16-1 ii python3-semver 2.10.2-3 ii python3-tomlkit 0.11.5-1 ii python3-tqdm 4.64.0-2 ii python3-upstream-ontologist 0.1.25-2 Versions of packages lintian-brush recommends: ii debhelper 13.10.1 ii decopy0.2.4.7-0.2 ii dos2unix 7.4.3-1 ii gpg 2.2.40-1 ii lintian 2.115.3 ii ognibuild 0.0.13-1 ii python3-bs4 4.11.1-2 ii python3-docutils 0.17.1+dfsg-2 ii python3-lxml 4.9.1-1+b1 ii python3-markdown 3.4.1-2 Versions of packages lintian-brush suggests: ii brz-debian 2.8.74 ii git-buildpackage 0.9.29 pn gnome-pkg-tools ii po-debconf 1.0.21+nmu1 ii postgresql-common 245 -- debconf-show failed
Bug#1023477: ITP: libtypec -- user-space library for accessing USB-C/USB-PD metadata
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: libtypec Version : 0.1 Upstream Author : Rajaram Regupathy * URL : https://github.com/Rajaram-Regupathy/libtypec/ * License : MIT Programming Lang: C Description : User-space library for accessing USB-C/USB-PD metadata USB-Type C and USB Power Delivery systems are with multiple specification versions, platform designs and microcontroller vendors to manage data, power and display. This library defines a generic way for userspace System Software on Linux, Android, Chrome OS or Other OSes to build developer tools or other management applications for USB-Type C and USB Power Delivery class devices.
Bug#1021582: ITP: python3-pytest-aiohttp -- Pytest plugin for aiohttp support
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python3-pytest-aiohttp Version : 1.0.4 Upstream Author : aiohttp team * URL : https://github.com/aio-libs/pytest-aiohttp * License : Apache-v2 Programming Lang: Python Description : Pytest plugin for aiohttp support pytest plugin for aiohttp support The library provides useful fixtures for creation test aiohttp server and client. Add asyncio_mode = auto line to pytest configuration (see pytest- asyncio modes for details). The plugin works with strict mode also.
Bug#1021131: Fix national-encoding tag
Package: lintian-brush Version: 0.132 Severity: wishlist Yadd writes in https://salsa.debian.org/jelmer/janitor/-/issues/153: > could Janitor fix this lintian tag? Here is a little script I use for this: > > ```bash > #!/bin/bash > TO="UTF-8"; FILE=$1 > FROM=$(file -i $FILE | cut -d'=' -f2) > if [[ $FROM = "binary" ]]; then > echo "Skipping binary $FILE..." > exit 0 > fi > iconv -f $FROM -t $TO -o $FILE.tmp $FILE; ERROR=$? > if [[ $ERROR -eq 0 ]]; then > echo "Converting $FILE..." > mv -f $FILE.tmp $FILE > else > echo "Error on $FILE" > fi > ``` Running "select information from lintian where tag = 'national-encoding' and package_type = 'source';" in UDD I see 731 issues for this tag. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.19.0-2-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian-brush depends on: ii devscripts 2.22.2 ii python3 3.10.6-1 ii python3-breezy 3.2.2-2+b1 ii python3-debian 0.1.47 ii python3-debmutate0.57 ii python3-distro-info 1.1 ii python3-dulwich 0.20.46-1 ii python3-iniparse 0.5-1 ii python3-iso8601 1.0.2-1 ii python3-ruamel.yaml 0.17.16-1 ii python3-tqdm 4.64.0-2 ii python3-upstream-ontologist 0.1.25-2 Versions of packages lintian-brush recommends: ii debhelper13.9.1 ii decopy 0.2.4.7-0.2 ii dos2unix 7.4.3-1 ii gpg 2.2.39-1 ii lintian 2.115.3 ii ognibuild0.0.13-1 ii python3-asyncpg 0.26.0-1 ii python3-bs4 4.11.1-1 ii python3-docutils 0.17.1+dfsg-2 ii python3-levenshtein 0.12.2-2+b2 ii python3-lxml 4.9.1-1+b1 ii python3-markdown 3.4.1-1 ii python3-pyinotify0.9.6-2 ii python3-semver 2.10.2-3 ii python3-tomlkit 0.9.2-1 Versions of packages lintian-brush suggests: ii brz-debian 2.8.70 ii git-buildpackage 0.9.28 pn gnome-pkg-tools ii po-debconf 1.0.21+nmu1 ii postgresql-common 243 -- debconf-show failed
Bug#1021129: deal with fuzz in debian/patches
Package: lintian-brush Version: 0.132 Severity: wishlist lintian-brush should deal better with patch application: * https://janitor.debian.net/cupboard/pkg/ros-robot-model/96756a8d-9272-40d6-ad26-30eb25a43326/ * https://janitor.debian.net/cupboard/pkg/doomsday/8c0583cf-609a-47dc-8273-2be8e441e03f/ * https://janitor.debian.net/cupboard/pkg/jnoisemeter/cd7ef123-502c-4274-9bb4-0b6aaf54a41f/ * https://janitor.debian.net/cupboard/pkg/giada/bbf98d6d-744e-4814-83c7-3e30d23041b4/ -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.19.0-2-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian-brush depends on: ii devscripts 2.22.2 ii python3 3.10.6-1 ii python3-breezy 3.2.2-2+b1 ii python3-debian 0.1.47 ii python3-debmutate0.57 ii python3-distro-info 1.1 ii python3-dulwich 0.20.46-1 ii python3-iniparse 0.5-1 ii python3-iso8601 1.0.2-1 ii python3-ruamel.yaml 0.17.16-1 ii python3-tqdm 4.64.0-2 ii python3-upstream-ontologist 0.1.25-2 Versions of packages lintian-brush recommends: ii debhelper13.9.1 ii decopy 0.2.4.7-0.2 ii dos2unix 7.4.3-1 ii gpg 2.2.39-1 ii lintian 2.115.3 ii ognibuild0.0.13-1 ii python3-asyncpg 0.26.0-1 ii python3-bs4 4.11.1-1 ii python3-docutils 0.17.1+dfsg-2 ii python3-levenshtein 0.12.2-2+b2 ii python3-lxml 4.9.1-1+b1 ii python3-markdown 3.4.1-1 ii python3-pyinotify0.9.6-2 ii python3-semver 2.10.2-3 ii python3-tomlkit 0.9.2-1 Versions of packages lintian-brush suggests: ii brz-debian 2.8.70 ii git-buildpackage 0.9.28 pn gnome-pkg-tools ii po-debconf 1.0.21+nmu1 ii postgresql-common 243 -- debconf-show failed
Bug#1018893: support for unshare in some form
Package: piuparts Severity: wishlist It would be great if piuparts supported root-less operation, ideally in a less complicated way than via podman+docker. Conversation in #debian-qa suggests the are various options for building on top of infrastructure that's provided by other packages, e.g. sbuild, autopkgtest or mmdebootstrap. Jelmer, h01ger: I'd second what helmut said. With mmdebstrap you get the equivalent of "lxc-usernsexec -- lxc-unshare -s 'MOUNT|PID|UTSNAME|IPC' -- /usr/sbin/chroot ./debian-rootfs /bin/bash" but without having to depend on lxc -- You can see a variant of this in the mmdebstrap man page where mmdebstrap is used as a wrapper of debootstrap to fix #829134. That way you can run debootstrap without needing root: mmdebstrap --variant=custom --mode=unshare --setup-hook='env container=lxc debootstrap unstable "$1"' - debian-debootstrap.tar Alternatively, if you want to depend on neither lxc nor mmdebstrap, a number of tools implemented a simple unshare backend already using code like this: https://salsa.debian.org/debian/sbuild/-/blob/main/lib/Sbuild/Utility.pm#L382 or this: https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/virt/autopkgtest-virt-unshare#L131 re-using the unshare functionality of either mmdebstrap, sbuild or autopkgtest would probably be best there was some discussion whether those three tools could share some code here: https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/138#note_306768 unfortunately i don't see how if somebody wants to work on unshare support for piuparts, feel free to ask me questions about unshare or its implementation in mmdebstrap, sbuild or autopkgtest the other people in the know are smcv and jochensp oh and there is this as a standalone replacement: https://gitlab.mister-muffin.de/josch/user-unshare/src/branch/main/user-unshare -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') merged-usr: no Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-4-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages piuparts depends on: ii debootstrap 1.0.127 pn debsums ii libjs-sphinxdoc 4.5.0-4 ii lsb-release 11.2 ii lsof 4.95.0-1 ii mount2.38.1-1 pn piuparts-common ii python3 3.10.6-1 ii python3-debian 0.1.47 Versions of packages piuparts recommends: pn adequate Versions of packages piuparts suggests: pn docker.io pn schroot
Bug#1014473: vcswatch: track identity of committers of unuploaded commits
Package: qa.debian.org Severity: wishlist X-Debbugs-Cc: m...@debian.org It would be great if vcswatch could track who the committers were of the commits have not yet made it into the archive. I'm curious about this as a way to track the number of janitor commits that have not yet been uploaded, and to find packages I should help upload. (Interested in working on a patch for vcswatch that does this)
Bug#1014415: ITP: dispatch -- incident management tool
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: dispatch Version : 20220607 Upstream Author : Netflix * URL : https://github.com/netflix/dispatch * License : Apachev2 Programming Lang: Python Description : incident management tool Dispatch helps effectively manage (security) incidents by deeply integrating with existing tools used throughout an organization (Slack, GSuite, Jira, etc.,) Dispatch is able to leverage the existing familiarity of these tools to provide orchestration instead of introducing another tool. This means you can let Dispatch focus on creating resources, assembling participants, sending out notifications, tracking tasks, and assisting with post-incident reviews; allowing you to focus on actually fixing the issue!
Bug#1014407: update lintian overrides to new format
Package: lintian-brush Version: 0.126 Severity: wishlist See https://lists.debian.org/debian-devel/2022/06/msg00184.html for background, and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007002 Paraphrasing a request from Helmut: in essence, lintian now flags a combination of "?: something [somearg]" + "W: mismatched-override something somearg [location]" and the fix is adding square braces. This might come in the form of fixing: https://lintian.debian.org/tags/mismatched-override We may need a database of formats for the lintian tags, so we know where to add the []. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-2-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian-brush depends on: ii devscripts 2.22.2 ii python3 3.10.4-1+b1 ii python3-breezy 3.2.2-2 ii python3-debian 0.1.44 ii python3-debmutate0.53 ii python3-distro-info 1.1 ii python3-dulwich 0.20.44-1 ii python3-iniparse 0.5-1 ii python3-iso8601 1.0.2-1 ii python3-ruamel.yaml 0.17.16-1 ii python3-tqdm 4.64.0-2 ii python3-upstream-ontologist 0.1.25-2 Versions of packages lintian-brush recommends: ii debhelper13.8 ii decopy 0.2.4.6-0.1 ii dos2unix 7.4.3-1 ii gpg 2.2.35-3 ii lintian 2.115.2 ii ognibuild0.0.13-1 ii python3-asyncpg 0.25.0-2 ii python3-bs4 4.11.1-1 ii python3-docutils 0.17.1+dfsg-2 ii python3-levenshtein 0.12.2-2+b1 ii python3-lxml 4.8.0-1 ii python3-markdown 3.3.7-1 ii python3-pyinotify0.9.6-2 ii python3-tomlkit 0.9.2-1 Versions of packages lintian-brush suggests: ii brz-debian 2.8.68 ii git-buildpackage 0.9.27 pn gnome-pkg-tools ii po-debconf 1.0.21+nmu1 ii postgresql-common 241 -- debconf-show failed
Bug#1010943: ITP: cri-dockerd -- a shim for Docker Engine that lets you control Docker via the Kubernetes Container Runtime Interface.
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: cri-dockerd Version : 0.2.0 Upstream Author : Mirantis Inc. * URL : https://github.com/Mirantis/cri-dockerd * License : Apachev2 Programming Lang: Go Description : shim for Docker that allows controlling Docker via the Kubernetes CRI This adapter provides a shim for Docker Engine that lets you control Docker via the Kubernetes Container Runtime Interface.
Bug#1010065: ITP: swagger-ui -- Swagger UI is a collection of HTML, JavaScript, and CSS assets that dynamically generate beautiful documentation from a Swagger-compliant API.
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: swagger-ui Version : 4.10.3 Upstream Author : Name * URL : https://github.com/swagger-api/swagger-ui * License : Apache-2.0 Programming Lang: Javsscript Description : generate beautiful documentation from a Swagger-compliant API Swagger UI allows anyone — be it your development team or your end consumers — to visualize and interact with the API’s resources without having any of the implementation logic in place. It’s automatically generated from your OpenAPI (formerly known as Swagger) Specification, with the visual documentation making it easy for back end implementation and client side consumption.
Bug#1009815: debmutate.watch: Use perl-compatible regular expressions
Package: python3-debmutate Version: 0.49 Severity: minor uscan is written in perl and uses perl regular expressions. debmutate.watch currently uses Python's default re module, which supports a slightly different syntax. We should ideally switch to the pcre module. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-3-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-debmutate depends on: ii python3 3.9.8-1 ii python3-debian 0.1.43 ii python3-merge3 0.0.8-1 ii python3-tr 0.1+git20161102.e74d4bd-1.1 Versions of packages python3-debmutate recommends: ii python3-debian 0.1.43 ii python3-semver 2.10.2-3 ii python3-tomlkit 0.9.2-1 Versions of packages python3-debmutate suggests: pn gnome-pkg-tools ii postgresql-common 240 -- debconf-show failed
Bug#1009811: ITP: python-pcre -- Python bindings for the Perl Compatible Regex Engine
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-pcre Version : 0.7 Upstream Author : Name * URL : https://github.com/awahlig/python-pcre * License : BSD-3 Programming Lang: Python, C Description : Python bindings for the Perl Compatible Regex Engine This Python module provides bindings for PCRE, useful in situations where strict compatibility is necessary.
Bug#1009235: ITP: rust-pyo3 -- Rust bindings for the Python interpreter
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: rust-pyo3 Version : 0.16.3 Upstream Author : Name * URL : https://github.com/pyo3/pyo3 * License : Apachev2 Programming Lang: Python, Rust Description : Rust bindings for the Python interpreter Rust bindings for Python, including tools for creating native Python extension modules. Running and interacting with Python code from a Rust binary is also supported.
Bug#1006804: ITP: janitor -- management platform for large-scale automated code improvements
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij X-Debbugs-Cc: team+jani...@tracker.debian.orgr debian-de...@lists.debian.org * Package name: janitor Version : 0.1.0 Upstream Author : Jelmer Vernooij * URL : https://github.com/jelmer/janitor/ * License : GPL Programming Lang: Python Description : management platform for large-scale automated code improvements The Janitor is a platform for running code improvement tools on a large number of repositories. It takes a collection of VCS repositories and will regularly try to run a set of specified code improvement tools on those repositories. Scheduling takes into account tool-specific hints, past success and chances of success. The web UI allows review and analysis of changes made. Depending on policy set, changes are either pushed directly back to the repository or included in a pull request (that is kept up to date). The Janitor currently powers the Debian Janitor @ https://janitor.debian.net/.
Bug#1006561: ITP: libcst -- A concrete syntax tree parser and serializer library for Python that preserves many aspects of Python's abstract syntax tree
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij * Package name: libcst Version : 0.4.1 Upstream Author : Meta, Inc. * URL : https://github.com/instagram/libcst * License : MIT Programming Lang: Python Description : Format-preserving AST manipulator for Python A concrete syntax tree parser and serializer library for Python that preserves many aspects of Python's abstract syntax tree
Bug#1006278: ITP: tokenize-rt -- A wrapper around the stdlib `tokenize` which roundtrips.
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij * Package name: python-tokenize-rt Version : 2.1.0 Upstream Author : Anthony Sottile * URL : https://github.com/asottile/tokenize-rt * License : MIT Programming Lang: Python Description : A wrapper around the stdlib `tokenize` which roundtrips. Python's stdlib tokenize module does not properly roundtrip. This wrapper around the stdlib provides two additional tokens ESCAPED_NL and UNIMPORTANT_WS, and a Token data type. Use src_to_tokens and tokens_to_src to roundtrip. This library is useful for writing a refactoring tool based on the python tokenization.
Bug#1005190: gbp dch: add trailing dot when updating changelog?
On Wed, Feb 09, 2022 at 09:12:39AM +0100, Guido Günther wrote: > Hi Jelmer, > On Tue, Feb 08, 2022 at 07:01:36PM +, Jelmer Vernooij wrote: > > Package: git-buildpackage > > Version: 0.9.25 > > Severity: wishlist > > > > Hi Guido! > > > > "gbp dch" generates entries for debian/changelog based on Git commit > > messages. > > > > Best practice in Git is that the first line of a Git commit message is email > > subject-style, i.e. without a trailing dot. > > > > (see > > https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project) > > > > However, the overwhelming practice in Debian (albeit not required or > > explicitly > > recommended by policy) is to use full dots at the end of each item in the > > changelog. > > > > (see > > https://www.debian.org/doc/debian-policy/ch-source.html#debian-changelog-debian-changelog > > for the part of policy that covers the changelog) > > > > This makes it hard to stick to the convention in both systems while using > > gbp dch; > > using commit messages without a trailing dot (per Git convention) means > > having > > to add trailing dots in debian/changelog afterwards. > > > > Would you consider having "gbp dch" add trailing dots in changelog messages > > if > > they're missing? > > Can we use `--customizations=customization-file` here? We could even > ship a customization function in > /usr/share/doc/git-buildpackage/examples/ similar to > /usr/share/doc/git-buildpackage/examples/wrap_cl.py > > gbp-dch tries to stick as possible since everybody has its own > taste. I'm not totally opposed to having a more "d/changelog" like > style built in (maybe a combination of wrap_cl.py and adding a `.`) but > my feeling is that this will result in a large amount of bike shedding. > > Maybe we can about it this way: > > Introduce a /usr/share/doc/git-buildpackage/examples/debian_cl.py that > has all the wanted options, have janitor recommend using that and later > on make it a built in option if it's a style maintainers are happy with? Yeah, that seems like a reasonable approach. Let me see if I can propose a script that does that. I agree it's probably going to be gnarly to get this right for all cases. Cheers, Jelmer > > > > > (background: discussion in > > https://salsa.debian.org/jelmer/debian-janitor/-/issues/248; > > the janitor attempts to accomodate "gbp dch" users but ends up violating > > Git convention for commit messages by doing so) > > > > Jelmer > > > > -- System Information: > > Debian Release: bookworm/sid > > APT prefers unstable > > APT policy: (500, 'unstable'), (500, 'testing') > > Architecture: amd64 (x86_64) > > > > Kernel: Linux 5.15.0-3-amd64 (SMP w/2 CPU threads) > > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE > > not set > > Shell: /bin/sh linked to /bin/dash > > Init: systemd (via /run/systemd/system) > > LSM: AppArmor: enabled > > > > Versions of packages git-buildpackage depends on: > > ii devscripts 2.22.1 > > ii git1:2.34.1-1 > > ii man-db 2.10.0-2 > > ii python33.9.8-1 > > ii python3-dateutil 2.8.1-6 > > ii python3-pkg-resources 59.6.0-1.2 > > ii sensible-utils 0.0.17 > > > > Versions of packages git-buildpackage recommends: > > ii cowbuilder0.89 > > ii pbuilder 0.231 > > ii pristine-tar 1.49 > > ii python3-requests 2.25.1+dfsg-2 > > > > Versions of packages git-buildpackage suggests: > > pn python3-notify2 > > ii sudo 1.9.9-1 > > ii unzip6.0-26 > > > > -- debconf-show failed > > -- Jelmer Vernooij PGP Key: https://www.jelmer.uk/D729A457.asc
Bug#1005190: gbp dch: add trailing dot when updating changelog?
Package: git-buildpackage Version: 0.9.25 Severity: wishlist Hi Guido! "gbp dch" generates entries for debian/changelog based on Git commit messages. Best practice in Git is that the first line of a Git commit message is email subject-style, i.e. without a trailing dot. (see https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project) However, the overwhelming practice in Debian (albeit not required or explicitly recommended by policy) is to use full dots at the end of each item in the changelog. (see https://www.debian.org/doc/debian-policy/ch-source.html#debian-changelog-debian-changelog for the part of policy that covers the changelog) This makes it hard to stick to the convention in both systems while using gbp dch; using commit messages without a trailing dot (per Git convention) means having to add trailing dots in debian/changelog afterwards. Would you consider having "gbp dch" add trailing dots in changelog messages if they're missing? (background: discussion in https://salsa.debian.org/jelmer/debian-janitor/-/issues/248; the janitor attempts to accomodate "gbp dch" users but ends up violating Git convention for commit messages by doing so) Jelmer -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-3-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages git-buildpackage depends on: ii devscripts 2.22.1 ii git1:2.34.1-1 ii man-db 2.10.0-2 ii python33.9.8-1 ii python3-dateutil 2.8.1-6 ii python3-pkg-resources 59.6.0-1.2 ii sensible-utils 0.0.17 Versions of packages git-buildpackage recommends: ii cowbuilder0.89 ii pbuilder 0.231 ii pristine-tar 1.49 ii python3-requests 2.25.1+dfsg-2 Versions of packages git-buildpackage suggests: pn python3-notify2 ii sudo 1.9.9-1 ii unzip6.0-26 -- debconf-show failed
Bug#1003062: ITP: aiohttp-openmetrics -- openmetrics integration for aiohttp
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij * Package name: aiohttp-openmetrics Version : 0.0.3 Upstream Author : Jelmer Vernooij * URL : https://github.com/jelmer/aiohttp-openmetrics * License : Apachev2+ Programming Lang: Python Description : openmetrics integration for aiohttp Library that provides a standard /metrics target for aiohttp applications, as well as a set of standard metrics.
Bug#1003054: ITP: wikkid -- VCS-backed Wiki
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij * Package name: wikkid Version : 0.0.3 Upstream Author : Wikkid Developers * URL : https://github.com/wikkid-team/wikkid * License : AGPLv3 Programming Lang: Python Description : VCS-backed Wiki Wikkid is a wiki that uses Git or Bazaar as a way to store the content.
Bug#1000677: RM: isso -- ROM; RC-buggy for a long time
Package: ftp.debian.org Severity: normal Please remove isso from unstable. It has been buggy for a long time, and blocks removal of some other packages
Bug#999850: ITP: maturin -- Build and publish crates with pyo3, rust-cpython and cffi bindings as well as rust binaries as python packages.
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: maturin Version : 0.11.5 Upstream Author : konstin * URL : https://github.com/pyo3/maturin * License : Apache2 Programming Lang: Python, Rust Description : Easy publishing of pyo3/cpython/cffi rust crates and Python packages Build and publish crates with pyo3, rust-cpython and cffi bindings as well as rust binaries as python packages. This project is meant as a zero configuration replacement for setuptools-rust and milksnake. It supports building wheels for python 3.5+ on windows, linux, mac and freebsd, can upload them to pypi and has basic pypy support.
Bug#995053: dh_assistant command for listing installed files
Hi Niels, On Sun, Oct 24, 2021 at 10:12:13AM +0200, Niels Thykier wrote: > On Sat, 25 Sep 2021 22:09:53 +0200 Niels Thykier wrote: > > Control: tags -1 moreinfo > > > > Jelmer Vernooij: > > > Package: debhelper > > > Version: 13.5.2 > > > Severity: wishlist > > > > > > Dear debhelper maintainers, > > > > > > For lintian-brush, it would be really useful if it was possible to > > > discover > > > which patterns it would be installing, why and where. > > > > > > I have no idea how hard this would be to implement, and whether this > > > information is readily available in debhelper - but figured it's at least > > > worth > > > starting the discussion and seeing where it goes. I suspect there are some > > > corner cases where it's impossible to discover like where dh-exec is in > > > use > > > (but even some information would be great). > > > > > > I imagine something like a "dh_assistant installed-files" that then > > > reports: > > > > > > [...] > > > > I can definitely see how that would be interesting to you. > > Unfortunately, debhelper is a bunch of "black box" tools that knows > > nothing about each other. Even figuring out which dh_tools will be run > > is non-trivial (but I might be able to do that). > > > > The best I can offer is a "post build" list of which tools installed > > what where. But I am pretty sure that would not be helpful to your case > > (because that would be "did install" and not "would install"). > > > > Even if I did find a solution, it would rely on each tool "helping out" > > somehow. In other words, the solution would be incomplete or "unsafe" > > with third party tools involved (or both). > > > > > > Can you describe the use cases where you see the use for this? Maybe we > > can meet somewhere in the middle for them. > > > > ~Niels > I am still waiting/hoping for your feedback on this. :) > > I would like to know what problem you want to solve using this data. :) > If we are going forward with this that information would be necessary to > understand what to do with: > > 1) debhelper supported substitutions (should the be expanded or not) > - If they are to be expanded, then when do we do when we cannot > expand them? > > 2) globs - currently debhelper is strict on expanding globs. The > provided example output implies it should *not* be expanded. > > 3) search path - debhelper cannot know where in the search path a file > is found unless the file is present (e.g., d/tmp is only available > after dh_auto_install). > > 4) executable config files. This involves third-party tooling and is > completely out of control for debhelper for how they will behave. > > 5) do you want tools like dh_link to provide data? It does not > "install" any upstream provided file but it can generate links. > > > I am still not sure to what extend debhelper can help with/provide this > data in its current form. However, I would still like to know the > problem better so I can look into supporting it in the future. Part of the challenge here is that I'm still trying to figure out exactly what we can do here as well. Rather than talking specifics which requires a lot more thought, let me at least provide you with the background to what I'm trying to do. Some of the use cases I'm trying to support are: * updating filepatterns in debhelper files to adjust for upstream changes, e.g. dropping patterns when there are no longer any files being provided that match those patterns, or adding new entries * determining which files in a source tree are relevant for various fixers because they're installed by the packaging. e.g. we only need to fix .desktop files that are installed by the debian package, not just any .desktop files * fixing file installed into bad install locations * being able to detect when packaging changes impact file installation, e.g. side-effects from a debhelper 12 => 13 upgrade * e.g. generating a stub manpage where a manpage is not installed * e.g. splitting packages with a large number of arch-all files The last two in particular are very speculative, but those are the sorts of things I'm thinking about. The janitor is best-effort - it's fine if we can do the analysis for some packages, and have to skip other packages because they e.g. rely on executable config files - so long as we know that we have to skip a package. -- Jelmer Vernooij PGP Key: https://www.jelmer.uk/D729A457.asc
Bug#996785: deb822-repro: doesn't support leading tabs when assigning values
Package: python3-debian Version: 0.1.39 Severity: normal X-Debbugs-Cc: nthyk...@debian.org python-debian doesn't seem to support assigning fields that contain tabs: >>> from debian._deb822_repro import parse_deb822_file >>> x = parse_deb822_file(["Source: foo\n", "Depends: bar\n"]) >>> next(x.iter_parts())['Depends'] = 'debhelper (>= 10), quilt (>= >>> 0.40),\n\tlibsystemd-dev [linux-any], pkg-config' Traceback (most recent call last): File "", line 1, in File "/home/jelmer/src/python-debian/lib/debian/_deb822_repro/parsing.py", line 1418, in __setitem__ self._paragraph.set_field_from_raw_string( File "/home/jelmer/src/python-debian/lib/debian/_deb822_repro/parsing.py", line 2012, in set_field_from_raw_string raise ValueError(msg.format(i=i, line=line[0])) ValueError: Line 2 in new value was invalid. It must either start with " " space (continuation line) or "#" (comment line). The line started with "" (This works with the old parser) -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-debian depends on: ii python3 3.9.2-3 ii python3-chardet 4.0.0-1 ii python3-six 1.16.0-2 Versions of packages python3-debian recommends: ii python3-apt 2.2.1 Versions of packages python3-debian suggests: ii gpgv 2.2.27-2 -- no debconf information
Bug#996784: deb822-repro: Doesn't preserve field name casing
Package: python3-debian Version: 0.1.39 Severity: normal X-Debbugs-Cc: nthyk...@debian.org When updating a field using the deb822 repro code, the existing field name casing is discarded and instead overriden by the user-provided casing. This is inconsistent with the way that the current code works, and makes it harder to make minimal changes to the existing file. >>> from debian._deb822_repro.parsing import parse_deb822_file >>> z = parse_deb822_file(["Source: blah", "Standards-version: 3.1.3"]) >>> list(z.iter_parts())[0]['Standards-Version'] = '1.2.3.4' >>> z.convert_to_text() 'Source: blah\nStandards-Version: 1.2.3.4\n' -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-debian depends on: ii python3 3.9.2-3 ii python3-chardet 4.0.0-1 ii python3-six 1.16.0-2 Versions of packages python3-debian recommends: ii python3-apt 2.2.1 Versions of packages python3-debian suggests: ii gpgv 2.2.27-2 -- no debconf information
Bug#996783: deb822-repro: Paragraph iter yields rather than strings
Package: python3-debian
Version: 0.1.39
Severity: normal
The new deb822 repro interface paragraph iterator yields objects of type
debian._util._CaseInsensitiveString rather than strings.
This breaks e.g. checks that verify that the name of the field appears in a
list of strings when there are non-lowercase field names:
>>> import debian._util
>>> x = debian._util._CaseInsensitiveString('Oo')
>>> x in set(['Oo'])
False
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages python3-debian depends on:
ii python3 3.9.2-3
ii python3-chardet 4.0.0-1
ii python3-six 1.16.0-2
Versions of packages python3-debian recommends:
ii python3-apt 2.2.1
Versions of packages python3-debian suggests:
ii gpgv 2.2.27-2
-- no debconf information
Bug#994911: error modifying deb822 object while iterating
On Sun, Oct 10, 2021 at 08:41:55AM +0200, Niels Thykier wrote:
> On Thu, 23 Sep 2021 00:43:50 +0000 Jelmer Vernooij
> wrote:
> > Package: python3-debian
> > Version: 0.1.41
> > Severity: normal
> >
> > Modifying a deb822 file while iterating over it results in a RuntimeError:
> >
> > ...
> > File
> > "/home/jelmer/src/debian-janitor/python-debian/lib/debian/_deb822_repro/parsing.py",
> > line 2208, in iter_keys
> > yield from self._kvpair_elements
> > RuntimeError: dictionary keys changed during iteration
> >
> > (This doesn't happen with the default deb822 implementation)
> >
> > [...]
>
>
> Hi,
>
> Can you provide the code snippet that triggers this bug?
>
> As I understand it, this is "normal" for a dict depending on the exact
> usage, which is why I would like to see what you were doing when you
> triggered the bug. :)
>
> Example with dict:
>
> >>>> d = {'a': 1, 'b': 2}
> >>>> for e in d:
> > ... if d[e] == 2:
> > ... d['z'] = 1
> > ...
> > Traceback (most recent call last):
> > File "", line 1, in
> > RuntimeError: dictionary changed size during iteration
> >>>> for e in d:
> > ... d[e] = 2
> > ...
> >>>>
Yep, this is standard behaviour with a dict - so I wouldn't be surprised if
this was happening generally, but the default deb822 doesn't exhibit
this so it makes migrating a bit harder.
Unfortunately I've lost track of the run in the janitor that
showed this issue so we'll just have to re-enable and see
if it's fixed now.
Jelmer
Bug#995053: dh_assistant command for listing installed files
Package: debhelper
Version: 13.5.2
Severity: wishlist
Dear debhelper maintainers,
For lintian-brush, it would be really useful if it was possible to discover
which patterns it would be installing, why and where.
I have no idea how hard this would be to implement, and whether this
information is readily available in debhelper - but figured it's at least worth
starting the discussion and seeing where it goes. I suspect there are some
corner cases where it's impossible to discover like where dh-exec is in use
(but even some information would be great).
I imagine something like a "dh_assistant installed-files" that then reports:
[
{
'install_path': '/usr/share/man/man1/blah.1',
'tool': 'dh_installman',
'tool_config': 'debian/blah.manpages',
'source_path': 'debian/blah.1',
},
{
'install_path': '/usr/bin/blah',
'tool': 'dh_install',
'source_path': 'scripts/blah',
},
{
'install_path': '/usr/lib/*',
'tool': 'dh_install',
'source_path': 'debian/tmp/usr/lib/*',
},
...
]
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages debhelper depends on:
ii autotools-dev20180224.1+nmu1
ii dh-autoreconf20
ii dh-strip-nondeterminism 1.12.0-1
ii dpkg 1.20.9
ii dpkg-dev 1.20.9
ii dwz 0.14-1
ii file 1:5.39-3
ii libdebhelper-perl13.5.2
ii libdpkg-perl 1.20.9
ii man-db 2.9.4-2
ii perl 5.32.1-5
ii po-debconf 1.0.21+nmu1
debhelper recommends no packages.
Versions of packages debhelper suggests:
pn dh-make
-- no debconf information
Bug#995004: support updating existing lists in changelog
Package: python3-debmutate Version: 0.40 Severity: wishlist When adding items to changelog with subitems, we should provide a way to easily deduplicate. E.g.: * Remove constraints unnecessary since buster: + Build-Conflicts: Drop constraint on ant. + Build-Conflicts: Drop constraint on blah. rather than: * Remove constraints unnecessary since buster: + Build-Conflicts: Drop constraint on ant. * Remove constraints unnecessary since buster: + Build-Conflicts: Drop constraint on blah. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-debmutate depends on: ii python3 3.9.2-3 ii python3-debian 0.1.39 ii python3-merge3 0.0.8-1 ii python3-tr 0.1+git20161102.e74d4bd-1.1 Versions of packages python3-debmutate recommends: ii python3-debian 0.1.39 ii python3-semver 2.10.2-2 ii python3-tomlkit 0.6.0-2 Versions of packages python3-debmutate suggests: pn gnome-pkg-tools ii postgresql-common 228 -- no debconf information
Bug#994911: error modifying deb822 object while iterating
Package: python3-debian Version: 0.1.41 Severity: normal Modifying a deb822 file while iterating over it results in a RuntimeError: ... File "/home/jelmer/src/debian-janitor/python-debian/lib/debian/_deb822_repro/parsing.py", line 2208, in iter_keys yield from self._kvpair_elements RuntimeError: dictionary keys changed during iteration (This doesn't happen with the default deb822 implementation) -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-debian depends on: ii python3 3.9.2-3 ii python3-chardet 4.0.0-1 ii python3-six 1.16.0-2 Versions of packages python3-debian recommends: ii python3-apt 2.2.1 Versions of packages python3-debian suggests: ii gpgv 2.2.27-2 -- no debconf information
Bug#994854: repro fails to parse some control files
Package: python3-debian
Version: 0.1.41
Severity: normal
The deb822_repro module struggles to parse the control file in
https://salsa.debian.org/go-team/packages/golang-github-suapapa-go-eddystone.git:
...
File
"/home/jelmer/src/debian-janitor/python-debian/lib/debian/_deb822_repro/parsing.py",
line 2951, in parse_deb822_file
raise ValueError('Syntax or Parse error on the line:
"{error_as_text}"'.format(
ValueError: Syntax or Parse error on the line: ", dh-golang\n ,
golang-any\n , golang-github-paypal-gatt-dev\n ,
golang-github-google-uuid-dev\n"
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages python3-debian depends on:
ii python3 3.9.2-3
ii python3-chardet 4.0.0-1
ii python3-six 1.16.0-2
Versions of packages python3-debian recommends:
ii python3-apt 2.2.1
Versions of packages python3-debian suggests:
ii gpgv 2.2.27-2
-- no debconf information
Bug#993813: warn about known invalid fields in debian/upstream/metadata
On Mon, Sep 06, 2021 at 03:10:05PM -0700, Felix Lechner wrote: > On Mon, Sep 6, 2021 at 2:26 PM Jelmer Vernooij wrote: > > It won't provide maintainers of packages that use > > invalid settings that they are. Isn't that purpose of lintian? > I am not sure. Is it perhaps a gray zone the Janitor could fill? I don't see how the janitor is related here. It's not a linting tool and it can't report issues to maintainers. lintian-brush can fix a subset of issues reported by lintian (where it can edit the canonical source that matches the output scanned by lintian), but in the cases where it can't we need the maintainer to fix the issue - and something needs to tell the maintainer their package is wrong. > There are a few open questions: Why for example does the Github signup > page occur so often in the archive? [1] Do we actually need the field? > [2] I am not even sure the reference is incorrect. What if an upstream > manages bug reports via Github's issue tracker, like gocryptfs? [3] > (Please don't worry—I did not set the Registration field there. [4]) > > To be sure, I am not opposed to your suggestion in principle, but > people do a lot of weird stuff. Is the obscure (and often ignored) > upstream metadata really worth our attention? Whether these fields are useful enough to be included in debian/upstream/metadata is a great question, and I'm very happy to receive pushback in that regard. That should probably be a part of the wider discussion around the finaliation of DEP-12. > > Or, looking at a counter-example - there is e.g. a pypi-homepage > > tag; not just a homepage classification. > > I think there is a difference. A project's home page is often the > first point of contact, especially in search of documentation. When do > people look at the Registration field in the upstream metadata, > please? I think we should either kill these fields if they're not useful, /or/ make sure that they have correct values in them. Leaving them with often incorrect data makes them even less useful and just adds extra noise and work. If they're a part of the debian/ packaging, then surely they're in the realm of what lintian checks for? Should we create separate linters for certain files under debian/ like debian/upstream/metadata ? Jelmer -- Jelmer Vernooij PGP Key: https://www.jelmer.uk/D729A457.asc signature.asc Description: PGP signature
Bug#993813: warn about known invalid fields in debian/upstream/metadata
On Mon, Sep 06, 2021 at 01:44:31PM -0700, Felix Lechner wrote: > On Mon, Sep 6, 2021 at 12:56 PM Jelmer Vernooij wrote: > > it would simply be a list of > > known bad values > > I am not sure I agree with the hardcoding of those values unless they > create legal issues like license violations or the risk of criminal > prosecution. How about we repurpose the classification tag > 'upstream-metadata-field-present' to also provide the field contents, > which is what you are after? > > You could then use Lintian's query interface to examine the values to > your liking. That will mean maintainers need to decide which values are valid and which ones aren't. It won't provide maintainers of packages that use invalid settings that they are. Isn't that purpose of lintian? Or, looking at a counter-example - there is e.g. a pypi-homepage tag; not just a homepage classification. Cheers, Jelmer -- Jelmer Vernooij PGP Key: https://www.jelmer.uk/D729A457.asc signature.asc Description: PGP signature
Bug#993813: warn about known invalid fields in debian/upstream/metadata
On Mon, Sep 06, 2021 at 12:51:43PM -0700, Felix Lechner wrote: > On Mon, Sep 6, 2021 at 12:24 PM Jelmer Vernooij wrote: > > > > Registration: https://github.com/join > > As a tool without network access, Lintian may not be well-suited to > synchronize upstream metadata. This wouldn't require network access - it would simply be a list of known bad values, in the same way that we have those in other places (e.g. known bad hosting sites for Homepage). Jelmer -- Jelmer Vernooij PGP Key: https://www.jelmer.uk/D729A457.asc signature.asc Description: PGP signature
Bug#993813: warn about known invalid fields in debian/upstream/metadata
Package: lintian Version: 2.104.0 Severity: wishlist Some packages have known incorrect values in debian/upstream/metadata. For example: Registration: https://github.com/join is certain to be incorrect - as we don't package GitHub. It would be great if lintian could warn about these. -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils2.37-4 ii bzip2 1.0.8-4 ii diffstat1.64-1 ii dpkg1.20.9 ii dpkg-dev1.20.9 ii file1:5.39-3 ii gettext 0.21-4 ii gpg 2.2.27-2 ii intltool-debian 0.35.0+20060710.5 ii libapt-pkg-perl 0.1.40 ii libarchive-zip-perl 1.68-1 ii libcapture-tiny-perl0.48-1 ii libclass-xsaccessor-perl1.19-3+b7 ii libclone-perl 0.45-1+b1 ii libconfig-tiny-perl 2.26-1 ii libcpanel-json-xs-perl 4.25-1+b1 ii libdata-dpath-perl 0.58-1 ii libdata-validate-domain-perl0.10-1.1 ii libdevel-size-perl 0.83-1+b2 ii libdpkg-perl1.20.9 ii libemail-address-xs-perl1.04-1+b3 ii libfile-basedir-perl0.08-1 ii libfile-find-rule-perl 0.34-1 ii libfont-ttf-perl1.06-1.1 ii libhtml-html5-entities-perl 0.004-1.1 ii libipc-run3-perl0.048-2 ii libjson-maybexs-perl1.004003-1 ii liblist-compare-perl0.55-1 ii liblist-moreutils-perl 0.430-2 ii liblist-utilsby-perl0.11-1 ii libmoo-perl 2.004004-1 ii libmoox-aliases-perl0.001006-1.1 ii libnamespace-clean-perl 0.27-1 ii libpath-tiny-perl 0.118-1 ii libperlio-gzip-perl 0.19-1+b7 ii libproc-processtable-perl 0.59-2+b1 ii libsereal-decoder-perl 4.018+ds-1+b1 ii libsereal-encoder-perl 4.018+ds-1+b1 ii libtext-glob-perl 0.11-1 ii libtext-levenshteinxs-perl 0.03-4+b8 ii libtext-markdown-discount-perl 0.12-1+b1 ii libtext-xslate-perl 3.5.8-1+b1 ii libtime-duration-perl 1.21-1 ii libtime-moment-perl 0.44-1+b3 ii libtimedate-perl2.3300-2 ii libtry-tiny-perl0.30-1 ii libtype-tiny-perl 1.012002-1 ii libunicode-utf8-perl0.62-1+b2 ii liburi-perl 5.08-1 ii libxml-libxml-perl 2.0134+dfsg-2+b1 ii libyaml-libyaml-perl0.82+repack-1+b1 ii lzip1.22-3 ii lzop1.04-2 ii man-db 2.9.4-2 ii patchutils 0.4.2-1 ii perl [libdigest-sha-perl] 5.32.1-5 ii t1utils 1.41-4 ii unzip 6.0-26 ii xz-utils5.2.5-2 lintian recommends no packages. Versions of packages lintian suggests: pn binutils-multiarch ii libtext-template-perl 1.59-1 -- no debconf information
Bug#992569: missing-debian-watch-file-standard files for watch files without content
Package: lintian Version: 2.104.0 Severity: minor The missing-debian-watch-file-standard tag triggers for a lot of debian/watch files that have no contents, or only contain comments. For example, this is the case for the "aladin" package, where the comments are: # The latest version of upstream can be found at # http://aladin.u-strasbg.fr/java/nph-aladin.pl?frame=downloading . # Since upstream does not provide a versioning scheme, however, # (source archives are generally named "AladinSrc.jar") the watch # file syntax will not have any effect. # # A tools to download + version the upstream Jarball can be found at: # https://github.com/sladen/vo/blob/master/aladin-meta/fetch-aladin-source.py https://lintian.debian.org/tags/missing-debian-watch-file-standard -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils2.37-4 ii bzip2 1.0.8-4 ii diffstat1.64-1 ii dpkg1.20.9 ii dpkg-dev1.20.9 ii file1:5.39-3 ii gettext 0.21-4 ii gpg 2.2.27-2 ii intltool-debian 0.35.0+20060710.5 ii libapt-pkg-perl 0.1.40 ii libarchive-zip-perl 1.68-1 ii libcapture-tiny-perl0.48-1 ii libclass-xsaccessor-perl1.19-3+b7 ii libclone-perl 0.45-1+b1 ii libconfig-tiny-perl 2.26-1 ii libcpanel-json-xs-perl 4.25-1+b1 ii libdata-dpath-perl 0.58-1 ii libdata-validate-domain-perl0.10-1.1 ii libdevel-size-perl 0.83-1+b2 ii libdpkg-perl1.20.9 ii libemail-address-xs-perl1.04-1+b3 ii libfile-basedir-perl0.08-1 ii libfile-find-rule-perl 0.34-1 ii libfont-ttf-perl1.06-1.1 ii libhtml-html5-entities-perl 0.004-1.1 ii libipc-run3-perl0.048-2 ii libjson-maybexs-perl1.004003-1 ii liblist-compare-perl0.55-1 ii liblist-moreutils-perl 0.430-2 ii liblist-utilsby-perl0.11-1 ii libmoo-perl 2.004004-1 ii libmoox-aliases-perl0.001006-1.1 ii libnamespace-clean-perl 0.27-1 ii libpath-tiny-perl 0.118-1 ii libperlio-gzip-perl 0.19-1+b7 ii libproc-processtable-perl 0.59-2+b1 ii libsereal-decoder-perl 4.018+ds-1+b1 ii libsereal-encoder-perl 4.018+ds-1+b1 ii libtext-glob-perl 0.11-1 ii libtext-levenshteinxs-perl 0.03-4+b8 ii libtext-markdown-discount-perl 0.12-1+b1 ii libtext-xslate-perl 3.5.8-1+b1 ii libtime-duration-perl 1.21-1 ii libtime-moment-perl 0.44-1+b3 ii libtimedate-perl2.3300-2 ii libtry-tiny-perl0.30-1 ii libtype-tiny-perl 1.012002-1 ii libunicode-utf8-perl0.62-1+b2 ii liburi-perl 5.08-1 ii libxml-libxml-perl 2.0134+dfsg-2+b1 ii libyaml-libyaml-perl0.82+repack-1+b1 ii lzip1.22-3 ii lzop1.04-2 ii man-db 2.9.4-2 ii patchutils 0.4.2-1 ii perl [libdigest-sha-perl] 5.32.1-5 ii t1utils 1.41-4 ii unzip 6.0-26 ii xz-utils5.2.5-2 lintian recommends no packages. Versions of packages lintian suggests: pn binutils-multiarch ii libtext-template-perl 1.59-1 -- no debconf information
Bug#992464: ITP: python-fastbencode -- Fast implementation of bencode serializer/deserializer
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij X-Debbugs-Cc: debian-de...@lists.debian.org, gzl...@googlemail.com * Package name: python-fastbencode Version : 0.0.4 Upstream Author : Breezy Developers * URL : http://github.com/breezy-team/fastbencode * License : GPL Programming Lang: Python/C/Cython Description : Fast implementation of bencode serializer/deserializer A fast (C/Cython-based) implementation of the bencode serialization mechanism used by e.g. BitTorrent. This is a new dependency for Breezy.
Bug#990956: uploading lintian-brush to testing-proposed-updates
On Wed, Jul 14, 2021 at 10:25:29PM +0200, Paul Gevers wrote:
> Hi,
>
> On 12-07-2021 01:20, Jelmer Vernooij wrote:
> > On Sun, Jul 11, 2021 at 09:58:30PM +0200, Paul Gevers wrote:
> >> On 11-07-2021 21:47, Jelmer Vernooij wrote:
> >>> It's going to be tricky to get this resolved in time before the removal of
> >>> lintian-brush from testing.
> >>
> >> Can you elaborate why it's tricky (not promising anything, but there
> >> could be reasons for t-p-u)? The current autoremoval is scheduled for
> >> August 8, which is *after* the tentative release date.
> >
> > There have been updates to the other packages that relate to
> > lintian-brush - both dependencies (python-tr, debmutate,
> > upstream-ontologist, buildlog-consultant) and reverse dependencies
> > ((silver-platter); we'd have to either roll those back in unstable as
> > well or instead patch lintian-brush with a set of changes to lintian-brush
> > that isn't really a
> > roll back.
>
> Still not promising anything, but what would be the proposed change in
> t-p-u?
Please find attached the proposed change. Please note that it only
affects the testsuite.
Cheers,
Jelmer
commit d9d08efed57eca3f434954495dd5c84bbfa4cb12
Author: Jelmer Vernooij
Date: Mon Jul 19 23:26:25 2021 +0100
Fix test suite compatibility with the version of upstream-ontologist in bullseye.
diff --git a/debian/changelog b/debian/changelog
index 5431fedc..a4ef35b0 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+lintian-brush (0.99.1) bullseye; urgency=high
+
+ * Fix test suite compatibility with the version of upstream-ontologist in
+bullseye.
+ + Bump minimum upstream-ontologist to 0.1.22 since the test suite now
+ relies on the output from that version.
+
+ -- Jelmer Vernooij Mon, 19 Jul 2021 23:25:07 +0100
+
lintian-brush (0.99) unstable; urgency=medium
* Also update 'set -e' in postrm files. Closes: #983347
diff --git a/debian/control b/debian/control
index 7644abac..0cc6006c 100644
--- a/debian/control
+++ b/debian/control
@@ -21,7 +21,8 @@ Build-Depends: bash-completion,
python3-setuptools,
python3-ruamel.yaml,
python3-toml,
- python3-upstream-ontologist,
+ python3-tomlkit,
+ python3-upstream-ontologist (>= 0.1.22),
po-debconf,
gpg (>= 2.1),
lintian (>= 2.104.0),
@@ -42,7 +43,7 @@ Depends: devscripts,
python3-distro-info,
python3-iniparse,
python3-ruamel.yaml,
- python3-upstream-ontologist,
+ python3-upstream-ontologist (>= 0.1.22),
ognibuild,
${misc:Depends},
${python3:Depends}
diff --git a/debian/tests/control b/debian/tests/control
index 40a21b0e..9da5a58f 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,5 +1,5 @@
Tests: tool-testsuite
-Depends: lintian-brush, python3-breezy.tests, gpg, dos2unix, libdebhelper-perl, lintian (>= 2.104.0), python3-iniparse, python3-toml, python3-levenshtein, decopy, po-debconf
+Depends: lintian-brush, python3-breezy.tests, gpg, dos2unix, libdebhelper-perl, lintian (>= 2.104.0), python3-iniparse, python3-toml, python3-levenshtein, decopy, po-debconf, python3-tomlkit
Restrictions: allow-stderr
Test-Command: deb-scrub-obsolete --version
diff --git a/tests/upstream-metadata-file/doap/message b/tests/upstream-metadata-file/doap/message
index 00d4f683..d0e9f9c9 100644
--- a/tests/upstream-metadata-file/doap/message
+++ b/tests/upstream-metadata-file/doap/message
@@ -1,3 +1,3 @@
-Set upstream metadata fields: Bug-Database, Name, Repository, Repository-Browse.
+Set upstream metadata fields: Bug-Database, Contact, Name, Repository, Repository-Browse.
Certainty: certain
Fixed-Lintian-Tags: upstream-metadata-file-is-missing, upstream-metadata-missing-repository
diff --git a/tests/upstream-metadata-file/doap/out/debian/upstream/metadata b/tests/upstream-metadata-file/doap/out/debian/upstream/metadata
index 7706a368..f6164da9 100644
--- a/tests/upstream-metadata-file/doap/out/debian/upstream/metadata
+++ b/tests/upstream-metadata-file/doap/out/debian/upstream/metadata
@@ -1,5 +1,6 @@
---
Name: blah
+Contact: Joe Maintainer
Bug-Database: http://example.com/blah/trac/newticket
Repository: http://example.com/blah/svn/trunk/
Repository-Browse: http://example.com/blah/trac/browser/
diff --git a/tests/upstream-metadata-file/fix-repository/message b/tests/upstream-metadata-file/fix-repository/message
index bda7d077..f266830a 100644
--- a/tests/upstream-metadata-file/fix-repository/message
+++ b/tests/upstream-metadata-file/fix-repository/message
@@ -1,2 +1,2 @@
-Set upstream metadata fields: Repository.
-Certainty: certain
+Set upstream metadata fields: Name, Repository.
+Certainty: possible
diff --git a/tests/upstrea
Bug#990956: uploading lintian-brush to testing-proposed-updates
On Sun, Jul 11, 2021 at 09:58:30PM +0200, Paul Gevers wrote: > Hi Jelmer, > > On 11-07-2021 21:47, Jelmer Vernooij wrote: > > It's going to be tricky to get this resolved in time before the removal of > > lintian-brush from testing. > > Can you elaborate why it's tricky (not promising anything, but there > could be reasons for t-p-u)? The current autoremoval is scheduled for > August 8, which is *after* the tentative release date. There have been updates to the other packages that relate to lintian-brush - both dependencies (python-tr, debmutate, upstream-ontologist, buildlog-consultant) and reverse dependencies ((silver-platter); we'd have to either roll those back in unstable as well or instead patch lintian-brush with a set of changes to lintian-brush that isn't really a roll back. (I appreciate that some of those changes probably should have gone to experimental) > > Of the reverse dependencies, routine-update can > > hopefully be updated easily (I've already pinged Andreas) to skip > > lintian-brush > > and silver-platter should probably not make it into bullseye (I've just > > filed a > > removal request for it). > > I'll handle the removals. Thanks! Cheers, Jelmer signature.asc Description: PGP signature
Bug#990956: uploading lintian-brush to testing-proposed-updates
Hi Paul, On Sun, Jul 11, 2021 at 08:35:07PM +0200, Paul Gevers wrote: > On 11-07-2021 19:44, Jelmer Vernooij wrote: > > Can I upload a small fix for lintian-brush to testing-proposed-updates to > > allow > > it to remain in testing? I just found out an old FTBFS bug is still > > affecting > > it in testing, and there's a much newer version in unstable. > > That's not why we have t-p-u. We really prefer you to revert the new > upstream release in unstable (using e.g. +really version number). See > also our FAQ [1]. Thanks for the reply. Unfortunately this is something that I get caught up in my workflow around every release - having to switch to uploading to experimental for some packages rather than unstable. I really should have paid more attention to that, rather than creating this mess. :-/ It's going to be tricky to get this resolved in time before the removal of lintian-brush from testing. Of the reverse dependencies, routine-update can hopefully be updated easily (I've already pinged Andreas) to skip lintian-brush and silver-platter should probably not make it into bullseye (I've just filed a removal request for it). Jelmer
Bug#990961: RM: ognibuild/0.0.1~git20201031.4cbc8df-1.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Please remove ognibuild from bullseye/testing; the current version (0.0.1~git20201031.4cbc8df-1.1) there is a very early prerelease that is unlikely to provide a good experience to users.
Bug#990960: RM: silver-platter/0.4.2-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Please remove silver-platter from bullseye; the current version has a low popcon count (9) and upgrading to future versions will require a major change for users - a new CLI has been introduced in 0.4.3. It's probably best not to encourage adoption of the old CLI.
Bug#990956: uploading lintian-brush to testing-proposed-updates
Package: release.debian.org Severity: important Hi release team, Can I upload a small fix for lintian-brush to testing-proposed-updates to allow it to remain in testing? I just found out an old FTBFS bug is still affecting it in testing, and there's a much newer version in unstable. The bug in question is https://bugs.debian.org/988909 Thanks, Jelmer
Bug#990941: ITP: zipkin -- Distributed tracing system
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: zipkin Version : 2.22.1 Upstream Author : Zipkin Team * URL : http://www.zipkin.org/ * License : Apache Programming Lang: Java Description : Distributed tracing system Zipkin is a distributed tracing system. It helps gather timing data needed to troubleshoot latency problems in service architectures. Features include both the collection and lookup of this data. If you have a trace ID in a log file, you can jump directly to it. Otherwise, you can query based on attributes such as service, operation name, tags and duration. Some interesting data will be summarized for you, such as the percentage of time spent in a service, and whether or not operations failed.
Bug#988933: deb-scrub-obsolete: when drop versioned dependencies for essential packages, drop entire dependency
Package: lintian-brush Version: 0.104 Severity: normal See https://salsa.debian.org/pkg-netfilter-team/pkg-nftables/-/merge_requests/5#note_239505 When dropping versioned dependencies for packages that are essential (and were so in upgrade-release), then drop the entire dependency. -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-4-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian-brush depends on: ii devscripts 2.21.2 ii python3 3.9.2-3 ii python3-breezy 3.2.0-1 ii python3-debian 0.1.39 ii python3-debmutate0.34 ii python3-distro-info 1.0 ii python3-dulwich 0.20.15-1 ii python3-iniparse 0.4-3 ii python3-ruamel.yaml 0.16.12-2 ii python3-upstream-ontologist 0.1.18-1 Versions of packages lintian-brush recommends: ii decopy 0.2.4.4-0.1 ii dos2unix 7.4.1-1 ii gpg 2.2.27-2 ii libdebhelper-perl13.3.4 ii lintian 2.104.0 ii ognibuild0.0.5-1 ii python3-asyncpg 0.21.0-1+b2 ii python3-bs4 4.9.3-1 ii python3-docutils 0.16+dfsg-4 ii python3-levenshtein 0.12.2-1 ii python3-lxml 4.6.3-1 ii python3-markdown 3.3.4-1 ii python3-pyinotify0.9.6-1.3 Versions of packages lintian-brush suggests: pn breezy-debian pn gnome-pkg-tools ii po-debconf 1.0.21+nmu1 ii postgresql-common 225 -- no debconf information
Bug#988932: deb-scrub-obsolete: should not strip trailing commas in dependencies
Package: lintian-brush Version: 0.104 Severity: normal See https://salsa.debian.org/postgresql/psqlodbc/-/merge_requests/1: deb-scrub-obsolete should not strip commas. This happens because it drops dependencies first at the moment and then removes any empty elements in the list. It should just drop dependencies and remove elements in the list *only* if it is causing the element to be empty. -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-4-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian-brush depends on: ii devscripts 2.21.2 ii python3 3.9.2-3 ii python3-breezy 3.2.0-1 ii python3-debian 0.1.39 ii python3-debmutate0.34 ii python3-distro-info 1.0 ii python3-dulwich 0.20.15-1 ii python3-iniparse 0.4-3 ii python3-ruamel.yaml 0.16.12-2 ii python3-upstream-ontologist 0.1.18-1 Versions of packages lintian-brush recommends: ii decopy 0.2.4.4-0.1 ii dos2unix 7.4.1-1 ii gpg 2.2.27-2 ii libdebhelper-perl13.3.4 ii lintian 2.104.0 ii ognibuild0.0.5-1 ii python3-asyncpg 0.21.0-1+b2 ii python3-bs4 4.9.3-1 ii python3-docutils 0.16+dfsg-4 ii python3-levenshtein 0.12.2-1 ii python3-lxml 4.6.3-1 ii python3-markdown 3.3.4-1 ii python3-pyinotify0.9.6-1.3 Versions of packages lintian-brush suggests: pn breezy-debian pn gnome-pkg-tools ii po-debconf 1.0.21+nmu1 ii postgresql-common 225 -- no debconf information
Bug#988666: ITP: aiozipkin -- Distributed tracing instrumentation for asyncio application with zipkin
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: aiozipkin Version : 1.1.0 Upstream Author : Nikolay Novik * URL : https://github.com/aio-libs/aiozipkin * License : (GPL, LGPL, BSD, MIT/X, etc.) Programming Lang: (C, C++, C#, Perl, Python, etc.) Description : Distributed tracing instrumentation for asyncio application with zipkin aiozipkin is Python 3.6+ module that adds distributed tracing capabilities from asyncio_ applications with zipkin (http://zipkin.io) server instrumentation. zipkin_ is a distributed tracing system. It helps gather timing data needed to troubleshoot latency problems in microservice architectures. It manages both the collection and lookup of this data. Zipkin’s design is based on the Google Dapper paper. Applications are instrumented with aiozipkin report timing data to zipkin. The Zipkin UI also presents a Dependency diagram showing how many traced requests went through each application. If you are troubleshooting latency problems or errors, you can filter or sort all traces based on the application, length of trace, annotation, or timestamp.
Bug#987544: RFP: envoyproxy -- high performance C++ distributed proxy designed for single services and applications
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: envoyproxy Version : 1.18.2 Upstream Author : Envoy Project Authors * URL : http://envoyproxy.io/ * License : Apachev2 Programming Lang: C++ Description : high performance C++ distributed proxy designed for single services and applications Envoy is an L7 proxy and communication bus designed for large modern service oriented architectures. Envoy is a self contained process that is designed to run alongside every application server. All of the Envoys form a transparent communication mesh in which each application sends and receives messages to and from localhost and is unaware of the network topology. I'm interested in helping out with packaging envoyproxy, but am not sure if I have the bandwidth to do so myself. I'm filing this RFP primarily as a way to track status. See also https://www.envoyproxy.io/docs/envoy/latest/intro/what_is_envoy
Bug#986751: ITP: python-apispec -- pluggable API specification generator
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij X-Debbugs-Cc: debian-de...@lists.debian.org, de...@kali.org * Package name: python-apispec Version : 3.3.1 * URL : https://github.com/marshmallow-code/apispec * License : MIT Programming Lang: Python Description : pluggable API specification generator This package contains a pluggable API specification generator. It currently supports the OpenAPI Specification (f.k.a. the Swagger specification). The features are: - Supports the OpenAPI Specification (versions 2 and 3) - Framework-agnostic - Built-in support for marshmallow - Utilities for parsing docstrings (this is already packaged in kali at https://gitlab.com/kalilinux/packages/apispec, I will base the package on theirs)
Bug#986750: ITP: python-webargs -- Python library for parsing and validating HTTP request arguments
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij X-Debbugs-Cc: debian-de...@lists.debian.org, de...@kali.org * Package name: python-webargs Version : 7.0.1 * URL : https://github.com/sloria/webargs * License : MIT Programming Lang: Python Description : Python library for parsing and validating HTTP request arguments This package contains a Python library for parsing and validating HTTP request arguments, with built-in support for popular web frameworks, including Flask, Django, Bottle, Tornado, Pyramid, webapp2, Falcon, and aiohttp. (Already packaged in Kali, I will be basing this on their packaging - https://gitlab.com/kalilinux/packages/python-webargs)
Bug#986641: ITP: aiohttp-aiospec -- swagger extension for aiohttp
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: aiohttp-aiospec Version : 2.2.1 Upstream Author : Danilchenko Maksim * URL : https://github.com/maximdanilchenko/aiohttp-apispec * License : MIT Programming Lang: Python Description : swagger extension for aiohttp Build and document REST APIs with aiohttp and apispec
Bug#985834: ancient-maintscript-entry should mention when last relevant version was
X-Debbugs-Cc: raph...@offensive-security.com Package: lintian-brush Version: 0.101 Severity: minor Raphael writes: > I noticed a case where lintian-brush drops a > .maintscript file: > https://janitor.kali.org/cupboard/pkg/hashcat-utils/059988c9-7de0-454a-9ed5-99381ae399a6/ >* > The commit message just says that it's "obsolete". How does it decide > that it's obsolete? Does it link the version with a date through the > changelog? In any case, it would be great if the commit message explained > how the tool came to this conclusion... Ideally, ancient-maintscript-entry should list when the last version was for which the maintscript entry was relevant and when it was uploaded. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-4-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian-brush depends on: ii devscripts 2.21.1 ii python3 3.9.2-2 ii python3-breezy 3.1.0-8 ii python3-debian 0.1.39 ii python3-debmutate0.27 ii python3-distro-info 1.0 ii python3-dulwich 0.20.15-1 ii python3-iniparse 0.4-3 ii python3-ruamel.yaml 0.16.12-2 ii python3-upstream-ontologist 0.1.14-1 Versions of packages lintian-brush recommends: ii decopy 0.2.4.4-0.1 ii dos2unix 7.4.1-1 ii gpg 2.2.27-1 ii libdebhelper-perl13.3.4 ii lintian 2.104.0 ii ognibuild0.0.2-1 ii python3-asyncpg 0.21.0-1+b2 ii python3-bs4 4.9.3-1 ii python3-docutils 0.16+dfsg-3 ii python3-levenshtein 0.12.2-1 ii python3-lxml 4.6.3-1 ii python3-markdown 3.3.4-1 ii python3-pyinotify0.9.6-1.3 Versions of packages lintian-brush suggests: pn breezy-debian pn gnome-pkg-tools ii po-debconf 1.0.21+nmu1 ii postgresql-common 225 -- no debconf information
Bug#985633: warn about watch files that use github and include full refs
On Sun, Mar 21, 2021 at 09:40:32PM -0700, Felix Lechner wrote: > On Sun, Mar 21, 2021 at 6:30 PM Jelmer Vernooij wrote: > > > > I was hoping that lintian could verify that there is at least > > something after "/archive/" in the matching pattern > Could Lintian-brush or the Janitor do so, when Lintian provides the string? It could, but at that point there isn't much value in having lintian involved - the janitor could just get that directly from UDD. The main value in having lintian in the loop here is: * lintian actively goes out and discovers issues (especially on fully built packages), so that lintian-brush runs can be prioritized. * so we can verify that issues that lintian found and lintian-brush thought it fixed are actually fixed Not all issues can be fixed by the janitor either, so it would be useful to have a lintian tag for those packages that are affected but can't be fixed. -- Jelmer Vernooij PGP Key: https://www.jelmer.uk/D729A457.asc signature.asc Description: PGP signature
Bug#985633: warn about watch files that use github and include full refs
Hi Felix, On Sat, Mar 20, 2021 at 09:44:07PM -0700, Felix Lechner wrote: > On Sat, Mar 20, 2021 at 7:27 PM Jelmer Vernooij wrote: > > > > https://qa.debian.org/cgi-bin/watch?pkg=jupyter-core > > I saw the traffic on IRC where someone suggested we replace > > .*archive/v?([0-9.]*).tar.gz > > with > > .*archive/.*/v?([0-9.]*).tar.gz > > to fix at least 1,500 affected packages. Unfortunately, that may not > work for jupyter-core, which does not prefix tags with a "v" and for > which "(.*)" catches the slash (or maybe even slashes). > > As a tool without network access, Lintian is not well positioned to > figure out, in general, whether a URL/regex combination works. Would > it be okay if Lintian instead issues two now classification tags? > > The first would occur once per source. It shows the watch file URL and > the regular expression for HTML parsing, possibly followed by "debian > update" (or similar). The second tag would occur once for each of the > options selected, i.e. multiple times. Armed with that information, > the Janitor could probe the URL and figure out which parts need > fixing. I was hoping that lintian could verify that there is at least something after "/archive/" in the matching pattern that could match slashes without relying on the main regex group - that could be done without querying GitHub. That said, that code would have to be updated if GitHub changes again in the future and it may be somewhat tricky code. The offer for informational tags is appreciated, but as you say - the data is already available in UDD so just providing the pure uscan contents wouldn't help much. The alternative is to just let lintian-brush work without a signal from lintian, and gradually grind through the archive. That'll work too, though it'll take a few months - and we lose the verification from lintian after the fix. Jelmer -- Jelmer Vernooij PGP Key: https://www.jelmer.uk/D729A457.asc signature.asc Description: PGP signature
Bug#985633: warn about watch files that use github and include full refs
Package: lintian Version: 2.104.0 Severity: normal Some watch files are now broken because GitHub archive URLs now include the full ref rather than the tag name. It would be great if lintian could warn when this was the case. See e.g. the watch file for jupyter-core: https://qa.debian.org/cgi-bin/watch?pkg=jupyter-core which reports the current upstream version as refs/tags/4.7.1 -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-4-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils2.35.2-2 ii bzip2 1.0.8-4 ii diffstat1.64-1 ii dpkg1.20.7.1 ii dpkg-dev1.20.7.1 ii file1:5.39-3 ii gettext 0.21-4 ii gpg 2.2.27-1 ii intltool-debian 0.35.0+20060710.5 ii libapt-pkg-perl 0.1.40 ii libarchive-zip-perl 1.68-1 ii libcapture-tiny-perl0.48-1 ii libclass-xsaccessor-perl1.19-3+b7 ii libclone-perl 0.45-1+b1 ii libconfig-tiny-perl 2.26-1 ii libcpanel-json-xs-perl 4.25-1+b1 ii libdata-dpath-perl 0.58-1 ii libdata-validate-domain-perl0.10-1.1 ii libdevel-size-perl 0.83-1+b2 ii libdpkg-perl1.20.7.1 ii libemail-address-xs-perl1.04-1+b3 ii libfile-basedir-perl0.08-1 ii libfile-find-rule-perl 0.34-1 ii libfont-ttf-perl1.06-1.1 ii libhtml-html5-entities-perl 0.004-1.1 ii libipc-run3-perl0.048-2 ii libjson-maybexs-perl1.004003-1 ii liblist-compare-perl0.55-1 ii liblist-moreutils-perl 0.430-2 ii liblist-utilsby-perl0.11-1 ii libmoo-perl 2.004004-1 ii libmoox-aliases-perl0.001006-1.1 ii libnamespace-clean-perl 0.27-1 ii libpath-tiny-perl 0.118-1 ii libperlio-gzip-perl 0.19-1+b7 ii libproc-processtable-perl 0.59-2+b1 ii libsereal-decoder-perl 4.018+ds-1+b1 ii libsereal-encoder-perl 4.018+ds-1+b1 ii libtext-glob-perl 0.11-1 ii libtext-levenshteinxs-perl 0.03-4+b8 ii libtext-markdown-discount-perl 0.12-1+b1 ii libtext-xslate-perl 3.5.8-1+b1 ii libtime-duration-perl 1.21-1 ii libtime-moment-perl 0.44-1+b3 ii libtimedate-perl2.3300-2 ii libtry-tiny-perl0.30-1 ii libtype-tiny-perl 1.012001-2 ii libunicode-utf8-perl0.62-1+b2 ii liburi-perl 5.08-1 ii libxml-libxml-perl 2.0134+dfsg-2+b1 ii libyaml-libyaml-perl0.82+repack-1+b1 ii lzip1.22-3 ii lzop1.04-2 ii man-db 2.9.4-2 ii patchutils 0.4.2-1 ii perl [libdigest-sha-perl] 5.32.1-3 ii t1utils 1.41-4 ii unzip 6.0-26 ii xz-utils5.2.5-2 lintian recommends no packages. Versions of packages lintian suggests: pn binutils-multiarch ii libtext-template-perl 1.59-1 -- no debconf information
Bug#984900: debhelper command printing buildsystem detection
Package: debhelper Version: 13.3.4 Severity: wishlist For lintian-brush, it would be great if there was a command that printed the buildsystem that debhelper would use in a directory. At the moment, lintian-brush runs something like: perl -w -MDebian::Debhelper::Dh_Lib -MDebian::Debhelper::Dh_Buildsystems -e
Bug#984626: ITP: python-tr -- implementation of the tr algorithm
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-tr Version : 0.1.2 Upstream Author : Yukino Ikegami * URL : https://pypi.org/project/python-tr/ * License : MIT Programming Lang: Python Description : implementation of the tr algorithm This module is a Python implementation of the tr algorithm. tr(string1, string2, source, option=’’) If not given option, then replace all characters in string1 with the character in the same position in string2.
Bug#984425: missing dependency on debhelper
Package: libconfig-model-perl Severity: normal There appears to be a missing depends/recommends on debhelper. Without debhelper installed, cme fails to run for me with: Use of uninitialized value $file_path in concatenation (.) or string at /usr/share/perl5/Config/Model/BackendMgr.pm line 346, line 84. Backend Dpkg failed to read : debhelper package is not installed at /usr/share/perl5/Config/Model/Dpkg/Compat.pm line 13, line 84. Compilation failed in require at /usr/share/perl5/Config/Model/Node.pm line 247, line 84. https://janitor.debian.net/cupboard/pkg/libxrandr/f6365b2b-a05a-4f2a-a5f3-73364b868158/worker.log -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-3-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libconfig-model-perl depends on: pn libboolean-perl pn libcarp-assert-more-perl ii libfile-homedir-perl 1.006-1 pn libhash-merge-perl ii libjson-perl 4.03000-1 ii liblist-moreutils-perl0.430-2 pn liblog-log4perl-perl ii libmouse-perl 2.5.10-1+b1 pn libmousex-nativetraits-perl pn libmousex-strictconstructor-perl pn libparse-recdescent-perl ii libpath-tiny-perl 0.118-1 pn libpod-pom-perl pn libregexp-common-perl pn libyaml-tiny-perl ii perl 5.32.1-3 Versions of packages libconfig-model-perl recommends: ii bash-completion 1:2.11-2 pn cme ii fuse 2.9.9-5 pn libconfig-model-tkui-perl pn libfuse-perl pn libtext-levenshtein-damerau-perl Versions of packages libconfig-model-perl suggests: pn libconfig-model-dpkg-perl pn libconfig-model-openssh-perl ii libterm-readline-gnu-perl 1.37-1
Bug#983809: ITP: pyahocorasick -- Aho-Corasick string search algorithm
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: pyahocorasick Version : 1.4.1 Upstream Author : Wojciech Muła * URL : https://github.com/WojciechMula/pyahocorasick/ * License : BSD-3-Clause Programming Lang: C, Python Description : Aho-Corasick string search algorithm pyahocorasick is a fast and memory efficient library for exact or approximate multi-pattern string search meaning that you can find multiple key strings occurrences at once in some input text. The library provides an ahocorasick Python module that you can use as a plain dict-like Trie or convert a Trie to an automaton for efficient Aho-Corasick search. This is a dependency of scancode.
Bug#983742: ITP: boolean.py -- boolean algebra library for Python
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: boolean.py Version : 3.8 Upstream Author : * URL : https://github.com/bastikr/boolean.py * License : BSD-2-clause Programming Lang: Python Description : boolean algebra library for Python "boolean.py" is a small library implementing a boolean algebra. It defines two base elements, TRUE and FALSE, and a Symbol class that can take on one of these two values. Calculations are done in terms of AND, OR and NOT - other compositions like XOR and NAND are not implemented but can be emulated with AND or and NOT. Expressions are constructed from parsed strings or in Python. This is a dependency for the license-expression module.
Bug#983741: ITP: license-expression -- parse, compare, ' 'simplify and normalize license expressions (such as SPDX license ' 'expressions) using boolean logic.
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: license-expression Version : 1.2 Upstream Author : * URL : https://github.com/nexb/license-expression * License : Apache-2.0 Programming Lang: Python Description : parse and manipulate SPDX license expressions license-expression is a small utility library to parse, compare, simplify and normalize license expressions (e.g. SPDX license expressions) using boolean logic such as: GPL-2.0 or later WITH Classpath Exception AND MIT. See also for details: https://spdx.org/sites/cpstandard/files/pages/files/spdxversion2.1.pdf#page=95=auto (this is a dependency for scancode-toolkit)
Bug#983711: ITP: saneyaml -- PyYaml wrapper with sane behaviour to read and write readable YAML safely
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij * Package name: saneyaml Version : 0.3 Upstream Author : Philippe Ombredanne * URL : https://github.com/nexB/saneyaml * License : Apache-2.0 Programming Lang: Python Description : PyYaml wrapper with sane behaviour to read and write readable YAML safely This micro library is a PyYaml wrapper with sane behaviour to read and write readable YAML safely, typically when used with configuration files. With saneyaml you can dump readable and clean YAML and load safely any YAML preserving ordering and avoiding surprises of type conversions by loading everything except booleans as strings. Optionally you can check for duplicated map keys when loading YAML. This is a dependency for scancode-toolkit.
Bug#983699: ITP: python-commoncode -- set of common functions and utilities for handling various things like paths, dates, files and hashes
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij * Package name: python-commoncode Version : 21.1.21 Upstream Author : Philippe Ombredanne * URL : https://github.com/nexB/commoncode * License : Apache-2.0 Programming Lang: Python Description : set of common functions and utilities for handling various things like paths, dates, files and hashes Commoncode provides a set of common functions and utilities for handling various things like paths, dates, files and hashes. It started as library in scancode-toolkit. Visit https://aboutcode.org and https://github.com/nexB/ for support and download. It is a dependency for scancode-toolkit
Bug#983640: ITP: scancode-toolkit -- detects licenses, copyrights, package manifests & dependencies and more by scanning code
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij * Package name: scancode-toolkit Version : 0.0.1 * URL : https://github.com/nexB/scancode-toolkit * License : Apache-2.0, some CC-BY-4.0 Programming Lang: Python Description : detects licenses, copyrights, package manifests & dependencies and more by scanning code A typical software project often reuses hundreds of third-party packages. License and origin information is not always easy to find and not normalized: ScanCode discovers and normalizes this data.
Bug#982883: report when fixes were skipped because of overrides
Package: lintian-brush Version: 0.95 Severity: wishlist lintian-brush should mention the number of skipped fixes due to overrides in its output, rather than silently skipping them and pretending there was nothing that could be fixed. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-4-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian-brush depends on: ii devscripts 2.20.5 ii ognibuild0.0.1~git20201031.4cbc8df-1.1 ii python3 3.9.1-1 ii python3-breezy 3.1.0-8 ii python3-debian 0.1.39 ii python3-debmutate0.20 ii python3-distro-info 1.0 ii python3-dulwich 0.20.15-1 ii python3-iniparse 0.4-3 ii python3-ruamel.yaml 0.16.12-2 ii python3-upstream-ontologist 0.1.9-1 Versions of packages lintian-brush recommends: ii decopy 0.2.4.4-0.1 ii dos2unix 7.4.1-1 ii gpg 2.2.27-1 ii libdebhelper-perl13.3.3 ii lintian 2.104.0 ii python3-asyncpg 0.21.0-1+b2 ii python3-bs4 4.9.3-1 ii python3-levenshtein 0.12.2-1 ii python3-pyinotify0.9.6-1.3 ii python3-toml 0.10.1-1 Versions of packages lintian-brush suggests: pn breezy-debian pn gnome-pkg-tools ii po-debconf 1.0.21+nmu1 ii postgresql-common 225 -- no debconf information
Bug#982655: scrub-obsolete: replace dependencies on transitional or removed packages
Package: lintian-brush Version: 0.92 Severity: wishlist scrub-obsolete should update any build-dependencies, test-dependencies or other dependencies on either: * packages that are transitional and for which the replacement can be derived * packages that have been removed but were present in the past and that have a single current package that Provides: them -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-4-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian-brush depends on: ii devscripts 2.20.5 ii python3 3.9.1-1 ii python3-breezy 3.1.0-8 ii python3-debian 0.1.39 ii python3-debmutate0.19 ii python3-distro-info 1.0 ii python3-dulwich 0.20.15-1 ii python3-iniparse 0.4-3 ii python3-ruamel.yaml 0.16.12-2 Versions of packages lintian-brush recommends: ii decopy 0.2.4.4-0.1 ii dos2unix 7.4.1-1 ii gpg 2.2.27-1 ii libdebhelper-perl13.3.3 ii lintian 2.104.0 ii python3-asyncpg 0.21.0-1+b2 ii python3-bs4 4.9.3-1 ii python3-levenshtein 0.12.1-1 ii python3-pyinotify0.9.6-1.3 ii python3-toml 0.10.1-1 Versions of packages lintian-brush suggests: pn breezy-debian pn gnome-pkg-tools ii po-debconf 1.0.21+nmu1 ii postgresql-common 225 -- no debconf information
Bug#982271: ITP: buildlog-consultant -- builg log parser and analyser
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: buildlog-consultant Version : 0.0.1 Upstream Author : Jelmer Vernooij * URL : https://github.com/jelmer/buildlog-consultant * License : GPL Programming Lang: Python Description : build log parser and analyser buildlog-consultant can parse build logs and highlight and extract the key error lines. This can be used to display a snippet from a build log with the actual problem. This functionality is factored out from debian-janitor, and a dependency for ognibuild.
Bug#981529: deb-scrub-obsolete: should strip redundant dependencies after removal
Package: lintian-brush Version: 0.92 Severity: normal When removing versioned dependencies, deb-scrub-obsolete should drop dependency entries that are also satisfied by other dependencies. For example, when changing: Depends: perl, libfoo-perl | perl (>> 5.6.0) to Depends: perl, libfoo-perl | perl deb-scrub-obsolete should just drop the second entry. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-4-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian-brush depends on: ii devscripts 2.20.5 ii python3 3.9.1-1 ii python3-breezy 3.1.0-8 ii python3-debian 0.1.39 ii python3-debmutate0.17 ii python3-distro-info 0.24 ii python3-dulwich 0.20.15-1 ii python3-iniparse 0.4-3 ii python3-ruamel.yaml 0.16.12-2 Versions of packages lintian-brush recommends: ii decopy 0.2.4.4-0.1 ii dos2unix 7.4.1-1 ii gpg 2.2.20-1 ii libdebhelper-perl13.3.1 ii lintian 2.104.0 ii python3-asyncpg 0.21.0-1+b2 ii python3-bs4 4.9.3-1 ii python3-levenshtein 0.12.1-1 ii python3-pyinotify0.9.6-1.3 ii python3-toml 0.10.1-1 Versions of packages lintian-brush suggests: pn breezy-debian pn gnome-pkg-tools ii po-debconf 1.0.21+nmu1 ii postgresql-common 224 -- no debconf information
Bug#981528: deb-scrub-obsolete: only updates changelog, but no deps changed
Package: lintian-brush Version: 0.92 Severity: normal See e.g.: https://janitor.debian.net/cupboard/pkg/libcatmandu-mods-perl/6be97b8e-9b65-4bec-9e08-4d655cc5f68c -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-4-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian-brush depends on: ii devscripts 2.20.5 ii python3 3.9.1-1 ii python3-breezy 3.1.0-8 ii python3-debian 0.1.39 ii python3-debmutate0.17 ii python3-distro-info 0.24 ii python3-dulwich 0.20.15-1 ii python3-iniparse 0.4-3 ii python3-ruamel.yaml 0.16.12-2 Versions of packages lintian-brush recommends: ii decopy 0.2.4.4-0.1 ii dos2unix 7.4.1-1 ii gpg 2.2.20-1 ii libdebhelper-perl13.3.1 ii lintian 2.104.0 ii python3-asyncpg 0.21.0-1+b2 ii python3-bs4 4.9.3-1 ii python3-levenshtein 0.12.1-1 ii python3-pyinotify0.9.6-1.3 ii python3-toml 0.10.1-1 Versions of packages lintian-brush suggests: pn breezy-debian pn gnome-pkg-tools ii po-debconf 1.0.21+nmu1 ii postgresql-common 224 -- no debconf information
Bug#980824: no-op-testsuite: many false positives
Package: lintian Version: 2.104.0 Severity: normal no-op-testsuite seems to trigger on any Test-Command that invokes /bin/true, even if that testcommand e.g. uses shell constructs and only invokes /bin/true in some code paths. Out of the ~dozen source packages listed, at least for the first few it is a false positive: https://lintian.debian.org/tags/no-op-testsuite.html (bcftools, php-zend-code, python-pysam, sleef) -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-4-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils2.35.1-7 ii bzip2 1.0.8-4 ii diffstat1.64-1 ii dpkg1.20.7.1 ii dpkg-dev1.20.7.1 ii file1:5.39-3 ii gettext 0.21-3 ii gpg 2.2.20-1 ii intltool-debian 0.35.0+20060710.5 ii libapt-pkg-perl 0.1.36+b4 ii libarchive-zip-perl 1.68-1 ii libcapture-tiny-perl0.48-1 ii libclass-xsaccessor-perl1.19-3+b6 ii libclone-perl 0.45-1+b1 ii libconfig-tiny-perl 2.24-1 ii libcpanel-json-xs-perl 4.25-1+b1 ii libdata-dpath-perl 0.58-1 ii libdata-validate-domain-perl0.10-1.1 ii libdevel-size-perl 0.83-1+b2 ii libdpkg-perl1.20.7.1 ii libemail-address-xs-perl1.04-1+b3 ii libfile-basedir-perl0.08-1 ii libfile-find-rule-perl 0.34-1 ii libfont-ttf-perl1.06-1.1 ii libhtml-html5-entities-perl 0.004-1.1 ii libipc-run3-perl0.048-2 ii libjson-maybexs-perl1.004003-1 ii liblist-compare-perl0.55-1 ii liblist-moreutils-perl 0.430-2 ii liblist-utilsby-perl0.11-1 ii libmoo-perl 2.004004-1 ii libmoox-aliases-perl0.001006-1.1 ii libnamespace-clean-perl 0.27-1 ii libpath-tiny-perl 0.114-2 ii libperlio-gzip-perl 0.19-1+b7 ii libproc-processtable-perl 0.59-2+b1 ii libsereal-decoder-perl 4.018+ds-1+b1 ii libsereal-encoder-perl 4.018+ds-1+b1 ii libtext-glob-perl 0.11-1 ii libtext-levenshteinxs-perl 0.03-4+b8 ii libtext-markdown-discount-perl 0.12-1+b1 ii libtext-xslate-perl 3.5.8-1+b1 ii libtime-duration-perl 1.21-1 ii libtime-moment-perl 0.44-1+b3 ii libtimedate-perl2.3300-1 ii libtry-tiny-perl0.30-1 ii libtype-tiny-perl 1.012000-1 ii libunicode-utf8-perl0.62-1+b2 ii liburi-perl 5.06-1 ii libxml-libxml-perl 2.0134+dfsg-2+b1 ii libyaml-libyaml-perl0.82+repack-1+b1 ii lzip1.21-8 ii lzop1.04-2 ii man-db 2.9.3-2 ii patchutils 0.4.2-1 ii perl [libdigest-sha-perl] 5.32.0-6 ii t1utils 1.41-4 ii unzip 6.0-26 ii xz-utils5.2.5-1.0 lintian recommends no packages. Versions of packages lintian suggests: pn binutils-multiarch ii libtext-template-perl 1.59-1 -- no debconf information
Bug#979464: ITP: qbrz -- Qt frontend for breezy
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij X-Debbugs-Cc: debian-de...@lists.debian.org, breezy-c...@googlegroups.com * Package name: qbrz Version : 0.1 Upstream Author : RJL situp and qbzr authors * URL : https://launchpad.net/qbrz * License : GPL Programming Lang: PYthon Description : Qt frontend for breezy QBrz is a cross platform, Qt-based front-end for Breezy, providing GUI applications for many core breezy commands. In addition, it provides several special dialogs and helper commands. Equivalents for core breezy commands have the same names as CLI commands but with a prefix of "q".
Bug#978081: ITP: setuptools-rust -- support for packaging rust extensions using setuptools
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: setuptools-rust Version : 0.11.6 Upstream Author : Nikolay Kim * URL : https://github.com/PyO3/setuptools-rust * License : MIT Programming Lang: Python Description : setuptools plugin for Rust extensions Setuptools helpers for rust Python extensions implemented with PyO3 and rust-cpython. Compile and distribute Python extensions written in rust as easily as if they were written in C.
Bug#977593: check cert validity when upgrading homepage field from http to https
Package: lintian-brush Version: 0.89 Severity: normal See e.g. https://salsa.debian.org/debian/sysstat/-/merge_requests/1/diffs#note_207379 When upgrading http: URLs to https:, lintian-brush should verify that the cert is trusted by the CAs on a normal Debian system. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-3-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian-brush depends on: ii devscripts 2.20.5 ii python3 3.9.0-4 ii python3-breezy 3.1.0-8 ii python3-debian 0.1.38 ii python3-debmutate0.16 ii python3-distro-info 0.24 ii python3-dulwich 0.20.8-1+b1 ii python3-iniparse 0.4-3 ii python3-ruamel.yaml 0.16.12-2 Versions of packages lintian-brush recommends: ii decopy 0.2.4.4-0.1 ii dos2unix 7.4.1-1 ii gpg 2.2.20-1 ii libdebhelper-perl13.3 ii lintian 2.104.0 ii python3-asyncpg 0.21.0-1+b2 ii python3-bs4 4.9.3-1 ii python3-levenshtein 0.12.0-5+b3 ii python3-pyinotify0.9.6-1.3 ii python3-toml 0.10.1-1 Versions of packages lintian-brush suggests: pn breezy-debian pn gnome-pkg-tools ii po-debconf 1.0.21 ii postgresql-common 223 -- no debconf information
