Bug#1005270: ITP: wsdd -- The Web Service Discovery Daemon, to announce hosts for the Windows Network Browser

[Matthew Grant]

Package: wnpp
Severity: wishlist
Owner: Matthew Grant 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: wsdd
  Version : 0.7.0
  Upstream Author : Steffan Christgau 
* URL : https://github.com/christgau/wsdd
* License : MIT License
  Programming Lang: Python 3
  Description : The Web Service Discovery Daemon, to announce hosts for the 
Windows Network Browser

This daemon is used to announce Linux Hosts to Windows 7+ computers for
use in their File Manager network browsing, by using the Windows
Services Discovery Protocol.

This protocol is a local network segment procotol, which is multicasted
on udp/3072, and incoming on tcp/5357 on the 239.255.255.250/ff02::c
multicast addresses.  It DOES have security issues, but it is designed
for use in a trusted environment inside a firewall.

Its quite useful for Samba, taking over from WINS and the Samba nmbd
daemon.  Installing this restores the Network browsing functionality to
Windows 7+ Samba clients.

I am initially getting it packaged and aceptted, dealing with intial
bugs, and then will pass it on to the Debian Python Maintainers Team of
which I am a member.

Bug#1005271: ITP: csound-plugins -- plugin collection for Csound

[Debian/GNU]

Package: wnpp
Severity: wishlist
Owner: IOhannes m zmölnig (Debian/GNU) 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: csound-plugins
  Version : 1.0.2
  Upstream Author : Csound Developers 
* URL : https://github.com/csound/plugins
* License : LGPL
  Programming Lang: C, C++

   Csound is a sound and music synthesis system. Drawing from over 450
   signal processing modules, it can be used to model virtually any
   synthesizer or multi-effect processor. It can work either in real-time
   or as a compiler.
   .
   Csound is to sound synthesis as C is to programming.
   .
   This package contains additional plugins.



Upstream has split their repository, so now add-ons for the main
"Csound" package have a different repo and release cycle.
To not lose those plugins in Debian, packaging the new repo is required
as well.

I intend to maintain this under the multimedia-team umbrella, along with
the other csound related packages.


gfmdasr
IOhannes

Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5

[Stephan Lachnit]

