On 31 July 2017 at 22:11, Nicholas D Steeves <nstee...@gmail.com> wrote: > Hi Dimitri, > > Thank you for taking a look at these. > > 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 =/ >> I personally have a global ignore setup on my machine to ignore .pc, >> or e.g. you can use local per-repository ignore. >> So i'm not taking this for now. > > In that case, lets submit the patch upstream? I'd be happy to, if > you're busy, and I'm reasonably confident it would be accepted because > Debian/Ubuntu are serious distributions and it doesn't break anything > for anyone else. >
possibly. >> > 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. >> > 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. >> > 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. >> > N 0013-Switch-to-debhelper-10-and-automatically-generated-d.patch >> > * No time like the present, right? :-) >> >> Ack, with dropping btrfs-tools-dbg transitional package, because nobody >> cares =) > > Haha, indeed! Ubuntu 18.04 will install btrfs-progs-dbgsym for anyone > who needs it. > >> > 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. > > Cheers, > Nicholas -- Regards, Dimitri.
