Bug#950920: [3dprinter-general] trimesh_3.5.25-1_amd64.changes REJECTED

2023-04-04 Thread Gregor Riepl
E   TypeError: Cannot cast array data from dtype('int64') to 
dtype('int32') according to the rule 'safe'


Tracked it down to incorrect usage of numpy.bincount: This function 
requires the native index type, which is int32 on i686 (and probably all 
other 32-bit architectures).


I submitted a documentation change request to numpy: 
https://github.com/numpy/numpy/issues/23526


I'll try to fix the issue in trimesh and submit an upstream patch.



Bug#950920: [3dprinter-general] trimesh_3.5.25-1_amd64.changes REJECTED

2023-04-03 Thread Gregor Riepl

So, I pushed my current version to Salsa.

The CI job found another issue: Some of the tests fail on i386 due to 
typing mismatches: 
https://salsa.debian.org/3dprinting-team/trimesh/-/jobs/4103005


E   TypeError: Cannot cast array data from dtype('int64') to 
dtype('int32') according to the rule 'safe'


This is probably similar to 
https://github.com/mwaskom/seaborn/issues/1950 - I'll try to fix it and 
submit an upstream patch.




Bug#950920: [3dprinter-general] trimesh_3.5.25-1_amd64.changes REJECTED

2023-04-01 Thread Gregor Riepl
I experimented with the package a bit and was successful in building it, 
including running all the tests.


My current fix for the model path issue is not very good, though:
I simply patched out the relative path so it would work with the local 
package build directory, but it's probably better if the build process 
copies the whole /models directory into the build dir before running the 
tests. Is there a "clean" way to do this? Any help would be appreciated.


Aside from that, I found two issues:

Lintian reports a source-is-missing error on load_base64.js. This is a 
hand-written JavaScript source file that contains a base64-encoded 
example. This example looks machine-generated and very trivial.

I think it would be ok to simply apply a Lintian override here.
The .js file isn't packaged anyway, and I don't think there's any 
copyright issue either.


The other problem may be much more serious. The example file 
models/duck.dae contains metadata that says it's under the "SCEA" 
license, which is not an OSI-approved free software license. That means 
this file is most likely not DFSG-compliant. The file is only an example 
that isn't packaged, but I'm not sure if we can keep it in the source 
tree. The license explicitly permits redistribution though, so this may 
not be an issue.




Bug#950920: [3dprinter-general] trimesh_3.5.25-1_amd64.changes REJECTED

2020-04-12 Thread Christoph Berg
retitle 950920 RFP: trimesh -- Python triangular meshes with an emphasis on 
watertight surfaces
noowner 950920
thanks

Re: Thorsten Alteholz 2020-04-08 
> please mention trimesh-3.5.25/models/duck.dae in your debian/copyright.
> 
> While you are at it, please also take care of the lintian error.

I updated the copyright, but there's more stuff to do in the new
upstream version:

 lintian ../trimesh_3.6.20-1_amd64.changes
E: trimesh source: source-is-missing 
trimesh/resources/javascript/load_base64.js line length is 2095 characters 
(>512)
W: python3-trimesh: broken-zip 
usr/lib/python3/dist-packages/trimesh/resources/gltf_2_schema.zip
W: trimesh source: dep5-copyright-license-name-not-unique (paragraph at line 
108)

There's also a load of errors at test time because the "models"
directory doesn't get created:

ERROR: tests.test_3mf (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: tests.test_3mf
Traceback (most recent call last):
  File 
"/srv/debian/3d/trimesh/trimesh/.pybuild/cpython3_3.8/build/tests/test_3mf.py", 
line 2, in 
from . import generic as g
  File 
"/srv/debian/3d/trimesh/trimesh/.pybuild/cpython3_3.8/build/tests/generic.py", 
line 332, in 
data = _load_data()
  File 
"/srv/debian/3d/trimesh/trimesh/.pybuild/cpython3_3.8/build/tests/generic.py", 
line 137, in _load_data
for f in os.listdir(dir_models)]
FileNotFoundError: [Errno 2] No such file or directory: 
'/srv/debian/3d/trimesh/trimesh/.pybuild/cpython3_3.8/build/models'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.8/unittest/loader.py", line 436, in _find_test_path
module = self._get_module_from_name(name)
  File "/usr/lib/python3.8/unittest/loader.py", line 377, in 
_get_module_from_name
__import__(name)
  File 
"/srv/debian/3d/trimesh/trimesh/.pybuild/cpython3_3.8/build/tests/test_3mf.py", 
line 4, in 
import generic as g
ModuleNotFoundError: No module named 'generic'


TBH, that's a lot more than my interest in the package as such, so I'd
be grateful if someone else would take over this ITP.

Git is here: https://salsa.debian.org/3dprinting-team/trimesh.git

Christoph