Re: PyTroll satpy packaging
Hi Bas,
a short recap of the current status of satpy packaging.
The following dependencies have been packaged and are already in the archive
* python-geotiepoints
* pytroll-schedule
* trollimage
* trollsift
pygac is in the new queue
pyspectral is ready for the upload
pyhdf
Should be OK but it is still not in the archive and I'm currently not
able to build it (after a gcc update). Not sure if we should file a bug
for this. Please let me know.
pylibtiff
has been adopted and updated to the latest version but it has some build
issue on different architectures.
An issue has been filed to upstream [1] but I do not expect a quick reply.
The issue seems to be related to the use of the bittools extension
module on 32bit and/or bigendian architectures.
Looking at the code the the bittools extension is only used in the
libtiff.lzw module that is deprecated in favor of the tif_lzw extension.
Probably it doesn't worth to spend too much time trying to fix it our
self. We could just disable the offending tests and put a note in the
README.Debian file.
satpy
It is almost ready. I have already added dependencies for pyspectral and
pygac that are still not in the archive.
Working on satpy I discovered I discovered that there are 3 undocumented
dependencies:
* pydecorate (from PyTroll) [2] that seems to be used also in some test.
I made a temporary patch to disable tests using pydecorate.
* glymur [3] a Python interface for JPEG 2000 that is imported at
toplevel in the satpy.readers.msi_safe reader module.
* pyninjotiff (also form PyTroll) [4] required by the
satpy.writers.ninjotiff writer module.
IMO packaging also missing modules should not require to much effort so
I would like to do it.
Can you please create repositories for them on salsa?
[1] https://github.com/pearu/pylibtiff/issues/86
[2] https://github.com/pytroll/pydecorate
[3] https://github.com/quintusdias/glymur
[4] https://github.com/pytroll/pyninjotiff
kind regards
antonio
Il 23/12/18 18:50, Sebastiaan Couwenberg ha scritto:
> Hi Antonio,
>
> This is thread is better suited for debian-gis@, I've redirected the OP
> there.
>
> On 12/23/18 6:21 PM, Antonio Valentino wrote:
>> If you agree, and someone is willing to sponsor uploads, I would like to
>> maintain the package and its dependencies under the debian-gis.
>
> It's already part of the blend tasks, and we have the other projects
> too, I don't see why the other related packages shouldn't be maintained
> within this team either.
>
>> Please let me know if you think that satpy is a good candidate for
>> debian-gis and if there is someone that want to sponsor it.
>
> I've sponsored your other packages in this team too, so these won't be
> any different.
>
>> satpy, trollsift, trollimage and python-geotiepoints have been uploaded
>> to mentors. I can put them on salsa as soon as someone creates the
>> repositories, I do not have permission to do it.
>
> The repos for the packages have been created:
>
> * https://salsa.debian.org/debian-gis-team/pygac
> * https://salsa.debian.org/debian-gis-team/pyhdf
> * https://salsa.debian.org/debian-gis-team/pylibtiff
> * https://salsa.debian.org/debian-gis-team/pyspectral
> * https://salsa.debian.org/debian-gis-team/python-geotiepoints
> * https://salsa.debian.org/debian-gis-team/pytroll-schedule
> * https://salsa.debian.org/debian-gis-team/satpy
> * https://salsa.debian.org/debian-gis-team/trollimage
> * https://salsa.debian.org/debian-gis-team/trollsift
>
> Please change your local repositories to use these remotes.
>
>> Regarding pylibtiff, it already has a git repository but probably it
>> would be better to move it under debian-gis.
>> In any case I will wait for an OK before changing the #705208 into an ITA.
>
> Is the communication to adopt pylibtiff public somewhere? I don't see
> anything on debian-qa@l.d.o in the last three months.
>
> Following the procedure documented in the devref should suffice:
>
> https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#adopting
>
> Kind Regards,
>
> Bas
>
--
Antonio Valentino
Reply to: