Bug#883657: ITP: node-locate-path -- Get the first path that exists on disk of multiple paths

[Paolo Greppi]

Package: wnpp
Severity: wishlist
Owner: Paolo Greppi 

* Package name: node-locate-path
  Version : 2.0.0
  Upstream Author : Sindre Sorhus  (sindresorhus.com)
* URL : https://github.com/sindresorhus/locate-path#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Get the first path that exists on disk of multiple paths

 Node.js module to get the first path that exists on disk, from
 an array of multiple possible paths.
 .
 Provides a synchronous version and an asynchronous version (that 
 returns a promise).
 .
 Node.js is an event-based server-side JavaScript engine.

This is required to update node-find-up to 2.1.0, which is required to update
node-yargs to 10.0.3, which is required for libnpx, which is needed to update
npm to 5.x (!).

I intend to maintain this package within the pkg-javascript team.

The git repo will be at:
https://anonscm.debian.org/git/pkg-javascript/node-locate-path.git

Regards,

Paolo

Re: Re: recommends for apparmor in newest linux-image-4.13

[Laurent Bigonville]

Theodore Ts'o wrote:

On Wed, Nov 29, 2017 at 11:51:55AM -0800, Russ Allbery wrote:


> Michael Stone  writes:
> > On Tue, Nov 28, 2017 at 08:22:50PM -0800, Russ Allbery wrote:
> 
> >> Ubuntu has successfully shipped with AppArmor enabled.
> 
> > For all the packages in debian? Cool! That will save a lot of work.
> 
> Yes?  I mean, most of them don't have rules, so it doesn't do anything,

> but that's how we start.  But indeed, Ubuntu has already done a ton of
> work here, so it *does* save us quite a bit of work.

The fact that AppArmor doesn't do anything if it doesn't have any
rules is why we have a chance of enabling it by default.  The problem
with SELinux is that it's "secure" by the security-weenies' definition
of secure --- that is, if there isn't provision made for a particular
application, with SELinux that application is secure the way a
computer with thermite applied to the hard drive is secure --- it
simply doesn't work.


The SELinux policy could be altered to either run everything that we 
know is not ready to be confined in an unconfined domain or put that 
domain in permissive (which would result in a lot of denials being 
logged), so it's possible to behave more or less the same way as 
AppArmor depending of how the policy is designed.




Every few years, I've tried turning on SELinux on my development
laptop.  After it completely fails and trying to make it work just
work for the subset of application that I care about, I give up and
turn it off again.  Having some kind of LSM enabled is, as far as I am
concerned, better than nothing.


I feel that having Apparmor running and not doing anything will give 
people a false sense of security, on my test machine almost nothing was 
confined


TBH I'm a bit disappointed with upstream state of Apparmor (no D-Bus 
mediation,...) and other missing features that are still ubuntu only.

Re: recommends for apparmor in newest linux-image-4.13

[intrigeri]

Hi Laurent,

Laurent Bigonville:
> The SELinux policy could be altered to either run everything that we know is 
> not
> ready to be confined in an unconfined domain or put that domain in permissive 
> (which
> would result in a lot of denials being logged), so it's possible to behave 
> more or
> less the same way as AppArmor depending of how the policy is designed.

Great!

Is there any plan to do this up to the point when it's realistic to
enable SELinux by default on Debian? Ideally this would be done early
enough so we can run the s/AppArmor/SELinux/ experiment during the
Buster cycle, and make a decision in time for Buster.

(I'm not counting on LSM stacking being finalized in time for Buster
so for now, if we want a LSM enabled by default, we need to choose
exactly one. I'd be fine with SELinux instead of AppArmor; what would
make me sad is if we remained in the "no LSM" situation much longer
only because we don't manage to pick one.)

> I feel that having Apparmor running and not doing anything will give people a 
> false
> sense of security,

That's definitely a risk. If AppArmor ends up being enabled by default
in Debian some day, I think we can easily mitigate this risk by
carefully wording our public communication about it.

> TBH I'm a bit disappointed with upstream state of Apparmor (no D-Bus 
> mediation,...)
> and other missing features that are still ubuntu only.

I can definitely relate to that feeling and have been frustrated about
this for years. Thankfully things have changed drastically recently:
quite a few features have been upstreamed to Linux mainline in 4.13
and 4.14, and more is upcoming, so I'm now hopeful :)

Cheers,
-- 
intrigeri

Re: ISO download difficult

[Steve McIntyre]

thib...@debian.org
>
>Having the two download links side by side on the front page would 
>already be a major improvement, but it would still be very confusing for 
>our users. That's why I would prefer to put the "beware of the leopard" 
>sign inside the install medium, and provide only one medium that would 
>work for both kinds of users.

Or a better solution would be a single link to a clean download
page. See #819664 for my thoughts on this, but I ran out of steam
before getting stuff finished.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You raise the blade, you make the change... You re-arrange me 'til I'm sane...

Re: ISO download difficult

[Michael Stone]

On Wed, Dec 06, 2017 at 12:04:21PM +0800, Paul Wise wrote:

On Wed, Dec 6, 2017 at 11:52 AM, Michael Stone wrote:


you want debian to be uninstallable on some hardware without a copy of
windows? that doesn't seem like a step forward or even a desirable goal.


Of course not, that would be a ridiculous suggestion.

...

For devices that don't ship with an OS or Debian doesn't yet have an
install bootstrap app, obviously d-i ISOs would still be available and
users could manually download and run them, with or without the needed
firmware.


Great, you can understand how "If we did this we could even drop the 
ISOs" was confusing, then?


Mike Stone

Bug#883686: ITP: clonalorigin -- inference of homologous recombination in bacteria using whole genome sequences

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: clonalorigin
  Version : 1.0
  Upstream Author : Xavier Didelot 
* URL : https://github.com/xavierdidelot/clonalorigin
* License : GPL
  Programming Lang: C++
  Description : inference of homologous recombination in bacteria using 
whole genome sequences
 Bacteria, unlike us, can reproduce on their own. They do however have
 mechanisms that transfer DNA between organisms, a process more formally
 known as recombination. The mechanisms by which recombination takes
 place have been studied extensively in the laboratory but much remains
 to be understood concerning how, when and where recombination takes
 place within natural populations of bacteria and how it helps them to
 adapt to new environments. ClonalOrigin performs a comparative analysis
 of the sequences of a sample of bacterial genomes in order to
 reconstruct the recombination events that have taken place in their
 ancestry.


Remark: The source code contains a GUI as well but this is non-functional.
Upstream confirmed himself that this was not used long ago and he has
no idea how to fix it.  Thus this package will only contain the CLI.  It
will be packaged by the Debian Med team at
https://anonscm.debian.org/git/debian-med/clonalorigin.git

Re: recommends for apparmor in newest linux-image-4.13

[Vincas Dargis]

On 2017-12-06 12:24, Laurent Bigonville wrote:
I feel that having Apparmor running and not doing anything will give people a false sense of security, on my test 
machine almost nothing was confined


Yeah, we really need much more working profiles ready to be shipped...  Thoguh I believe our AppArmor maintainer stated 
opinion that we should fix what's already available, instead of rushing to write bunch of new profiles (please correct 
me if I mistaken, intrigeri :-) ).


As a hint, try running "sudo aa-enforce /etc/apparmor.d/*", it might enable some disabled-by-defaut profiles, as 
Thunderbird and Libreoffice ones.


TBH I'm a bit disappointed with upstream state of Apparmor (no D-Bus mediation,...) and other missing features that are 
still ubuntu only.


Yes I miss features too (not only mediation...). Though Signal and Mount mediation is available in 4.14 (not enabled in 
Debian AppArmor configuration _yet_, until it's tested enough), Network might come in 4.16.

Re: Debian Stretch new user report (vs Linux Mint)

[Wouter Verhelst]

On Mon, Dec 04, 2017 at 04:29:43PM +0200, Lars Wirzenius wrote:
> Myself, I would prefer us to keep both the free-software-only ISO and
> the non-free ISO with firmware and other things needed to get typical
> modern hardware running, and improve the discoverability of the
> latter. I think we can do that without having to have a GR to change
> the Social Contract or the DFSG.

Something like https://lists.debian.org/debian-www/2017/12/msg00027.html ?

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: ISO download difficult

[Alf Gaida]

Russ, thanks, convinced.

On 06.12.2017 00:15, Russ Allbery wrote:
> It's not quite that simple.  Once it's included in the default
> sources.list, those packages show up in apt-cache search and other tools,
> or in aptitude browsing.  Then, when looking for a package to solve a
> particular problem, 

Re: ISO download difficult

[Russ Allbery]

Paul Wise  writes:
> On Wed, Dec 6, 2017 at 2:58 PM, Russ Allbery wrote:

>> I'm certainly not arguing for removing this as an option.  I am arguing
>> for challenging ourselves to do better than that for as many cases as
>> we can, because that's not a fun experience.  Even those of us who
>> thoroughly understand Debian deserve to have fun and relatively
>> pain-free experiences installing our operating system!

> Hmm, I thought you were arguing for the manual option to continue to be
> the main way we suggest people install Debian, rather than the OS app
> style option. Seems I was wrong and now my guess is that in addition to
> keeping the manual option available, you think we should improve our
> download web page re firmware, while leaving the rest of the parts of
> the install process as manual as before and keep win32-loader as an
> obscure option most folks haven't heard of?

I have no opinion about win32-loader since I've never used it and would
never use it (I don't even have any family members who would use it or be
able to use it), so I'm really unqualified to comment.  What you describe
sounds great for people starting from a Windows system.  That's just not a
problem I've had in about 20 years.

I don't want work on win32-loader to *replace* making download of a
working network install USB image easier, since that's the change that
would help me and those I know the most.  I'm very happy if we can do
both!

-- 
Russ Allbery (r...@debian.org)   

Re: ISO download difficult

[Jonathan Dowland]

On Wed, Dec 06, 2017 at 10:55:20AM -0800, Russ Allbery wrote:

I have no opinion about win32-loader since I've never used it and would
never use it (I don't even have any family members who would use it or be
able to use it), so I'm really unqualified to comment.  What you describe
sounds great for people starting from a Windows system.  That's just not a
problem I've had in about 20 years.

I don't want work on win32-loader to *replace* making download of a
working network install USB image easier, since that's the change that
would help me and those I know the most.  I'm very happy if we can do
both!


Seconded. win32-loader sounds very good for some people but not for
everyone.

I've literally installed Debian on a work-provided laptop this week; it
came with a RHEL7 variant pre-installed and I didn't even boot that (I
might have to at least have a look, but I was too lazy to look up the
instructions to find the IT-supplied default LUKS passphrase).

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: Debian Stretch new user report (vs Linux Mint)

[Adam Borowski]

On Wed, Dec 06, 2017 at 10:05:51AM +0800, Paul Wise wrote:
> On Wed, Dec 6, 2017 at 1:46 AM, Didier 'OdyX' Raboud wrote:
> 
> > * splitting non-free in subsets;
> > * adding a non-free-firmware area;
> 
> I think we don't want either of these, instead we should *add*
> additional Packages files for each of the classes of non-free things
> that people want to be able to isolate from the rest of non-free,
> "firmware" being the first one and probably the only one.
> 
> After talking with the apt maintainers on IRC and some
> experimentation, I think this is doable and it definitely does not
> require the GR process.
> 
> The parts that need to be patched seem to be:
> 
> Each firmware package to use 3-part Section fields like
> non-free/firmware/sound. Initially dak could override all of the
> packages we want in that subcomponent.

