Re: New supply-chain security tool: backseat-signed
Hello, On Sat 06 Apr 2024 at 02:42pm +03, Adrian Bunk wrote: > On Sat, Apr 06, 2024 at 07:13:22PM +0800, Sean Whitton wrote: >> Hello, >> >> On Fri 05 Apr 2024 at 01:31am +03, Adrian Bunk wrote: >> >> > >> > Right now the preferred form of source in Debian is an upstream-signed >> > release tarball, NOT anything from git. >> >> The preferred form of modification is not simply up for proclamation. >> Our practices, which are focused around git, make it the case that >> salsa & dgit in some combination are the preferred form for modification >> for most packages. > > You cannot simply proclaim that some git tree is the preferred form of > modification without shipping said git tree in our ftp archive. > > If your claim was true, then Debian and downstreams would be violating > licences like the GPL by not providing the preferred form of modification > in the archive. Well, maybe we are! Or maybe we're not when we publish those histories on salsa and/or dgit-repos. It also seems important to note that this is project-specific. Whether the git history is part of the preferred form of modification depends on the project's practices and content. I don't have a settled opinion on what we should be doing. But what I am sure about is that the preferred form for modification is determined by the content of the project, and we can't change what the preferred form for modification actually is just by choosing what exactly we publish. -- Sean Whitton signature.asc Description: PGP signature
Re: New supply-chain security tool: backseat-signed
Hello, On Sat 06 Apr 2024 at 02:24pm +02, Guillem Jover wrote: > Hi! > > On Sat, 2024-04-06 at 19:13:22 +0800, Sean Whitton wrote: >> On Fri 05 Apr 2024 at 01:31am +03, Adrian Bunk wrote: >> > Right now the preferred form of source in Debian is an upstream-signed >> > release tarball, NOT anything from git. >> >> The preferred form of modification is not simply up for proclamation. >> Our practices, which are focused around git, make it the case that >> salsa & dgit in some combination are the preferred form for modification >> for most packages. > > People keep bringing this up, and it keeps making no sense. I've > covered this over the years in: > > https://lists.debian.org/debian-devel/2014/03/msg00330.html > https://lists.debian.org/debian-project/2019/07/msg00180.html > > (There's in addition the part that Adrian covers in another reply.) I understand this point of view. The situation is not clear. But it is at least plausible that for some projects, the git history is part of the preferred form for modification. It is certainly not always true. I think that this point is largely academic, however. We are doing a disservice to our users if they have to go hunting beyond Debian services to find the upstream git history, because they'll likely want it if they indeed do want to modify packages installed on their system. Our own git histories of packaging changes aren't enough. So we should be hosting both, on some combination of salsa and dgit-repos. -- Sean Whitton signature.asc Description: PGP signature
Bug#1068546: ITP: async-asgi-testclient -- Python async client for testing ASGI web applications
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: async-asgi-testclient Version : 1.4.11 Upstream Author : Jordi Masip * URL : https://github.com/vinissimus/async-asgi-testclient * License : Expat Programming Lang: Python Description : Python async client for testing ASGI web applications This library is used for testing ASGI (Asynchronous Server Gateway Interface) applications. It is designed to be a common testing library for such applications that does not depend on the specific web framework being used. . It works by calling the ASGI app directly rather than via a web server. This package is a (recursive) dependency of the new version of jupyter-server. (More precisely, it is a test-time dependency of a currently unreleased version of picobox.) It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/async-asgi-testclient
Bug#1068547: ITP: jupyter-server-terminals -- Jupyter server extension providing support for terminals
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: jupyter-server-terminals Version : 0.5.3 Upstream Author : Jupyter Development Team * URL : https://github.com/jupyter-server/jupyter_server_terminals * License : BSD-3-clause Programming Lang: Python Description : Jupyter server extension providing support for terminals This package allows Jupyter servers to interface to terminals via Tornado websockets. This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/jupyter-server-terminals
Bug#1068549: ITP: pytest-console-scripts -- Pytest plugin for running Python scripts from within tests
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: pytest-console-scripts Version : 1.4.1 Upstream Author : Vasily Kuznetsov * URL : https://github.com/kvas-it/pytest-console-scripts * License : Expat Programming Lang: Python Description : Pytest plugin for running Python scripts from within tests This plugin is quite similar to `subprocess.run()`, but it also has an in-process mode, where the scripts are executed by the interpreter that's running `pytest` (using some amount of sandboxing). . In-process mode significantly reduces the run time of the test suites that run many external scripts. This is speeds up development. In a CI environment subprocess mode can be used to make sure the scripts also work (and behave the same) when run by a fresh interpreter. This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/pytest-console-scripts
Bug#1068548: ITP: picobox -- Opinionated Python dependency injection framework
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: picobox Version : 4.0.0 Upstream Author : Ihor Kalnytskyi * URL : https://github.com/ikalnytskyi/picobox * License : Expat Programming Lang: Python Description : Opinionated Python dependency injection framework Picobox is designed to be clean, pragmatic and with Python in mind. No complex graphs, no implicit injections, no type bindings - just picoboxes and explicit demands. . It is a small, thread-safe, pure Python library with no dependencies. This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/picobox
Bug#1068550: ITP: pytest-mypy-testing -- Plugin to test mypy output with pytest
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: pytest-mypy-testing Version : 0.1.3 Upstream Author : Copyright: David Fritzsche * URL : https://github.com/davidfritzsche/pytest-mypy-testing * License : CC0-1.0 Programming Lang: Python Description : Plugin to test mypy output with pytest This plugin provides a way to test that mypy produces a given output. As mypy can be told to display the type of an expression, this allows one to check mypy's type interference. This package is a test-time dependency of the new version of traitlets; the current version in unstable has the relevant tests ignored at present, but it would be good to be able to include these tests in the autopkgtest suite. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/pytest-mypy-testing
Bug#1068551: ITP: python-fqdn -- Python library to validate fully qualified domain names (FQDNs)
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: python-fqdn Version : 1.5.1 Upstream Author : ypcrts * URL : https://github.com/ypcrts/fqdn * License : MPL-2.0 Programming Lang: Python Description : Python library to validate fully qualified domain names (FQDNs) This package validates FQDNs conforming to the Internet Engineering Task Force (IETF) specification (RFC 1123 in particular). The design intent is to validate that a string would be traditionally acceptable as a public Internet hostname to RFC-conforming software. Configuration options can be used to obtain more relaxed checks. This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/python-fqdn
Bug#1068552: ITP: python-isoduration -- Operations with ISO 8601 durations (Python 3 package)
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: python-isoduration Version : 20.11.0+git20211126.ae0bd61 Upstream Author : Víctor Muñoz * URL : https://github.com/bolsote/isoduration * License : ISC Programming Lang: Python Description : Operations with ISO 8601 durations (Python 3 package) ISO 8601 supports time durations in string format, for example "P3Y6M4DT12H30M5S" represents a duration of 3 years, 6 months, 4 days, 12 hours, 30 minutes, and 5 seconds. This package supports working with such durations, addressing the shortcomings of the isodate package. This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/python-isoduration
Bug#1068553: ITP: python-overrides -- Python decorator to verify that expected overrides are maintained
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: python-overrides Version : 7.7.0 Upstream Author : Copyright: Mikko Korpela * URL : https://github.com/mkorpela/overrides * License : Apache-2.0 Programming Lang: Python Description : Python decorator to verify that expected overrides are maintained Provides a decorator @override that verifies that a method that should override an inherited method actually does it. Python has no standard mechanism by which to guarantee that (1) a method that previously overrode an inherited method continues to do so, and (2) a method that previously did not override an inherited will not override now. This package allows this to be addressed in an automated manner. This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/python-overrides
Bug#1068554: ITP: rfc3339-validator -- RFC 3339 validator (Python library)
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: rfc3339-validator Version : 0.1.4 Upstream Author : Nicolas Aimetti * URL : https://github.com/naimetti/rfc3339-validator * License : Expat Programming Lang: Python Description : RFC 3339 validator (Python library) This package provides a validator for date-time strings to determine whether they conform to the Internet Engineering Task Force (IETF) Internet Date/Time Format (RFC 3339). This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/rfc3339-validator
Bug#1068555: ITP: rfc3986-validator -- RFC 3986 validator (Python library)
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: rfc3986-validator Version : 0.1.1 Upstream Author : Nicolas Aimetti * URL : https://github.com/naimetti/rfc3986-validator * License : Expat Programming Lang: Python Description : RFC 3986 validator (Python library) This package provides a validator for URIs to determine whether they conform to the Internet Engineering Task Force (IETF) specification (RFC 3986). This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/rfc3986-validator
Bug#1068556: ITP: sphinxcontrib-emojicodes -- Sphinx extension to use emoji codes in Sphinx documentation
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: sphinxcontrib-emojicodes Version : 0.3.1 Upstream Author : Copyright: The Sphinx Emoji Codes contributors * URL : https://github.com/sphinx-contrib/emojicodes * License : BSD-3-clause Programming Lang: Python Description : Sphinx extension to use emoji codes in Sphinx documentation This extension allows one to write things like |:smile:| in Sphinx documentation. This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/sphinxcontrib-emojicodes
Bug#1068557: ITP: sphinxcontrib-openapi -- Sphinx extension to generate API docs from OpenAPI spec
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: sphinxcontrib-openapi Version : 0.8.4 Upstream Author : Ihor Kalnytskyi * URL : https://github.com/sphinx-contrib/openapi * License : BSD-2-clause Programming Lang: Python Description : Sphinx extension to generate API docs from OpenAPI spec This extension generates API documentation for reStructuredText documentation using the Sphinx system. It also depends on `sphinxcontrib.httpdomain` that provides an HTTP domain for describing RESTful HTTP APIs. This package is a (recursive) dependency of the new version of jupyter-server. It will be team-maintained within the Debian Python Team. The Debian packaging is on salsa at https://salsa.debian.org/python-team/packages/sphinxcontrib-openapi
Debian 12 released with two RC bugs in Sylpheed
Hi, Debian 12 was released with two Release Critical bugs I filed on May 20th 2023 (#1036424 and #1036388) on Sylpheed about issues that I found on stable, and remain, with Debian 12 released later on June 10th 2023. The maintainer accumulates a lot of bugs for the package, doesn't take care about almost all, and when I filed a RC bug because the package became unusable to me he downgraded severity to important claiming it was just a Gmail issue, when it didn't seem so, even if it was just happening with Gmail. I wanted to point you to this bug number to provide records, but couldn't find it neither opened nor archived. The supposed solution at the time for it was to upload 3.7.0beta1, when the existing version was 3.6.0, and the issue magically disappeared without explanation from him. I discovered he uploaded later another beta (3.8.0beta1), which was included in Debian 12. As far as I recall, 3.7.0beta1 got into Debian 11. He even claimed at the time that Sylpheed was too old and so troublesome and useless and was considering removing it from Debian just because of that. I want to know why Debian 12 was released with those two Sylpheed RC bags, report the incident to you all, know what to do with the maintainer and kindly request that someone better at the job takes over Sylpheed maintainance, or otherwise I will become a Debian developer and package it myself. There are earlier precedents of me filing a RC bug on Sylpheed, with the bug getting unattended, he raising a bad excuse that it was inexistant, and the package caming up later with a newer version with the issue solved and me making the mistake of thinking I was wrong about the bug existing and needed to be filed, and (me) closed the bug, most likely when it still remained in stable (this I don't remember perfectly at this time). I even have no doubt that what he packaged to stable (bookworm) currently has at least one back door that is not credible at all is in upstream, showing up with the spell checker marking some words in this email as wrong after initially turning up as correctly spelt, namedly "caming" and "mistakingly".
Re: [sylpheed:37253] Debian 12 released with two RC bugs in Sylpheed
On Sun, 7 Apr 2024 13:26:49 +0200 José Luis González wrote: > Debian 12 was released with two Release Critical bugs I filed on May > 20th 2023 (#1036424 and #1036388) on Sylpheed about issues that I > found on stable, and remain, with Debian 12 released later on June 10th > 2023. Those are not "Release Critical bugs". > I want to know why Debian 12 was released with those two Sylpheed RC > bags, report the incident to you all, know what to do with the > maintainer and kindly request that someone better at the job takes over > Sylpheed maintainance, or otherwise I will become a Debian developer > and package it myself. The upstream mailing list is not the place for this Debian discussion. On the one hand you "kindly request" and on the other your hurl unwarranted insults on a public list about the long-term Debian maintainer. Maybe Debian will overlook your behaviour and accept you as a developer, I don't know. with regards Paul
Re: Debian 12 released with two RC bugs in Sylpheed
On Apr 07, José Luis González wrote: > I want to know why Debian 12 was released with those two Sylpheed RC > bags, report the incident to you all, know what to do with the > maintainer and kindly request that someone better at the job takes over > Sylpheed maintainance, or otherwise I will become a Debian developer > and package it myself. Big Jia Tan vibe here... -- ciao, Marco signature.asc Description: PGP signature
Bug#1068578: RFH: singularity-container -- container platform focused on supporting "Mobility of Compute"
Package: wnpp Severity: normal X-Debbugs-Cc: singularity-contai...@packages.debian.org, debian-devel@lists.debian.org, o...@debian.org, me...@dogguy.org Control: affects -1 + src:singularity-container Assistance required with maintaining the singularity-container package. I am not the uploader/maintainer of this package, however I am the only one who has been taking care of it via team uploads for more than 2 years and all other uploaders are MIA. Few of them asked me to remove myself from uploaders field, which I have done. However, I don't consider the package well-maintained w/o me doing the work. It is also stalled from migrating to stable because maintaining it there requires backporting and testing CVE fixes and I don't have the bandwidth to do that work, which is the reason for #1029669. With my available time, it is unlikely that I will be maintaining it timely or at all. Any help for maintaining it would be great. The package description is: Mobility of Compute encapsulates the development to compute model where developers can work in an environment of their choosing and creation and when the developer needs additional compute resources, this environment can easily be copied and executed on other platforms. Additionally as the primary use case for Singularity is targeted towards computational portability, many of the barriers to entry of other container solutions do not apply to Singularity making it an ideal solution for users (both computational and non-computational) and HPC centers. signature.asc Description: PGP signature
Re: Debian 12 released with two RC bugs in Sylpheed
In days of yore (Sun, 07 Apr 2024), José Luis González thus quoth: > Hi, > > Debian 12 was released with two Release Critical bugs I filed on May > 20th 2023 (#1036424 and #1036388) on Sylpheed about issues that I > found on stable, and remain, with Debian 12 released later on June 10th > 2023. So, bug #1036424 is a problem that when you reply to an email, it does not set the From account properly, it uses the default account. That is perhaps a usability defect, but it is not a critical impact defect by any stretch of the imagination. Critical is usually reserved for things like remote exploit, data corruption, or otherwise, you know, critical issues. The other bug, #1036388, has a little more meat on it, but still does not meet the criteria of Critical. Looking at it on the scale of Critical, Important, Medium and Low, I think it warrants Important if I understand the problem description right. Which, correct me if I am wrong, is: - Configure Sylpheed with account A and sender u...@a.com - Configure Sylpheed with additional account B and sender u...@b.com - Account A is default, but we switch to account B for the session. - When a new mail for Account A is received, it is placed in Account B's folders. Okay, that would be an annoying issue. But the bug was addressed. The issue was resolved in Sylpheed 3.8.0~beta1-1. For all I know, the issue was complex and non-trivial to backport to version 3.7.0. I am not the package maintainer, nor the upstream developer, so I am not about to yell at them when they actually produced the fix. To put a perspective on this - I use mutt, with at least four separate email accounts, all receiving email and ultimately pooling into my mailserver. When I send email, I do need to check that I am actually sending as the correct persona as mutt does guess who to send as, but it does not always get it right. Has it led to me sending emails with the wrong sender? Yep. And I apologise when it happens and move on, re-rending with the correct sender. I do not consider this to be a defect in mutt as mutt has never advertised that it will get its guesses of who to send as 100% right when there are more than one account configured as I have it set up. Also - a question that is rhetorical and more food for thought: How much are you paying for your Debian subscription and support per year? -- Kind regards, /S
Re: Debian 12 released with two RC bugs in Sylpheed
On Sun, 7 Apr 2024 13:26:49 +0200 José Luis González wrote: > The maintainer accumulates a lot of bugs for the package, doesn't take > care about almost all, and when I filed a RC bug because the package > became unusable to me he downgraded severity to important claiming it > was just a Gmail issue, when it didn't seem so, even if it was > just happening with Gmail. I wanted to point you to this bug number to > provide records, but couldn't find it neither opened nor archived. The I found the report now. It's #1036799.
Bug#1068581: ITP: goawk -- A POSIX-compliant AWK interpreter written in Go, with CSV support
Package: wnpp Severity: wishlist Owner: Guilherme Puida Moreira * Package name: goawk Version : 1.26.0-1 Upstream Author : Ben Hoyt * URL : https://github.com/benhoyt/goawk * License : Expat Programming Lang: Go Description : POSIX-compliant AWK interpreter written in Go, with CSV support GoAWK is a POSIX-compatible version of AWK, and additionally has a CSV mode for reading and writing CSV and TSV files. . Additional features GoAWK has over AWK: . * It has proper support for CSV and TSV files. * It's the only AWK implementation we know with a code coverage feature * It supports negative field indexes to access fields from the right, for example, $-1 refers to the last field. * It's embeddable in your Go programs! You can even call custom Go functions from your AWK scripts. * Most AWK scripts are faster than awk and on a par with gawk, though usually slower than mawk. * The parser supports 'single-quoted strings' in addition to "double- quoted strings", primarily to make Windows one-liners easier when using the cmd.exe shell (which uses " as the quote character). I plan to maintain this package under the Go Team's umbrella. --puida
Re: finally end single-person maintainership
Hi Wouter, Am Sun, Apr 07, 2024 at 03:31:43PM +0200 schrieb Wouter Verhelst: > [Feel free to quote any part of this email which I wrote outside of this > mailinglist] OK, moving the discussion to debian-devel where it should belong. > Debian packages need to be well maintained. In some cases, having > multiple maintainers on a package improves the resulting quality of > packages. But in some other cases, it does not; one example for this > second case is my package "logtool", which I'm going to upload to fix > #1066251 soon and for which by the simple act of doing that I will > double the amount of uploads it's seen in the past five years (and the > number of uploads in the past 10 can still be counted on the fingers of > a single hand). > > This is not because it's not well maintained; it's because the package > just *does not require* a lot of work to be kept up to date: upstream > has not been active for over 20 years, but it still performs the job it > was designed to do, as it was designed to, and I see no need to have it > removed from the archive. What is your opinion about pushing logtool to Salsa? > A second good example is my package "nbd". Which is maintained on Salsa which I personally consider nice. > Similarly, the fact that a package has a "team" listed as its maintainer > not in any wayimply that the team has more than zero members. ACK, > If there are stupid barriers to helping people out by doing NMUs or > taking over packages, then by all means let's break down those barriers. I was sometimes confronted with those barriers. > But let's not try to "fix" a problem by introducing a rule that is, at > best, affecting something only very weakly related to the problem that > we are trying to solve. I would be happy to talk about rules that might help solving problems (as well as droping rules that are creating barriers). Kind regards Andreas. -- https://fam-tille.de
Re: finally end single-person maintainership
On Sun, Apr 07, 2024 at 04:04:18PM +0200, Andreas Tille wrote:
> Hi Wouter,
>
> Am Sun, Apr 07, 2024 at 03:31:43PM +0200 schrieb Wouter Verhelst:
> > [Feel free to quote any part of this email which I wrote outside of this
> > mailinglist]
>
> OK, moving the discussion to debian-devel where it should belong.
>
> > Debian packages need to be well maintained. In some cases, having
> > multiple maintainers on a package improves the resulting quality of
> > packages. But in some other cases, it does not; one example for this
> > second case is my package "logtool", which I'm going to upload to fix
> > #1066251 soon and for which by the simple act of doing that I will
> > double the amount of uploads it's seen in the past five years (and the
> > number of uploads in the past 10 can still be counted on the fingers of
> > a single hand).
> >
> > This is not because it's not well maintained; it's because the package
> > just *does not require* a lot of work to be kept up to date: upstream
> > has not been active for over 20 years, but it still performs the job it
> > was designed to do, as it was designed to, and I see no need to have it
> > removed from the archive.
>
> What is your opinion about pushing logtool to Salsa?
I did that as part of my latest upload :)
https://salsa.debian.org/wouter/logtool
(I realize now that I forgot to add VCS headers... ah well, next time
I'm sure)
[...]
> > If there are stupid barriers to helping people out by doing NMUs or
> > taking over packages, then by all means let's break down those barriers.
>
> I was sometimes confronted with those barriers.
And that's not good, and we should work on those.
I just don't think that mandating team maintenance drops those barriers.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Re: finally end single-person maintainership
Hi again, Am Sun, Apr 07, 2024 at 04:10:15PM +0200 schrieb Wouter Verhelst: > > > > What is your opinion about pushing logtool to Salsa? > > I did that as part of my latest upload :) > > https://salsa.debian.org/wouter/logtool Great. > (I realize now that I forgot to add VCS headers... ah well, next time > I'm sure) This happens. I was seeking Salsa before asking - if people do so they'll find it. > And that's not good, and we should work on those. > > I just don't think that mandating team maintenance drops those barriers. Do you think that mandating Salsa is a sensible step in this direction? Kind regards Andreas. -- https://fam-tille.de
Re: [sylpheed:37255] Re: Debian 12 released with two RC bugs in Sylpheed
On Sun, 7 Apr 2024 15:18:57 +0200 José Luis González wrote: > I found the report now. It's #1036799. Yes, it looks like a temporary server issue. And you're sending via gmail now. But again, what do you expect a package maintainer to do? It's upstream where bugs get fixed. Your subject is wrong, your two RC bugs are not RC bugs; in fact, they both seem to be describing the same behaviour, and you are requesting that the behaviour be different. i.e. they are feature requests. The more I consider your complaints about the Debian maintainer, the less they seem to hold water. with regards Paul
Re: Bug#1068479 cynically closed by Rene Engelhard (Re: Bug#1068479: libreoffice-writer: space between paragraphs missing in spacing and indentation)
reopen 1068479 thanks Hi all, Rene Engelhard seems to be a worse case even than Ricardo Mones. Take a look at my recent bug reports to libreoffice-writer and his replies. In this one: > Am 06.04.24 um 11:03 schrieb Rene Engelhard: > > Am 06.04.24 um 00:34 schrieb José Luis González: > >> The setting for spacing between paragraphs is missing in the spacing > >> and indentation tab of the paragraph dialog. > > > > ? > > > > It's definitely there. Format -> Paragraph has spacing "after/before". I meant spacing between paragraphs, not spacing after and before paragraphs. The report was crystal clear. The difference, for those who didn't realize is space after paragraph happens always, and between only between them, being the regular separation between paragraphs (the other is formatting, and isn't useful as a substitute because it adds something undesirable at the end of the document or between paragraphs and other kinds of block elements). > As said here and proved by screenshots in en,de and es this is present. Why should anybody provide a screenshot of a feature that is missing? What would be the screenshot of? Vacuum? > Closing this non-bug. The non-bug that should be closed is your brain pretending a RC bug doesn't exist, especially since you fully knew it was a bug, and you closed it just because it bothers you having a RC one in the package. If you don't want to maintain the package leave the position for other who does, and stop ruining Debian's Quality and bothering me. > > From: José Luis González > > To: sub...@bugs.debian.org > > Subject: libreoffice-writer: space between paragraphs missing in spacing > > and indentation > > Date: Sat, 6 Apr 2024 00:34:12 +0200 > > X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) > > > > Package: libreoffice-writer > > Version: 4:7.4.7-1+deb12u1 > > Severity: serious > > > > The setting for spacing between paragraphs is missing in the spacing > > and indentation tab of the paragraph dialog. > > > > Serious severity because the bug has a major effect on the usability of > > the package, without rendering it completely unusable, considering > > paragraphs are a key feature in a word processor, and spacing is > > something very very basic for them and incredibly necessary. On Sun, 07 Apr 2024 18:36:07 + "Debian Bug Tracking System" wrote: > This is an automatic notification regarding your Bug report > which was filed against the libreoffice-writer package: > > #1068479: libreoffice-writer: space between paragraphs missing in spacing and > indentation > > It has been closed by Rene Engelhard (reply to Rene > Engelhard , 1068...@bugs.debian.org). > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Rene Engelhard > (reply to Rene Engelhard , > 1068...@bugs.debian.org) by > replying to this email. > > > -- > 1068479: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068479 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems
Re: Bug#1068479 cynically closed by Rene Engelhard (Re: Bug#1068479: libreoffice-writer: space between paragraphs missing in spacing and indentation)
Hi, Am 07.04.24 um 20:59 schrieb José Luis González: Am 06.04.24 um 00:34 schrieb José Luis González: The setting for spacing between paragraphs is missing in the spacing and indentation tab of the paragraph dialog. ? It's definitely there. Format -> Paragraph has spacing "after/before". I meant spacing between paragraphs, not spacing after and before paragraphs. The report was crystal clear. No, it wasn't. The difference, for those who didn't realize is space after paragraph happens always, and between only between them, being the regular separation between paragraphs (the other is formatting, and isn't useful as a substitute because it adds something undesirable at the end of the document or between paragraphs and other kinds of block elements). Aha. Still not RC. You could have replied to my mails, though. As said here and proved by screenshots in en,de and es this is present. Why should anybody provide a screenshot of a feature that is missing? What would be the screenshot of? Vacuum? Read again, I didn't ask for screenshots. Closing this non-bug. The non-bug that should be closed is your brain pretending a RC bug doesn't exist, especially since you fully knew it was a bug, and you closed it just because it bothers you having a RC one in the package. If you don't want to maintain the package leave the position for other who does, and stop ruining Debian's Quality and bothering me. Even if there was a bug it's not RC. From: José Luis González To: sub...@bugs.debian.org Subject: libreoffice-writer: space between paragraphs missing in spacing and indentation Date: Sat, 6 Apr 2024 00:34:12 +0200 X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Package: libreoffice-writer Version: 4:7.4.7-1+deb12u1 Severity: serious The setting for spacing between paragraphs is missing in the spacing and indentation tab of the paragraph dialog. Serious severity because the bug has a major effect on the usability of the package, without rendering it completely unusable, considering paragraphs are a key feature in a word processor, and spacing is something very very basic for them and incredibly necessary. And again: That is the definition of important at most, not serious. Read the bug severities. Regards, Rene
Re: Bug#1068479 cynically closed by Rene Engelhard (Re: Bug#1068479: libreoffice-writer: space between paragraphs missing in spacing and indentation)
Hi, Am 07.04.24 um 20:59 schrieb José Luis González: Closing this non-bug. Maybe that indeed was too harsh, I apologize. But you could have explained what you mean in a polite way instead of starting directly with ad-hominem attacks on a public list? The non-bug that should be closed is your brain pretending a RC bug doesn't exist, especially since you fully knew it was a bug, and you closed it just because it bothers you having a RC one in the package. No, I wasn't. And there's no RC bug here anyway. I closed it because I thought before/after is what you meant with between. And that is definitely there. Now that you say there's something else you mean (please describe it exactly so I forward it upstream), that is someting else. If you don't want to maintain the package leave the position for other who does, and stop ruining Debian's Quality and bothering me. Thanks, but I *want* to maintain the package and I *do* maintain the package. Regards, Rene
Silent hijacking and stripping records from changelog
Hi Sylvestre and Alexander (cc Rust team and debian-devel), Please do not silently hijack packages. If you would like to take over maintenance for some package, then please ask. Then I won't bite¹. And when you do hijack packages²³, then please be respectful and give credit, by preserving/reviving past contributions in the changelog file. Kind regards, - Jonas ¹ Just like I didn't bite at the accidental hijack in February: Quoting Jonas Smedegaard (2024-02-17 02:20:03) > Hi Sylvestre, > > Quoting Sylvestre Ledru (2024-02-16 19:24:00) > > I am really sorry but it seems that I made a mistake with rust > > palette: > > > > https://tracker.debian.org/pkg/rust-palette > > > > I didn't realize that it was already uploaded (probably because I > > uploaded https://tracker.debian.org/pkg/rust-palette-derive ) > > > > Please let me know how to fix this issue :( > > > > I needed it for the new version of eza! > > Ok, I will try fix that. I recognize how that confusion could arise (as > in: I could've easily made the same mistake - and possible did). > > Please take a look at related bug#1063779. And just as I didn't bite when, after ignoring the above mentioned bug and after my work cleaning up after the February accident, that same package *again* was hijacked: https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2024-April/040451.html Only when you shrugged when my pointing out that second hijack did I arguably bite: https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2024-April/040452.html ² This changelog: https://tracker.debian.org/media/packages/r/rust-palette/changelog-0.7.5-1 is missing these entries: https://salsa.debian.org/debian/rust-palette/-/blob/debian/0.7.4.0+dfsg-3/debian/changelog ³ This changelog: https://tracker.debian.org/media/packages/r/rust-lazy-regex-proc-macros/changelog-3.1.0-1 is missing these entries: https://tracker.debian.org/media/packages/r/rust-lazy-regex/changelog-3.1.0-1 -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Debian openssh option review: considering splitting out GSS-API key exchange
On Tue, 2024-04-02 at 12:04 +0200, Marco d'Itri wrote: > On Apr 02, Colin Watson wrote: > > > At the time, denyhosts was popular, but it was removed from Debian > > several years ago. I remember that, when I dealt with that on my > > own > > systems, fail2ban seemed like the obvious replacement, and my > > impression > > is that it's pretty widely used nowadays; it's very pluggable but > > it > > normally works by adding firewall rules. Are there any similar > > popular > > systems left that rely on editing /etc/hosts.deny? > Yes, people. I object to removing TCP wrappers support since the > patch > is tiny and it supports use cases like DNS-based ACLs which cannot be > supported by L3 firewalls. > There are more than enough ways to keep the entries based on dns records in your l3 firewalls uptodate, I can't see how this should warrant to keep yet another patch Jan^WMarco. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Re: finally end single-person maintainership
On 2024-04-07 16:04 +0200, Andreas Tille wrote: > Am Sun, Apr 07, 2024 at 03:31:43PM +0200 schrieb Wouter Verhelst: > > [Feel free to quote any part of this email which I wrote outside of this > > mailinglist] > > OK, moving the discussion to debian-devel where it should belong. Good plan. > > Debian packages need to be well maintained. In some cases, having > > multiple maintainers on a package improves the resulting quality of > > packages. But in some other cases, it does not; > > I am all for reducing the barrier to doing NMUs. Let's look at > > that; it's ridiculous that we need to ask permission to help > > someone else with maintaining packages if it's clear that they can > > use it. Debian as a whole is a team, and we maintain the > > distribution together. So when I do an NMU for your stuff, I'm > > here to help. You should be happy when I'm offering to help; and > > that's even enshrined in the code of conduct: > > [...] offers for help should be seen in the context of our shared > > goal of improving Debian > > The fact that a package is listed as maintained by a person rather > > than a team does not mean the person is the only person who is > > responsible for that package. Debian as a whole is. And the > > release team is, in the context of deciding what happens with a > > package that has outstanding RC bugs. And the QA team is, when > > they run full-archive test rebuilds for new things. And our users > > are, when they file bugs. So I agree with everything Wouter said in this mail. I'm keen on changing the _culture_ to make it easier to just fix things. But Andreas seems to have taken this idea of 'we should make it easier to help people maintain packages', and conflated it with 'everyone has to use salsa' and 'everything should be team maintained'. I think that's a mistake, and I'm not a fan. Because so far as I can tell 'use salsa' actually means 'maintain your packages in git'. So far as I can see it is not possible to use our existing 'uscan, patch, sbuild, dupload' type workflows with Salsa. And that's why I'm not using it, and don't want to be made to use it. But I am _not_ against people helping me fix my stuff - I'm on the 'just NMU my packages - I won't bite' list. As I said elsewhere: For me Salsa is just one more thing to deal with. It is useful if you need to share a package _before_ it is uploaded, but mostly it's just a load of extra stuff I didn't want or need (git, web-interfaces, certificates). And when I _do_ have to deal with it it takes a lot of extra time and effort I would prefer to have spent elsewhere. I have a workflow I am quite happy with (uscan, meld, quilt, sbuild, dupload). I've tried various fancy new things (salsa, git, dgit) but mostly I've found they got in the way (and delayed uploads/wasted time) rather than made my life easier, so I keep going back to the old way because it just works. I don't mind what other people do, but I worry that conversations like this seem to take the new thing as so self-evidently better that no-one can reasonably complain about them being made a requirement. Well, we don't all think it's better, and I wouldn't enjoy seeing 'packages must be in Salsa' made a requirement, for example. Dgit almost solves this problem but is backwards from my POV. It lets the git people pretend that they still use quilt and tarballs so the interface remains compatible (excellent). But it doesn't let the tarball people expose an interface to keep the git people happy (SFAIK - you can't do a dgit upload unless you have a git repo) which is a pity - I'd be fine doing doing 'dgit upload' instead of 'dupload' for compatibility purposes. > > If there are stupid barriers to helping people out by doing NMUs or > > taking over packages, then by all means let's break down those barriers. Right, but this is (or should be) quite separate from 'make everyone use git/salsa, i.e. stop them using the existing workflows'. If 'use salsa' means that when I do 'dupload' a copy ends up in salsa too, and when I do 'dget' it actually gets the dsc+tarball from salsa then that's fine. But if it means 'your package is a git repo, you have to use git to work with it', then no, I strongly object. I don't want to change all my workflows and tools. Perhaps there is some tool I am not aware of that can solve this problem? Like I say, dgit is so close, but exactly the opposite of what I need. > > But let's not try to "fix" a problem by introducing a rule that is, at > > best, affecting something only very weakly related to the problem that > > we are trying to solve. > > I would be happy to talk about rules that might help solving problems > (as well as droping rules that are creating barriers). Me too. Please let us improve the culture around NMUs, collaboration and fixes without making people (OK, duffers like me) change all their tooling. I am all for more Matrix over IRC though - that's a genuine improvement (and they are easy to bridge). Wookey -- Pri
Re: Debian openssh option review: considering splitting out GSS-API key exchange
On Apr 07, Bernd Zeimetz wrote: > There are more than enough ways to keep the entries based on dns > records in your l3 firewalls uptodate, I can't see how this should > warrant to keep yet another patch Jan^WMarco. Not for the form *.domain.tld. -- ciao, Marco signature.asc Description: PGP signature
Re: finally end single-person maintainership
On Apr 07, Wookey wrote: > I think that's a mistake, and I'm not a fan. Because so far as I can > tell 'use salsa' actually means 'maintain your packages in git'. So > far as I can see it is not possible to use our existing 'uscan, patch, > sbuild, dupload' type workflows with Salsa. And that's why I'm not > using it, and don't want to be made to use it. I started using git quite late and spent really a lot of time trying to understand how it fit in my quilt workflow (I loved quilt), but in the end I figured out that it maps well to a patch unapplied gbp-like workflow: If no changes to the packaging are needed then it's just: uscan --rename gbp import-orig ../package_*.tar.xz dch -v $(cat VERSION)-1 'New upstream release.' git add debian/changelog git commit git tag ... dpkg-source --build . pbuilder build $(ls -1tr ../*.dsc | tail -1) dupload ... Check the rpki-client repository for an example. (Using gbp is not mandatory, but it allows to import with just one command the upstream tar archive or git tree reference.) And now having the full git history of my packages is invaluable when trying to understand what has changed and when. -- ciao, Marco signature.asc Description: PGP signature
Re: finally end single-person maintainership
On Sun, Apr 07, 2024 at 04:04:18PM +0200, Andreas Tille wrote: > Hi Wouter, > > Am Sun, Apr 07, 2024 at 03:31:43PM +0200 schrieb Wouter Verhelst: > > [Feel free to quote any part of this email which I wrote outside of this > > mailinglist] > > OK, moving the discussion to debian-devel where it should belong. > > > Debian packages need to be well maintained. In some cases, having > > multiple maintainers on a package improves the resulting quality of > > packages. But in some other cases, it does not; one example for this > > second case is my package "logtool", which I'm going to upload to fix > > #1066251 soon and for which by the simple act of doing that I will > > double the amount of uploads it's seen in the past five years (and the > > number of uploads in the past 10 can still be counted on the fingers of > > a single hand). > > > > This is not because it's not well maintained; it's because the package > > just *does not require* a lot of work to be kept up to date: upstream > > has not been active for over 20 years, but it still performs the job it > > was designed to do, as it was designed to, and I see no need to have it > > removed from the archive. > > What is your opinion about pushing logtool to Salsa? Not speaking for logtool obviously, but maintaining simple packages on salsa is just useless bureaucracy. Forcing people to waste time creating a salsa project, a git repository etc. to maintain what is effectively a debian/rules that can be summarised by "dh:" does not serve any purpose. 'git log' is just redundant with debian/changelog. If you want the source of a package, 'apt-get source' should suffice. Most of the actual packager work is not reflected in the source package. Testing that the package integrates well with the rest of Debian, replying to bug reports, communicating with upstream etc. The more we waste time with bureaucracy the less we have time for actual work. For some of my packages I have a tool that generates the debian directory from the upstream metadata, so all packages debian/ are similar looking. Storing the output of this tool in separate git repo for each packages would be a absolute waste of resources. Also on a large timescale, our infrastructure change. We move from one VCS to another, to one service to another etc. and then repository need to be moved. It takes time. I maintain a number of packages. Some are on Salsa, some are not, some are team maintained, some are not, some use dh, some use debhelper etc. This is a matter of efficiency, one size does not fit all. Cheers, -- Bill. Imagine a large red swirl here. signature.asc Description: PGP signature
Re: finally end single-person maintainership
On 07/04/24 23:11, Bill Allombert wrote: What is your opinion about pushing logtool to Salsa? Not speaking for logtool obviously, but maintaining simple packages on salsa is just useless bureaucracy. As a contributor, having a package on salsa is extremely useful, far from "useless". By clicking on "fork" (or running the equivalent CLI command) I get a copy of the package, with all its history, a Debian-specific CI, the ability to work on different features or bug fixes at the same time and independently from one another, the possibility to send a merge request, that can be annotate line-by-line by all other Debian contributors. A package with a repo on salsa is sending a clean message: go away, I don't want your contribution. Most of the actual packager work is not reflected in the source package. Testing that the package integrates well with the rest of Debian, That time is better invested writing autopkgtests and letting Salsa-CI and debci run the tests. Having autopkgtests also lowers the barrier to contribute because the contributors can now be more confident of the fact that their changes did not cause any issue. replying to bug reports, Not affected by having a repo on salsa. communicating with upstream etc. Upstream that in 99% of the cases uses a git repo. I maintain a number of packages. Some are on Salsa, some are not, some are team maintained, some are not, some use dh, some use debhelper etc. This is a matter of efficiency, one size does not fit all. The lack of a standardized sanctioned workflow is the main reason (together with unresponsive maintainers) why big cross-distro changes are nigh impossible to carry out. I would not classify it as a big advantage. Regards, -- Gioele Barabucci
Re: Bug#1068479 cynically closed by Rene Engelhard (Re: Bug#1068479: libreoffice-writer: space between paragraphs missing in spacing and indentation)
Good evening, José Luis González wrote on 07/04/2024 at 20:59:53+0200: > Hi all, > > Rene Engelhard seems to be a worse case even than Ricardo Mones. Take a > look at my recent bug reports to libreoffice-writer and his replies. Your attitude is not okay, be it in this mail or in the sylpheed thread you sent earlier. This mail is therefore a friendly request for you to stop and find other ways of expressing disagreement. Regards, -- PEB signature.asc Description: PGP signature
Re: finally end single-person maintainership
Hi, Quoting Wookey (2024-04-07 22:42:34) > On 2024-04-07 16:04 +0200, Andreas Tille wrote: > > Am Sun, Apr 07, 2024 at 03:31:43PM +0200 schrieb Wouter Verhelst: > > > [Feel free to quote any part of this email which I wrote outside of this > > > mailinglist] > > OK, moving the discussion to debian-devel where it should belong. > Good plan. finally! Thank you!! <3 My personal take on the general discussion: can we first agree on a non-mandatory packaging workflow before we talk about reducing strong package ownership? Or at least add a way for a package to declare the used workflow? I'm not feeling comfortable doing more than opening merge requests or sending patches via the BTS to any package (even if the package is in the low threshold nmu list) without this knowledge. > > > The fact that a package is listed as maintained by a person rather than a > > > team does not mean the person is the only person who is responsible for > > > that package. Debian as a whole is. And the release team is, in the > > > context of deciding what happens with a package that has outstanding RC > > > bugs. And the QA team is, when they run full-archive test rebuilds for > > > new things. And our users are, when they file bugs. > > So I agree with everything Wouter said in this mail. I'm keen on > changing the _culture_ to make it easier to just fix things. > > But Andreas seems to have taken this idea of 'we should make it easier > to help people maintain packages', and conflated it with 'everyone has > to use salsa' and 'everything should be team maintained'. > > I think that's a mistake, and I'm not a fan. Because so far as I can > tell 'use salsa' actually means 'maintain your packages in git'. So > far as I can see it is not possible to use our existing 'uscan, patch, > sbuild, dupload' type workflows with Salsa. And that's why I'm not > using it, and don't want to be made to use it. > > But I am _not_ against people helping me fix my stuff - I'm on the > 'just NMU my packages - I won't bite' list. > > As I said elsewhere: > For me Salsa is just one more thing to deal with. It is useful if you > need to share a package _before_ it is uploaded, but mostly it's just > a load of extra stuff I didn't want or need (git, web-interfaces, > certificates). And when I _do_ have to deal with it it takes a lot of > extra time and effort I would prefer to have spent elsewhere. > > I have a workflow I am quite happy with (uscan, meld, quilt, sbuild, > dupload). I've tried various fancy new things (salsa, git, dgit) but > mostly I've found they got in the way (and delayed uploads/wasted > time) rather than made my life easier, so I keep going back to the old > way because it just works. > > I don't mind what other people do, but I worry that conversations like > this seem to take the new thing as so self-evidently better that > no-one can reasonably complain about them being made a > requirement. Well, we don't all think it's better, and I wouldn't > enjoy seeing 'packages must be in Salsa' made a requirement, for > example. > > Dgit almost solves this problem but is backwards from my POV. It lets > the git people pretend that they still use quilt and tarballs so the > interface remains compatible (excellent). But it doesn't let the > tarball people expose an interface to keep the git people happy (SFAIK - you > can't do a dgit upload unless you have a git repo) which is a pity - I'd be > fine doing doing 'dgit upload' instead of 'dupload' for compatibility > purposes. Personally, I cannot imagine myself maintaining my packages without them being in a VCS like git. I want to be able to "git log" a file to see which changes touched it. I want to be able to "git blame" a file to see which change modified a certain line. I want to "git revert" changes or "git rebase" local feature branches. Even without any contributors, I don't mind the overhead of using git for packaging as it helps *me* in the end. Then there is salsa... I have mixed feelings about it. On the one hand, it's this big beast with tons of javascript and apparently we are not even dog-fooding gitlab as packaged in Debian to overseves. I'd like our infrastructure to be based on the things we offer in our distro. And it's just so much javascript... I cannot open a build log in the browser without it just vanishing before my eyes with an error message in red at the top. My computer is slow (ARM Cortex A53) and this does not play well with it. I wish there was a way to interact with it from my terminal instead of having to click on buttons in a very slow web interface. On the other hand, salsa has enabled me to have confidence in what I upload as I haven't had before. I really like that I can "git push" my changes and then another computer can tell me whether autopkgtest, piuparts, reprotest and friends are happy. I could set all this up locally but due to the limitations of my machine I like that I can just trigger another computer to do this work for me while I
Re: finally end single-person maintainership
> Then there is salsa... I have mixed feelings about it. On the one hand, it's > this big beast with tons of javascript and apparently we are not even > dog-fooding gitlab as packaged in Debian to overseves. I'd like our > infrastructure to be based on the things we offer in our distro. And it's just > so much javascript... I cannot open a build log in the browser without it > just > vanishing before my eyes with an error message in red at the top. My computer > is slow (ARM Cortex A53) and this does not play well with it. I wish there was > a way to interact with it from my terminal instead of having to click on > buttons in a very slow web interface. We actually have `glab`[0] packaged in Debian Sid, Trixie and Bookworm-backports now, so there is a relatively easy to use way of accessing it from the CLI. [0] https://packages.debian.org/sid/glab
Bug#1068621: ITP: bisect-ppx -- Code coverage for OCaml and ReScript
Package: wnpp Severity: wishlist Owner: Bo YU X-Debbugs-Cc: debian-devel@lists.debian.org, debian-ocaml-ma...@lists.debian.org * Package name: bisect-ppx Version : 2.8.3 Upstream Contact: Anton Bachin Leonid Rozenberg * URL : https://github.com/aantron/bisect_ppx * License : MIT Programming Lang: OCaml Description : Code coverage for OCaml and ReScript Bisect-ppx helps you test thoroughly. It is a small preprocessor that inserts instrumentation at places in your code, such as if-then-else and match expressions. After you run tests, Bisect-ppx gives a nice HTML report showing which places were visited and which were missed. Usage is simple - add package bisect-ppx when building tests, run your tests, then run the Bisect-ppx report tool on the generated visitation files." The package is a dependency of sail[0] also. I will package it and maintianit under Debian OCaml team. [0]: https://bugs.debian.org/1065419 -- Regards, -- Bo YU signature.asc Description: PGP signature
