[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#837650: RFS: cf-python/1.3.1+dfsg.1-1 [ITP]

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

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 :)


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: