Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5
On Thu, Jan 27, 2022 at 12:39 AM Phil Morrell wrote: > > TLDR: I think REUSE.software is a bad idea that is worse than what > Debian already invented with Machine-readable debian/copyright file. I > guess if upstream uses it, there's no reason not to ignore that as a > source of copyright assertions. I expected some concerns about the complexity of the SPDX document, but certainly not about standardized copyright information in source files. Yes, Debian may have invented the machine-readable copyright bill, but not machine-readable copyright information in source files. This is what REUSE is all about, and it greatly reduces manual labor - I don't understand how this can be seen as bad. On Thu, Jan 27, 2022 at 12:39 AM Phil Morrell wrote: > > I *am* a big fan of SPDX-License-Identifier, but the above being > straightforward is only true for the most trivial of examples. REUSE > advocate for sprinkling .license files around your repo for e.g. logos > and other binaries. Same story with multiple authors, they recommend > using multiple FileCopyrightText's initially, then split it out to a > separate AUTHORS file and use something like "Project X contributors". No, it does not only work for trivial examples. Take any project with a significant amount of code, e.g. [1], and most of the time you will find that every source file has the copyright information in the header. The problem is, there has been no standardized way to parse them. That's why we have tools like licensecheck that try to find it out. With REUSE, it gets much much easier. Wrt to the .license files: yes they're ugly, but still better than no automation at all. With the new yaml spec, I suspect that these will go away. Wrt to multiple authors: this is not the fault of REUSE, but just how copyright works. > Ultimately, when everything becomes too much, REUSE falls back to > recommending Debian's copyright format anyway! So even if upstream sees > the value in taking some copyright busywork off our hands, why not > suggest they just use it in the first place in e.g. the LICENSE file. Sight, yes, because Debian's format is afaik the only standardized, easy to parse format out there. But the reason why it is there is *not* for "when everything becomes", but for files that you cannot and don't want to alter. For example, if you regularly import 3rd-party code that does not follow REUSE and you don't want to edit the header all the time. Note that if everyone would use REUSE, that would not be a problem. Another example is when you have tiny example code or configs that you want to present to a user, but without any distracting comments (think beginner tutorials). However, they want to switch from DEP-5 to a more flexible (i.e. non-central, relocatable) spec [2]. And there is good reason to do so: for example we as Debian can specify the copyright information from our packaging separate from the upstream code, without conflict. DEP-5 does not allow that. > Firstly, I didn't think it was called DEP-5 anymore - it was accepted > into policy in 2012 as "copyright-format" titled "Machine-readable > debian/copyright file", so no longer a proposal for enhancement. This > would be a minor pedantic point (a colloquialism) except for the fact > that REUSE encourages it as part of their interface: `.reuse/dep5`. Yes it is called "Machine-readable debian/copyright file Version 1.0", but everybody knows it _is_ DEP-5, it is even in the spec in the second sentence of the abstract. The spec _is_ still DEP-5, being accepted doesn't change that. > I think this undermines your previous point about it being less prone to > failure - if we could trust upstream assertions on copyright, the NEW > review wouldn't be a problem in the first place. I strongly disagree. First of all, upstream knows way better where they copy the code from than packagers do. And projects that use REUSE are more likely to write that somewhere down as your average NPM package that puts a "under MIT license" in the readme and copies minified code from everywhere. And as a second point, if you write a debian/copyright, you are most likely to trust what is in the header, and I suspect the copyright review in NEW is not different from this regard. I mean how can one even know if the copyright information is wrong? Yes there are cases where copyright information is missing and one can try to search it, I've done this not just once, but if a project uses REUSE headers, this doesn't happen. Regards, Stephan [1] https://gitlab.cern.ch/geant4/geant4 [2] https://github.com/fsfe/reuse-docs/issues/81
Bug#1004432: ITP: cloud-enum -- Enumerate public resources in cloud
Package: wnpp Severity: wishlist Owner: Guilherme de Paula Xavier Segundo X-Debbugs-Cc: debian-devel@lists.debian.org, guilherme@gmail.com * Package name: cloud-enum Version : 0.6 Upstream Author : initstring * URL : https://github.com/initstring/cloud_enum * License : GPL3+ Programming Lang: Python Description : Enumerate public resources in cloud Enumerates public resources matching user requested keywords in public clouds as Amazoan (Open / Protected S3 Buckets awsapps), Azure (Storage Accounts, Open Blob Storage Containers, Hosted Databases, Virtual Machines Web Apps), Google Cloud (Open / Protected GCP Buckets, Open / Protected Firebase Realtime Databases, Google App Engine sites, Cloud Functions).
Bug#1004434: ITP: python-rangehttpserver -- SimpleHTTPServer with support for Range requests
Package: wnpp Severity: wishlist Owner: Scott Kitterman * Package name: python-rangehttpserver Version : 1.2.0 Upstream Author : Dan Vanderkam * URL : https://github.com/danvk/RangeHTTPServer * License : Apache 2.0 Programming Lang: Python Description : SimpleHTTPServer with support for Range requests RangeHTTPServer is a Python module for running a simple HTTP server with support for range requests. It is suitable for use in local testing, not Internet scale production use. . HTTP range requests ask the server to send only a portion of an HTTP message back to a client and are useful for clients like media players that support random access, data tools that know they need only part of a large file, and download managers that let the user pause and resume the download. I will maintain this in the Debian Python Team. It is required to make the serve option in clamav-cvdupdate work (currently disabled until this gets in). Also, it looks like there is an embedded copy in python3-asdf, so perhaps it could be updated to use a system version.
Work-needing packages report for Jan 28, 2022
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 1218 (new: 1) Total number of packages offered up for adoption: 193 (new: 5) Total number of packages requested help for: 60 (new: 0) Please refer to https://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: esnacc (#1004270), orphaned 4 days ago Description: ASN.1 to C or C++ or IDL compiler Reverse Depends: esnacc libesnacc-dev Installations reported by Popcon: 9 Bug Report URL: https://bugs.debian.org/1004270 1217 older packages have been omitted from this listing, see https://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: autobahn-cpp (#1004235), offered 4 days ago Reverse Depends: autobahn-cpp-doc Installations reported by Popcon: 1 Bug Report URL: https://bugs.debian.org/1004235 dlang-libevent (#1004236), offered 4 days ago Installations reported by Popcon: 4 Bug Report URL: https://bugs.debian.org/1004236 dlang-openssl (#1004237), offered 4 days ago Reverse Depends: dlang-libevent Installations reported by Popcon: 19 Bug Report URL: https://bugs.debian.org/1004237 mpdscribble (#1004254), offered 4 days ago Description: Last.fm reporting client for mpd Installations reported by Popcon: 82 Bug Report URL: https://bugs.debian.org/1004254 python-gbulb (#1004238), offered 4 days ago Installations reported by Popcon: 9 Bug Report URL: https://bugs.debian.org/1004238 188 older packages have been omitted from this listing, see https://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apache2 (#910917), requested 1202 days ago Description: Apache HTTP Server Reverse Depends: apache2 apache2-ssl-dev apache2-suexec-custom apache2-suexec-pristine backuppc bfh-container-server courier-webadmin cvsweb debbugs-web doc-central (136 more omitted) Installations reported by Popcon: 98574 Bug Report URL: https://bugs.debian.org/910917 aufs (#963191), requested 586 days ago Description: driver for a union mount for Linux filesystems Reverse Depends: fsprotect Installations reported by Popcon: 9353 Bug Report URL: https://bugs.debian.org/963191 autopkgtest (#846328), requested 1884 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: debci-worker sbuild-qemu Installations reported by Popcon: 1240 Bug Report URL: https://bugs.debian.org/846328 balsa (#642906), requested 3777 days ago Description: An e-mail client for GNOME Reverse Depends: balsa Installations reported by Popcon: 654 Bug Report URL: https://bugs.debian.org/642906 cargo (#860116), requested 1752 days ago Description: Rust package manager Reverse Depends: dh-cargo rust-all Installations reported by Popcon: 2796 Bug Report URL: https://bugs.debian.org/860116 courier (#978755), requested 392 days ago Description: Courier mail server Reverse Depends: courier-faxmail courier-filter-perl courier-imap courier-ldap courier-mlm courier-mta courier-pcp courier-pop courier-webadmin couriergrey (3 more omitted) Installations reported by Popcon: 924 Bug Report URL: https://bugs.debian.org/978755 cron (#984736), requested 326 days ago Description: new maintainer need Reverse Depends: apticron autolog backintime-common btrfsmaintenance buildd checksecurity clamtk cricket email-reminder exim4-base (20 more omitted) Installations reported by Popcon: 208259 Bug Report URL: https://bugs.debian.org/984736 cyrus-imapd (#921717), requested 1084 days ago Description: Cyrus mail system - IMAP support Reverse Depends: cyrus-admin cyrus-caldav cyrus-clients cyrus-dev cyrus-imapd cyrus-murder cyrus-nntpd cyrus-pop3d cyrus-replication Installations reported by Popcon: 408 Bug Report URL: https://bugs.debian.org/921717 debtags (#962579), requested 596 days ago Description: Debian Package Tags support tools Reverse Depends: packagesearch Installations reported by Popcon: 1498 Bug Report URL: https://bugs.debian.org/962579 dee (#831388), requested 2022 days ago Description: model to synchronize mutiple instances over DBus Reverse Depends: dee-tools gir1.2-dee-1.0 gir1.2-unity-7.0 libdee-dev libunity-dev libunity-protocol-private0 libunity-tools libunity9 zeitgeist-core Installatio
Bug#1004462: ITP: node-should-sinon -- Sinon.js assertions for should.js
Package: wnpp Severity: wishlist Owner: Doug Torrance X-Debbugs-Cc: debian-devel@lists.debian.org, dtorra...@piedmont.edu * Package name: node-should-sinon Version : 0.0.6 Upstream Author : Denis Bardadym * URL : https://github.com/shouldjs/sinon * License : Expat Programming Lang: JavaScript Description : Sinon.js assertions for should.js should is an expressive, readable, framework-agnostic assertion library. The main goals of this library are to be expressive and to be helpful. It keeps your test code clean, and your error messages helpful. This module adds additional assertions for sinon.js, which provides standalone test spies, stubs and mocks. Node.js is an event-based server-side JavaScript engine. I plan to maintain this package as a member of the Debian JavaScript Team. signature.asc Description: PGP signature
Unplanned freeze?
Hi, I just observed that many of my packages that are currently in unstable are not migrating because of | Not touching package due to block request by elbrus (Follow the freeze | policy when applying for an unblock) where the "freeze policy" is linked to the bookworm Freeze Timeline (?). f.e. https://tracker.debian.org/pkg/photutils However, I couldn't find an announcement of a freeze in d.d.a. What is the cause of this? Best Ole
Re: Unplanned freeze?
On Fri, Jan 28, 2022 at 07:53:02AM +0100, Ole Streicher wrote: > I just observed that many of my packages that are currently in unstable > are not migrating because of > > | Not touching package due to block request by elbrus (Follow the freeze > | policy when applying for an unblock) > > where the "freeze policy" is linked to the bookworm Freeze Timeline (?). > > f.e. https://tracker.debian.org/pkg/photutils > > However, I couldn't find an announcement of a freeze in d.d.a. What is > the cause of this? http://bugs.debian.org/1004272 I agree that it should have been announced somewhere in addition to the #debian-devel topic. -- WBR, wRAR signature.asc Description: PGP signature
Re: Unplanned freeze?
On 1/28/22 07:53, Ole Streicher wrote: Hi, I just observed that many of my packages that are currently in unstable are not migrating because of | Not touching package due to block request by elbrus (Follow the freeze | policy when applying for an unblock) where the "freeze policy" is linked to the bookworm Freeze Timeline (?). f.e. https://tracker.debian.org/pkg/photutils However, I couldn't find an announcement of a freeze in d.d.a. What is the cause of this? Cause is binutils bug #1004272. From https://release.debian.org/britney/hints/elbrus: # 20220125 # 1004272 block-all source Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
