Bug#829205: RFS: btrfs-progs/4.5.3-0.1

[Nicholas D Steeves]

Hi Adam,

On 8 July 2016 at 08:58, Adam Borowski  wrote:
> Might be RC but certainly isn't urgent.  I don't see Nicholas pointing any
> of the upstream changes as immediately important (and I _do_ read
> linux-bt...@vger.kernel.org); debian/copyright changes are hardly ever
> time-sentitive too.

For 4.5.3, the only potentially urgent fix was for sparc, which is no
longer a 1st tier support arch.
http://www.spinics.net/lists/linux-btrfs/msg54831.html

I believe the following two fixes in 4.5.3 are probably normal
priority, and are definitely a positive and desirable direction.  Does
reducing the probability of a corner case causing a problem count as
important?:

https://github.com/kdave/btrfs-progs/commit/df2236d73bdffd69cf6d9aac7d80c880b4413aaa
https://github.com/kdave/btrfs-progs/commit/9988284574c1692e5181ecd6f8b9e2512b0503ae

> Especially that the proposed new contents of debian/copyright is, IMHO,
> containing far more inaccuracies than the old one did.

I consulted the xfsprogs and linux-src debian/copyrights.  Other than
the git repo already mentioned in the file, do you know of another
location that could be cited?  I've attached asubstantially simplified
copyright.  Would you please review it and offer critique?

I went for the following approach, similarly to xfsprogs and linux-src:
> * a blanket statement, listing maybe some major holders but with a stress on
>   "and others".