It might be less disruptive to add a new field like Subsection; that'd avoid
the need to change any of archive tools -- including ones not used on the
official archive, like reprepro.

> dak for dealing with 3-part Section fields, adding the new
> non-free/firmware component, generating the new Packages files and
> adding them to Release files.

Turns out you don't need to mess with dak; it's an one-liner to produce such
a Packages file:

grep-dctrl -FDescription firmware 
/var/lib/apt/lists/apt.angband.pl:3142_debian_dists_unstable_non-free_binary-amd64_Packages

(Obviously, this should be ｢-FSubsection firmware｣ or [-FTag use::firmware｣
or whatever way you want to mark subsets.)

Then you generate Release and sign it.

Obviously encapsulating such a feature as an option of dak would be
reasonable, but it's in no way dak exclusive.

> d-i for adding the non-free/firmware component instead of non-free.
> 
> Possibly aptitude/packages.d.o/lintian for dealing with 3-part Section fields.

Apt (and aptitude) should work flawlessly: there's security.debian.org
jessie/updates, and we had non-free/non-us in the past.

> Policy for describing 3-part Section fields and listing allowed ones.
> 
> Alternatively, we could end the conflation between the Section and
> Components but that would require more changes.

Because Section: implies an unique section, while we want the same package
to be present in both non-free and non-free/firmware, I'd suggest
Subsection: or abusing debtags instead.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 14:13 < icenowy[m]> are they hot enough? ;-)
⣾⠁⢰⠒⠀⣿⡁ 14:17 < icenowy[m]> I think now in Europe it should be winter? Let
⢿⡄⠘⠷⠚⠋⠀ the BPi warm you ;-)
⠈⠳⣄ 14:17 <@KotCzarny> yeah, i have a pc to warm me ;)

Re: Debian Stretch new user report (vs Linux Mint)

[Paul Wise]

On Thu, Dec 7, 2017 at 11:39 AM, Adam Borowski wrote:

> It might be less disruptive to add a new field like Subsection; that'd avoid
> the need to change any of archive tools -- including ones not used on the
> official archive, like reprepro.
...
> Because Section: implies an unique section, while we want the same package
> to be present in both non-free and non-free/firmware, I'd suggest
> Subsection: or abusing debtags instead.

We are talking about sub-*components* here not sub-*sections*.
Sections are only simple tags, they don't affect the archive structure
at all, except through the component, because the current Section
field conflates the component (main/contrib/non-free) and the section
(sound/kernel/etc).

I would either continue the conflation and go with:

Section: component/subcomponent/section
Section: non-free/firmware/sound

Or get rid of the conflation:

Section: section
Component: component/subcomponent

Section: sound
Component: non-free/firmware

Or for even more separation:

Component: component
Subcomponent: subcomponent
Section: section

Component: non-free
Subcomponent: firmware
Section: sound

> Turns out you don't need to mess with dak; it's an one-liner to produce such
> a Packages file
...
> Obviously encapsulating such a feature as an option of dak would be
> reasonable, but it's in no way dak exclusive.

Sure, but if we want them on ftp.debian.org (the main place we want to
use them) we need to modify or configure dak to generate them :)

> Apt (and aptitude) should work flawlessly: there's security.debian.org
> jessie/updates, and we had non-free/non-us in the past.

FYI ftpmasters vetoed the proposal of using the syntax
non-free/firmware in the component. They also want to kill
jessie/updates and rename it to jessie-security.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Why do we list individual copyright holders?

[Steve Robbins]

On Wednesday, November 29, 2017 11:46:00 PM CST Steve Robbins wrote:
> On Tuesday, November 28, 2017 9:00:10 AM CST Chris Lamb wrote:
> > Hi,
> > 
> > Sorry for the rejection but "Copyright: See individual source files"
> > unfortunatley does not meet the high standards we strive for within
> > Debian.
> 
> That is odd.  It has been accepted for over 16 years.   What has changed?

[...]

> Why shouldn't we have some way to say "Copyright by the Boost authors"?