On Tue, Feb 8, 2022 at 8:45 PM Russ Allbery  wrote:
>
> I recommend thinking about how to generate an existing debian/copyright
> file and putting the SPDX-formatted one in a different location.  You're
> going to want to decouple the new work from any transition that requires
> other people change tools.  There are a lot of tools that make assumptions
> about debian/copyright, and trying to track them all down will be
> counterproductive for trying to make forward progress on exposing
> information in a more interoperable format.
>
> The way I see this, there are three different things that have been
> discussed on this thread:
>
> 1. Consuming upstream data in SPDX or REUSE format and automating the
>generation of required Debian files using it.
>
> 2. Exposing SPDX data for our packages for downstream consumption.
>
> 3. Aligning the standard way to present Debian copyright information with
>other standards.
>
> I can tell you from prior experience with DEP-5 that 3 is wildly
> controversial and will produce the most pushback.  There are a lot of
> packagers who flatly refuse to even use the DEP-5 format, and (pace
> Jonas's aspirations) I don't expect that to change any time soon.
>
> I think that's fine for what you're trying to accomplish, because I think
> 1 and 2 are where the biggest improvements can be found.  As long as your
> system for managing copyright and license information can spit out a DEP-5
> debian/copyright file (in its current or a minorly modified format, not
> with new files elsewhere that would have to be extracted from the
> package), you are then backward-compatible with the existing system and
> that takes 3 largely off the table (which is what you want).  Then you can
> demonstrate the advantages of the new system and people can choose to be
> convinced by those advantages or not, similar to DEP-5, and we can reach
> an organic consensus without anyone feeling like they're forced to change
> how they do things.

Thanks for this input, Russ! I think you're right: it will be easier
to output the DEP5 format in addition to SPDX at the beginning, and
see from there how it works. I would install the source SPDX document
then to /usr/share/doc/PACKAGE/copyright_spdx in addition to the DEP5
file in the usual place.

I will write a SPDX -> DEP5 tool for this, which should be "fairly
trivial". Regarding concerns about the different file formats SPDX can
come in: for us only the tag:value format makes sense, I don't want to
support other formats.

On Tue, Feb 8, 2022 at 8:36 PM Jonas Smedegaard  wrote:
>
> For starters, the format adds one SHA1 hash per source file, right?

Yes, one checksum per file.

> Sure I can "just" ignore all FileChecksum: lines, but anyone working
> with XML will know that plaintext does not equal human-readable.

This comparison is a bit off, XML is a representation. The SPDX format
I want to use is tag:value just like DEP5, so in this regard
"human-readable". There is more cruft content, but it takes less than
5 minutes to understand where the per file copyright and license
information is.

> > However, I also think the human-readable aspect is less important here
> > because it is an output format. What I mean with this is that the
> > information is already there in a human readable way: either via REUSE
> > or in the file headers directly. While it is theoretically possible to
> > write SPDX documents by hand, I would not treat them with the same
> > trust as one created by REUSE.
>
> Here you seem to assume that humans need not be involved in authoring
> the contents or at least that human-facing interfaces for smart tools
> exist and is expressive enough to cover all that is needed.
>
> That is quite an assumption, I dare say.

I think this is a misconception: I don't want people to write SPDX
documents by hand at all. IMHO for this scenario, DEP5 is still
superior (that's e.g. why REUSE can also use DEP5).

> Writing the debian/copyright file for ghostscript took quite some time.
> Singularity is imminent, I know, and I wouldn't mind machines taking
> over the task of classifying tights statements, when they are up to the
> task - but until then I will want to proof-read and intervene as needed.
> My own experience is that they are not yet there - you seem to claim
> they have already surpassed humans for this task...
>
> Can you show me (off list if too long for an attachment) how your new
> not-really-needing-manual-editing file for ghostscript looks like, so I
> can compare with my lesser trusted human-laboured product?

No, because if ghostscript doesn't have the information to
automatically generate a SPDX document, don't do it by hand, use DEP5
instead.

What you can do is to put your DEP5 in .reuse/dep5 in the top-level
dir and run "reuse spdx" if you want to see how it looks.

> > Regarding reviews: I plan to write a SPDX-to-DEP5 converter anyway to
> > get a better feel for the spec. I will probably also write a copyright
> > review too

Re: What are the most important projects that Debian ought to work on?

[dude]

provide build in easy feedback-communications to digest, collect, 
analyze user's needs and progress from there


(more security, stability and faster boot is laways better X-D (in that 
order))


aka: what is REALLY needed (comes per installed per default) and what is 
optional/can be installed by user later


imho the minimalistic approach is my favorite: have as little software 
installed/running as possible


and then gradually add stuff as needed

to gradually improof the OS in a user-centric way

right now pretty happy with Debian 10 and 11 + MATE 2 Desktop (not as 
minimalistic as xfce but not as bloated as Ubuntu Desktop X-D)


and usually without a lot of tinkering it works out of the box on most 
hardware

Re: LESS copyright, not more!

[dude]

Linus: the (GPL 2.0) intented social contract is: “i give you 
sourcecode, give me back your changes”


https://dwaves.de/2022/01/31/why-is-it-gnu-linux-and-not-just-linux-linus-talking-about-gpl-v3-vs-gpl-v2-the-better-one-the-social-gpl-contract-is-i-give-you-sourcecode-give-me-back-your-changes-non-free-binary/

if the developer does not want-need changes back GPL 3.0 is also "okayish"

the kernel licensing is also rather... complicated... (with the many 
different versions of GPL and LGPL) maybe a user can do a 30min 
entertaining sum up video explanation of this ...


 *


 Linux kernel licensing rules

 * The Linux Kernel is provided under the terms of the GNU General
   Public License version 2 only (GPL-2.0), as provided in
   LICENSES/preferred/GPL-2.0, with an explicit syscall exception
   described in LICENSES/exceptions/Linux-syscall-note, as described in
   the COPYING file.This documentation file provides a description of
   how each source file should be annotated to make its license clear
   and unambiguous. It doesn’t replace the Kernel’s license.The license
   described in the COPYING file applies to the kernel source as a
   whole, *though individual source files can have a different license
   which is required to be compatible with the GPL-2.0*:

   GPL-1.0+  :  GNU General Public License v1.0 or later
   GPL-2.0+ : GNU General Public License v2.0 or later  

   
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/LICENSES/preferred/GPL-2.0?h=v5.17-rc2
   LGPL-2.0  :  GNU Library General Public License v2 only
   LGPL-2.0+ :  GNU Library General Public License v2 or later
   LGPL-2.1  :  GNU Lesser General Public License v2.1 only
   LGPL-2.1+ :  GNU Lesser General Public License v2.1 or later

   src: https://docs.kernel.org/process/license-rules.html

 * actually there is a whole folder “LICENCE” that is shipped with the
   kernel sources, which has the following subfolders:
   


 o deprecated
   

 o dual
   

 o exceptions
   

 o preferred
   

 * *here is a list of all sorts of free licences
   https://spdx.org/licenses/ **(RSS Feed)*
   

PS: yes iterating over this stuff takes time, anyone ever read the whole 
GPL 2.0?


actually did - entertainment factor was... okay

On 2/9/22 10:45, Gard Spreemann wrote:


The Social Contract says clearly:
 "Our priorities are our users and free software"

developers-reference "vs" wiki.debian.org/DebianMaintainer

[Holger Levsen]

hi,

so Stephan Lachnit submitted an MR for developers-reference on Monday to
document how to grant DM upload permissions, which I gladly merged, even
though I was aware of "#653399: developers-reference: Please include a 
paragraph about Debian Maintainers (DM)" still being unresolved.

Which lead me to (quoting from #-devel that day)

< h01ger> stephanlachnit: now i'm wondering how much of 
  https://wiki.debian.org/DebianMaintainer i should copy into 
  developers-reference... i've seen you also documented the dcut
  commands there, which makes sense as it is now, though i'm not
  convinced it's good to have all the docs in two places
< h01ger> so i'm also pondering about mostly adding a pointer to that wiki 
  page to devref
< h01ger> (the wiki and devref are both GPL2 licenced, so that part is easy :)
< h01ger> feedback from anyone is welcome of course, not just stephan :)

So what do you all think?

I'm leaning towards explaining the basics in devref (mostly by copying bits
from the wiki page) and adding a pointer to the wiki page, but if there's 
consensus that the wiki page is supposed to be made obsolete by *moving*
the contents to src:devref and leaving a pointer on the wiki page, I could
also do that.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

The vision of self driving cars is nothing compared to the vision of no cars at 
all.


signature.asc
Description: PGP signature

Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5

[Jonas Smedegaard]

Quoting Stephan Lachnit (2022-02-10 11:59:11)
> On Tue, Feb 8, 2022 at 8:36 PM Jonas Smedegaard  
> wrote:
> >
> > For starters, the format adds one SHA1 hash per source file, right?
> 
> Yes, one checksum per file.
> 
> > Sure I can "just" ignore all FileChecksum: lines, but anyone working 
> > with XML will know that plaintext does not equal human-readable.
> 
> This comparison is a bit off, XML is a representation. The SPDX format 
> I want to use is tag:value just like DEP5, so in this regard 
> "human-readable". There is more cruft content, but it takes less than 
> 5 minutes to understand where the per file copyright and license 
> information is.

It takes less than 5 minutes to understand where the per file copyright 
and license information is: "Just" ignore all angle-bracket markup.

Comparison is that both XML and checksums adds noise, reducing 
readability.

...and seems you agree:

> Yes I agree that adding hashes to DEP5 makes it unreadable and utterly 
> annoying to maintain, that's why I don't want to add it. DEP5 is 
> designed to be written by humans, SPDX is not. That's why SPDX can add 
> hashes without any drawbacks.

A file containing checksums for all files is much harder not only to 
write but also to read, than one without such hashes.

[ original criticism revived ]

Quoting Jonas Smedegaard (2022-02-08 16:39:36)
> If we permit a debian/copyright format that is not human-readable, it 
> means that I cannot confidently proof-read and change the contents of 
> the debian subdir without the help of machine-parsers, and I would 
> need to know two formats with different goals.

> > > I don't see the problem with machine parsers. We already use a lot 
> > > of different tools for our processes (git, dput, dpkg, debhelper, 
> > > lintian, uscan, a mail program, a text editor, ...), adding one 
> > > more shouldn't be a big deal. It needs to be provided of course, 
> > > but I plan to do that.
> >
> > Only 2 of those you list are mandatory: dpkg and RFC822 email - the 
> > rest are optional, some quite popular but even then routinely 
> > bypassed.
> 
> I mean if you want you can write SPDX files by hand, it's not a binary 
> format. Same as you can write a Debian package without debhelper.

I can also transfer TCP packets using pigeons, if I seek challenges.

My concern is not about binary versus text-based format, but about 
only-machine-readable versus human-and-machine-readable format.


> > I would be quite happy if our work on evolving debian/copyright would
> > result in a future revision being identical to REUSE format.
> >
> > What I dislike is requiring all developers to master 3 formats instead
> > of currently only two: freeform-human-only and (also-)machine-readable.
> 
> No, you don't have to master SPDX! That's the point: you don't
> interact with it at all. It's created by tools, and shipped to satisfy
> the legal obligation to provide copyright information. Users don't
> care how the copyright information is shipped. As a developer, you
> just have one less thing to care about, namely writing
> debian/copyright by hand.

I need to either interact with the format or depend on tools that do.

When I release a package to Debian, then I am responsible for that 
package being in compliance with Debian Policy - including § 2.3 about 
information that the debian/copyright file MUST cover.

It does not matter if I write debian/copyright by hand or choose to use 
automated tools to autogenerate that file - regardless it is my 
responsibility to ensure that contents or that file comply with Debian 
Policy.

If I upgrade a package as an NMU, then it is my responsibility to ensure 
that the new package comply with Debian Policy - including 
debian/copyright getting updated as needed - but if debian/copyright 
format is alien to me then I cannot do that responsibly.

Your argument seems to be that I can simply trust SPDX/REUSE tools.  
Agreed, I can choose to trust tools doing magic for me, but that is 
exactly my concern: I am _forced_ to trust tools, where I have the 
(easy!) option of by-passing helper tools with current 
[also-]machine-readable format.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: What are the most important projects that Debian ought to work on?

[Andrey Rahmatullin]

On Thu, Feb 10, 2022 at 12:07:24PM +0100, dude wrote:
> provide build in easy feedback-communications to digest, collect, analyze
> user's needs and progress from there
> 
> (more security, stability and faster boot is laways better X-D (in that
> order))
> 
> aka: what is REALLY needed (comes per installed per default) and what is
> optional/can be installed by user later
> 
> imho the minimalistic approach is my favorite: have as little software
> installed/running as possible
> 
> and then gradually add stuff as needed
> 
> to gradually improof the OS in a user-centric way
> 
> right now pretty happy with Debian 10 and 11 + MATE 2 Desktop (not as
> minimalistic as xfce but not as bloated as Ubuntu Desktop X-D)
> 
> and usually without a lot of tinkering it works out of the box on most
> hardware
This isn't related to this thread.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: LESS copyright, not more!

[Andrey Rahmatullin]

On Thu, Feb 10, 2022 at 12:14:40PM +0100, dude wrote:
> Linus: the (GPL 2.0) intented social contract is: “i give you sourcecode,
> give me back your changes”
> 
> https://dwaves.de/2022/01/31/why-is-it-gnu-linux-and-not-just-linux-linus-talking-about-gpl-v3-vs-gpl-v2-the-better-one-the-social-gpl-contract-is-i-give-you-sourcecode-give-me-back-your-changes-non-free-binary/
> 
> if the developer does not want-need changes back GPL 3.0 is also "okayish"
> 
> the kernel licensing is also rather... complicated... (with the many
> different versions of GPL and LGPL) maybe a user can do a 30min entertaining
> sum up video explanation of this ...
This isn't related to this thread.

> PS: yes iterating over this stuff takes time, anyone ever read the whole GPL
> 2.0?
Yes.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: write-only copyright information

[Simon McVittie]

On Thu, 10 Feb 2022 at 11:59:11 +0100, Stephan Lachnit wrote:
> No, you don't have to master SPDX! That's the point: you don't
> interact with it at all. It's created by tools, and shipped to satisfy
> the legal obligation to provide copyright information.

So, are you saying this is something you are doing to satisfy the "letter
of the law" for licenses that require copyright notices to be reproduced
alongside binaries, to avoid having that noise reduce the clarity of the
information we are providing for other, arguably more useful reasons?

Obviously it's not my decision to make, but I have never been particularly
convinced by the assertion that we can fulfil the GPL's requirement for
corresponding source to accompany binaries by offering source packages
from the same places that ship binaries, but at the same time we cannot
fulfil various licenses' requirement for copyright notices to accompany
binaries by pointing to those same source packages and saying "it's
all there".

The usual form of words in the licenses that require copying copyright
notices calls for the copyright notice to appear in the "documentation or
other materials"; I think we could reasonably argue that source packages
are a form of extremely comprehensive documentation (they document the
precise behaviour of the binaries!) and they are certainly "other materials".

However, if the ftp team have a problem with that reasoning, then yes,
it seems like there could be value in having an essentially write-only
format for the information that the license requires us to reproduce. That
way, we fulfil the letter of the license by providing the information we
are required to (even though it isn't particularly practically useful
to wade through the list of around 400 potential copyright holders in
a medium-sized package like GTK[1]), and at the same time, fulfil the
spirit of the license by communicating the parts that practically matter
in a more concise form (in the case of GTK, this would be "LGPL-2.1+
and various compatible licenses", which is the information you'll get
from basically any other distribution's GTK packaging).

smcv

[1] https://tracker.debian.org/media/packages/g/gtk4/copyright-4.6.0ds1-3,
almost certainly incomplete (but neither the maintainers nor the ftp
team noticed any omissions, which is as good as we will
realistically get)

Re: developers-reference "vs" wiki.debian.org/DebianMaintainer

[Stephan Lachnit]

On Thu, Feb 10, 2022 at 12:49 PM Holger Levsen  wrote:
>
> So what do you all think?
>
> I'm leaning towards explaining the basics in devref (mostly by copying bits
> from the wiki page) and adding a pointer to the wiki page, but if there's
> consensus that the wiki page is supposed to be made obsolete by *moving*
> the contents to src:devref and leaving a pointer on the wiki page, I could
> also do that.

As already mentioned on IRC, I think in this case I would move the
information for the DDs to the devref and reference it on the wiki
with "if you are a DD, see also section X in devref". Currently when I
search something related to general DD tasks I first look in the
devref and not in the wiki. In particular most of the DebianMaintainer
wiki page is for those wanting to become a DM, I only found the
granting permissions section after looking a second time.

In general I would put information specific for people who are already
DDs in the devref written with the assumption that everyone who reads
it is a DD. The wiki on the other hand is more "public facing", so I
would put here more introductory content (like "what can I do as a DM"
and "how I can become a DM").

Regards,
Stephan

multiple roles of d/copyright

[Simon McVittie]

On Tue, 08 Feb 2022 at 08:59:23 -0500, Scott Kitterman wrote:
> From my point of view, treating something like other common classes of RC 
> bugs 
> means that the project is producing tools and processes to make detection of 
> such bugs more automated to remove them from the archive, that developers are 
> actively looking for them, and that they are routinely fixed in the normal 
> course of Debian development.

I think part of the problem here might be that copyright information is
"social", not "technical": software authors can claim copyright and/or
authorship in various forms of human-readable, free-form text, which means
any automated detection is necessarily going to be imperfect, and as long
as our policy demands perfection, there will be a reluctance to automate
this (or at least a reluctance to say that we are automating it).

Another part of the problem is that licensing and copyright-information
bugs are not something that we are realistically going to find through
normal use of software: if GTK crashes when you print on a Tuesday, one
of our users will eventually notice, but if we have missed a copyright
holder, it's unlikely that anyone is going to notice that omission from
the list of around 400 potential copyright holders in

unless they repeat the time-consuming process of collecting possible
copyright claims from the source code (as the ftp team presumably do). I
have no idea how the maintainers of larger and more complicated packages
manage to do this, or how the ftp team manage to review larger and more
complicated packages in a finite time.

I think the copyright file is doing several things which are perhaps in
conflict:

* It lets consumers of packages know what restrictions apply to their
  use of a package
  - This requires *most* of the license information, although not
necessarily all of it: for example if a package like Linux is licensed
under a mixture of GPL, LGPL, BSD and MIT licenses, it's usually
sufficient to be aware of the most restrictive of those licenses, in
this case GPL
  - Having too much information, however, well-intentioned, actually works
against this by making it harder to find what you need
  - I would argue that requiring the text of licenses like the CC family
to be inlined into the copyright file works against this goal, by
reducing the signal-to-noise ratio: if you are not familiar with a
particular license, then obviously you will need to read its text
to see what it means, but if you are looking at packages that have
content under various semi-common licenses, you only need to read
each license once
  - I would argue that requiring lists of copyright holders in the same
file to be inlined into the copyright file also works against this
goal, again by harming the signal-to-noise ratio

* It lets consumers of packages know that the package is DFSG-compliant
  - Same requirements as above

* It's a place to reproduce information that licenses require us to, like
  a comprehensive set of copyright notices (if our interpretation of the
  applicable licenses is that pointing to nearby source code and calling
  it extremely comprehensive accompanying documentation is insufficient)
  - In this role, it's essentially write-only: we're doing this because
we have been required to do it, more than because it's practically
useful, and I don't expect anyone to actually read this, except for
the maintainer when collecting it and the ftp team when verifying
that it has been collected
  - In another subthread, Stephan Lachnit suggests using the SPDX format
for this write-only information, which I think might be intended as
a way to eventually separate it from the other roles of d/copyright

* It gives authors due credit (which we are not *required* to do, but
  in previous discussions of d/copyright I've seen this cited as a reason
  why we *should* do this in order to be good citizens)
  - Note that collecting copyright holders is not necessarily actually
helpful here, because that often means we are required to "credit"
an employer, rather than mentioning the actual author
  - In a medium-sized package like GTK, it's not clear to me that a list of
about 400 possible copyright holders is actually serving this purpose,
because any individual contributor is lost in the noise

* It lets us meet our self-imposed rules
  - This is circular, so I'm inclined to disregard it when discussing what
the rules should be: we should set rules because they help us to
achieve a goal, rather than for the sake of having rules

* It lets the ftp team (or other interested reviewers) duplicate the
  info-collecting process to check that all of the above have been done
  - This is somewhat circular, because this is a way to support the other
goals, not really a goal in its own right

* Are there other relevant goals t

Re: write-only copyright information

[Stephan Lachnit]

On Thu, Feb 10, 2022 at 2:10 PM Simon McVittie  wrote:
>
> On Thu, 10 Feb 2022 at 11:59:11 +0100, Stephan Lachnit wrote:
> > No, you don't have to master SPDX! That's the point: you don't
> > interact with it at all. It's created by tools, and shipped to satisfy
> > the legal obligation to provide copyright information.
>
> So, are you saying this is something you are doing to satisfy the "letter
> of the law" for licenses that require copyright notices to be reproduced
> alongside binaries, to avoid having that noise reduce the clarity of the
> information we are providing for other, arguably more useful reasons?

I think I don't fully get the question, but yes, essentially this
would be a write-only format that I expect no human to read. Users
don't care about it and it's more than enough from the legal side.

Regards,
Stephan

Re: multiple roles of d/copyright

[Scott Kitterman]

On Thursday, February 10, 2022 8:26:23 AM EST Simon McVittie wrote:
> On Tue, 08 Feb 2022 at 08:59:23 -0500, Scott Kitterman wrote:
> > From my point of view, treating something like other common classes of RC
> > bugs means that the project is producing tools and processes to make
> > detection of such bugs more automated to remove them from the archive,
> > that developers are actively looking for them, and that they are
> > routinely fixed in the normal course of Debian development.
> 
> I think part of the problem here might be that copyright information is
> "social", not "technical": software authors can claim copyright and/or
> authorship in various forms of human-readable, free-form text, which means
> any automated detection is necessarily going to be imperfect, and as long
> as our policy demands perfection, there will be a reluctance to automate
> this (or at least a reluctance to say that we are automating it).
> 
> Another part of the problem is that licensing and copyright-information
> bugs are not something that we are realistically going to find through
> normal use of software: if GTK crashes when you print on a Tuesday, one
> of our users will eventually notice, but if we have missed a copyright
> holder, it's unlikely that anyone is going to notice that omission from
> the list of around 400 potential copyright holders in
> 
> unless they repeat the time-consuming process of collecting possible
> copyright claims from the source code (as the ftp team presumably do). I
> have no idea how the maintainers of larger and more complicated packages
> manage to do this, or how the ftp team manage to review larger and more
> complicated packages in a finite time.
> 
> I think the copyright file is doing several things which are perhaps in
> conflict:
> 
> * It lets consumers of packages know what restrictions apply to their
>   use of a package
>   - This requires *most* of the license information, although not
> necessarily all of it: for example if a package like Linux is licensed
> under a mixture of GPL, LGPL, BSD and MIT licenses, it's usually
> sufficient to be aware of the most restrictive of those licenses, in
> this case GPL
>   - Having too much information, however, well-intentioned, actually works
> against this by making it harder to find what you need
>   - I would argue that requiring the text of licenses like the CC family
> to be inlined into the copyright file works against this goal, by
> reducing the signal-to-noise ratio: if you are not familiar with a
> particular license, then obviously you will need to read its text
> to see what it means, but if you are looking at packages that have
> content under various semi-common licenses, you only need to read
> each license once
>   - I would argue that requiring lists of copyright holders in the same
> file to be inlined into the copyright file also works against this
> goal, again by harming the signal-to-noise ratio
> 
> * It lets consumers of packages know that the package is DFSG-compliant
>   - Same requirements as above
> 
> * It's a place to reproduce information that licenses require us to, like
>   a comprehensive set of copyright notices (if our interpretation of the
>   applicable licenses is that pointing to nearby source code and calling
>   it extremely comprehensive accompanying documentation is insufficient)
>   - In this role, it's essentially write-only: we're doing this because
> we have been required to do it, more than because it's practically
> useful, and I don't expect anyone to actually read this, except for
> the maintainer when collecting it and the ftp team when verifying
> that it has been collected
>   - In another subthread, Stephan Lachnit suggests using the SPDX format
> for this write-only information, which I think might be intended as
> a way to eventually separate it from the other roles of d/copyright
> 
> * It gives authors due credit (which we are not *required* to do, but
>   in previous discussions of d/copyright I've seen this cited as a reason
>   why we *should* do this in order to be good citizens)
>   - Note that collecting copyright holders is not necessarily actually
> helpful here, because that often means we are required to "credit"
> an employer, rather than mentioning the actual author
>   - In a medium-sized package like GTK, it's not clear to me that a list of
> about 400 possible copyright holders is actually serving this purpose,
> because any individual contributor is lost in the noise
> 
> * It lets us meet our self-imposed rules
>   - This is circular, so I'm inclined to disregard it when discussing what
> the rules should be: we should set rules because they help us to
> achieve a goal, rather than for the sake of having rules
> 
> * It lets the ftp team (or other interested reviewers) duplicate the
> 

Re: multiple roles of d/copyright

[The Wanderer]

On 2022-02-10 at 09:06, Scott Kitterman wrote:

> On Thursday, February 10, 2022 8:26:23 AM EST Simon McVittie wrote:

>> I think the copyright file is doing several things which are perhaps in
>> conflict:

>> * It's a place to reproduce information that licenses require us to, like
>>   a comprehensive set of copyright notices (if our interpretation of the
>>   applicable licenses is that pointing to nearby source code and calling
>>   it extremely comprehensive accompanying documentation is insufficient)

> How about it enables the project to comply with license requirements?  I may 
> have missed it, but I don't see that on your list.

Isn't that the above paragraph?

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: multiple roles of d/copyright

[Scott Kitterman]

On Thursday, February 10, 2022 9:13:29 AM EST The Wanderer wrote:
> On 2022-02-10 at 09:06, Scott Kitterman wrote:
> > On Thursday, February 10, 2022 8:26:23 AM EST Simon McVittie wrote:
> >> I think the copyright file is doing several things which are perhaps in
> >> conflict:
> >> 
> >> * It's a place to reproduce information that licenses require us to, like
> >> 
> >>   a comprehensive set of copyright notices (if our interpretation of the
> >>   applicable licenses is that pointing to nearby source code and calling
> >>   it extremely comprehensive accompanying documentation is insufficient)
> > 
> > How about it enables the project to comply with license requirements?  I
> > may have missed it, but I don't see that on your list.
> 
> Isn't that the above paragraph?

It is.  Thanks.

Scott K


signature.asc
Description: This is a digitally signed message part.

Bug#1005291: ITP: golang-github-mdlayher-dhcp6 -- implements a DHCPv6 server, as described in RFC 3315 (library)

[Francisco Vilmar Cardoso Ruviaro]

Package: wnpp
Severity: wishlist
Owner: Francisco Vilmar Cardoso Ruviaro 
X-Debbugs-Cc: debian-devel@lists.debian.org, francisco.ruvi...@riseup.net

* Package name: golang-github-mdlayher-dhcp6
  Version : 0.0~git20190311.2a67805
  Upstream Author : Matt Layher
* URL : https://github.com/mdlayher/dhcp6
* License : Expat
  Programming Lang: Go
  Description : implements a DHCPv6 server, as described in RFC 3315 
(library)

  Package dhcp6 implements a DHCPv6 server, as described in IETF RFC 3315.
  .
  This package implements a DHCP server for IPv6.


  Reason for packaging:
  This package is one of the dependencies for bettercap
  (https://github.com/bettercap/bettercap)

Re: developers-reference "vs" wiki.debian.org/DebianMaintainer

[Sam Hartman]

> "Holger" == Holger Levsen  writes:

Holger> So what do you all think?

Holger> I'm leaning towards explaining the basics in devref (mostly
Holger> by copying bits from the wiki page) and adding a pointer to
Holger> the wiki page, but if there's consensus that the wiki page
Holger> is supposed to be made obsolete by *moving* the contents to
Holger> src:devref and leaving a pointer on the wiki page, I could
Holger> also do that.

developers-reference is available offline, is in my experience better
organized, and is where I look for stuff like that.
I am able to place more trust in devref than wiki.debian.org.
Some parts of wiki.debian.org are great; some parts are horribly out of
date.

I'd say that as best we are able, things normal Debian developers need
to do should be in devref.  So, what are DMs, how to grant permissions,
how to revoke are things I'd hope would be in devref.

Beyond that, I think wiki.debian.org could be fine.

Re: What are the most important projects that Debian ought to work on?

[Sam Hartman]

> "Andrey" == Andrey Rahmatullin  writes:

Andrey> 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.
Andrey> Eh, if it's just for new people who don't know which
Andrey> workflow to use then fine, it's a good idea, but the scope
Andrey> of that is quite narrow and doesn't even help the second
Andrey> point in "This impacts" ("every package I need to change is
Andrey> set up in a different way!").

Over time, if people see the value in migrating toward something more
people understand, the probability of people seeing the value and
migrating increases.
Especially in this community, there is still value in suggestions people
can optionally follow.
We've seen such suggestions get adopted organically time and time again,
and it does make things easier.

Bug#1005295: ITP: golang-github-bettercap-nrf24 -- allows interaction with nRF24LU1+ based USB dongles (library)

[Francisco Vilmar Cardoso Ruviaro]

Package: wnpp
Severity: wishlist
Owner: Francisco Vilmar Cardoso Ruviaro 
X-Debbugs-Cc: debian-devel@lists.debian.org, francisco.ruvi...@riseup.net

* Package name: golang-github-bettercap-nrf24
  Version : 0.0~git20190219.aa37e6d
  Upstream Author : Simone Margaritelli
* URL : https://github.com/bettercap/nrf24
* License : GPL-3
  Programming Lang: Go
  Description : allows interaction with nRF24LU1+ based USB dongles 
(library)

  This package allows interaction with nRF24LU1+ Nordic
  Semiconductor based USB dongles and the RFStorm firmware
  (https://github.com/BastilleResearch/nrf-research-firmware).


  Reason for packaging:
  This package is one of the dependencies for bettercap
  (https://github.com/bettercap/bettercap).

Bug#1005296: ITP: synadm -- Command line admin tool for Synapse (Matrix reference homeserver)

[Sebastien Badia]

Package: wnpp
Severity: wishlist
Owner: Sebastien Badia 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: synadm
  Version : 0.33.1
  Upstream Author : J0J0 T 
* URL : https://github.com/JOJ0/synadm
* License : GPL-3
  Programming Lang: Python
  Description : Command line admin tool for Synapse (Matrix reference
homeserver)

A CLI tool to help admins of Matrix-Synapse homeservers
conveniently issue commands available via its admin API.

Access requested in order to maintain this package inside
the Debian matrix-team https://salsa.debian.org/matrix-team

ISS is running GNU Linux Debian :)

[dude]

 International Space Station adopts Debian Linux, drops Windows & Red
 Hat into airlock X-D

https://www.computerweekly.com/blog/Open-Source-Insider/International-Space-Station-adopts-Debian-Linux-drops-Windows-Red-Hat-into-airlock


   Boldly Going, Running Linux in Space" - Sam Bishop (LCA 2022 Online)

as seen on https://ytpak.net/watch?v=G1fOZr9v2lY

#NOICE! ✌️😎👍⭐🍻

GO DEBIAN GO! (to Mars and beyond!)

Bug#1005301: ITP: python-dt-schema -- Devicetree schema tools

[Romain Porte]

Package: wnpp
Severity: wishlist
Owner: Romain Porte 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org, 
deb...@microjoe.org

* Package name: python-dt-schema
  Version : 2022.01
  Upstream Author : Devicetree Specification 
* URL : http://www.devicetree.org
* License : BSD-2-Clause
  Programming Lang: Python
  Description : Devicetree schema tools

The tools contained in this package are used by the Linux kernel for
doing device-tree specification validation.

I intent to maintain this package under the umbrella of the Debian
Python Team.

Re: What are the most important projects that Debian ought to work on?

[Simon Richter]

Hi,

On 2/10/22 6:55 PM, Sam Hartman wrote:


Over time, if people see the value in migrating toward something more
people understand, the probability of people seeing the value and
migrating increases.


What we are absolutely missing is a workflow for software that does not 
have well-defined releases that are supported by upstream, or that 
release through separate packaging infrastructure with a different 
feature set than ours, but this is largely not a technical problem, but 
a social one.


The technical side is easy: we already know how to ship arbitrary 
snapshots from git, and for situations like in npm where multiple 
version-locked dependencies might need to be co-installable, we can 
probably think of a mapping onto package names that allows us to do so.


On the social side, our users have a certain expectation of support for 
a stable release that we have cultivated over the years, and this has 
usually been with explicit help from upstream, because we can neither 
expect packagers to also become upstream maintainers for out-of-support 
versions nor users to update to unstable or experimental versions before 
reporting a problem.


Users of the npm ecosystem have different expectations than traditional 
Debian users: their infrastructure is online-only, fast-paced, support 
for older versions is less expected, but dependencies on older versions 
can be expressed and will be honoured.


Resolving this conflict will require more than a change in workflow, and 
I'd argue that packages where this conflict does not exist are already 
well served with the two major existing workflows ("version control in 
the Debian archive" and "version control in git, with salsa").


   Simon



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1005303: ITP: python-rfc3987 -- Parsing and validation of URIs (RFC 3896) and IRIs (RFC 3987)

[Romain Porte]

Package: wnpp
Severity: wishlist
Owner: Agathe Porte 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org, 
deb...@microjoe.org

* Package name: python-rfc3987
  Version : 1.3.8
  Upstream Author : Daniel Gerber 
* URL : https://pypi.org/project/rfc3987/
* License : GPL-3+
  Programming Lang: Python
  Description : Parsing and validation of URIs (RFC 3896) and IRIs (RFC 
3987)

This module provides regular expressions according to RFC 3986 “Uniform
Resource Identifier (URI): Generic Syntax” and RFC 3987
“Internationalized Resource Identifiers (IRIs)”, and utilities for
composition and relative resolution of references.

This module is introduced as a dependency for python-dt-schema. I intent
to maintain this package under the umbrella of the Debian Python Team.

Re: ISS is running GNU Linux Debian :)

[Wookey]

On 2022-02-10 21:39 +0100, dude wrote:
>  International Space Station adopts Debian Linux, drops Windows & Red Hat into
>   airlock X-D
> 
>
> https://www.computerweekly.com/blog/Open-Source-Insider/International-Space-Station-adopts-Debian-Linux-drops-Windows-Red-Hat-into-airlock

Or at least was in 2013/4.

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Work-needing packages report for Feb 11, 2022

[wnpp]

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: 1216 (new: 0)
Total number of packages offered up for adoption: 189 (new: 0)
Total number of packages requested help for: 60 (new: 0)

Please refer to https://www.debian.org/devel/wnpp/ for more information.



No new packages have been orphaned, but a total of 1216 packages are
orphaned.  See https://www.debian.org/devel/wnpp/orphaned
for a complete list.



No new packages have been given up for adoption, but a total of 189 packages
are awaiting adoption.  See https://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

   apache2 (#910917), requested 1216 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 (135 more omitted)
 Installations reported by Popcon: 98963
 Bug Report URL: https://bugs.debian.org/910917

   aufs (#963191), requested 600 days ago
 Description: driver for a union mount for Linux filesystems
 Reverse Depends: fsprotect
 Installations reported by Popcon: 9232
 Bug Report URL: https://bugs.debian.org/963191

   autopkgtest (#846328), requested 1898 days ago
 Description: automatic as-installed testing for Debian packages
 Reverse Depends: debci-worker sbuild-qemu
 Installations reported by Popcon: 1230
 Bug Report URL: https://bugs.debian.org/846328

   balsa (#642906), requested 3791 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 1766 days ago
 Description: Rust package manager
 Reverse Depends: dh-cargo rust-all
 Installations reported by Popcon: 2814
 Bug Report URL: https://bugs.debian.org/860116

   courier (#978755), requested 406 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: 898
 Bug Report URL: https://bugs.debian.org/978755

   cron (#984736), requested 340 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: 208889
 Bug Report URL: https://bugs.debian.org/984736

   cyrus-imapd (#921717), requested 1098 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: 415
 Bug Report URL: https://bugs.debian.org/921717

   debtags (#962579), requested 610 days ago
 Description: Debian Package Tags support tools
 Reverse Depends: packagesearch
 Installations reported by Popcon: 1504
 Bug Report URL: https://bugs.debian.org/962579

   dee (#831388), requested 2036 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
 Installations reported by Popcon: 42475
 Bug Report URL: https://bugs.debian.org/831388

   developers-reference (#759995), requested 2721 days ago
 Description: guidelines and information for Debian developers
 Installations reported by Popcon: 3676
 Bug Report URL: https://bugs.debian.org/759995

   devscripts (#800413), requested 2326 days ago
 Description: scripts to make the life of a Debian Package maintainer
   easier
 Reverse Depends: apt-build apt-listdifferences aptfs arriero
   brz-debian buildd debci debian-builder debmake debpear (31 more
   omitted)
 Installations reported by Popcon: 10751
 Bug Report URL: https://bugs.debian.org/800413

   dh-make-elpa (#942642), requested 845 days ago
 Description: helper for creating Debian packages from ELPA packages
 Installations reported by Popcon: 38
 Bug Report URL: https://bugs.debian.org/942642

   docker.io (#908868), requested 1244 days ago
 Description: Linux container runtime
 Reverse Depends: charliecloud-builders docker-clean due
   golang-github-containerd-stargz-snaps

Re: developers-reference "vs" wiki.debian.org/DebianMaintainer

[Gunnar Wolf]

Holger Levsen dijo [Thu, Feb 10, 2022 at 11:49:05AM +]:
> hi,
> 
> so Stephan Lachnit submitted an MR for developers-reference on Monday to
> document how to grant DM upload permissions, which I gladly merged, even
> though I was aware of "#653399: developers-reference: Please include a 
> paragraph about Debian Maintainers (DM)" still being unresolved.
> (...)
> I'm leaning towards explaining the basics in devref (mostly by copying bits
> from the wiki page) and adding a pointer to the wiki page, but if there's 
> consensus that the wiki page is supposed to be made obsolete by *moving*
> the contents to src:devref and leaving a pointer on the wiki page, I could
> also do that.

I agree with Stephan's and Sam's reasoning, I think the detailed
information should be in the devref.

A wiki is by definition open to edition by any (authorized?) user; the
devref has named editors (as you are very well aware ;-) ) and can be
seen as verified and curated information. I think the information
should be concisely explained in the devref, leaving the Wiki for more
full/detailed information on specific points, examples, or documenting
changes as they are discussed or implemented, while waiting for them
to arrive to the devref's next edition.


signature.asc
Description: PGP signature

Re: ISS is running GNU Linux Debian :)

[tomas]

On Thu, Feb 10, 2022 at 10:45:42PM +, Wookey wrote:
> On 2022-02-10 21:39 +0100, dude wrote:
> >  International Space Station adopts Debian Linux, drops Windows & Red Hat 
> > into
> >   airlock X-D
> > 
> >
> > https://www.computerweekly.com/blog/Open-Source-Insider/International-Space-Station-adopts-Debian-Linux-drops-Windows-Red-Hat-into-airlock
> 
> Or at least was in 2013/4.

A bit newer (2016), but by far not current:

  
https://space.stackexchange.com/questions/13539/which-operating-systems-is-the-international-space-station-running

(The nice part about this internet thing is that there are search
engines -- no, not Google, use that other one ;-)

The answer is, as always, more nuanced. The question "which OS is the
ISS running" is so naïve as the question "which kind of cell is your
organism made of". Well, duh, many kinds, of course :-)

The ISS is up there since 1998. Computers have changed a bit since
then. And then, you have life support systems, steering and navigation,
tons of scientific instruments and yes, probably entertainment, too.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: ISS is running GNU Linux Debian :)

[Devops PK Carlisle LLC]

It IS noice. I know change is inevitable, yada, yada... I ran Centos 5
and 6 for around 10 years and thought I had found the One. I could make
those suckers tap dance around Windows. Centos 7 went totally off the
rails, and here I be.

Don't forget...


On 2/10/22 3:39 PM, dude wrote:
> 
>   International Space Station adopts Debian Linux, drops Windows & Red
>   Hat into airlock X-D
> 
> https://www.computerweekly.com/blog/Open-Source-Insider/International-Space-Station-adopts-Debian-Linux-drops-Windows-Red-Hat-into-airlock
> 
> 
> Boldly Going, Running Linux in Space" - Sam Bishop (LCA 2022 Online)
> 
> as seen on https://ytpak.net/watch?v=G1fOZr9v2lY
> 
> #NOICE! ✌️😎👍⭐🍻
> 
> GO DEBIAN GO! (to Mars and beyond!)
>