Hey, Tino. I've been a bit slow because I've had a bad cold for ~5 days.
Tino Mettler: > On Tue, Jan 19, 2016 at 16:55:15 +0000, Chris Knadle wrote: >> Tino Mettler: >>> On Tue, Jan 19, 2016 at 15:17:50 +0000, Chris Knadle wrote: >>> >>> [...] >>> >>>> I'm using git-buildpackage along with pristine-tar. gitpkg has a few >>>> things >>>> I consider peculiarities. >>> >>> So does git-buildpackage in my opinion. :-) >> >> It can, yes. Especially bad is when I've seen upstream git repositories are >> imported directly that contain sub-modules. *shudder* > > My fundamental problem with git-buildpackage is that patches to the > upstream source are kept in files, not in git commits, which is, for > me, one of the main benefits from using git. Yes, I know there is gbp > pq, but still... What you're currently looking at as a disadvantage is something I see as an advantage -- odd as that may sound. I had some discussion with Ian Jackson at DebConf15 concerning dgit along these same lines; there are benefits and drawbacks to each of the solutions of Debian packaging with Git. What I like about git-buildpackage is that I can still use 'dquilt pop -a' to always get back to the unpatched code, and patches can contain DEP3 headers which is something I particularly like using. The downside from the point of view of dgit is that new users coming to the package can't simply make git commits and expect that the work will be automatically considered a patch. It's supposedly possible to do DEP3 headers and have them show up in the patches by using the DEP3 headers as the git commit message which will then get exported to the patch. (I haven't tried this or using dgit, and I wonder what would happen if another commit was done on top as to what would be exported.) dgit also has some quirks where some specific dgit infrastructure for the remote repository needs to exist for it to work correctly. I don't fully understand it's design or how it works, and I haven't looked into it much because of concerns over the DEP3 patch headers quirkiness. My interest in gitpkg is -- well, negative to be honest -- the creator and maintainer of gitpkg has been quite unpleasant to interact with, and the popcon of gitpkg has been on a steady downward trend for the last 5 years. If others choose to use gitpkg that's fine -- I just don't have much interest in it myself. >>> I contacted upstream if there is a way to provide CPPFLAGS without >>> messing with the upstream source (e.h. Rules.mk). >> >> Okay. I don't see modifying Rules.mak as a big deal, but I'm fine with >> avoiding it if it can be avoided. > > I'll just use your change for now. I found where CPPFLAGS gets reset -- "CPPFLAGS=" appears in Local.mak.in. If I remember correctly I tried patching that file first, looked through other "Makeish" files and found that the output of testing with blhc only came out correctly after patching Rules.mak. As far as I can tell from doing package hardening in several other packages the "general rule" seems to be to patch whatever is necessary such that the patch can be small. That is, patching one file that gets imported a bunch of places to add the needed flags is better than patching a slew of Makefiles instead. >>> Another missing item is the current policy standards version. I'll >>> check if the version bump is ok without further changes to the package, >>> but it would be nice if you could double check this. >> >> I already did that. > > Thanks for that. > > So the list of pending changes on my side: > > 1. Incorporate your patch with spelling errors > > 2. Incorporate a fix for the lintian warning regarding the BSD license > > I also have some remarks on your package after I glaced over the > changes. > > 1. You removed source/git-patches, which I consider a bad thing as it > would break my setup for gitpkg. I'm not looking to cause you extra work; the way that went was that I found that the two existing patches weren't needed, then IIRC lintian threw an Error concerning source/git-patches because there were no patches in gitpkg (which obviously I'm not using), so that's why I removed the file. Then later I added other patches, and didn't know how to bring the file back without causing a lintian error, so ... left it as-is. If you know of a way I could have avoided doing this without using gitpkg, let me know. > 2. It looks as if you intended to fix the lintian warning > copyright-refers-to-deprecated-bsd-license-file by just removing the > reference to /usr/share/common-licenses/BSD. In my unserstanding, the > full text to the license needs to be supplied in debian/copyright > instead. The debian/copyright file already contains a full BSD-3-clause license. Referenced by the copyright-format-1.0 page: https://spdx.org/licenses/BSD-3-Clause The differences between BSD-2/3/4-clause licenses are likely why the "common" BSD file isn't being referenced anymore, and the lintian error said that this file is likely to be removed in the future. > 3. The above change to debian/copyright is missing in the changelog Yep, agreed, that was an oversight. -- Chris -- Chris Knadle [email protected]