It was pointed out [1] that the linux-image copyright file contains 
"Copyright: 1991-2012 Linus Torvalds and many others".  

So: if I changed the boost copyright file to say "Copyright: $Dates Boost 
authors", would it pass ftp-master scrutiny?

Thanks,
-Steve

[1] https://lists.debian.org/debian-devel/2016/08/msg00181.html






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

Re: Has Copyright summarizing outlived its usefulness?

[Steve Robbins]

On Thursday, November 30, 2017 11:26:31 AM CST Simon McVittie wrote:
> On Wed, 29 Nov 2017 at 23:46:00 -0600, Steve Robbins wrote:
> > On Tuesday, November 28, 2017 9:00:10 AM CST Chris Lamb wrote:
> > > Hi,
> > > 
> > > Sorry for the rejection but "Copyright: See individual source files"
> > > unfortunatley does not meet the high standards we strive for within
> > > Debian.
> > 
> > [For] a massive multi-author, multi-year work like Boost, there seems very
> > little value in summarizing copyrights.  Boost has nearly 55000 files in
> > the source distribution.  What could one possibly achieve by summarizing
> > this? How would anyone even read and make sense of it?
> 
> I've written about this before, for example in
> , and I'd be
> very glad to see an "official" response from the ftp team.

It would, indeed, be nice to get a rationale for summarizing a file-by-file 
list of copyrights.

I re-read that 2016 thread just now and it seems to me that most of the 
discussion centres around summarizing the LICENSE(s) of the resulting work.  I 
agree that knowing the license of a package is useful.  Having 55000 copyright 
lines is not.

Perhaps we should deprecate debian/copyright and just create debian/license 
instead!

> For a large package, gathering the list of copyright holders from
> the source into debian/copyright is clearly a lot of work. Is there a
> rationale for why we do that work? Is it self-imposed (because there
> is believed to be consensus within Debian that we want it), or is it
> to comply with the requirements of that particular package's copyright
> license, or is it to meet some other legal requirement?

It's telling to me that there was *no* answer to your question in the 2016 
thread.  I have only been around Debian for 20 years.  Maybe someone with a 
longer history can recall the reasoning behind the copyright file?

-Steve


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

Re: Has Copyright summarizing outlived its usefulness?

[Boyuan Yang]

在 2017年12月6日星期三 CST 下午11:12:19，Steve Robbins 写道：
> On Thursday, November 30, 2017 11:26:31 AM CST Simon McVittie wrote:
> > On Wed, 29 Nov 2017 at 23:46:00 -0600, Steve Robbins wrote:
> > > On Tuesday, November 28, 2017 9:00:10 AM CST Chris Lamb wrote:
> > > > Hi,
> > > > 
> > > > Sorry for the rejection but "Copyright: See individual source files"
> > > > unfortunatley does not meet the high standards we strive for within
> > > > Debian.
> > > 
> > > [For] a massive multi-author, multi-year work like Boost, there seems
> > > very
> > > little value in summarizing copyrights.  Boost has nearly 55000 files in
> > > the source distribution.  What could one possibly achieve by summarizing
> > > this? How would anyone even read and make sense of it?
> > 
> > I've written about this before, for example in
> > , and I'd be
> > very glad to see an "official" response from the ftp team.
> 
> It would, indeed, be nice to get a rationale for summarizing a file-by-file
> list of copyrights.
> 
> I re-read that 2016 thread just now and it seems to me that most of the
> discussion centres around summarizing the LICENSE(s) of the resulting work. 
> I agree that knowing the license of a package is useful.  Having 55000
> copyright lines is not.
> 
> Perhaps we should deprecate debian/copyright and just create debian/license
> instead!
> 
> > For a large package, gathering the list of copyright holders from
> > the source into debian/copyright is clearly a lot of work. Is there a
> > rationale for why we do that work? Is it self-imposed (because there
> > is believed to be consensus within Debian that we want it), or is it
> > to comply with the requirements of that particular package's copyright
> > license, or is it to meet some other legal requirement?
> 
> It's telling to me that there was *no* answer to your question in the 2016
> thread.  I have only been around Debian for 20 years.  Maybe someone with a
> longer history can recall the reasoning behind the copyright file?
> 
> -Steve

