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

Re: PyTroll satpy packaging

On 12/30/18 10:18 AM, Antonio Valentino wrote:
> Hi Bas,
> Il 29/12/18 21:32, Sebastiaan Couwenberg ha scritto:
>> On 12/29/18 8:01 PM, Antonio Valentino wrote:
>>> pyspectral is ready for the upload
>> There were a bunch of permission errors due to unwritable $HOME like this:
>> [...]
>> This looks like a violation of Policy 4.9:
>> [...]
>> https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules
>> The defaults in the upstream sources may need to be changed, or a custom
>> config file needs to be used to use $TMPDIR instead of $HOME.
> this one should be fixed now (in git)

Uploaded, thanks.

>>> 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.
>> Filing an RM bug for the package on the failing architectures is also an
>> option. That just leaves i386 as this is treated specially but britney
>> along with amd64 (NOBREAKALL_ARCHES).
>> Since the package has no reverse dependencies, having just amd64 may be
>> good enough for now. How much do you care about satpy on other
>> architectures?
> My first option is still to disable the internal bittools totally.
> I verified that the bittools extension module is not part of the public
> API and it is not mentioned in the documentation.
> Also, it can be replaced by a bitarray (that is packaged in debian) as
> backend for the libtiff.lzw module.
> Even if it is not the default I think it is perfectly fail to use the
> alternative backend.
> So my plan is to disable the bittool extension totally: no build and no
> test.
> Do you think it could be an reasonable solution?

That seems very reasonable, yes.

Kind Regards,


 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Reply to: