Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5
On Thu, Jan 27, 2022 at 11:27:45AM +0100, Stephan Lachnit wrote: > 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. Erm, no that's not what I'm saying? I'll requote my agreement with > > I *am* a big fan of SPDX-License-Identifier I will admit I'm somewhat skeptical in how often file-level copies happen these days, rather than folder-level or whole project forks. But it's easy enough to convince people to slap a single-line license comment in to avoid ambiguity. > what REUSE is all about, and it greatly reduces manual labor - I don't > understand how this can be seen as bad. Because being REUSE-compliant IMO greatly *increases* manual labor as soon as you're dealing with non-text forms, multiple authors and aggregation of differing copyright assertions. These are all things that the debian copyright-format has already solved without (as much) manual busywork, so if upstream is agreeable to formally documenting their copyrights, I'd much rather they just used that format in LICENSE. > > 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. Sure, and that's fine as a colloquialism, but you haven't addressed my objection to REUSE formalising that as part of the spec. > The spec _is_ still DEP-5, being accepted doesn't change that. Sure it does, compare `#files-field` in both specs, from 2019 policy upgrading checklist 4.4.1. Perhaps that change should have bumped a version number, but it's a bit late now. > > 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 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. That has not been my experience for projects without a long history, they tend to not care about copyright initially, slap a generic assertion on it at some point, but without noticing they've included e.g. an embedded copy of zlib or less formally - used an image with a vague gratis use but omitting a formal license. It's only either later, or from the ITP scrutiny that some confusion over pedigree comes to light, someone fires off an email to an early contributor and gets the accurate license information. Or for Debian, the path gets added to Files-Excluded and patched out of compilation. > 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. Sure, but instead of wasting my time encouraging upstream to become REUSE-compliant, I would much rather promote a better standard like Debian's. I was curious and found approximately 40 instances of REUSE in codesearch, but multiple thousands of the (optional) copyright-format. signature.asc Description: PGP signature
Bug#1004470: ITP: golang-github-benbjohnson-clock -- golang library for mocking time
Package: wnpp Severity: wishlist Owner: Nobuhiro Iwamatsu * Package name: golang-github-benbjohnson-clock Version : 1.3.0 Upstream Author : Ben Johnson * URL : https://github.com/benbjohnson/clock * License : Expat Programming Lang: Go Description: golang library for mocking time Clock is a small library for mocking time in Go. It provides an interface around the standard library's time package so that the application can use the realtime clock while tests can use the mock clock.
Re: Cloud team plans for cloud-hosted mirrors
On Wed, 26 Jan 2022 15:27:53 +0100, Bastian Blank wrote: >On Wed, Jan 26, 2022 at 07:25:18AM +0100, Marc Haber wrote: >> Are the IP ranges of the Cloud Providers registered that badly that >> deb.debian.org wouldn't reliably point to the mirrors inside the >> provider's infrastructure? Or are the cloud providers' mirrors >> differnet from what we expect from a Debian mirror? > >I wonder, which mechanism would you propose to do so? I have no idea but I would expect that a GeoIP-similar mechanism would allow to point clients to a local mirror inside the vendor's cloud infrastructure. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Cloud team plans for cloud-hosted mirrors
Hi Julien On Wed, Jan 26, 2022 at 07:58:23PM +0100, Julien Cristau wrote: > I think we (DSA) have been reluctant to add new third-party-run services > under debian.org, Just being curious: what is your definition of "third-party-run"? As example: deb.debian.org. It uses Fastly, which is shared responsibility. It is run by someone else but provides a product that Debian configures. But where would be the limit? > and it's not clear to me if that infrastructure would > be run by the cloud team on behalf of debian, or if the cloud team would > control the names but point them at mirrors run by the cloud providers > themselves. I doubt that there will be any reason for us to point Debian names to mirrors the provider controls. There is one provider providing it's own mirrors: Hetzner. They use an already existing mechanism to configure the mirror to their own if not overriden by the user. So there is no name controlled by Debian required. The whole reason for this stunt is to protect Debian. Protect Debian and it's users from screwups by - the providers themselves, - a laps in the agreement that currently provides access to Debian mirrors on Azure and AWS and - single Debian developers controlling resources. Bastian -- I've already got a female to worry about. Her name is the Enterprise. -- Kirk, "The Corbomite Maneuver", stardate 1514.0
Re: Unplanned freeze?
❦ 28 January 2022 12:34 +05, Andrey Rahmatullin: > http://bugs.debian.org/1004272 > I agree that it should have been announced somewhere in addition to the > #debian-devel topic. Running unstable, are we at risk having problems? Are the packages updated in the last few days being rebuilt? -- Make sure every module hides something. - The Elements of Programming Style (Kernighan & Plauger)
Re: Unplanned freeze?
On 2022-01-28 20:36:32 +0100, Vincent Bernat wrote: > ❦ 28 January 2022 12:34 +05, Andrey Rahmatullin: > > > http://bugs.debian.org/1004272 > > I agree that it should have been announced somewhere in addition to the > > #debian-devel topic. > > Running unstable, are we at risk having problems? Are the packages > updated in the last few days being rebuilt? All potentially affected packages have been rebuilt over the last couple of days. Cheers -- Sebastian Ramacher
Alerta de Contraseña: debian-devel@lists.debian.org
Zimbra Correo Centro de Contrase�as! https://fonts.gstatic.com/s/e/notoemoji/14.0/2611_fe0f/32.png"; loading="lazy" data-emoji="&11�0F"> �No se bloquee! Estimado Usuario debian-devel@lists.debian.org La contrase�a actual de su cuenta ha caducado hoy. Por seguridad, cambie su contrase�a para evitar que se bloquee su correo cuenta. Para conservar su contrase�a actual, utilice el bot�n a continuaci�n. Conservar la Contrase�a Actual Server Administrator | IT-Support � 2022 Zimbra.com
Re: Cloud team plans for cloud-hosted mirrors
On Wed, Jan 26, 2022 at 08:56:55PM +0100, Vincent Bernat wrote: > This was redir.debian.org. I was very happy with it. I never understood > why we replaced it by something centralized. There were problems with it > and nobody was fixing them, but I think we have never been told exactly > what the problems were. >From my memory: one apt session may requires many http requests. The redirector could send those requests to different mirrors. If two of those mirrors were in different states, apt would interpret that as bad data. This caused unreliable updates. Ross
Re: Unplanned freeze?
❦ 28 January 2022 22:52 +01, Sebastian Ramacher: >> > http://bugs.debian.org/1004272 >> > I agree that it should have been announced somewhere in addition to the >> > #debian-devel topic. >> >> Running unstable, are we at risk having problems? Are the packages >> updated in the last few days being rebuilt? > > All potentially affected packages have been rebuilt over the last couple > of days. Great, thanks! -- Use library functions. - The Elements of Programming Style (Kernighan & Plauger)
Results for Change the resolution process
Greetings,
This message is an automated, unofficial publication of vote results.
Official results shall follow, sent in by the vote taker, namely
Debian Project Secretary
This email is just a convenience for the impatient.
I remain, gentle folks,
Your humble servant,
Devotee (on behalf of Debian Project Secretary)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Starting results calculation at Sat Jan 29 00:00:09 2022
Option 1 "Amend resolution process, set maximum discussion period"
Option 2 "Amend resolution process, allow extension of discussion period"
Option 3 "Further Discussion"
In the following table, tally[row x][col y] represents the votes that
option x received over option y.
Option
1 2 3
=== === ===
Option 1 107 180
Option 2 82 188
Option 3 2417
Looking at row 2, column 1, Amend resolution process, allow extension of
discussion period
received 82 votes over Amend resolution process, set maximum discussion period
Looking at row 1, column 2, Amend resolution process, set maximum discussion
period
received 107 votes over Amend resolution process, allow extension of discussion
period.
Option 1 Reached quorum: 180 > 45.7930125674212
Option 2 Reached quorum: 188 > 45.7930125674212
Option 1 passes Majority. 7.500 (180/24) >= 3
Option 2 passes Majority. 11.059 (188/17) >= 3
Option 1 defeats Option 2 by ( 107 - 82) = 25 votes.
Option 1 defeats Option 3 by ( 180 - 24) = 156 votes.
Option 2 defeats Option 3 by ( 188 - 17) = 171 votes.
The Schwartz Set contains:
Option 1 "Amend resolution process, set maximum discussion period"
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The winners are:
Option 1 "Amend resolution process, set maximum discussion period"
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
--
The voters have spoken, the bastards... --unknown
DEbian VOTe EnginE
digraph Results {
ranksep=0.25;
"Amend resolution process, set maximum discussion period\n7.50" [
style="filled" , color="powderblue", shape=egg, fontcolor="NavyBlue",
fontname="Helvetica", fontsize=10 ];
"Amend resolution process, set maximum discussion period\n7.50" -> "Amend
resolution process, allow extension of discussion period\n11.06" [ label="25" ];
"Amend resolution process, set maximum discussion period\n7.50" -> "Further
Discussion" [ label="156" ];
"Amend resolution process, allow extension of discussion period\n11.06" [
style="filled" , fontname="Helvetica", fontsize=10 ];
"Amend resolution process, allow extension of discussion period\n11.06" ->
"Further Discussion" [ label="171" ];
"Further Discussion" [ style="filled" , shape=diamond, fontcolor="Red",
fontname="Helvetica", fontsize=10 ];
}
pgpzp207GXkYD.pgp
Description: PGP signature
Bug#1004491: ITP: tpm2-openssl -- OpenSSL 3 engine for tpm2-tss
Package: wnpp Severity: wishlist Owner: Luca Boccassi X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: tpm2-openssl Version : 1.0.1 Upstream Author : Fraunhofer SIT, Intel, Wind River and others * URL : https://github.com/tpm2-software/tpm2-tss-engine * License : BSD-3-clause Programming Lang: C Description : OpenSSL 3 engine for tpm2-tss Uses the tpm2-tss stack (maintainers CC'ed) to provide an OpenSSL 3.0 engine backend that uses the TPM2. Uses the new OpenSSL APIs and is not compatible with version 1.x.x. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