My personal thoughts:

Debian/copyright file can help maintainers figure out the license status of 
*each* files to check DFSG status more easily, and that's all. The copyright 
holder does not really matter: listing contributors really should be the job 
of *upstream*.

We must admit that d/copyright is useful: writing this file can help figure 
out the source and license to each file and discover non-dfsg files / vendored 
libraries included secretly by upstream (which happens from time to time). 
That should be helpful to ftp master's task of processing NEW queue and 
examining each file's license.

Howerver, what we, the distribution maintainers, really care is that these 
files do not conflict with our guideline aka DFSG. In this situation it is the 
license that matters, not copyright holders. For large software like linux 
kernel or libboost, we don't really need to take hours trying to make a 
comprehensive author list in d/copyright file. Something like
"2010-2017 (C) The Boost Maintainers" should be acceptable. Of course if the 
file is under a different license (different from th license of whole project) 
or some authors had their names written inside source code *explicitly*(e.g., 
in the comment), it must be listed out in a separate paragraph of d/copyright.

Regards,
Boyuan Yang

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

Re: Has Copyright summarizing outlived its usefulness?

[Russ Allbery]

Boyuan Yang <073p...@gmail.com> writes:

> Howerver, what we, the distribution maintainers, really care is that
> these files do not conflict with our guideline aka DFSG. In this
> situation it is the license that matters, not copyright holders. For
> large software like linux kernel or libboost, we don't really need to
> take hours trying to make a comprehensive author list in d/copyright
> file. Something like "2010-2017 (C) The Boost Maintainers" should be
> acceptable. Of course if the file is under a different license
> (different from th license of whole project) or some authors had their
> names written inside source code *explicitly*(e.g., in the comment), it
> must be listed out in a separate paragraph of d/copyright.

One caveat: be careful of licenses that include clauses like:

The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.

or:

Permission to use, copy, modify, and distribute this software and its
documentation for any purpose and without fee is hereby granted,
provided that the above copyright notice appear in all copies and that
both that copyright notice and this permission notice appear in
supporting documentation

or:

1. Redistributions of source code must retain the above copyright
   notice, this list of conditions and the following disclaimer.

