Hi Gianfranco, hi Bas, Am 01.10.2016 um 20:35 schrieb Gianfranco Costamagna: > (additional review, on top of Sebastiaan's one) > * Requires a python version from 2.6 up to, but not including, 3.0. > > Sebastiaan, I'm not sure we can build Python3 version, but I leave this > check to the maintainer :p Indeed, regrettably python3 is not supported upstream at the moment. I am also working on that, but, you know, one step at a time.
>> If it's preferable to keep the package in the GIS team, I will also be >> happy to do that. I am inexperienced in Debian politics and submit to >> your better judgment. > > not needed, it is fine this way Ok, so also in light of what Bas wrote, let's keep it in DPMT. > review: > 1) > ./docs/source/ttt/cloud_sptheme/themes/redcloud/static/redcloud.css_t: * > :license: BSD > ./docs/source/ttt/cloud_sptheme/themes/cloud/static/jquery.cookie.js: * Dual > licensed under the MIT and GPL licenses: > ./docs/source/ttt/cloud_sptheme/themes/cloud/static/jquery.cookie.js: * > http://www.opensource.org/licenses/mit-license.php > ./docs/source/ttt/cloud_sptheme/themes/cloud/static/jquery.cookie.js: * > http://www.gnu.org/licenses/gpl.html > ./docs/source/ttt/cloud_sptheme/themes/cloud/static/cloud.js_t: * :license: > BSD > ./docs/source/ttt/cloud_sptheme/themes/cloud/static/cloud.css_t: * :license: > BSD > ./docs/source/ttt/cloud_sptheme/themes/cloud/layout.html: :license: BSD > > missing licenses ^^ > 2) grep copyright . -Ri > > some missing copyrights :) I removed most of the offending content and added the information for the remaining stuff, namely two files of static sphinx content. > 3) > > something about: > cf/um/umread/c-lib/Makefile > > CC=gcc > > such stuff is a no-go for my personal policy. > People might want to export CC=clang or whatever, and see it build with it. > > Changing > CC=gcc > to CC?=gcc fixes this > (set if not already set) > the same applies to other stuff in that file. I incorporated all of the above. > $(LDFLAGS)<-- this should be at the end of the line, not at the begin, > otherwise > you might see some libraries stripped just because the .o files needing them > are put after (this happens when wl-asneeded is used/default) Hm, GNU make disagrees with you here. The built-in rule for linking is $(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH) $^ $(LOADLIBES) $(LDLIBS) -o $@ Anyway, I think the Makefiles are improved now, thanks for all the help! This also allowed for adding the hardening features to the build. > 4) > Depends: > libudunits2-0, > > please avoid this because it means a sourceful uploads each time that package > has a soname bump. > > e.g. you can avoid that by having a dependency on the -dev package, > and for runtime... don't know, you don't link it, do you? > > ./cf/units.py: _udunits = ctypes.CDLL('libudunits2.so.0') > > > probably that is the best way, at least a sourceful upload is needed > anyway, to check if the code still works. I am sorry, but I don't understand: So we are talking about the '-0' at the end, right? My first question is: Why is that there in the first place? Why is the package not simply called libudunits2? I will be happy to change the dependencies, but at the moment I don't understand how, since I never need the -dev package, and it seems the libudunits2-0 is the only possibility for the binary package, right? > 5) > http://debomatic-amd64.debian.net/distribution#unstable/cf-python/1.3.2+dfsg.1-1/lintian It lists five errors. For the specifics I refer to the above link. Just for reference I repeat the first couple of words: 5.1) X: python-cf-doc: duplicate-files There is only one sphinx template. I have the nagging feeling that those templates aren't even used, but at the moment I don't know sphinx enough to make that call. If you know this, I would gladly remove them. Anyway it is just three lines of text, so I think we can ignore it for now. 5.2) X: python-cf: library-package-name-for-application 5.3) X: python-cf: application-in-library-section These are correct, i.e. unavoidable since the applications are merely small helper scripts for the library that is the main work. 5.4) I: python-cf: hardening-no-bindnow 5.5) I: python-cf: hardening-no-fortify-functions Thanks to the above Makefile improvements, hardening has now been added and those should be gone. > something might be addressed, something is not worth a fix > also blhc complains > http://debomatic-amd64.debian.net/distribution#unstable/cf-python/1.3.2+dfsg.1-1/blhc This should also be clear now, thanks to hardening. > 6) isn't 1.3.1+dfsg1-1 a better versioning? I don't like too much that "." I took it from some guide on how to do the dfsg cleaning, but since I don't feel strongly about it I changed it. > I think this is all for now :) Thanks! Klaus
signature.asc
Description: OpenPGP digital signature
