nbi and nbc files differ between builds

[bmwiedemann]

While working on the reproducible builds effort, I found that
when building the python-acoular package for openSUSE Linux, there were slight differences between each build:

--- filter/RPMS.2/usr/lib/python3.8/site-packages/acoular/__pycache__/guf-fastFuncs.damasSolverGaussSeidel-875.py38.1.nbc
+++ filter/RPMS.1/usr/lib/python3.8/site-packages/acoular/__pycache__/guf-fastFuncs.damasSolverGaussSeidel-875.py38.1.nbc
@@ -1,9 +1,9 @@
 00000000: 8005 95da 2700 0000 0000 008c 413c 6e75  ....'.......A<nu
 00000010: 6d62 612e 6e70 2e75 6675 6e63 2e77 7261  mba.np.ufunc.wra
 00000020: 7070 6572 732e 5f47 7566 756e 6357 7261  ppers._GufuncWra
 00000030: 7070 6572 206f 626a 6563 7420 6174 2030  pper object at 0
-00000040: 7837 6666 6665 6131 6664 3064 303e 948c  x7fffea1fd0d0>..
+00000040: 7837 6666 6665 6136 3434 3136 303e 948c  x7fffea644160>..
 00000050: 066f 626a 6563 7494 42d0 0f00 007f 454c  .object.B.....EL
 00000060: 4602 0101 0000 0000 0000 0000 0001 003e  F..............>
 00000070: 0001 0000 0000 0000 0000 0000 0000 0000  ................
 00000080: 0000 0000 0010 0d00 0000 0000 0000 0000  ................

--- filter/RPMS.2/usr/lib/python3.8/site-packages/acoular/__pycache__/guf-fastFuncs.damasSolverGaussSeidel-875.py38.nbi
+++ filter/RPMS.1/usr/lib/python3.8/site-packages/acoular/__pycache__/guf-fastFuncs.damasSolverGaussSeidel-875.py38.nbi
@@ -1,6 +1,6 @@
 00000000: 8005 950a 0000 0000 0000 008c 0630 2e34  .............0.4
 00000010: 392e 3094 2e80 0595 3305 0000 0000 0000  9.0.....3.......
-00000020: 4741 d7aa 7c17 0000 004d c7f9 8694 7d94  GA..|....M....}.
+00000020: 4741 d7aa 7c29 c000 004d c7f9 8694 7d94  GA..|)...M....}.
 00000030: 8c1b 6e75 6d62 612e 636f 7265 2e74 7970  ..numba.core.typ
 00000040: 696e 672e 7465 6d70 6c61 7465 7394 8c09  ing.templates...
 00000050: 5369 676e 6174 7572 6594 9394 2981 9428  Signature...)..(

See https://reproducible-builds.org/ for why this matters.

The diff even occurs when trying to make 2 builds as similar as possible.

[esarradj]

I am not sure why this happens. However, those files should not be part of a build anyway and are not included in either the wheel nor the conda packages nor the sdist.
Both files are only created on the first run and normally reside in the user directory.

[bmwiedemann]

So we could just delete them from our rpm package and they would be recreated on the user side (if write permission is available)?

[esarradj]

Yes, indeed. These are Numba cache files (see https://numba.pydata.org/numba-doc/dev/developer/caching.html) and reside in the https://numba.pydata.org/numba-doc/dev/reference/envvars.html#envvar-NUMBA_CACHE_DIR
I am asking myself how they end up in the package in your case?

[bmwiedemann]

We run unit-tests and maybe they get created there and get collected as part of the __pycache__ dir.

[esarradj]

ok, then we should call the cleaning crew after the tests! I will try to fix this, just in case.