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