In chose cases, the list of copyright holders may well be part of the
"above copyright notice" and hence must be included in the binary package
somewhere.  (Also note that this means the copyright notice provided by
upstream, even if it's wrong, which is an interesting wrinkle.)

Admittedly, it's highly unlikely anyone would pursue legal action over
this, but still, our goal around licenses has generally been to fully
comply with the license, even the bits people probably don't care about.

-- 
Russ Allbery (r...@debian.org)   

Re: Has Copyright summarizing outlived its usefulness?

[Adam Borowski]

On Wed, Nov 29, 2017 at 11:46:00PM -0600, Steve Robbins wrote:
> On Tuesday, November 28, 2017 9:00:10 AM CST Chris Lamb wrote:
> > Sorry for the rejection but "Copyright: See individual source files"
> > unfortunatley does not meet the high standards we strive for within Debian.
> 
> That is odd.  It has been accepted for over 16 years.   What has changed?   
> 
> It is useful to me that the debian/copyright file contain the distribution 
> license.  For a one-author package, it could even be convenient to describe 
> the author and copyright.
> 
> But for a massive multi-author, multi-year work like Boost, there seems very 
> little value in summarizing copyrights.  Boost has nearly 55000 files in the 
> source distribution.  What could one possibly achieve by summarizing this?  
> How would anyone even read and make sense of it?

Lemme paste a recent case where I've done the relevant analysis:

==
Subject: Re: btrfs-compsize_0~65-gd026966-1_armhf.changes REJECTED

On Thu, Nov 16, 2017 at 07:00:10PM +, Thorsten Alteholz wrote:
> Hi Adam,
>
> "some fine kernel folks" is a bit unspecific in  your debian/copyright.

I wonder how to put it then.  The line in the file, "Copyright (C) 2007
Oracle.  All rights reserved." (from btrfs-progs) is obviously false: all
Oracle did was that at the time it employed some of people who copied and
adapted this code from the kernel.


The provenience of radix-tree.{c,h} is obvious: it's lib/radix-tree.c and
include/linux/radix-tree.h from the kernel tree, although it has diverged
since: it lacks most of changes since 2007 but has a few fixes on its own.

At that time the file listed the following:
* Copyright (C) 2001 Momchil Velikov
* Portions Copyright (C) 2001 Christoph Hellwig
* Copyright (C) 2005 SGI, Christoph Lameter 
which is probably accurate wrt the first two being the principal authors,
but otherwise has no meaningful data on fixes.

Since radix-tree.* was imported into btrfs-progs, it has only a few changes:
mechanical ones by Jan Engelhardt , Zach Brown
 and a three-line meaningful fix by Adam Buchbinder
.  Thus, it's safe to say the copyright claim by
Oracle is bogus.


Not so easy with kerncompat.h: it's a collection of random typedefs and
short functions from the kernel that has seen new stuff imported whenever
it was needed.  Btrfs-progs sees a lot of code copying to and from the
kernel, thus use of common types has an obvious reason.  The copyright on
these snippets belongs to a multitude of kernel folks.  As for copying to
btrfs-progs, git says this file was edited by:
  1 Andi Drebes 
  1 Ben Peddell 
  1 Brendan Heading 
  2 Chris Mason 
 15 Chris Mason 
  1 Cristian Rodríguez 
 13 David Sterba 
  1 David Sterba 
  1 Eric Sandeen 
  2 Goldwyn Rodrigues 
  1 Gustavo Zacarias 
  3 Josef Bacik 
  1 Karel Zak 
  1 Mark Fasheh 
  2 Merlijn Wajer 
  1 Michal Marek 
  1 Mitch Harder 
  1 Omar Sandoval 
  1 Ondrej Kozina 
  5 Qu Wenruo 
  1 Shen Feng 
  1 Wade Cline 
  1 Wang Shilong 
  2 Yan 
  3 Zach Brown 
Most of those use company e-mail addresses, and the only person at Oracle
was Chris Mason early on (but, as usual for an initial author, the biggest
part of the compilation work was done on Oracle's dime).


As for compsize -- I'm its principal author, but Timofey Titovets has
replaced my quick-and-dirty C++ STL code with proper structures from
btrfs-progs, as the plan at the time was to eventually move compsize there,
and obviously a C project doesn't want to be polluted by C++.  Thus, he
imported kernel pieces into these three files.


Thus: in the good Free Software code borrowing ways, there's no reasonable
doubt wrt these files being pure kosher GPL, but any attempts to list
individual authors are utterly doomed.

I wonder how to describe these two files then.
==

> Has copyright summarizing outlived its usefulness for large sources?  Why 
> shouldn't we have some way to say "Copyright by the Boost authors"?

As this case is common to the point of ubiquity, I'd say that listing
authors on cooperative work is not just a pointless waste of time, but is
outright harmful, as it mispreresents authorship data.

Typically, people listed in a header are: 1. whoever started the file, 2.
those ordered to do so by an especially litigious employer.  The bulk of
authors are not listed there at all -- you'd usually need to look at a file
such as AUTHORS (if present), or git history.

There are even worse ideas: every single case I've reviewed a copyright file
mechanically generated with cme, it produced garbage even an inattentive
human wouldn't make.  Just two examples:

https://bugs.debian.org/824896
(Bogusly claims GPL3 in a GPL2-only project, etc.)

https://anonscm.debian.org/cgit/pkg-fonts/ttfautohint.git/commit/?id=