Bug#1060318: This is a regression: it used to pass with PoCL3.1
Platform Name Portable Computing Language Platform Vendor The pocl project Platform VersionOpenCL 3.0 PoCL 3.1+debian Linux, None+Asserts, RELOC, SPIR, LLVM 15.0.6, SLEEF, DISTRO, POCL_DEBUG Platform ProfileFULL_PROFILE
Bug#1056471: python-fabio: debdiff with patch from upstream recommendation
This looks good to be. Thanks for your contribution. Cheers, -- Jérôme Kieffer
Bug#1056471: Patch for 3.12
Hi, I am the upstream author of FabIO and indeed, there is a regression in the tests when run for the first time. This is linked to an un-flushed file. This can simply be corrected with this simple patch https://github.com/silx-kit/fabio/pull/550/files It is probably simpler to debian to just apply this patch to the source when packaging instead of making a new release... Cheers, -- Jérôme Kieffer tel +33 476 882 445
Bug#1041443: issue at meson-python
Hi, Apparently this bug comes from the tool used to build the source package: "meson-python" ... it does not set properly timestamps in the source archive. https://github.com/mesonbuild/meson-python/issues/450 Cheers, Jerome
Bug#1039722: [Debian-pan-maintainers] Bug#1039722: pyfai is failing autopkg tests with python 3.11.4
Hi Matthias, I am the upstream developper of pyFAI. This version is >1 year old and I don't have the resources to backport bug-fixes. I develop on a daily basis on debian 12 and python 3.11 and the latest version is OK there. https://pypi.org/project/pyfai/#history How much work would it represent to package the the version from 2023 ? Cheers, Jerome On Wed, 28 Jun 2023 18:41:46 +0200 Matthias Klose wrote: > Package: src:pyfai > Version: 0.21.3+dfsg1-4 > Severity: serious > Tags: sid trixie > > pyfai is failing it's autopkg tests on amd64 with python 3.11.4: > > https://ci.debian.net/data/autopkgtest/testing/amd64/p/pyfai/34908607/log.gz > > 442s == > 442s FAIL: test_count_csr > (pyFAI.test.test_histogram.TestHistogram2d.test_count_csr) > 442s Test that the pixel count and the total intensity is conserved > 442s -- > 442s Traceback (most recent call last): > 442s File "/usr/lib/python3/dist-packages/pyFAI/test/test_histogram.py", > line > 340, in test_count_csr > 442s self.assertTrue(delta == 0, msg="check all pixels were counted") > 442s AssertionError: False is not true : check all pixels were counted > 442s > 442s == > 442s FAIL: test_numpy_vs_cython_vs_csr_2d > (pyFAI.test.test_histogram.TestHistogram2d.test_numpy_vs_cython_vs_csr_2d) > 442s Compare numpy histogram with cython simple implementation > 442s -- > 442s Traceback (most recent call last): > 442s File "/usr/lib/python3/dist-packages/pyFAI/test/test_histogram.py", > line > 375, in test_numpy_vs_cython_vs_csr_2d > 442s self.assertTrue(delta_max <= self.err_max_cnt, "pixel count > difference > numpy/csr : max delta=%s" % delta_max) > 442s AssertionError: False is not true : pixel count difference numpy/csr : > max > delta=8.0 > 442s > 442s -- > 442s Ran 376 tests in 272.476s > 442s > 442s FAILED (failures=2, skipped=9) > 442s 92 > 442s 61 > 442s 33 > 442s autopkgtest [15:28:03]: test command1: ---] > 443s command1 FAIL non-zero exit status 1 > 443s autopkgtest [15:28:04]: test command1: - - - - - - - - - - results - - > - - > - - - - - - > 443s autopkgtest [15:28:04]: summary > 443s command1 FAIL non-zero exit status 1 > > -- > Debian-pan-maintainers mailing list > debian-pan-maintain...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-pan-maintainers -- Jérôme Kieffer tel +33 476 882 445
Bug#1018811: [Debian-pan-maintainers] Bug#1018811: Three new test issues preventing upload of patch (Was: pyfai: autopkgtest regression on armel and i386)
On Sun, 22 Jan 2023 16:56:46 +0100 Andreas Tille wrote: > Thanks for commenting on this. Would you be able to push the needed changes > to Salsa (and preferably upload)? Hi Andreas, I know a bit about debian packaging and also about the gitlab-CI, but I never used the later for the former. I just re-acetivated my salsa account and forked the project. Now what should I do ? * I guess replace the content of the master branch with the newest release * should I update the content of any other branch ? * then perform a merge-request on the scient-team Maybe (probably) there is a documentation existing, but as usual a quick googling did not provide the adequate answer. Cheers, Jerome
Bug#1018811: Three new test issues preventing upload of patch (Was: pyfai: autopkgtest regression on armel and i386)
Hi Andreas,
Thanks for taking care of the packaging of pyFAI. I had a look at what
the logs and apparently you are packaging the version 0.21.3 ... while
I released the verison 2023.1 last week:
https://pypi.org/project/pyfai/
I just checked on the i386-debian sid chroot I have and none of the 3 test you
found were failing (they are skipped)... but there is another one failing:
==
FAIL: test (pyFAI.test.test_error_model.TestErrorModel.test)
--
Traceback (most recent call last):
File
"/tmp/pyFAI/build/lib/python3/dist-packages/pyFAI/test/test_error_model.py",
line 121, in test
self.assertGreaterEqual(cormap(ref.__getattribute__(array),
res.__getattribute__(array)), epsilon, f"array {array} matches for {k} vs
numpy")
AssertionError: 0 not greater than or equal to 0.002 : array
sum_normalization matches for ('poisson', 'opencl', 'integrate') vs numpy
I double checked and this failure is relative to the PoCL
implemantation used on my i386-chroot. If OpenCL is disabled for the
tests in debian, this test should pass OK.
Cheers,
Jerome
On Fri, 20 Jan 2023 22:20:57 +0100
Andreas Tille wrote:
> Hi Jerome,
>
> I've applied the suggested patch to relax the tests on 32 bit architectures.
> Unfortunately there are new test suite errors as you can see in Salsa CI[1]:
>
>
> ==
> FAIL: test_count_csr
> (pyFAI.test.test_histogram.TestHistogram2d.test_count_csr)
> Test that the pixel count and the total intensity is conserved
> --
> Traceback (most recent call last):
> File
> "/builds/science-team/pyfai/debian/output/source_dir/.pybuild/cpython3_3.11_pyfai/build/pyFAI/test/test_histogram.py",
> line 339, in test_count_csr
> self.assertTrue(delta == 0, msg="check all pixels were counted")
> AssertionError: False is not true : check all pixels were counted
> ==
> FAIL: test_numpy_vs_cython_vs_csr_2d
> (pyFAI.test.test_histogram.TestHistogram2d.test_numpy_vs_cython_vs_csr_2d)
> Compare numpy histogram with cython simple implementation
> --
> Traceback (most recent call last):
> File
> "/builds/science-team/pyfai/debian/output/source_dir/.pybuild/cpython3_3.11_pyfai/build/pyFAI/test/test_histogram.py",
> line 373, in test_numpy_vs_cython_vs_csr_2d
> self.assertTrue(delta_max <= self.err_max_cnt, "pixel count difference
> numpy/csr : max delta=%s" % delta_max)
> AssertionError: False is not true : pixel count difference numpy/csr : max
> delta=8.0
> ==
> FAIL: test_2d_nosplit (pyFAI.test.test_csr.TestCSR.test_2d_nosplit)
> --
> Traceback (most recent call last):
> File
> "/builds/science-team/pyfai/debian/output/source_dir/.pybuild/cpython3_3.11_pyfai/build/pyFAI/test/test_csr.py",
> line 195, in test_2d_nosplit
> self.assertLess(error.mean(), 1e-3, "img are almost the same")
> AssertionError: 244.15215998872887 not less than 0.001 : img are almost the
> same
> ==
>
> Any idea how to fix these?
>
> Kind regards
>Andreas.
>
>
> [1] https://salsa.debian.org/science-team/pyfai/-/jobs/3826387
>
> --
> http://fam-tille.de
Bug#1022440: [Debian-pan-maintainers] Bug#1022440: python-fabio: FTBFS: distutils.errors.DistutilsClassError: command class must subclass Command
Dear Lucas,
I suspect the issue is once again the "numpy.distutils" which enforces
"setuptools<60"...
I have started to port FabIO to the meson-python builder, in a similar
way to what is done for scipy-1.9 (still not packaged for debian).
It is now close to production ready and can release a version as soon
the packaging tools are available in debian.
Best regards,
Jérôme Kieffer
On Sun, 23 Oct 2022 15:37:18 +0200
Lucas Nussbaum wrote:
> Source: python-fabio
> Version: 0.14.0+dfsg-1
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20221023 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
> > fakeroot debian/rules clean
> > dh clean --buildsystem=pybuild
> >dh_auto_clean -O--buildsystem=pybuild
> > I: pybuild base:240: python3.10 setup.py clean
> > /<>/setup.py:49: DeprecationWarning: The distutils package is
> > deprecated and slated for removal in Python 3.12. Use setuptools or check
> > PEP 632 for potential alternatives
> > from distutils.command.clean import clean as Clean
> > /usr/lib/python3/dist-packages/_distutils_hack/__init__.py:18: UserWarning:
> > Distutils was imported before Setuptools, but importing Setuptools also
> > replaces the `distutils` module in `sys.modules`. This may lead to
> > undesirable behaviors or errors. To avoid these issues, avoid using
> > distutils directly, ensure that setuptools is installed in the traditional
> > way (e.g. not an editable install), and/or make sure that setuptools is
> > always imported before distutils.
> > warnings.warn(
> > /usr/lib/python3/dist-packages/_distutils_hack/__init__.py:33: UserWarning:
> > Setuptools is replacing distutils.
> > warnings.warn("Setuptools is replacing distutils.")
> > INFO: Disabling color, you really want to install colorlog.
> > INFO:pythran:Disabling color, you really want to install colorlog.
> > INFO:fabio.setup:Use setuptools with cython
> > INFO:fabio.setup:Use setuptools.setup
> > Traceback (most recent call last):
> > File "/<>/setup.py", line 1118, in
> > setup_package()
> > File "/<>/setup.py", line 1114, in setup_package
> > setup(**setup_kwargs)
> > File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 87, in
> > setup
> > return distutils.core.setup(**attrs)
> > File "/usr/lib/python3/dist-packages/setuptools/_distutils/core.py", line
> > 172, in setup
> > ok = dist.parse_command_line()
> > File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", line
> > 474, in parse_command_line
> > args = self._parse_command_opts(parser, args)
> > File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 1107, in
> > _parse_command_opts
> > nargs = _Distribution._parse_command_opts(self, parser, args)
> > File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", line
> > 540, in _parse_command_opts
> > raise DistutilsClassError(
> > distutils.errors.DistutilsClassError: command class > '__main__.CleanCommand'> must subclass Command
> > E: pybuild pybuild:379: clean: plugin distutils failed with: exit code=1:
> > python3.10 setup.py clean
> > dh_auto_clean: error: pybuild --clean -i python{version} -p 3.10 returned
> > exit code 13
> > make: *** [debian/rules:7: clean] Error 25
>
>
> The full build log is available from:
> http://qa-logs.debian.net/2022/10/23/python-fabio_0.14.0+dfsg-1_unstable.log
>
> All bugs filed during this archive rebuild are listed at:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20221023;users=lu...@debian.org
> or:
> https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20221023=lu...@debian.org=1=1=1=1#results
>
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
>
> If you reassign this bug to another package, please marking it as
> 'affects'-ing
> this package. See https://www.debian.org/Bugs/server-control#affects
>
> If you fail to reproduce this, please provide a build log and diff it with
> mine
> so that we can identify if something relevant changed in the meantime.
>
> --
> Debian-pan-maintainers mailing list
> debian-pan-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-pan-maintainers
--
Jérôme Kieffer
tel +33 476 882 445
Bug#1020073: [Debian-pan-maintainers] Bug#1020073: pyfai: FTBFS: distutils.errors.DistutilsError: Command '['/usr/bin/python3.10', '-m', 'pip', '--disable-pip-version-check', 'wheel', '--no-deps', '-w
Hi Lucas,
All my packages (and probably many more) are marked for removal because of this
bug.
I believe this bugs comes from a specificity of Debian which does not
install python3-pip together with python3. If python3-pip is now needed by
pybuild it should be a build dependency.
Cheers,
Jerome
On Sun, 18 Sep 2022 08:31:39 +0200
Lucas Nussbaum wrote:
> Source: pyfai
> Version: 0.21.3+dfsg1-1
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220917 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
> > fakeroot debian/rules clean
> > dh clean --buildsystem=pybuild
> >dh_auto_clean -O--buildsystem=pybuild
> > install -d
> > /<>/pyfai-0.21.3\+dfsg1/debian/.debhelper/generated/_source/home
> > pybuild --clean -i python{version} -p 3.10
> > I: pybuild base:240: python3.10 setup.py clean
> > /<>/setup.py:43: DeprecationWarning: The distutils package is
> > deprecated and slated for removal in Python 3.12. Use setuptools or check
> > PEP 632 for potential alternatives
> > from distutils.command.clean import clean as Clean
> > /usr/lib/python3/dist-packages/_distutils_hack/__init__.py:18: UserWarning:
> > Distutils was imported before Setuptools, but importing Setuptools also
> > replaces the `distutils` module in `sys.modules`. This may lead to
> > undesirable behaviors or errors. To avoid these issues, avoid using
> > distutils directly, ensure that setuptools is installed in the traditional
> > way (e.g. not an editable install), and/or make sure that setuptools is
> > always imported before distutils.
> > warnings.warn(
> > /usr/lib/python3/dist-packages/_distutils_hack/__init__.py:33: UserWarning:
> > Setuptools is replacing distutils.
> > warnings.warn("Setuptools is replacing distutils.")
> > INFO: Disabling color, you really want to install colorlog.
> > INFO:pythran:Disabling color, you really want to install colorlog.
> > INFO:pyFAI.setup:Use setuptools with cython
> > INFO:pyFAI.setup:Use setuptools.setup
> > /usr/lib/python3/dist-packages/setuptools/installer.py:27:
> > SetuptoolsDeprecationWarning: setuptools.installer is deprecated.
> > Requirements should be satisfied by a PEP 517 installer.
> > warnings.warn(
> > /usr/lib/python3/dist-packages/setuptools/installer.py:34: UserWarning:
> > Unbuilt egg for pyFAI [unknown version] (/<>)
> > pkg_resources.get_distribution('wheel')
> > WARNING: The wheel package is not available.
> > /usr/lib/python3/dist-packages/setuptools/installer.py:60: UserWarning:
> > Unbuilt egg for pyFAI [unknown version] (/<>)
> > environment = pkg_resources.Environment()
> > /usr/bin/python3.10: No module named pip
> > Traceback (most recent call last):
> > File "/usr/lib/python3/dist-packages/setuptools/installer.py", line 82,
> > in fetch_build_egg
> > subprocess.check_call(cmd)
> > File "/usr/lib/python3.10/subprocess.py", line 369, in check_call
> > raise CalledProcessError(retcode, cmd)
> > subprocess.CalledProcessError: Command '['/usr/bin/python3.10', '-m',
> > 'pip', '--disable-pip-version-check', 'wheel', '--no-deps', '-w',
> > '/tmp/tmpymrbi1ta', '--quiet', 'setuptools<60.0.0']' returned non-zero exit
> > status 1.
> >
> > The above exception was the direct cause of the following exception:
> >
> > Traceback (most recent call last):
> > File "/<>/setup.py", line 1137, in
> > setup_package()
> > File "/<>/setup.py", line 1133, in setup_package
> > setup(**setup_kwargs)
> > File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 86, in
> > setup
> > _install_setup_requires(attrs)
> > File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 80, in
> > _install_setup_requires
> > dist.fetch_build_eggs(dist.setup_requires)
> > File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 875, in
> > fetch_build_eggs
> > resolved_dists = pkg_resources.working_set.resolve(
> > File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
> > 789, in resolve
> > dist = best[req.key] = env.best_match(
> > File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
> > 1075, in best_match
> > return self.obtain(req, installer)
> > File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
> > 1087, in obtain
> > return installer(requirement)
> > File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 945, in
> > fetch_build_egg
> > return fetch_build_egg(self, req)
> > File "/usr/lib/python3/dist-packages/setuptools/installer.py", line 84,
> > in fetch_build_egg
> > raise DistutilsError(str(e)) from e
> > distutils.errors.DistutilsError: Command '['/usr/bin/python3.10', '-m',
> > 'pip', '--disable-pip-version-check', 'wheel', '--no-deps', '-w',
> > '/tmp/tmpymrbi1ta', '--quiet', 'setuptools<60.0.0']' returned non-zero exit
>
Bug#1008465: [Debian-pan-maintainers] Bug#1008465: python-fabio: FTBFS: Could not import extension nbsphinx (exception: No module named 'ipython_genutils')
Hi Lucas,
Thanks for the report. This looks like a bug I recently fixed in pyFAI ... I'll
have a look tomorrow. Probably just a missing dependency like in
https://github.com/silx-kit/pyFAI/commit/7bcb6dd7419b48580d97cd91a28d05f86b301f1c
Cheers,
Jerome
On Sat, 26 Mar 2022 22:57:37 +0100
Lucas Nussbaum wrote:
> Source: python-fabio
> Version: 0.13.0+dfsg-1
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220326 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > dh_auto_build
> > I: pybuild base:237: /usr/bin/python3.10 setup.py build
> > /<>/setup.py:49: DeprecationWarning: The distutils package is
> > deprecated and slated for removal in Python 3.12. Use setuptools or check
> > PEP 632 for potential alternatives
> > from distutils.command.clean import clean as Clean
> > INFO:fabio.setup:Use setuptools with cython
> > INFO:fabio.setup:Install requires: numpy >=1.21.5
> > running build
> > running build_py
> > running build_ext
> > I: pybuild base:237: /usr/bin/python3 setup.py build
> > INFO:fabio.setup:Use setuptools with cython
> > INFO:fabio.setup:Install requires: numpy >=1.21.5
> > running build
> > running build_py
> > running build_ext
> > dh_auto_build -- -s custom --build-args="PYTHONPATH={build_dir} xvfb-run -a
> > --server-args=\"-screen 0 1024x768x24\" {interpreter} setup.py build_man"
> > I: pybuild base:237:
> > PYTHONPATH=/<>/.pybuild/cpython3_3.10_fabio/build xvfb-run -a
> > --server-args="-screen 0 1024x768x24" python3.10 setup.py build_man
> > /<>/setup.py:49: DeprecationWarning: The distutils package is
> > deprecated and slated for removal in Python 3.12. Use setuptools or check
> > PEP 632 for potential alternatives
> > from distutils.command.clean import clean as Clean
> > INFO:fabio.setup:Use setuptools with cython
> > INFO:fabio.setup:Install requires: numpy >=1.21.5
> > running build_man
> > INFO:fabio.setup:Build man for entry-point target 'fabio-convert'
> > INFO:fabio.setup:Build man for entry-point target 'eiger2cbf'
> > ERROR:eiger2cbf:Numexpr is needed to interpret formula ...
> > INFO:fabio.setup:Build man for entry-point target 'eiger2crysalis'
> > ERROR:eiger2crysalis:Numexpr is needed to interpret formula ...
> > INFO:fabio.setup:Build man for entry-point target 'densify-Bragg'
> > INFO:fabio.setup:Build man for entry-point target 'fabio_viewer'
> > I: pybuild base:237:
> > PYTHONPATH=/<>/.pybuild/cpython3_3.9_fabio/build xvfb-run -a
> > --server-args="-screen 0 1024x768x24" python3.9 setup.py build_man
> > INFO:fabio.setup:Use setuptools with cython
> > INFO:fabio.setup:Install requires: numpy >=1.21.5
> > running build_man
> > INFO:fabio.setup:Build man for entry-point target 'fabio-convert'
> > INFO:fabio.setup:Build man for entry-point target 'eiger2cbf'
> > ERROR:eiger2cbf:Numexpr is needed to interpret formula ...
> > INFO:fabio.setup:Build man for entry-point target 'eiger2crysalis'
> > ERROR:eiger2crysalis:Numexpr is needed to interpret formula ...
> > INFO:fabio.setup:Build man for entry-point target 'densify-Bragg'
> > INFO:fabio.setup:Build man for entry-point target 'fabio_viewer'
> > dh_auto_build -- -s custom --build-args="cd doc && PYTHONPATH={build_dir}
> > http_proxy='127.0.0.1:9' {interpreter} -m sphinx -N -bhtml source
> > build/html"
> > I: pybuild base:237: cd doc &&
> > PYTHONPATH=/<>/.pybuild/cpython3_3.10_fabio/build
> > http_proxy='127.0.0.1:9' python3.10 -m sphinx -N -bhtml source build/html
> > Running Sphinx v4.3.2
> >
> > Extension error:
> > Could not import extension nbsphinx (exception: No module named
> > 'ipython_genutils')
> > E: pybuild pybuild:367: build: plugin custom failed with: exit code=2: cd
> > doc && PYTHONPATH=/<>/.pybuild/cpython3_3.10_fabio/build
> > http_proxy='127.0.0.1:9' python3.10 -m sphinx -N -bhtml source build/html
> > I: pybuild base:237: cd doc &&
> > PYTHONPATH=/<>/.pybuild/cpython3_3.9_fabio/build
> > http_proxy='127.0.0.1:9' python3.9 -m sphinx -N -bhtml source build/html
> > Running Sphinx v4.3.2
> >
> > Extension error:
> > Could not import extension nbsphinx (exception: No module named
> > 'ipython_genutils')
> > E: pybuild pybuild:367: build: plugin custom failed with: exit code=2: cd
> > doc && PYTHONPATH=/<>/.pybuild/cpython3_3.9_fabio/build
> > http_proxy='127.0.0.1:9' python3.9 -m sphinx -N -bhtml source build/html
> > dh_auto_build: error: pybuild --build -i python{version} -p "3.10 3.9" -s
> > custom "--build-args=cd doc && PYTHONPATH={build_dir}
> > http_proxy='127.0.0.1:9' {interpreter} -m sphinx -N -bhtml source
> > build/html" returned exit code 13
> > make[1]: *** [debian/rules:21: override_dh_auto_build-indep] Error 25
>
>
> The full build log is available from:
> http://qa-logs.debian.net/2022/03/26/python-fabio_0.13.0+dfsg-1_unstable.log
>
> A list of
Bug#1008119: [Debian-pan-maintainers] Bug#1008119: src:pyfai: fails to migrate to testing for too long: autopkgtest regression
Dear Paul, I am the upstream author of pyFAI and the release 0.21.1 is a bugfix for the regressions spotted by the debian CI on a couple of 32-bit computer architectures (thanks to debian for that). Thus I don't understand why the migration from unstable to testing is blocked, especially that the tests passes on all architectures now. Best regards, Jerome Nota, a version 0.21.2 was released with some documentation improvements. On Tue, 22 Mar 2022 20:34:35 +0100 Paul Gevers wrote: > Source: pyfai > Version: 0.20.0+dfsg1-4.1 > Severity: serious > Control: close -1 0.21.1+dfsg1-1 > Tags: sid bookworm > User: release.debian@packages.debian.org > Usertags: out-of-sync > Control: block -1 by 1004509 > > Dear maintainer(s), > > The Release Team considers packages that are out-of-sync between testing > and unstable for more than 60 days as having a Release Critical bug in > testing [1]. Your package src:pyfai has been trying to migrate for 61 > days [2]. Hence, I am filing this bug. > > If a package is out of sync between unstable and testing for a longer > period, this usually means that bugs in the package in testing cannot be > fixed via unstable. Additionally, blocked packages can have impact on > other packages, which makes preparing for the release more difficult. > Finally, it often exposes issues with the package and/or > its (reverse-)dependencies. We expect maintainers to fix issues that > hamper the migration of their package in a timely manner. > > This bug will trigger auto-removal when appropriate. As with all new > bugs, there will be at least 30 days before the package is auto-removed. > > I have immediately closed this bug with the version in unstable, so if > that version or a later version migrates, this bug will no longer affect > testing. I have also tagged this bug to only affect sid and bookworm, so > it doesn't affect (old-)stable. > > If you believe your package is unable to migrate to testing due to > issues beyond your control, don't hesitate to contact the Release Team. > > Paul > > [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html > [2] https://qa.debian.org/excuses.php?package=pyfai > -- Jérôme Kieffer tel +33 476 882 445
Bug#1004509: [Debian-pan-maintainers] Bug#1004509: pyfai: autopkgtest regression on armhf: images have different dimensions
Dear Paul, Dear Fred. Those 3-broken tests are exactly the same as the one reported by Fred Picca on i386 with Python3.10. I tried to reproduce them manually on a Zen computer with an i386 debian system installed on it, without success. I will try to reproduce the bug on an ARM system: I own a Tinkerboard to perform this test. What puzzles me is that it shows of only with Py3.10 The 2GB limit per process can be hit with even moderate size problems in pyFAI and I wonder if it makes sense to package pyFAI for 32-bits systems. That said, I could easily release a 0.21.1 with those 3 tests disables on 32-bits systems. Cheers, Jerome developer of pyFAI On Sat, 29 Jan 2022 19:21:38 +0100 Paul Gevers wrote: > Source: pyfai > Version: 0.21.0+dfsg1-1 > X-Debbugs-CC: debian...@lists.debian.org > Severity: serious > User: debian...@lists.debian.org > Usertags: regression > > Dear maintainer(s), > > With a recent upload of pyfai the autopkgtest of pyfai fails in testing > when that autopkgtest is run with the binary packages of pyfai from > unstable. It passes when run with only packages from testing. In tabular > form: > > passfail > pyfai from testing0.21.0+dfsg1-1 > all others from testingfrom testing > > I copied some of the output at the bottom of this report. > > Currently this regression is blocking the migration to testing [1]. Can > you please investigate the situation and fix it? > > More information about this bug and the reason for filing it can be found on > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation > > Paul > > [1] https://qa.debian.org/excuses.php?package=pyfai > > https://ci.debian.net/data/autopkgtest/testing/armhf/p/pyfai/18797397/log.gz > > == > FAIL: test_count_csr (pyFAI.test.test_histogram.TestHistogram2d) > Test that the pixel count and the total intensity is conserved > -- > Traceback (most recent call last): >File "/usr/lib/python3/dist-packages/pyFAI/test/test_histogram.py", > line 337, in test_count_csr > self.assertTrue(delta == 0, msg="check all pixels were counted") > AssertionError: False is not true : check all pixels were counted > > == > FAIL: test_numpy_vs_cython_vs_csr_2d > (pyFAI.test.test_histogram.TestHistogram2d) > Compare numpy histogram with cython simple implementation > -- > Traceback (most recent call last): >File "/usr/lib/python3/dist-packages/pyFAI/test/test_histogram.py", > line 370, in test_numpy_vs_cython_vs_csr_2d > self.assertTrue(delta_max <= self.err_max_cnt, "pixel count > difference numpy/csr : max delta=%s" % delta_max) > AssertionError: False is not true : pixel count difference numpy/csr : > max delta=8.0 > > == > FAIL: test_2d_nosplit (pyFAI.test.test_csr.TestCSR) > -- > Traceback (most recent call last): >File "/usr/lib/python3/dist-packages/pyFAI/test/test_csr.py", line > 193, in test_2d_nosplit > self.assertLess(error.mean(), 1e-3, "img are almost the same") > AssertionError: 244.15215998872887 not less than 0.001 : img are almost > the same > > -- > Ran 375 tests in 138.562s > > FAILED (failures=3, skipped=9) > 60 > 44 > 23 > autopkgtest [08:17:51]: test command1 >
Bug#971829: python3-pyopencl: Random runtime error in the C++ layer (crash the program)
Package: python3-pyopencl Version: 2019.1.1-1 Severity: critical Tags: upstream Justification: causes serious data loss Dear Maintainer, We are using pyopencl to perform GPU computing in Python workflows. Since we deployed Ubuntu 20.04 (which is using the same version as Debian 10 (and newer), we encounter various crashes of the server with the following error message: ``` terminate called after throwing an instance of 'std::runtime_error' what(): pybind11_object_dealloc(): Tried to deallocate unregistered instance! ``` As thoses server are managing HDF5, this causes (lots of) data corruption. The good piece of news is that the bug is known and has been fixed by this patch: https://github.com/inducer/pyopencl/commit/1dd0183dba05c17d0c21e3f9b3d73d0fee257a2d Moreover there has been a 5 releases since then which include the fix. The easiest would probably be to upgrade the package in debian. Conda based system with recent version of pyopencl are not subject to this kind of crashes. Thanks for your help, Jerome Kieffer -- System Information: Debian Release: 10.6 APT prefers stable APT policy: (800, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.19.0-11-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF8:fr:en_GB.UTF8:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-pyopencl depends on: ii amd-opencl-icd [opencl-icd] 1:15.9-4~deb8u2 ii libc6 2.28-10 ii libgcc1 1:8.3.0-6 ii libstdc++6 8.3.0-6 ii nvidia-opencl-icd [opencl-icd] 450.66-1~bpo10+1 ii ocl-icd-libopencl1 [libopencl1] 2.2.12-2 ii pocl-opencl-icd [opencl-icd]1.2-5 ii python3 3.7.3-1 ii python3-appdirs 1.4.3-1 ii python3-decorator 4.3.0-1.1 ii python3-numpy [python3-numpy-abi9] 1:1.16.2-1 ii python3-pkg-resources 40.8.0-1 ii python3-pytools 2019.1-1 ii python3-six 1.12.0-1 Versions of packages python3-pyopencl recommends: ii python-pyopencl-doc 2019.1.1-1 ii python3-mako 1.0.7+ds1-1 Versions of packages python3-pyopencl suggests: pn python3-imaging-tk ii python3-matplotlib3.0.2-2 ii python3-opengl3.1.0+dfsg-2 ii python3-pyopencl-dbg 2019.1.1-1 ii python3-pytest3.10.1-2 -- no debconf information
Bug#954352: pymca: Missing dependency "python3-scipy", probably in "python3-silx"
Package: pymca Version: 5.4.3+dfsg-1 Severity: grave Justification: renders package unusable Dear Maintainer, I installed "pymca" on a debian 10 system, this draggs the dependencies: * python3-pymca5 * python3-silx The package python3-silx apparently requires python3-scipy, the graphical user interface does not load and crashed at start up. Cheers, Jerpme -- System Information: Debian Release: 10.3 APT prefers stable APT policy: (800, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.19.0-8-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF8:fr:en_GB.UTF8:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pymca depends on: ii python3 3.7.3-1 ii python3-numpy 1:1.16.2-1 ii python3-pymca5 5.4.3+dfsg-1 pymca recommends no packages. pymca suggests no packages. -- no debconf information
Bug#946422: Fw: pocl and silx
Thanks Fred for the time spent on this. It looks like it is a very deep problem ! Concerning the code: This medfilt code never properly worked on POCL CPU-thread version while it works as expected on CUDA (POCL+CUDA) or other drivers. There is a huge amount of shared memory involved which may be the root of the problem (?) But about the interference I mainly see specfile (the C-library) which is our "first" guess inside "silx.io". This legacy code is far from our current standards ... Other point, pyopencl.array.zeros_like() is calling the opencl enfillBuffer function which caused me also issues in (POCL+CUDA). Creating a work-around on the silx side is an option as it has been done many times. I opened a bug on our side: https://github.com/silx-kit/silx/issues/2848 Cheers Begin forwarded message: Date: Thu, 19 Dec 2019 10:08:49 + From: PICCA Frederic-Emmanuel To: "kief...@esrf.fr" Subject: pocl and silx Salut Jerome, on est en train d'essayer de demerder le problème avec pocl. On a mis les info la https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946422 est-ce que cela te dis quelque choses. C'est vrai que si l'on import silxs.io avant silxs.opencl dans le petit snipset de test, ca change fondamentalement la done... Amicalement Fred -- Jérôme Kieffer tel +33 476 882 445
Bug#916292: Kahan summation not working on i386
Hi, This FBFS bug comes down to the POCL on i386 which is not able to perform calculation as described by the OpenCL spec. It is likely a numerical optimization at the wrong place as those tests ensures the calculation are performed as expected. This is described in: https://en.wikipedia.org/wiki/Kahan_summation_algorithm#Possible_invalidation_by_compiler_optimization If I find some time I could have a look at it, but on the other hand, pyFAI does not support 32bits architecture as it requires often more than 2GB of memory for real scientific application. -- Jérôme Kieffer: core dev of pyFAI.
Bug#784709: os-prober prevent the upgrade to jessie
Package: os-prober Version: 1.65 Severity: critical Tags: newcomer Justification: breaks the whole system Dear Maintainer, During the upgrade (apt-get dist-upgrade) of a computer from debian7 (Wheezy) to Debian8 (Jessie) the system still runs the kernel 3.2 from Wheezy; but the os-prober version used by update-grub is already the one from Jessie... and hang. According to: https://lists.debian.org/debian-boot/2013/05/msg00077.html (and related bugs at maegia), the new os-prober (from Jessie) is unable to scan a hard-drive containing Extended partitions (like sdb4 hereafter) and locks forever (at least 90mn), locking the debian system in the middle of a dist- upgrade. Disque /dev/sdb : 1,8 TiB, 2000398934016 octets, 3907029168 secteurs Unités : secteur de 1 × 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 512 octets taille d'E/S (minimale / optimale) : 512 octets / 512 octets Type d'étiquette de disque : dos Identifiant de disque : 0x9a2578f7 Device Boot StartEndSectors Size Id Type /dev/sdb1 63 33575849 33575787 16G 82 Linux swap / Solaris /dev/sdb2 33575850 243304424 209728575 100G 83 Linux /dev/sdb3243304425 453032999 209728575 100G 83 Linux /dev/sdb4453033000 3907024064 3453991065 1,6T 5 Extended /dev/sdb5453033063 557905319 104872257 50G 83 Linux /dev/sdb6557905383 662777639 104872257 50G 83 Linux /dev/sdb766203 767649959 104872257 50G 83 Linux /dev/sdb8767650023 872522279 104872257 50G 83 Linux /dev/sdb9872522343 1082250854 209728512 100G 83 Linux /dev/sdb10 1082250918 3907024064 2824773147 1,3T 83 Linux The system was fully occupied by a mount process trying to mount /dev/sdb4. This process was uninteruptable (kill -9 being ineffective) and forced to reboot exactly at the stage grub was updating. The only solution found was to boot an external device with a rescue system and a recent kernel (3.16) to finish the dist-upgrade. One solution may have been to upgrade first the kernel via wheezy-backports packages before upgrading to Jessie. Best regards, Jerome Kieffer -- System Information: Debian Release: 8.0 APT prefers stable APT policy: (800, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages os-prober depends on: ii libc6 2.19-18 os-prober recommends no packages. os-prober suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735432: new upstream
Hi, The new upstream version (0.14) will include a debian-friendly source tree which includes test images (this makes the source package 100MB) and exclude all auto-generated files like from cython, sphinx, pylint, epydoc, ... to keep it compatible with debian rules. Once upon a time I read upstream packages should not be tailored for Debian ... but that was a long time ago. -- Jérôme Kieffer tel +33 476 882 445 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664993: python-rfoo and remote-tty: error when trying to install together
On Thu, 22 Mar 2012 08:12:00 +0100 Treinen trei...@free.fr wrote: Package: remote-tty,python-rfoo Version: remote-tty/4.0-13 Version: python-rfoo/1.3.0-1 Severity: serious User: trei...@debian.org Usertags: edos-file-overwrite Thanks Ralf for the bug report, the fault is on our side. I contacted the upstream author to let him choose the name of the new script in /usr/bin. Cheers, -- Jérôme Kieffer On-Line Data analysis / Software Group ISDD / ESRF tel +33 476 882 445 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
