On Mon, Jul 31, 2017 at 11:51:18PM +0100, Dimitri John Ledkov wrote: > On 31 July 2017 at 22:11, Nicholas D Steeves <nstee...@gmail.com> wrote: > > On Mon, Jul 31, 2017 at 04:03:36PM +0100, Dimitri John Ledkov wrote: > >> On 14 July 2017 at 00:59, Nicholas D Steeves <nstee...@gmail.com> wrote: > >> > M 0002-Ignore-.pc-the-quilt-state-tracking-dir.patch > >> > * I read that this is supposed to be standard in dgit repos > >> > >> True, but upstream tarball ships .gitignore, and i'd rather not patch > >> upstream .gitignore =/ > > > > In that case, lets submit the patch upstream? I'd be happy to, if > > you're busy > > possibly.
Should I submit this patch upstream or wait for you to? > >> > N 0004-Move-all-binaries-back-to-sbin-Closes-786893.patch > >> > * Completely up to you, of course ;-) > >> > >> Hmmmm...... maybe i should give up on this one and apply it. > > > > Please consider it :-) If/when Debian/Ubuntu moves to /usrmerge by > > default, then it will be confusing to have mkfs and admin tools in > > /usr/bin rather than /usr/sbin. At some point in the future I'm sure > > there will a tool that is limited to a subset of 'btrfs' that insures > > users don't do unsafe things, and that tool will go in /usr/bin. IIRC > > Ubuntu has /sbin and /usr/sbin for all sudoers, and Debian users who > > complain can be referred to the traditional > > PATH="$PATH:/sbin:/usr/sbin" > > > > That said, thank you for your work on finding and challenging > > arbitrary restrictions in initramfs and other parts of Debian. > > > > Smooth flattery. Thanks? What is the rational today for installating to non-standard (or unconventional) /bin instead of /sbin? I was surprised when this wasn't reverted for the stable release, because I believed it was a method to test for corner cases during development of stretch. > >> > I 0006-Exclude-non-free-RFC-BCP78-files-affects-test-suite.patch > >> > >> The code from RFC 6234 is under Simplified BSD License see sha.h. How > >> is this non-free / what am I missing that you have spotted? > > > > I took a look at this again, and tests/sha224-256.c is the only > > non-free file. I've pushed a fixup to my proposed branch, and have > > also attached it as a patch. 5f1d55d is a fixup for 9e41daf. As is > > customary, I'll leave it to you to rebase/autosquash fixup before > > pushing. > > > > As I read it the licensing is a combination of Simplified BSD plus BCP > > 78 restrictions. The following article mentions two problems with BCP > > 78: > > > > Problem #1: No Rights To Adapt Parts Of Contributions > > Problem #2: No Rights Are Granted To Third Parties > > https://josefsson.org/bcp78broken/ > > > > As i read it is this. The whole RFC is subject to BCP 79, which states > that a subset of the document - the code component, is only subject to > BSD license as long as both the BSD license and the IETF copyright is > included. The whole text of RFC does not follow the copyright, only > the the code component which is only under the bsd as documented in > the sha.h. > > > Also there's the lintian Error: license-problem-non-free-RFC-BCP78... > > If you're certain that it's a false positive then you can probably > > override it. I hope it's a false positive, because upstream finally > > made the test suite actually work! Sadly, I think the error is > > legitimate... > > > > I will check the tag, but it does seem like a false positive to me. I > will check if I can consult somebody about this. Thank you. If I don't hear back from you by Aug 9th I'll ask debian-legal for their analysis. As it stands the presently not excluded tests/sha-stuff needs to be added to debian/copyright, and it might also be a good idea to add a README.copyright explaining how this licensing functions. I'm not familiar enough with legal-speak to understand the details of sublicensing. In any case, any BSD-licensed stuff will need to be documented in debian/copyright, because BSD-licensed code cannot be relicensed as GPL. That said, I'm totally willing to help with this work with the support of debian-legal. > >> > I 0008-Add-dversionmangle-to-handle-dfsg-version-suffix.patch > >> > >> On hold, until 0006 is discussed. > >> > >> > N 0011-debian-watch-Switch-to-version-4-and-add-repacksuffi.patch > >> > >> Simply updated to v4 without any other changes due to 0006. > > > > If you agree, please take a look at these. > > > >> > N 0012-Drop-btrfs-tools-transitional-dummy-package.patch > >> > * Can be safely dropped now, because Stretch was released with > >> > the transitional package > >> > >> https://launchpad.net/ubuntu/+source/btrfs-progs > >> > >> But not yet Ubuntu 18.04 LTS. So 16.04 LTS was still with btrfs-tools, > >> thus ideally I would want to drop this transitional package in May > >> 2018, after 18.04 LTS has been released. Is that ok? > > > > Agreed, we shouldn't break downstreams. I suspect waiting until after > > the last Debian->Ubuntu sync for 18.04 rather than release would be > > best, because Debian will probably be in some state of freeze at that > > time. I don't think is is possible to drop a dummy package during > > deep freeze, but I could be wrong. > > > > That's probably doable. Or e.g. have the dbg package as a delta in > ubuntu temporarliy. Cool. > >> > N 0014-Update-changelog.patch > >> > * Please delete entries for patches you reject > >> > > >> > >> Instead of this, I simply used $ gbp dch to generate the changelog > >> entries from the git commit messages and thus matches what has been > >> applied. They are not as pretty, but I hope that is ok. > > > > Sean Whitton likes very detailed and pretty changelogs, which is why I > > took care to write a nice one, but honestly that's fine with me. I'll > > configure my editor to hard-wrap lines for any future patches. Would > > you please take care to reflow those long lines in the current > > changelog when you're ready to release? The lintian Warning > > debian-changelog-line-too-long occurs without this. > > > > people should buy wide screen monitors lol. no seriously, even kernel > doesn't have a hard line limit. > > But sure, I can redo them. Thanks. Yeah, with good resolution and a large diagonal surface wide monitors are great! :-) Cheers, Nicholas
