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 [email protected] 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
