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,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Reply to: