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
Attachment:
signature.asc
Description: OpenPGP digital signature