The rules I used to order it were 1) license, alphabetised 2) date  3)
exception for debian/* to put it near the end of GPL-2+  4) Removed
configure and autoconf stuff which was either "redistributable without
notice" or able to be relicensed under the GPL-2 glob.  Further
compaction of the GPL-2+ exceptions is probably possible.  Please let
me know!

Cheers,
Nicholas


copyright
Description: Binary data

Bug#829205: RFS: btrfs-progs/4.5.3-0.1

[Nicholas D Steeves]

Hi Dimitri!

On 8 July 2016 at 05:27, Dimitri John Ledkov  wrote:
> On 6 July 2016 at 11:17, Gianfranco Costamagna  
> wrote:
>> Hi,
>>>Have you coordinated with Dimitri?  When the regular maintainer is active,
>>
>>>NMUs are appropriate for urgent changes, not for regular work.  Ie, instead
>>>of random sponsors, I'd suggest letting him do uploads.
>>>
>>>As you've helped with this package before, perhaps it might be good to
>>>consider co-maintenance?
>>
>> he declined the offer!
>> he is in lowNMU threshold however :)
>>
>
> lowNMU is not meant for hostile takeovers of the package, ok?! =)

I am motivated towards collaboration, not hostile takeover, and I
truly believe that our development strategies are complementary.  I'd
also like to help triage and follow up on bugs.  Where you prefer
large periodic updates, I prefer small incremental updates, after
verifying that they are progressive rather than regressive.  This
verification is a mix of testing on a server, testing on a laptop, and
following linux-btrfs.  Furthermore, given the following I understood
understood that smaller, more atomic and easily reversible incremental
changes over time were preferred, because that would make it easier
for you to revert ones you didn't like:

Date: Sat, 23 Apr 2016 00:20:44 +0100
Message-ID: 
Subject: Re: Bug#818687: RFS: btrfs-progs/4.4.1-1.1 [NMU]
From: Dimitri John Ledkov 
To: Nicholas D Steeves 
Cc: Christian Seiler , 818...@bugs.debian.org,
Gianfranco Costamagna 

> I haven't looked closely, but i have a lot dubious emails about btrfs package.
> (a) i do not maintain backports, anybody is free to do those
> (b) all of my packages are lowNMU, meaning I trust any/all DDs to do
> sensible things
> (c) I do not trust any other developers, meaning that nobody should be
> granting DM and/or changing Uploaders/Maintainers fields etc
> (d) any other fixes is fine to be uploaded, and if things break I am
> on the hook to fix things up afterwards =)

Getting the copyright file into a better state, making uscan work
properly, adding crypto signature verification for tarballs, and
ensuring that the upstream changelog is correctly installed are all
sensible things, are they not?

>
> And I have accepted some patches from you, not all, and I did respond
> to you about that.

You wrote something similar in the following email, but I couldn't
find a record of those responses either:

Date: Tue, 31 May 2016 12:38:48 +0100
Message-ID: 
Subject: Re: Problem with btrfs-progs package
From: Dimitri John Ledkov 
To: Gianfranco Costamagna 
Cc: Uher Marek , Nicholas D Steeves
,
"debian-backpo...@lists.debian.org" 

> I have accepted some, but not all patches from him. I disagree with
> some of them, which i have clearly stated before =)

Please let me know where you clearly state your reasons for
disagreeing with some of my patches.  If you are taking the time to
reply then I don't want to waste your time by having not read your
replies!  I follow debian-backports, debian-boot, debian-cd,
debian-devel, debian-kernel, debian-mentors, debian-multimedia,
linux-btrfs, and of course any bugs that I open.

Sincerely,
Nicholas

Bug#829205: RFS: btrfs-progs/4.5.3-0.1

[Adam Borowski]

On Fri, Jul 08, 2016 at 09:42:10AM +, Gianfranco Costamagna wrote:
> control: owner -1 x...@debian.org

Sounds more like "close" to me...


> >lowNMU is not meant for hostile takeovers of the package, ok?! =)
> 
> sure, this is why  only one NMU was done on your package :)

I'd guess the problem here is that continuing after this issue was flagged
certainly didn't send a message that a next NMU won't be done.


> >And I have accepted some patches from you, not all, and I did respond
> >to you about that.
> >
> >The urgency about the updates and fixes, for the issues that you
> >yourself raise, are a bit self-inflicted. Maybe I am wrong, but
> >certainly, there isn't an immediate needs to NMU this package.
> 
> the copyright issues seems to be a policy violation, and this is what
> I'm mostly concerned about (I asked to make them RC, but you are of course
> free to disagree/downgrade)

Might be RC but certainly isn't urgent.  I don't see Nicholas pointing any
of the upstream changes as immediately important (and I _do_ read
linux-bt...@vger.kernel.org); debian/copyright changes are hardly ever
time-sentitive too.

Especially that the proposed new contents of debian/copyright is, IMHO,
containing far more inaccuracies than the old one did.


Meow!
-- 
An imaginary friend squared is a real enemy.

Bug#829205: RFS: btrfs-progs/4.5.3-0.1

[Gianfranco Costamagna]

control: owner -1 x...@debian.org

Hi Dimitri!


>lowNMU is not meant for hostile takeovers of the package, ok?! =)


sure, this is why  only one NMU was done on your package :)
>And I have accepted some patches from you, not all, and I did respond
>to you about that.
>
>The urgency about the updates and fixes, for the issues that you
>yourself raise, are a bit self-inflicted. Maybe I am wrong, but
>certainly, there isn't an immediate needs to NMU this package.


the copyright issues seems to be a policy violation, and this is what
I'm mostly concerned about (I asked to make them RC, but you are of course
free to disagree/downgrade)

>Patches relevant for btrfs have been pulled into 4.7rc6 and once 4.7
>is updated into experimental or unstable, I can look into updating the
>package with some of the changes that you are proposing.


thanks for that, I'm setting you as owner for this bug :)

>I have just finished a big update to mdadm, and I am at Debconf at the
>moment. And I am still maintaining btrfs-progs.


thanks, I hope you will consider his work, I like it ;)

I'm leaving you the copyright answers then!

G.

Bug#829205: RFS: btrfs-progs/4.5.3-0.1

[Dimitri John Ledkov]

Hello,

On 6 July 2016 at 11:17, Gianfranco Costamagna  wrote:
> control: owner -1 !
> control: tags -1 moreinfo
>
> Hi,
>>Have you coordinated with Dimitri?  When the regular maintainer is active,
>
>>NMUs are appropriate for urgent changes, not for regular work.  Ie, instead
>>of random sponsors, I'd suggest letting him do uploads.
>>
>>As you've helped with this package before, perhaps it might be good to
>>consider co-maintenance?
>
> he declined the offer!
> he is in lowNMU threshold however :)
>

lowNMU is not meant for hostile takeovers of the package, ok?! =)

And I have accepted some patches from you, not all, and I did respond
to you about that.

The urgency about the updates and fixes, for the issues that you
yourself raise, are a bit self-inflicted. Maybe I am wrong, but
certainly, there isn't an immediate needs to NMU this package.

Patches relevant for btrfs have been pulled into 4.7rc6 and once 4.7
is updated into experimental or unstable, I can look into updating the
package with some of the changes that you are proposing.

I have just finished a big update to mdadm, and I am at Debconf at the
moment. And I am still maintaining btrfs-progs.

>>I'm afraid the new debian/copyright is a good deal _worse_ than before.
>>
>>For example, you claim there's a file under GPL3, which would make the
>>package undistributable.  That file's license would be GPL3+ (not =3),
>>still bad, if not for an exception "... you may include it under the same
>>distribution terms that you use for the rest of that program".  Ie, GPL2.
>>
>>Except for some specific projects with tightly controlled copyright notices,
>>Cme produces output indistinguishable from noise.  And knowingly providing
>>obviously incorrect copyright data is bad.  This Cme-produced output claims
>>every file has a single copyright holder who last touched the file years
>>ago -- easily disproven by "git log" on any file I looked at.
>>
>>And btrfs-progs is a massively cooperative project, with a core gang each of
>>whom holds copyright to most of files (or rather, their companies do -- but
>>those change) and a gaggle of minor contributors (including you and me).
>>
>>Thus, I see two alternatives:
>>* you do a massive work of archeology on every file to find the set of
>>  copyright holders.  Every file will have a long list.
>>* a blanket statement, listing maybe some major holders but with a stress on
>>  "and others".
>>
>>I'd say the important points to convey are "1. many contributors, 2. GPL2".
>
>
> Actually I agree,  I try to sum up files for licenses, instead of copyright 
> holders
> e.g.
> all the autoconf* stuff, can go in a single file
> and many copyright headers listed in that section.
>
> Files: config/config.guess
> config/config.sub
> Copyright: 1992-2013, Free Software Foundation, Inc. 
> License: GPL-3
>
>
> this is wrong, because actually it is GPL-3+ or whatever you want in your 
> source
> "
> # As a special exception to the GNU General Public License, if you
> # distribute this file as part of a program that contains a
> # configuration script generated by Autoconf, you may include it under
> # the same distribution terms that you use for the rest of that
> # program.  This Exception is an additional permission under section 7
> # of the GNU General Public License, version 3 ("GPLv3").
> "
>
> so, as all the autoconf files, you might try to put them under the same 
> copyright
> section.
>
> Another thing, you might consider to change
> Files: debian/*
> Copyright: 2007-2012, Daniel Baumann 
> 
> License: GPL-2+
>
> Files: debian/watch
> Copyright: 2016, Nicholas D Steeves 
> License: GPL-2
>
>
> into something like
> Files: debian/*
> Copyright: 2007-2012, Daniel Baumann 
> 
>2016, Nicholas D Steeves 
>
> License: GPL-2+
>
>
> (and add xnox maybe :) )
>
> some more "contraction" might be e.g.
> Files: send-test.c
> Copyright: 2013, SUSE 
> 2012, Alexander Block.
> License: GPL-2
>
> Files: send.h
> Copyright: 2012, STRATO 
> 2012, Alexander Block.
> License: GPL-2
>
> Files: ulist.c
> ulist.h
> Copyright: 2011, STRATO 
> License: GPL-2
>
> this can become
>
> Files: send-test.c send.h ulist.c ulist.h
> Copyright: 2013, SUSE 
> 2011-2012, STRATO 
> 2012, Alexander Block.
> License: GPL-2
>
>
> and so on, unless they have different licensing, just fix the copyright years
> and try to merge them as much as possible, I know this isn't perfectly clear
> but it is highly maintainable!
>
>
> lets review something more:
> +++ btrfs-progs-4.5.3/debian/btrfs-progs.changelogs 2016-07-01 
> 13:01:45.0 +0200
> @@ -0,0 +1 @@
> +CHANGES
>
>
> mmm such files should be automatically picked up by debhelper...
> I would say this file 

Bug#829205: RFS: btrfs-progs/4.5.3-0.1

[Nicholas D Steeves]

Hi Gianfranco!

On 6 July 2016 at 05:17, Gianfranco Costamagna  wrote:
>>I'd say the important points to convey are "1. many contributors, 2. GPL2".
>
>
> Actually I agree,  I try to sum up files for licenses, instead of copyright 
> holders
> e.g.
> all the autoconf* stuff, can go in a single file
> and many copyright headers listed in that section.
...
> so, as all the autoconf files, you might try to put them under the same 
> copyright
> section.

Ok, so group primarily according to licenses, then
functionality/subsection?  eg: autoconf* stuff, send|receive stuff,
subsystem a stuff, subsystem b stuff?

> Another thing, you might consider to change
> Files: debian/*
> Copyright: 2007-2012, Daniel Baumann 
> 
> License: GPL-2+
>
> Files: debian/watch
> Copyright: 2016, Nicholas D Steeves 
> License: GPL-2
>
>
> into something like
> Files: debian/*
> Copyright: 2007-2012, Daniel Baumann 
> 
>2016, Nicholas D Steeves 
>
> License: GPL-2+
>
>
> (and add xnox maybe :) )

Done, in my working copy.

> some more "contraction" might be e.g.
> Files: send-test.c
> Copyright: 2013, SUSE 
> 2012, Alexander Block.
> License: GPL-2
>
> Files: send.h
> Copyright: 2012, STRATO 
> 2012, Alexander Block.
> License: GPL-2
>
> Files: ulist.c
> ulist.h
> Copyright: 2011, STRATO 
> License: GPL-2
>
> this can become
>
> Files: send-test.c send.h ulist.c ulist.h
> Copyright: 2013, SUSE 
> 2011-2012, STRATO 
> 2012, Alexander Block.
> License: GPL-2

So in this case the rule is group by individual, after grouping by
license, but list corporation first?

>
> lets review something more:
> +++ btrfs-progs-4.5.3/debian/btrfs-progs.changelogs 2016-07-01 
> 13:01:45.0 +0200
> @@ -0,0 +1 @@
> +CHANGES
>
>
> mmm such files should be automatically picked up by debhelper...
> I would say this file is useless :)

;-) The CHANGES file wasn't being automatically picked up when I built
the package, on either sid, testing, or as a jessie-backport.  This
surprised me, and I read that package.changelogs was the cleanest way
to give debhelper a hint without using an override in rules.  Also,
faster to remove whenever debhelper starts automatically finding it!

> +++ btrfs-progs-4.5.3/debian/upstream/signing-key.asc   2016-07-01 
> 13:01:45.0 +0200
>
>
> YAY!

:-)  Finally, right?!

> +++ btrfs-progs-4.5.3/debian/watch  2016-07-01 13:35:15.0 +0200
>
> +
>
>
> spurious newline at the end :)

Fixed!

Ay ya yai that copyright file is tricky...  Do you think I should
maybe just rebase off of the original and apply only the most
essential changes?

Cheers!
Nicholas

Bug#829205: RFS: btrfs-progs/4.5.3-0.1

[Nicholas D Steeves]

Hi Adam,

Thank you for taking the time to help me along the way and to produce
higher quality work.

On 5 July 2016 at 22:12, Adam Borowski  wrote:
>
>>   * Fix serious errors in debian/copyright.  This is not a GPL2+ package.
>> Cme was used to generate a machine-readable copyright file, then
>
> I'm afraid the new debian/copyright is a good deal _worse_ than before.
>
> For example, you claim there's a file under GPL3, which would make the
> package undistributable.  That file's license would be GPL3+ (not =3),
> still bad, if not for an exception "... you may include it under the same
> distribution terms that you use for the rest of that program".  Ie, GPL2.

I consulted #debian-mentors on this, and was advised that GPL-3
referred to /usr/share/common-licenses/GPL-3, and yes, I found this
counter-intuitive.  I was also advised to paste the short form into
the debian/copyright, and it includes the "or
 (at your option) any later version" qualifying clause.  At any rate,
can I just drop the GPL3+ sections, because they are being distributed
as GPL2 and thus fall under the GPL2 "Files: *" glob, yes?
>
> Except for some specific projects with tightly controlled copyright notices,
> Cme produces output indistinguishable from noise.  And knowingly providing
> obviously incorrect copyright data is bad.  This Cme-produced output claims
> every file has a single copyright holder who last touched the file years
> ago -- easily disproven by "git log" on any file I looked at.

This is my first time time a copyright review, and it's a learning
process :-)  As for "knowingly providing obviously incorrect copyright
data", I'm uncomfortable with "contracting" date ranges, because a,
list, of, dates with separate copyright holders has a meaning that is
distinct from a-date_range with a list of contributors; summarising
makes me similarly intellectually and ethically uncomfortable...
Short of:
>
> * you do a massive work of archeology on every file to find the set of
>   copyright holders.  Every file will have a long list.

any approach is compromise...  Legally and academically speaking, the
copyright file seems to be more of a non-authoritative at-a-glance
overview of significant contributors.

> And btrfs-progs is a massively cooperative project, with a core gang each of
> whom holds copyright to most of files (or rather, their companies do -- but
> those change) and a gaggle of minor contributors (including you and me).

:-D thank you for noticing!  I was surprised cme didn't find any of
the regular patch contributors to linux-btrfs@vger...

> * a blanket statement, listing maybe some major holders but with a stress on
>   "and others".
>
> I'd say the important points to convey are "1. many contributors, 2. GPL2".

Could you please point me towards a good model?  Since learning that
machine-readable copyright files are still not useful, I've also been
wondering what rules should be used to order the contributors.  Does
it go by alphabetical corporation, then by individuals, then by date?
Should related subsections of code be grouped?  (eg: contributors to
send|receive functionality).  I'd prefer to follow rules than group
things according to patterns that might not be self-evident to others.

Best regards,
Nicholas

Bug#829205: RFS: btrfs-progs/4.5.3-0.1

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo

Hi,
>Have you coordinated with Dimitri?  When the regular maintainer is active,

>NMUs are appropriate for urgent changes, not for regular work.  Ie, instead
>of random sponsors, I'd suggest letting him do uploads.
>
>As you've helped with this package before, perhaps it might be good to
>consider co-maintenance?

he declined the offer!
he is in lowNMU threshold however :)

>I'm afraid the new debian/copyright is a good deal _worse_ than before.
>
>For example, you claim there's a file under GPL3, which would make the
>package undistributable.  That file's license would be GPL3+ (not =3),
>still bad, if not for an exception "... you may include it under the same
>distribution terms that you use for the rest of that program".  Ie, GPL2.
>
>Except for some specific projects with tightly controlled copyright notices,
>Cme produces output indistinguishable from noise.  And knowingly providing
>obviously incorrect copyright data is bad.  This Cme-produced output claims
>every file has a single copyright holder who last touched the file years
>ago -- easily disproven by "git log" on any file I looked at.
>
>And btrfs-progs is a massively cooperative project, with a core gang each of
>whom holds copyright to most of files (or rather, their companies do -- but
>those change) and a gaggle of minor contributors (including you and me).
>
>Thus, I see two alternatives:
>* you do a massive work of archeology on every file to find the set of
>  copyright holders.  Every file will have a long list.
>* a blanket statement, listing maybe some major holders but with a stress on
>  "and others".
>
>I'd say the important points to convey are "1. many contributors, 2. GPL2".


Actually I agree,  I try to sum up files for licenses, instead of copyright 
holders
e.g.
all the autoconf* stuff, can go in a single file
and many copyright headers listed in that section.

Files: config/config.guess
config/config.sub
Copyright: 1992-2013, Free Software Foundation, Inc. 
License: GPL-3


this is wrong, because actually it is GPL-3+ or whatever you want in your source
"
# As a special exception to the GNU General Public License, if you
# distribute this file as part of a program that contains a
# configuration script generated by Autoconf, you may include it under
# the same distribution terms that you use for the rest of that
# program.  This Exception is an additional permission under section 7
# of the GNU General Public License, version 3 ("GPLv3").
"

so, as all the autoconf files, you might try to put them under the same 
copyright
section.

Another thing, you might consider to change
Files: debian/*
Copyright: 2007-2012, Daniel Baumann 
License: GPL-2+

Files: debian/watch
Copyright: 2016, Nicholas D Steeves 
License: GPL-2


into something like
Files: debian/*
Copyright: 2007-2012, Daniel Baumann 
   2016, Nicholas D Steeves 

License: GPL-2+


(and add xnox maybe :) )

some more "contraction" might be e.g.
Files: send-test.c
Copyright: 2013, SUSE 
2012, Alexander Block.
License: GPL-2

Files: send.h
Copyright: 2012, STRATO 
2012, Alexander Block.
License: GPL-2

Files: ulist.c
ulist.h
Copyright: 2011, STRATO 
License: GPL-2

this can become

Files: send-test.c send.h ulist.c ulist.h
Copyright: 2013, SUSE 
2011-2012, STRATO 
2012, Alexander Block.
License: GPL-2


and so on, unless they have different licensing, just fix the copyright years
and try to merge them as much as possible, I know this isn't perfectly clear
but it is highly maintainable!


lets review something more:
+++ btrfs-progs-4.5.3/debian/btrfs-progs.changelogs 2016-07-01 
13:01:45.0 +0200
@@ -0,0 +1 @@
+CHANGES


mmm such files should be automatically picked up by debhelper...
I would say this file is useless :)


+++ btrfs-progs-4.5.3/debian/upstream/signing-key.asc   2016-07-01 
13:01:45.0 +0200


YAY!

+++ btrfs-progs-4.5.3/debian/watch  2016-07-01 13:35:15.0 +0200

+


spurious newline at the end :)

that said, modulo the copyright file, I like the changes :)


thanks for working on it!

Gianfranco

Bug#829205: RFS: btrfs-progs/4.5.3-0.1

[Adam Borowski]

Hi!

On Fri, Jul 01, 2016 at 08:16:14AM -0400, Nicholas D Steeves wrote:
> I am looking for a sponsor for this update of "btrfs-progs".

Have you coordinated with Dimitri?  When the regular maintainer is active,
NMUs are appropriate for urgent changes, not for regular work.  Ie, instead
of random sponsors, I'd suggest letting him do uploads.

As you've helped with this package before, perhaps it might be good to
consider co-maintenance?


>   * Fix serious errors in debian/copyright.  This is not a GPL2+ package.
> Cme was used to generate a machine-readable copyright file, then

I'm afraid the new debian/copyright is a good deal _worse_ than before.

For example, you claim there's a file under GPL3, which would make the
package undistributable.  That file's license would be GPL3+ (not =3),
still bad, if not for an exception "... you may include it under the same
distribution terms that you use for the rest of that program".  Ie, GPL2.

Except for some specific projects with tightly controlled copyright notices,
Cme produces output indistinguishable from noise.  And knowingly providing
obviously incorrect copyright data is bad.  This Cme-produced output claims
every file has a single copyright holder who last touched the file years
ago -- easily disproven by "git log" on any file I looked at.

And btrfs-progs is a massively cooperative project, with a core gang each of
whom holds copyright to most of files (or rather, their companies do -- but
those change) and a gaggle of minor contributors (including you and me).

Thus, I see two alternatives:
* you do a massive work of archeology on every file to find the set of
  copyright holders.  Every file will have a long list.
* a blanket statement, listing maybe some major holders but with a stress on
  "and others".

I'd say the important points to convey are "1. many contributors, 2. GPL2".


Meow!
-- 
An imaginary friend squared is a real enemy.

Bug#829205: RFS: btrfs-progs/4.5.3-0.1

[Nicholas D Steeves]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for this update of "btrfs-progs".  I have
chosen to update to v4.5.3, because this version does not trigger a
bug when combined with linux-4.6.x as discussed in the following
email:
https://www.spinics.net/lists/linux-btrfs/msg56664.html

If the two patches discussed in this email are merged into linux-4.7,
I plan to package btrfs-progs-4.6.1 or v4.7 when linux-4.7 is uploaded
to unstable:
https://www.spinics.net/lists/linux-btrfs/msg56659.html

Alternatively, this bug might be fixed in btrfs-progs-4.7.  For now,
lets use 4.5.3!  Here is the upstream changelog post-4.5.2:

  * ioctl: fix unaligned access in buffer from TREE_SEARCH; might cause SIGBUS
on architectures that do not support unaligned access and do not perform
any fixups
  * improved validation checks of superblock and chunk-related structures
  * subvolume sync: fix handling of -s option
  * balance: adjust timing of safety delay countdown with --full-balance
  * rescue super-recover: fix reversed condition check
  * check: fix bytes_used accounting
  * documentation updates: mount options, scrub, send, receive, select-super,
check, mkfs
  * testing: new fuzzed images, for superblock and chunks

Package name: btrfs-progs
Version: 4.5.3-0.1
Section: admin

It builds these binary packages:

btrfs-progs - Checksumming Copy on Write Filesystem utilities
btrfs-progs-dbg - Checksumming Copy on Write Filesystem utilities (debug)
btrfs-progs-udeb - Checksumming Copy on Write Filesystem utilities (udeb) (udeb)
btrfs-tools - transitional dummy package
btrfs-tools-dbg - transitional dummy package

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/btrfs-progs

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/b/btrfs-progs/btrfs-progs_4.5.3-0.1.dsc

Changes since the last upload:

  * Non-maintainer upload.
  * New upstream release.
  * Update standards version to 3.9.8 (no changes needed).
  * Install upstream changelog. (Closes: #824894)
  * Fix serious errors in debian/copyright.  This is not a GPL2+ package.
Cme was used to generate a machine-readable copyright file, then
manual fixes were made. (Closes: #824896)
  * Add mangling rules to debian/watch to prefer non-rcN versions;
  * Add cryptographic signature verification of tarball.

Thank you,
Nicholas