Re: LESS copyright, not more!
Adam Borowski writes: > Guys, once again we had a complaint about forcing people to waste their time > on copyright matters then wait months or years for review of said matters > -- just for the discussion degenerate into a proposal to bring even MORE > copyright into our life! > >> - What is REUSE? >> The REUSE specification [1] is a specification to make copyright >> machine-readable in the source files itself. It is straightforward to >> implement, add (e.g.) "SPDX-FileCopyrightText: 2019 Jane Doe > [...] >> The spec is made by the Free Software Foundation Europe (FSFE) and is >> already implemented in several projects [3]. > > ... and this proposal includes gems such as an extra copyright-only file per > every image. Dᴏ ɴᴏᴛ ᴡᴀɴᴛ! > > The Social Contract says clearly: > "Our priorities are our users and free software" > -- NOT copyright lawyers. > > I, and probably others, consider copyright to be a crime against humanity > -- and this is not just a figure of speech[1]. We are forced to comply > with these laws, risking fines and violence if we don't, but why should > we put more effort than the minimum necessary? To better protect our users as they exercise point 1 of the DFSG, obviously! We can disagree about what the right amount of such effort is, and its diminishing returns, but I don't see how the intention/objective itself is at question here. -- Gard signature.asc Description: PGP signature
Re: What are the most important projects that Debian ought to work on?
On തി, ജനു 24 2022 at 10:31:01 രാവിലെ +0100 +0100, Sébastien Delafond wrote: Hello, As part of an upcoming survey that we are preparing, we plan to ask Debian developers to rank, by order of importance, the most popular ideas of improvements for Debian. However, there's no easy way to identify what are the most popular ideas of improvements that Debian ought to make. We know of the "grow-your-ideas" project on Salsa, but it's far from exhaustive: https://salsa.debian.org/debian/grow-your-ideas That's where you come into play: it would be nice if you could share what are — according to you — the most important projects/improvements that Debian ought to make. You can share your ideas here by replying to this email, but it would be interesting to file them as new issues in the "grow-your-ideas" project and then reply here pointing to your new issue: https://salsa.debian.org/debian/grow-your-ideas/-/issues I have added an idea to create unstable-proposed-updates for use during freeze to avoid reuploading to unstable from experimental after freeze. https://salsa.debian.org/debian/grow-your-ideas/-/issues/25
Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not
On Tue, 25 Jan 2022 21:38:01 +0100, Vincent Bernat wrote: > > I think we should forego the NEW queue. If people want to check > packages, they can do it once they are in unstable with regular bugs. > Current checks are partly done by Lintian and I suppose people could > watch new Lintian warnings and detect bad packages quickly. This could > be done when src is not NEW as a test. People could loose their upload > rights if they are caught abusing the system (and get DM rights for some > selected packages instead). +1. If we have a good remediation mechanism, this bottleneck is not necessary.
Re: What are the most important projects that Debian ought to work on?
On Mon, Jan 24, 2022 at 10:31:01AM +0100, Sébastien Delafond wrote: > That's where you come into play: it would be nice if you could share > what are — according to you — the most important projects/improvements > that Debian ought to make. You can share your ideas here by replying to > this email, but it would be interesting to file them as new issues in > the "grow-your-ideas" project and then reply here pointing to your new > issue: > > https://salsa.debian.org/debian/grow-your-ideas/-/issues I've added "We should have a default standard packaging workflow": https://salsa.debian.org/debian/grow-your-ideas/-/issues/24 There's been some good discussion in this direction a few years ago, and it never went as far as I'd have liked. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
Re: What are the most important projects that Debian ought to work on?
On Wed, Feb 09, 2022 at 03:23:38PM +0100, Enrico Zini wrote: > > That's where you come into play: it would be nice if you could share > > what are — according to you — the most important projects/improvements > > that Debian ought to make. You can share your ideas here by replying to > > this email, but it would be interesting to file them as new issues in > > the "grow-your-ideas" project and then reply here pointing to your new > > issue: > > > > https://salsa.debian.org/debian/grow-your-ideas/-/issues > > I've added "We should have a default standard packaging workflow": > https://salsa.debian.org/debian/grow-your-ideas/-/issues/24 This should include ideas what to do with resignations that will follow. -- WBR, wRAR signature.asc Description: PGP signature
Re: What are the most important projects that Debian ought to work on?
On Wed, Feb 09, 2022 at 09:55:24PM +0500, Andrey Rahmatullin wrote: > > I've added "We should have a default standard packaging workflow": > > https://salsa.debian.org/debian/grow-your-ideas/-/issues/24 > This should include ideas what to do with resignations that will follow. Why would one decide to resign based on a standard for a default that nobody is required to follow? I'm talking about suggesting a widely accepted default for people who would love to have a widely accepted default suggested instead of needing to figuring out a workflow from lots of conflicting tutorials. I'm not talking about mandating the way everyone has to do their work in Debian. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: What are the most important projects that Debian ought to work on?
On Wed, Feb 09, 2022 at 06:53:49PM +0100, Enrico Zini wrote:
> > > I've added "We should have a default standard packaging workflow":
> > > https://salsa.debian.org/debian/grow-your-ideas/-/issues/24
> > This should include ideas what to do with resignations that will follow.
>
> Why would one decide to resign based on a standard for a default that
> nobody is required to follow?
>
> I'm talking about suggesting a widely accepted default for people who
> would love to have a widely accepted default suggested instead of
> needing to figuring out a workflow from lots of conflicting tutorials.
>
> I'm not talking about mandating the way everyone has to do their work in
> Debian.
Eh, if it's just for new people who don't know which workflow to use then
fine, it's a good idea, but the scope of that is quite narrow and doesn't
even help the second point in "This impacts" ("every package I need to
change is set up in a different way!").
--
WBR, wRAR
signature.asc
Description: PGP signature
Bug#1005239: ITP: libperl-critic-community-perl -- community-inspired Perl::Critic policies
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libperl-critic-community-perl Version : 1.0.2 Upstream Author : Dan Book * URL : https://metacpan.org/release/Perl-Critic-Community * License : Artistic-2.0 Programming Lang: Perl Description : community-inspired Perl::Critic policies Perl::Critic::Community is a set of Perl::Critic policies to enforce the practices generally recommended by subsets of the Perl community, particularly on IRC. Formerly known as Perl::Critic::Freenode. Because this policy "theme" is designed to be used with zero configuration on the command line, some duplication will occur if it is used in combination with core Perl::Critic policies. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. signature.asc Description: Digital Signature
Re: NEW processing friction
On Mon, Feb 07, 2022 at 09:28:16PM -0500, Theodore Ts'o wrote: > > > On Mon, Feb 07, 2022 at 12:06:24AM -0700, Sean Whitton wrote: > > >> When we treat any of the above just like other RC bugs, we are accepting > > >> a lower likelihood that the bugs will be found, and also that they will > > >> be fixed > > > Another part of this discussion which shouldn't be lost is the > > > probabiltiy that these bugs will even *exist* (since if they don't > > > exist, they can't be found :-P) in the case where there is a NEW > > > binary package caused by a shared library version bump (and so we have > > > libflakey12 added and libflakey11 dropped as binary packages) and a > > > NEW source package. > > Which category of bugs do you mean? I distinguished three. > The argument why a package which has an upstream-induced shared > library version bump, has to go through the entire NEW gauntlent, is > because it is Good Thing that to check to see if it has any copyright > or licensing issue. But if you have a different package which doesn't > have upstream-induced shared library bump, it doesn't go throguh the > same kind of copyright and license hazing. And I believe this isn't > fair. > Either we should force every single package to go through a manual > copyright/licensing recheck, because Debian Cares(tm) about copyright, > or "copyright/licensing concerns are an existential threat to the > project" (I disagree with both arguments), or a package such as > libflakey which is going through constant shared library version bumps > should not go through the NEW gauntlet just because it has new binary > packages (libflakey11, libflakey12, libflakey13, etc.) at every single > upstream release. Thanks, this is the exact point I wanted to make here (although rather than saying it isn't "fair", I would say it isn't sensible as a criterion for review). The fact that the FTP team applies license/copyright review as part of their review of source packages has grounding in a number of goals of Debian as a project. The existence of a binary NEW queue is also sensible, as the FTP team have to manage the namespace of the packages in the archive. But the application of license/copyright review by the FTP team for existing source packages as part of binary NEW processing /and at no other time/ is arbitrary. It is, at best, a historical accident that has taken on the authority of precedent. Guarding against debian/copyright drift is a useful goal. But it is harmful to the velocity of the project to either block or reject new binary packages in the archive because of this linkage to license review. Actively-developed library packages with ABI changes are not fundamentally more likely to have license drift than any other package in the archive, so focusing FTP team time on reviewing the licenses of these packages in particular is a misapplication of resources. The responses I've seen from the FTP team to this can, I believe, be roughly paraphrased as "we would like all debian/copyright in the archive to be clean, but we don't have capacity to do that, so we're doing this instead". I assert that it is much, much worse to continue doing this than to do *no* license/copyright review as part of binary NEW. It does not achieve the goal of having clean debian/copyright across the archive; it slows down the binary NEW queue due to (self-imposed) workload of the FTP team; and it deters developers interested in this problem space from innovating better (and more systematic) solutions outside the small FTP team. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#1005257: ITP: hatchling -- Python package build backend used by Hatch
Package: wnpp Severity: wishlist Owner: Stefano Rivera X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: hatchling Version : 0.11.2 Upstream Author : Ofek Lev * URL : https://ofek.dev/hatch/ * License : Expat Programming Lang: Python Description : Python package build backend used by Hatch This is the extensible, standards compliant build backend used by Hatch. It may be required to build a Python module from source. I intend to package it under the Debian Python Team.
Debian Med sprint from 2022-02-18 to 2021-02-20
Hi, since more people confirmed the dates Friday 2022-02-18 to Sunday 2021-02-20 the Debian Med team will do the second sprint online at this time. The main information about the sprint can be obtained from the Wiki page[1]. If you have short questions you are kindly invited to ask on our Matrix channel. Everybody (specifically beginners) are welcome to join the fun of our meeting. We try to find interesting tasks also for newcomers. See you Andreas. [1] https://salsa.debian.org/med-team/community/sprints/-/wikis/202202_debian-med_sprint_online [2] https://app.element.io/#/room/#debian-med:matrix.org -- http://fam-tille.de
Bug#1005267: ITP: python-bytecode -- Python module to generate, modify and optimize Python bytecode
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: python-bytecode Version : 0.13.0 Upstream Author : Victor Stinner and Matthieu C. Dartiailh * URL : https://github.com/MatthieuDartiailh/bytecode * License : MIT Programming Lang: Python Description : Python module to generate, modify and optimize Python bytecode The bytecode module can be used to write Python bytecode directly and then convert it into executable Python statements. It also provides a pure Python implementation of the Peephole Optimizer introduced in CPython 3.6. This Python module was vendored by the pydevd developers, and having a standalone version of the module will avoid having the embedded module in pydevd. (And pydevd turns out to be a recursive dependency of Spyder) The Debian version of this package will therefore require the pydevd patch; this enhances the bytecode functionality if it is used (via an optional argument) but has no effect otherwise. It will be maintained within the Debian Python Team.
