I have patches for #848764 and #831540; I haven't yet found the cause of
#831541, but as it only affects big-endian systems, partial removal is
an option.
However, one of these bugs is a point where upstream plan to make an
incompatible change (though my fix doesn't), and upstream aren't sure
Forwarded Message
Subject: intent to NMU #848748: blockdiag FTBFS
Date: Sun, 22 Jan 2017 23:29:24 +
From: Rebecca N. Palmer <rebecca_pal...@zoho.com>
To: 848...@bugs.debian.org
Attached is a proposed NMU fixing this bug (identical to my original
patch other than
missing python{,3}-olefile in Build-Depends.
There is no such package in unstable - was this a typo?
(For me the only failed tests were the two in the bug, and just the
patch was enough to fix that.)
I now also see the no-olefile errors in sid:
(This was with a locally built wand - the in-archive one is currently
uninstallable due to #850815 - and is one of many with similar messages.)
I haven't checked whether it works in stretch (which has an older
version of pillow, with an embedded
Why do you think the test failures are due to missing olefile?
There are two sets of test failures here: the two in #848748 (test
mistakes new-in-0.4.1 wand warning for an error), and the ~70 first
reported in this thread (lack of olefile, now probably fixed in pillow).
All my testing was
raise nose.SkipTest("known failure of test_stata on non-little endian")
E NameError: name 'nose' is not defined
You need an 'import nose' first, if the test doesn't already have one.
On 30/09/17 16:50, Diane Trout wrote:
I am curious if Rebecca is using pandas on a non-intel architecture
though (was wondering how she noticed pandas hadn't built)
No - I found this email thread and checked
https://buildd.debian.org/status/package.php?p=pandas
On 29/09/17 23:55, Diane Trout wrote:
I wonder if it's better to filter sphinxdoc out of the dh line, install
sphinx-common, or just always install python3-sphinx?
For local testing of this, use pbuilder --debbuildopts -B
Given earlier messages that we want this working ASAP, always
statsmodels passed NEW...and FTBFS with
dh: unable to load addon sphinxdoc: Can't locate
Debian/Debhelper/Sequence/sphinxdoc.pm in @INC
That file is in the sphinx-common package, which suggests that at least
some of the sphinx dependencies need to be Build-Depends and not just
I see that gdal has moved ahead to 2.3 in Sid, I'm guessing this means opencv
needs to be rebuilt (potentially with API changes...).
It now has been: https://release.debian.org/transitions/html/gdal-2.3.0.html
With its previous Uploader's permission, I have prepared an updated
libgpuarray package, available in Salsa. As I am only a DM, I can't
currently upload this package.
0.6.9-3 [0] is intended for unstable, and is ready for upload; 0.7.6-1
[1] is intended for experimental (we're in transition
I suspect this is caused by bumping debhelper compat (while often a good
idea, this is intentionally *not* risk-free, which is why it requires
explicit action), but I haven't actually tried fixing it by reverting this.
codesearch finds that message in dwz:
On 12/01/2019 12:27, Rebecca N. Palmer wrote:
0.6.9-3 [0] is intended for unstable, and is ready for upload;
On further investigation, it isn't: while the failing tests on i386 only
happen in 0.7.6, the underlying bug (assuming cl_ulong and size_t are
the same type - https://github.com
I haven't found anything officially saying they're abandoned upstream,
but none of them have any commits since August 2017, despite open pull
requests.
clblas and clfft currently appear to be mostly OK in Debian (and most of
the bugs that are known have patches; clsparse was removed because
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Fixing statsmodels turned into a much bigger job than I was expecting:
* The tests were disabled, possibly by accident. Re-enabling them
found that 70 fail, for ~10 different reasons that all look related to
newer versions of dependencies. These
On 25/02/2019 10:04, Andreas Tille wrote:
Dear Rebecca,
thanks for your work on this. I admit it is not clear to me whether you
intent / have permission to upload the status of the buster branch
It's not entirely clear to me either, given that this is more than (at
least I) expected at the
On 27/02/2019 07:00, Andreas Tille wrote:
Dear Rebecca,
I do not think that there is any
need for a separate branch. Just stick to the debian branch.
It's needed because the debian branch contains the attempt at packaging
0.24 described earlier in this thread, which it's now too late for.
Any comment (and preferably upload) on statsmodels? That needs to be
uploaded by the 2nd (in testing by the 12th) if at all, as it has
changes that wouldn't be allowed under full freeze.
On 27/02/2019 14:46, Yaroslav Halchenko wrote:
On Wed, 27 Feb 2019, Andreas Tille wrote:
I'd prefer if
I now have fixes for both #918206 (test failure, RC) and #804552 (no
documentation), in those bugs. (Would you prefer to have a salsa branch?)
Several other open pandas bugs appear to be either already fixed or
non-bugs: is it appropriate for me to close them?
Is the subject line a leftover, or are you actually proposing to move
0.9.0 from experimental to unstable (which is not generally allowed in
soft freeze)?
The upstream fix for #880245 (the original reason given for wanting the
new version) is supposedly
On 13/02/2019 09:10, Andreas Tille wrote:
Any volunteer to backport the relevant changes I pushed to Git right now
to 0.8.0?
I intend to try tomorrow, if the uploaders don't say anything first.
I'm actually wondering why the package did not got any removal
from testing warning (or did I
Package: clsparse
Severity: serious
X-Debbugs-Cc: debian-science@lists.debian.org, ghisv...@gmail.com
(plus an identical one for freefem3d)
This package is dead upstream, and it has been suggested [0] that
because of this, it should not be fixed for buster.
I don't know enough about it to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Please upload libgpuarray 0.7.6-1
(https://salsa.debian.org/science-team/libgpuarray.git commit
c1d24cd9ff81c230b809cc534ff5c59f05b9cf08, not tagged as a previous
sponsor preferred not doing this in advance) to experimental.
This is binary-NEW
Control: tags -1 fixed-upstream patch
The test failure is that np.array @ pd.DataFrame (matrix product) tries
to keep both the DataFrame's indices, which fails because the new matrix
is a different shape.
This appears to be fixed in 0.24.1 from PyPI, but as previously noted,
this is a new
Both these packages currently FTBFS (for similar reasons: invalid unused
templates, which GCC 8 is stricter at rejecting). I have posted (but
can't upload) fixes for both.
As neither of these is currently in testing and there is no re-entry
after 12 Feb (migration date, not upload date),
Has anyone checked whether this would break pandas' reverse dependencies?
To be clear before I start uploading new upstream versions: was our
before-freeze discussion [0-1] a permanent invitation to help (and not
just to fix the then-immediate problems)?
I'd like to get them up to latest upstream in time for the next Ubuntu
(freeze 22 August[2]), but am not sure if
matplotlib and scikit-learn have also had upstream releases, and numpy
is likely to soon; I do not know their maintainers' intentions.
On 07/07/2019 12:59, Drew Parsons wrote:
On 2019-07-07 19:29, Rebecca N. Palmer wrote:
I'd like to get [pandas+statsmodels] up to latest upstream in time
On 10/08/2019 04:02, Drew Parsons wrote:
Strange, they haven't accepted scipy 1.2.2 yet. But mpi4py 3.0.2 went
straight in.
Autopkgtest failure:
https://autopkgtest.ubuntu.com/packages/python-scipy/eoan/amd64
(Though I'm not sure why they're calling something that's been failing
since before
statsmodels 0.9 (#931540) turned into a bigger job than I was expecting
(in general packaging cleanup, not because it's a transition), but is
now almost ready to go - probably tomorrow if there are no unexpected
issues.
I then intend to look at pandas 0.24 (#931557), but suspect that may be
psychopy isn't blocking pandas' testing migration because psychopy
already isn't in testing (for reasons unrelated to py2removal).
Upstream say it's now Python 3 compatible [0], but I haven't tried to
fix its other problems.
The ones that are blocking pandas [1] are python-skbio,
On 18/11/2019 07:07, Matthias Klose wrote:
On 18.11.19 07:52, Alastair McKinstry wrote:
So I've uploaded a python-xarray 0.14.0-2 which passes on python3.7.
Its failing on python 3.8 but apparently due to pandas not ready on 3.8, so it
should be ok to pass as the transition completes.
I
mdp isn't in testing either, but if you're using a policy of "no
py2removals that break packages in testing", tnseq-transit (Depends:
statsmodels) and possibly stimfit (Recommends: pandas) need to be done
as well. Those are both thought to need new upstream versions.
(patsy isn't a leaf
I have uploaded pandas and statsmodels.
On 10/11/2019 14:18, Matthias Klose wrote:
https://people.debian.org/~doko/tmp/
The patsy one has a bug: as debian/tests/nosetests3 was a symlink to
nosetests2, it should have deleted this link and renamed nosetests2 to
nosetests3, not deleted
That looks like a "not built for Python 3.8" error.
Does the -lib package contain both Python 3.7 and 3.8 C extensions (both
/usr/lib/python3/dist-packages/tables/utilsextension.cpython-38m-x86_64-linux-gnu.so
and
Stefan van der Walt wrote:
One possibility is that NumPy was compiled with an older version of
Cython:[...]
Do you know how I can check the source files for the NumPy 1.17 build
that is used here?
Source: https://sources.debian.org/src/numpy/1:1.17.4-3/
Build log:
Python 3.8 is being added (#942106). pandas <0.25 does not support
Python 3.8[0] (when Ubuntu tried they got 268 test failures [1]), while
pandas>=0.25 does not support Python 2.
Hence, our options are:
(a) Remove python-pandas and upgrade pandas to 0.25
(b) Split pandas into two source
On 28/10/2019 06:30, Mo Zhou wrote:
Hi Rebecca,
Theano is a leaf package
No it isn't: deepnano Depends on it.
(If you used my checker - not finding this is bug
https://lists.debian.org/debian-python/2019/10/msg00106.html )
blocking python2 removal.
What's the blocker for the pending
Matthias Klose wrote:
On 2/3/20 8:22 PM, Simon McVittie wrote: >> Meanwhile, multiple packages seem to FTBFS on s390x with the new
libgcc_s
(I've just opened the bug for that, so no bug number known yet), which is
going to limit the ability to get things into testing.
please retry your
Andreas Tille wrote:
I was just
astonished about the long list of unattended merge requests in Debian
Science team. I wonder whether we should somehow prevent people from
dumping code there which will simply bitrot since nobody realy cares.
Salsa allows users to request notifications of merge
shiny-server has been mentioned as a potential covid-19 related package
[0], though it isn't on the current hackathon list [4].
There is a packaging attempt in science-team Salsa (but no formal ITP)
from early 2018. Discussion at the time suggests it builds but possibly
doesn't work [1], and
If upstream provide a test script, you can use "Test-Command" to call it
from autopkgtest.
Daniel Leidert wrote:
However there is a restriction called 'build-needed' which I guess
is for cases where you rely on something inside the source.
Tests always have the source available, and start in
From searching the source, it appears that only 2 tests (plus some
examples) need tensorflow:
hashing_test.py:HashTest.test_tensorflow_non_hashable and
keras_test.py:KerasTest. Hence, skipping these tests may be a
reasonable option after all.
Internet-using tests are discouraged because they can fail for external
reasons, but preferred to leaving online features untested:
https://sources.debian.org/src/autopkgtest/5.12.1/doc/README.package-tests.rst/#L431
(Not sure if there are any rules about downloading code vs data)
There is a
From #954150, it appears there _is_ a code vs data distinction: tests
are allowed to use the network but not to download and run code.
https://ftp-master.debian.org/REJECT-FAQ.html Non-Main II
I intend to post a patch to autopkgtest to document this.
Manually running the tests in question
A potential workaround for testing: while package builds (including
build-time tests) are not allowed to use the network, autopkgtests *are*
allowed to => skip the tensorflow-needing tests in build, but run them
(with tensorflow from PyPI) in autopkgtest?
However, streamlit also has a Javascript component (the frontend
directory), with ~100 dependencies Debian doesn't have (plus a few that
Debian has in too old a version):
$ npm2deb depends /home/rnpalmer/Debian/builds/stackbuild/package.json
Dependencies:
NPM
Previous discussions:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862524
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887728
Package FTBFS everywhere, for multiple reasons but looks like the new
pytest_asyncio is at least one of them; will investigate further later.
Not yet, it should at least be 1.0.5 from Salsa.
(Also, q2-* have autopkgtests so it will probably get stuck in -proposed.)
On 25/08/2020 08:19, Graham Inggs wrote:
Hi Rebecca
On Mon, 24 Aug 2020 at 01:03, Rebecca N. Palmer wrote:
pandas 1.0 has been in experimental for 6+ months, because
Second attempt uploaded.
Of the reverse dependencies with known fixes, python-feather-format has
been uploaded but q2templates hasn't.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950430
pandas 1.0 has been in experimental for 6+ months, because it breaks
some of its reverse dependencies:
In testing:
#950924 python-feather-format (has patch, no maintainer response to it)
#950931 q2templates (has upstream fix)
#950929
On 08/06/2020 18:35, Qianqian Fang wrote:
I picked one of my projects (https://github.com/fangq/zmat) to get
started, currently, I managed to create all basic packaging files (3
subpackages, zmat/zmat-dev/octave-zmat)
https://github.com/fangq/debpkg/tree/zmat
This is a library, so the
On 08/06/2020 21:04, Qianqian Fang wrote:
from browsing some of the existing repos, it appears that the package
repo contains all upstream source files (with the addition of the
debian/ folder), which is different from Fedora (upstream source package
is separate from the .spec and patch*
Thank you for offering to contribute.
Qianqian Fang wrote:
1. is there an established procedure to convert an official Fedora RPM to a deb
package?
Not that I'm aware of. (The package 'alien' can install RPM binary
packages on Debian, but does not convert source packages.)
any best
Control: block 996584 by -1
On 21/11/2021 06:30, Graham Inggs wrote:
It might be easier to upgrade to 1.2.4 first, then 1,3,x later.
Probably not, given that we're now trying to add Python 3.10 support
(#996584), and pandas upstream's work on that is recent (maybe still
unfinished):
I was already planning to try a build+autopkgtest of the reverse
dependencies, and probably an upload to experimental (it's also common
for pandas to fail a few tests on non-amd64), at some point, but not
just yet. (The last time I did this was #969650.)
Thanks for the tools suggestions.
I
Source: pandas
Version: 1.1.5+dfsg-2
Severity: wishlist
On 10/11/2021 17:14, Andreas Tille wrote:
pandas is lagging behind upstream by several versions. I guess we
should try to get in sync with upstream a bit more.
Yes, but please don't upload this yet: it's common for a pandas upgrade
to
After build-testing about half of the reverse dependencies, failures
that look new-pandas-related are cfgrib #1000726, joypy #1000727,
python-skbio #1000752, and maybe hyperspy (not filed yet).
python-skbio and hyperspy already FTBFS for unrelated reasons (but fail
more tests with new
In Debian (only change from -1 should be disabling some tests, i.e. real
pandas-related failures are unlikely):
mdtraj/amd64: upstream tests pass but a warning is printed to stderr,
which autopkgtest counts as a fail
partd/ppc64el: save/load of a plain string fails
snakemake/i386: hang in
pandas has now migrated (on both Debian and Ubuntu).
I have uploaded versions of statsmodels and snakemake that should
(almost always) avoid these test failures, and reported the partd
failure as #1005045.
Thanks. (Please do _not_ immediately upload what I just pushed to
Salsa, it still needs more testing.)
The version of openpyxl currently in Debian is over a year behind
upstream, and this is blocking the pandas 2.x transition. I previously
reported this as #1051233, to no response. (The package has been
uploaded more recently than that, but keeping the same upstream version;
as noted in that
Should this go ahead before the freeze? I think yes if the new dask
works, but am open to disagreement.
Issues this would fix:
python3.11 #1023965: We're currently ignoring these test failures.
Mystery autopkgtest failure (fails without any listed individual test
failure, started
skbio is fixed, ulmo is maybe fixed but untested.
dask is unclear (see #1027254 for details): it looks like it's probably
fixable, but I don't have an actual working fix yet. There has been no
response from its maintainers.
theano has been mostly abandoned upstream since 2018. (The Aesara fork
is not abandoned, but includes interface changes including the import
name, so would break reverse dependencies not specifically altered for it.)
Its reverse dependencies are keras, deepnano and invesalius.
It is
Control: tags 1029701 fixed-upstream
Full log:
https://ci.debian.net/data/autopkgtest/unstable/amd64/s/scikit-learn/30693526/log.gz
There appear to be at least 2 separate failures here, both known and
probably fixed upstream. So yes, 'new upstream version' is the first
thing to try, but
Control: tags -1 fixed-upstream patch
Control: forwarded -1 https://github.com/scipy/scipy/pull/17033
This "broken by numpy 1.24" bug looks to me like 17033, not 17630. This
has what looks like a trivially-backportable patch, though I haven't
actually tried that:
The remaining autopkgtest failures blocking pandas are:
- dipy/amd64 and snakemake/i386 look like random flakiness: please retry
them. (I think DMs can't use the self-service interface.) Or for dipy,
see #1029533 for a possible fix.
- python-xarray/i386 looks like xarray not pandas: see
On 02/03/2023 10:38, Andreas Tille wrote:
I admit I do not see any good reason to stick to the old version if we
decided before that keras/deepnano are no real blockers to even drop
theano. Thus I was considering it more promising to spent my time on
the latest version.
1.1.2 isn't the latest
On 03/03/2023 06:00, Andreas Tille wrote:
Ahh, so aesara is not really a "fork" but a "rename"?
The original is abandoned (no new development since 2017, and now mostly
unmaintained, which is probably why it has this kind of bug). Aesara is
a continuation by a new upstream (possibly one
I agree that switching to Aesara is probably the only reasonable option
other than removal. (I'd given up on trying to fix 1.0, and was
intending to let removal happen.)
However, it's a much bigger change than is normally allowed in bookworm
at this point. (1.1 includes multiple breaking
Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 src:theano src:deepnano src:keras
Control: reopen 1026539
Control: reopen 1027215
theano has been mostly abandoned upstream since 2018. (The Aesara fork
is not abandoned, but includes
Control: severity 1053943 1053939 1053942 1044053 1044056 serious
Control: severity 1044074 1053946 1044078 1044079 1044077 serious
Control: severity 1044071 1044067 1044068 1044055 1044060 serious
Control: severity 1044072 1044073 1044064 1053945 1044054 serious
Control: severity 1044076 1053940
libgpuarray has been de facto abandoned upstream since 2018, and is
currently unused in Debian. (Its original user was theano, which was
removed in #1042574.)
It currently has what may or may not be a wrong-answer bug (#1031414),
and two broken-by-transition bugs. (The latter two _might_ be
I'd like to move forward with the pandas 1.5 -> 2.1 transition
reasonably soon.
Given that pandas 2.x is *not* required for Python 3.12 (but is required
for Cython 3.0), should we wait for the Python 3.12 transition to be
done first?
These are broken by pandas 2.x and have a possible (but
Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove
libgpuarray has been de facto abandoned upstream since 2018, and is
unused in Debian since theano was removed (#1042574).
It currently has what may or may not be a wrong-answer bug (#1031414),
and two
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Please upload openpyxl 3.1.2+dfsg-3 to unstable
(Salsa HEAD = commit ea63a153033c7d6ed426e4931d952d027ce6b855).
This enables the documentation, and places it in a new binary
package because of its size,
which I can't do myself because DMs can't
I intend to upload pandas 2.x to unstable soon. These packages have a
patch in their bug - please upload them (I'm a DM, I can't do that), or
if you think this patch won't work or isn't a good idea, tell me why:
dials influxdb-python python-altair python-feather-format seaborn tqdm
In
79 matches
Mail list logo
