Source: xhtml2pdf
Version: 0.2.5-1
Followup-For: Bug #610390
As discussed in upstream issue #11, xhtml2pdf is deprecated (no longer
supported).
The xhtml2pdf documentaiton itself
(https://github.com/xhtml2pdf/xhtml2pdf/blob/master/README.rst) says
to use WeasyPrint (http://weasyprint.org/)
On 2020-10-27 03:11, Emmanuel Arias wrote:
Hi Drew,
I push to salsa the new upstream release (4.0.2)
Cheers,
Arias Emmanuel
Looks good. Uploading.
___
Python-modules-team mailing list
Python-modules-team@alioth-lists.debian.net
On 2020-10-27 03:11, Emmanuel Arias wrote:
Hi Drew,
I push to salsa the new upstream release (4.0.2)
Thanks Emmanuel. I'll check and upload.
Drew
___
Python-modules-team mailing list
Python-modules-team@alioth-lists.debian.net
(again)
thanks!
Cheers,
Arias Emmanuel
@eamanu
http://eamanu.com
El lun., 26 de oct. de 2020 a la(s) 08:22, Drew Parsons
(dpars...@debian.org) escribió:
Great! I'll be happy to sponsor.
Drew
On 2020-10-26 19:19, Emmanuel Arias wrote:
Hi,
Ok, I will ask sponsorship for the source upload
, Drew Parsons
(dpars...@debian.org) escribió:
Source: monty
Severity: normal
Thanks for packaging monty! It will need another source-only upload
in
order to migrate to testing.
While preparing that upload, could the version be updated to the
latest upstream release at the same time?
The latest
Source: monty
Severity: normal
Thanks for packaging monty! It will need another source-only upload in
order to migrate to testing.
While preparing that upload, could the version be updated to the
latest upstream release at the same time?
The latest pymatgen 2020.10.20 requires monty >= 4.0.2
On 2020-08-24 16:08, Drew Parsons wrote:
On 2020-08-24 15:31, Rebecca N. Palmer wrote:
The patch still works for me
... I'll have to dig
deeper (and try a chroot build).
My bad, looks like I forget to run quilt refresh when I was pushing the
patch in. I actually only had half
On 2020-08-24 15:31, Rebecca N. Palmer wrote:
The patch still works for me (on amd64, dpkg-buildpackage in a chroot
with experimental python3-pandas(-lib), sid everything else; keep the
existing pandas025.patch). Anything obviously different about your
test environment?
To be fair, I didn't
Source: python-feather-format
Followup-For: Bug #950924
X-Debbugs-Cc: "Rebecca N. Palmer"
Hi Rebecca, could you check the #950924 patch for python-feather-format?
I applied tha patch, but it's still failing against pandas 1.0.4+dfsg-1.
test_boolean_object_nulls still fails the same way, and
Source: sphinx
Followup-For: Bug #961206
I've just updated numba from Build-Depends: python3-sphinx
to Build-Depends: sphinx as recommended here (#961741).
The change is giving me a lintian error:
E: numba source: missing-build-dependency-for-dh-addon sphinxdoc =>
python-sphinx |
Control: reassign -1 src:numba
On 2020-05-29 00:36, Simon McVittie wrote:
On Fri, 29 May 2020 at 00:02:46 +0800, Drew Parsons wrote:
http_proxy='127.0.0.1:9'
/usr/share/sphinx/scripts/python3/sphinx-build /usr/bin/sphinx-build
-N -bhtml \
.pybuild/cpython3_3.8_numba
Package: python3-sphinx
Version: 2.4.3-3
Severity: grave
Justification: renders package unusable
The new release 2.4.3-3 appears to have broken sphinx-build. It no
longer recognises the OUTPUTDIR argument.
This causes numba to FTBFS (OUTPUTDIR here is
Source: scipy
Followup-For: Bug #957780
https://github.com/xianyi/OpenBLAS/issues/2262 takes it up further:
-fallow-argument-mismatch would be a better (more targetted) flag than
-std=legacy
___
Python-modules-team mailing list
Source: scipy
Followup-For: Bug #957780
The error is
gfortran:f77: scipy/sparse/linalg/eigen/arpack/ARPACK/SRC/dsaitr.f
gfortran:f77: scipy/sparse/linalg/eigen/arpack/ARPACK/SRC/cnaitr.f
scipy/sparse/linalg/eigen/arpack/ARPACK/SRC/dsaitr.f:671:35:
369 | call dvout (logfil, 1,
Source: scipy
Followup-For: Bug #957780
In any case, addressed upstream,
https://github.com/scipy/scipy/pull/11842
___
Python-modules-team mailing list
Python-modules-team@alioth-lists.debian.net
No, the blacklist appears to be preventing me from launching them.
On 2020-04-18 15:08, Graham Inggs wrote:
Hi Drew
On Sat, 18 Apr 2020 at 08:46, Drew Parsons wrote:
I've uploaded scipy 1.4 to unstable. Tests run normally on my
system.
Could we trigger some debci tests to check
I've uploaded scipy 1.4 to unstable. Tests run normally on my system.
Could we trigger some debci tests to check if the new version has
resolved the test problem?
Ideally, say, 2 a day for the next 5 days to get a sample size of 10?
(unless the test failure proves reproducible every time
Package: python3-xhtml2pdf
Version: 0.2.2-5
Followup-For: Bug #610390
Control: forwarded -1 https://github.com/xhtml2pdf/xhtml2pdf/issues/11
This bug is reported upstream, see
https://github.com/xhtml2pdf/xhtml2pdf/issues/11
and
https://github.com/xhtml2pdf/xhtml2pdf/issues/345
etc.
Apparently
Package: python3-xhtml2pdf
Version: 0.2.2-5
Followup-For: Bug #592500
For what it's worth, the generated pdf is still viewable in evince,
xpdf, okular, even with the diagnostic output embedded in the file.
So the output is not unusable.
-- System Information:
Debian Release: bullseye/sid
APT
On 2020-01-14 02:13, Sandro Tosi wrote:
>It's just that there is no extra effort required in this case.
>python3-scipy does indeed need the effort taken, but once that effort
>is
>done, it's no more effort to apply the same fix to python-scipy. So
>yes, please do focus on fixing python3-scipy!
On 2020-01-13 12:47, Sandro Tosi wrote:
Thanks Sandro. There is RC bug#946624 affecting python-scipy, with a
counterpart in #946625 for python3-scipy. Something subtle has
changed
in the syntax for skipping tests, I haven't figured out what yet. Help
needed.
Since that problem needs to be
On 2020-01-13 09:52, Sandro Tosi wrote:
we finally reach the point were src:python-scipy produces only leaf
binary packages (excluding packages that are not in testing because RC
already), so i think it's time to file for its removal, and continue
with src:scipy.
I've copied maintainers and
Thanks Håvard. Placing @pytest.mark.skip will get the job so worse come
to worse we can deal with it that way. The reason why I'd prefer not to
do it that way is that that here we only want to control the tests being
run from debian/tests. The @pytest.mark.skip will disable them for all
Package: python-scipy
Version: 1.2.2-11
Followup-For: Bug #946624
Control: tags -1 help
The rules for skipping the failing tests
(test_sparsetools.TestInt32Overflow) are already in place in
debian/tests/python2
It looks like something must have changed in pytest such that the skip
instructions
Source: scipy
Followup-For: Bug #946625
Control: tags -1 help
The rules for skipping the failing tests
(test_sparsetools.TestInt32Overflow) are already in place in
debian/tests/python3
It looks like something must have changed in pytest such that the skip
instructions are now being ignored.
Package: python-scipy-doc
Version: 1.3.3-1
Followup-For: Bug #873433
It's in
doc/scipy-sphinx-theme/_theme/scipy/static/css/spc-bootstrap.css
doc/scipy-sphinx-theme/_theme/scipy/static/less/spc-bootstrap.less
I daresay we can just remove the line and let the local system find its
own "Open
On 2019-11-04 01:15, Emmanuel Arias wrote:
Hi,
I've just prepare the new upstream release (for some reason
the upstream branch was not merge to master). [1]
Emmanuel, the work-in-progress is in the experimental branch. Push to
experimental first before pulling into master.
Drew
On 2019-10-29 03:01, Rebecca N. Palmer wrote:
Assuming we're talking about
https://salsa.debian.org/python-team/modules/dask/blob/experimental/debian/patches/use-local-intersphinx.patch
I think the actual problem is on the numpy line: it adds the local
inventory but doesn't remove the online
Source: dask
Followup-For: Bug #942235
Fixed upstream, latest version is pushed to the experimental branch.
Needs sphinx-click, which is in the NEW queue.
Drew
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Package: wnpp
Severity: wishlist
Owner: Drew Parsons
* Package name: python3-sphinx-click
Version : 2.1.0
Upstream Author : Stephen Finucane http://that.guru/
* URL : https://github.com/click-contrib/sphinx-click
* License : MIT
Programming Lang: Python
Package: python3-pluggy
Version: 0.13.0-1
Severity: normal
Control: affects -1 python3-fiat
pluggy does import importlib_metadata, at least with python3.7
python3-pluggy should therefore Depends: python3-importlib-metadata
The bug can be seen in fiat tests,
Package: python3-scipy
Version: 1.3.1-1exp1
Severity: normal
Control: forwarded -1 https://github.com/scipy/scipy/issues/10656
hppa, riscv64, sparc64 are hanging on the same built-time test,
stopping at test_nan_inputs[iv]:
On 2019-08-08 15:57, Ondřej Nový wrote:
I see, coming from flaky. Thanks Ondrej.
this should be fixed now with python-flaky 3.6.1-1.
Thanks again Ondrej. That fixes the mpi4py 3.0.2-10 tests.
Drew
___
Python-modules-team mailing list
On 2019-08-07 03:41, Novy, Ondrej wrote:
Hi,
Drew Parsons píše v Út 06. 08. 2019 v 17:25 +0800:
e.g what to do about
...
"/usr/lib/python3/dist-packages/flaky/flaky_pytest_plugin.py", line
272,
in call_runtest_hook
INTERNALERROR> when=when,
INTERNALERROR> Typ
On 2019-08-05 16:37, Novy, Ondrej wrote:
Tags: wontfix
On Mon, 05 Aug 2019 11:43:39 +0800 Drew Parsons
wrote:
This upgrade should be treated as a Transition, uploading the
package to
experimental first.
We are not using Transitions for Python upgrades because almost every
module upgrade
Package: python3-pytest
Version: 4.6.4-1
Severity: serious
Justification: breaks autopkgtest tests
Control: affects -1 + src:apipkg src:betamax src:ccdproc src:chardet
Control: affects -1 + src:dask src:django-axes src:doit src:drms
Control: affects -1 + src:fiat src:mpi4py src:pandas
Package: python-scipy
Version: 1.2.2-1
Tags: + moreinfo
Followup-For: Bug #860138
Hi James, we'll need a test case that triggers the error message in
order to process this bug.
Drew
___
Python-modules-team mailing list
On 2019-05-21 19:55, Mo Zhou wrote:
On 2019-05-21 09:13, Drew Parsons wrote:
Perhaps our scipy build should explicitly avoid libopenblas.so by
setting
export BLAS=/path/to/libblas.so
export LAPACK=/path/to/liblapack.so
as suggested at
http://scipy.github.io/devdocs/building/linux.html
. In that case tt links against
liblapack.so.3 as it should.
On 2019-05-21 04:57, Drew Parsons wrote:
The problem is that libopenblasp-r0.3.5.so contains exactly the same
symbols as libblas.so and liblapack.so. This seems to be confusing
linkers, e.g. see Bug#914655 for python-scipy.
The Debian
Package: python-scipy
Followup-For: Bug #914655
Digging a bit deeper, I think this bug may be impacted by the presence
of /usr/lib/x86_64-linux-gnu/libopenblas.so provide by libopenblas-base
I think you will find your bug may be present in local builds of
scipy, but the official Debian builds
Package: python-scipy
Followup-For: Bug #919929
Should be easier than it looks: the structure is already in place in
debian/tests/python2.
___
Python-modules-team mailing list
Python-modules-team@alioth-lists.debian.net
Package: python-scipy
Version: 1.1.0-4
Followup-For: Bug #919929
Curiously, only python2 is affected now.
Same sympton, MemoryError, now in TestInt32Overflow.test_matvecs and
TestInt32Overflow.test_dia_matvec.
Assuming the MemoryError is again triggered by excessive warnings, the
warning
Package: python-scipy
Followup-For: Bug #723722
Apologies, I was trying to cancel my previous message but it slipped
through by accident, so please ignore it.
What I found was that the warning is emitted in
all cases, whether
np.nanmean([np.nan, np.nan])
np.nanmean([[np.nan, np.nan]])
Package: python-scipy
Followup-For: Bug #723722
nanmean is now removed from scipy.stats (1.1.0-4)
np.nanmean will process the array (without a warning) if given as a
numpy array (numpy 1:1.16.2-1):
>>> np.nanmean(np.array([np.nan, np.nan]))
nan
___
Package: python-scipy
Version: 1.1.0-4
Followup-For: Bug #778635
Hi Gard, can you provide a simple test script so we can confirm that
scipy works correctly after applying your L-BFGS-B patch?
Thanks, Drew
___
Python-modules-team mailing list
Package: python-scipy
Followup-For: Bug #919929
debci tests are consistently passing with python-scipy/1.1.0-4
I think we can consider this bug resolved now.
Drew
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Package: python-scipy
Version: 1.1.0-4
Followup-For: Bug #758022
i386 tests are still a problem in 1.1.0-4
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Incidentally, the matrix DeprecationWarnings related to the test
failures seem to have started with the switch of default python3 from
3.6 to 3.7, 21 Nov 2018. Not from numpy as such (certainly not numpy
1.16).
Possibly due to https://github.com/python/cpython/pull/4458
On 2019-03-16 22:07, Paul Gevers wrote:
On 16-03-2019 13:48, Drew Parsons wrote:
Is there enough will to add more scipy patches for the buster release
to
reduce the remaining DeprecationWarnings? (they don't break tests,
they're just annoying)
Or should we just let it go at this point
On 2019-03-11 14:39, Drew Parsons wrote:
I've adapted the 3 patches and pushed to salsa,
matrix_API_614847c5.patch
matrix_API_more_e0cfa29e2.patch
matrix_API_filter_check_87e48c3c5.patch
https://salsa.debian.org/python-team/modules/python-scipy/tree/master/debian/patches
Package: python-scipy
Version: 1.1.0-4
Followup-For: Bug #914655
This bug was partially fixed in python-scipy 0.19.1-2 when
determination of the location of atlas and openblas was fixed.
ilaver_ is found in libopenblas.so.0.
_flapack.x86_64-linux-gnu.so now has NEEDED libopenblas.so.0
But
On 2019-03-10 15:46, Drew Parsons wrote:
On 2019-03-10 03:51, Paul Gevers wrote:
Hi Drew,
To remove the deprecation warnings we'd need to deal with them at the
source. Upstream has patches
https://github.com/scipy/scipy/commit/614847c5fc8d5f8a618980df3c1b93540428ae46
https://github.com
On 2019-03-10 03:51, Paul Gevers wrote:
Hi Drew,
On 08-03-2019 03:08, Drew Parsons wrote:
On 2019-03-07 20:46, Paul Gevers wrote:
If you upload now, your package will not migrate to testing before
the
full freeze becomes effective so it would need an unblock. If you
want
to fix this issue
On 2019-03-07 20:46, Paul Gevers wrote:
If you upload now, your package will not migrate to testing before the
full freeze becomes effective so it would need an unblock. If you want
to fix this issue with the three lines I saw in the bug report, you can
go ahead. However, it is probably worth
On 2019-03-07 20:46, Paul Gevers wrote:
Hi Drew,
On 07-03-2019 13:19, Drew Parsons wrote:
python-scipy is currently failing all debci tests in both unstable and
testing.
autopkgtest only, so no FTBFS?
That's right, scipy builds fine.
Some of us want failing autopkgtest to be RC *after
On 2019-03-07 19:00, Paul Gevers wrote:
Hi Drew,
On 07-03-2019 09:03, Andreas Tille wrote:
On Tue, Mar 05, 2019 at 07:01:54PM +0800, Drew Parsons wrote:
python-scipy has recently started failing all debci tests in testing
and
unstable, exacerbating the bug report in Bug#919929 [1
Package: python-scipy
Followup-For: Bug #919929
Probably a simple pytest.ini diff between scipy 1.1 and 1.2 makes the
simplest patch:
--- pytest.ini.old 2019-03-05 18:36:51.532842277 +0800
+++ pytest.ini 2019-02-28 11:57:04.155637459 +0800
@@ -7,5 +7,8 @@
error
Package: python-scipy
Followup-For: Bug #919929
No, I am wrong. Tests are pytest, the junit reference is --junitxml,
indicated test reports are in junit format.
The question then, is why is the instruction in pytest.ini to ignore
deprecation warnings not being honoured?
Ah I see it. I'm
Package: python-scipy
Followup-For: Bug #919929
Note PendingDeprecationWarning is set to be ignored in pytest.ini.
The problem is that the tests in debian/tests do not use pytest...
___
Python-modules-team mailing list
Package: python-scipy
Followup-For: Bug #919929
Something weird going on with the scipy tests. There's a clue in this
bug report already: "MemoryError".
Fails are now consistent since 25/2/2019. The funny thing is, even
when I try to access the test log for the last successful
60 matches
Mail list logo
