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
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.
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
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal
theano 1.0.5+dfsg-3 is currently held in unstable for an autopkgtest
"regression" on armhf.
The test in question (smoketestgpu) is currently skipped in plain
testing because it depends
Cyril Brulebois wrote:
getting my hands on relevant hardware is in progress
Note that https://lists.debian.org/debian-boot/2021/04/msg00247.html
implies the affected hardware is _not_ simply "all AMD/ATI or NVidia
hardware". Do we know of hardware that is reproducibly affected?
YunQiang
hypercorn is arch:all, and their build-dependencies aren't checked:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=145257
The (libjs-)jquery and node-jquery packages used to be separate source
packages. #940975 merged them into one source package with two
binaries, but does not appear to change either binary's functionality
(other than upgrading from 3.3.1/3.4.0 to 3.5.1).
However, the transition tracker
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
On 22/11/2019 17:06, Graham Inggs wrote:
I scheduled statsmodels there, but it
still fails.
The error message points to joblib, which has just been uploaded
(#942899): try again when the new version is available?
The binNMUs (to add python3.8 support) of pandas and statsmodels failed.
I think this will make them work (but haven't tried it):
- Apply the (existing) #943418 fix to python-xlrd.
- Build matplotlib, pandas and statsmodels in that order. (ben can't
work this out because the declared
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
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
Matthias Klose wrote:
yes, please do [raise pandas 0.25 blocking bugs to "important"]
Done, but only 2 of them have been fixed since.
This leaves 13:
has patch or Ubuntu fix: matplotlib2 patsy python-apptools scikit-learn
may need more extensive work: cnvkit python-feather-format python-skbio
Detailed discussion of pandas has moved to #931557 / debian-science.
Summary:
- python-pandas removal looks feasible, but there is one item that needs
ftpmaster or release team authorization: either let pypubsub out of NEW
(preferred), or give us permission to break tnseq-transit.
- 0.23 ->
On 26/10/2019 22:50, Matthias Klose wrote:
Ubuntu already dropped python-pandas, I wasn't involved with that.
This seems to have been done by the "let things break" approach that
isn't allowed in Debian, e.g. they can no longer build python-matplotlib:
What should be done with modules where Python 3.8 compatibility requires
moving to a new upstream release that doesn't support Python 2, but the
Python 2 package still has dependencies (so can't be removed yet under
existing rules)?
- Split them into two source packages with different
Chris Lamb wrote:> Just to take one recent example: I noticed yesterday
a regression
whereby one of our tools (strip-nondeterminism) is causing a fair
number of Java packages to be unreproducible — it would seem a little
antisocial to block them from migrating to testing when it was "our"
fault.
On 06/03/2019 07:19, Niels Thykier wrote:
[...]
[... Quote from elbrus ...]> Does "installed" imply "built"? Due to the above
bug, statsmodels
won't be buildable until pandas is fixed.
Yes and yes.
However, there would still have been alternative solutions where
statsmodels issue could
Control: tags -1 - moreinfo
Built on every release architecture, autopkgtest good.
As discussed, please also give back statsmodels, as the new pandas
should allow it to build.
07)
+ * Revert "Add documentation examples dependencies" to comply with
+ freeze policy.
+
+ -- Rebecca N. Palmer Mon, 04 Mar 2019
21:59:43 +
+
pandas (0.23.3+dfsg-2) unstable; urgency=medium
* Team upload.
diff --git a/debian/control b/debian/control
index e36eca515..a7b429d
(Not release team)
Iain Lane wrote:
I should have uploaded this with a higher urgency probably
That wouldn't have done anything: urgencies have been ignored since soft
freeze.
some quite nice
fixes
Are any of them Important or higher?
On 05/03/2019 06:32, Niels Thykier wrote:
Hi Rebecca,
I realise that the answer now is probably less relevant as your enquiry
had a deadline that has now passed.
Rebecca N. Palmer:
i.e. are we effectively frozen (due to 10 day testing migration) now?
At the time you wrote[Sat, 2 Mar
i.e. are we effectively frozen (due to 10 day testing migration) now?
I uploaded two new-to-me packages last night, in a hurry after "fix some
d/copyright lintian errors" became "notice that d/copyright is 5 years
out of date and that the package contains apparent[0] copyright
violations".
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
I have just been given permission to take over libgpuarray.
I would like to update it from 0.6.9 to 0.7.6, which bumps SONAME from 2
to 3 and is described by upstream as including API
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
(or should this be 'nmu'?)
The Clang resource directory (clang --print-resource-dir) changes every
upstream *bugfix* release (e.g. /usr/lib/llvm-6.0/lib/clang/6.0.1/ ),
but clang's
Vincent Bernat wrote:
WebExtensions are backed by a standard draft:
https://browserext.github.io/browserext/. So, situation is expected to
improve in the future.
Mozilla have explicitly said that "Extensions created with the new
standard[...]won’t break in new Firefox releases." [0]
It has
The formal transition process rarely seems to be used for cases that
don't require binNMUs. Given this, what is supposed to happen when an
interpreted-language module changes its API, and hence potentially
breaks its reverse dependencies?
The case I have in mind is #893360 (which makes it an
+0100
+++ beignet-1.3.0/debian/changelog 2017-05-25 19:51:36.0 +0100
@@ -1,3 +1,9 @@
+beignet (1.3.0-4) unstable; urgency=medium
+
+ * Install OpenCL 2.0 libraries. (Closes: #863300)
+
+ -- Rebecca N. Palmer <rebecca_pal...@zoho.com> Thu, 25 May 2017 19:50:07
+0100
+
beignet (1
-1,3 +1,10 @@
+beignet (1.3.0-3) unstable; urgency=medium
+
+ * Fix "Exec...-5" error on older hardware. (Closes: #860805)
+ * Use LLVM 3.8 on x32 to fix FTBFS.
+
+ -- Rebecca N. Palmer <rebecca_pal...@zoho.com> Tue, 02 May 2017
23:23:11 +0100
+
beignet (1.3.0-2) unstable; urgency=me
Upstream status update:
- The patch is probably better than disabling softpin, but neither is
perfect; in particular, there is now a report of *silently wrong
results* (it's now yet clear with which), which means a partial fix
*may* be worse than nothing.
- We now have a test case for the
(workaround for #852746).
+ * Disable OpenCL 2.0 on i386, as it is likely to crash.
+(Closes: #855651)
+ * Add missing build-dependencies on x32 to fix FTBFS.
+ * Fix broken link in documentation.
+
+ -- Rebecca N. Palmer <rebecca_pal...@zoho.com> Tue, 21 Feb 2017 22:45:18
+
+
b
As you can see in the headers of the mail, the autoremoval warnings
are sent by the release team not the QA infrastructure.
That script looks like it gets version and bug information in one fetch
from UDD
Would it be possible/reasonable (at least for stretch) to have the
installer detect this and ask "your hardware appears to be too new for
this release, would you like to enable -backports?"
On 04/07/16 23:38, Ben Hutchings wrote:
As I understand it, xserver-xorg-video-modesetting should be
- - beignet builds fine with llvm-3.6, but needs a sourceful upload
because of hardcoded dependencies on control file
That's there because, while it builds and mostly works with 3.6, this at
least used to sometimes hit a bug:
http://www.freedesktop.org/wiki/Software/Beignet/
As I do not have
Forwarded Message
Subject: Re: Bug#799322: pocl: FTBFS: (gcc5 related?) symbols mismatches
+ test failures
Date: Thu, 17 Sep 2015 23:23:44 +0200
From: Vincent Danjean <vdanjean...@free.fr>
To: Rebecca N. Palmer <rebecca_pal...@zoho.com>, 799...@bugs.debian.org
L
New gcc5 transition notices are still being sent out with the "Such a
change can be avoided, if you have a soversion bump and you upload this
version instead of the renamed package" wording (e.g. simgear
https://bugs.debian.org/797944 ); is this a mistake, or is hdf5 special
because it has
That probably
means changing the libgdal binary package name
to e.g. libgdal1a; see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712688#10 and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731261#30 for previous
examples.
--
To UNSUBSCRIBE, email to
I'm not aware of any that do, but haven't specifically looked.
I now have: as far as I can tell, no Nasal scripts are currently writing
to /tmp, and given that upstream also support Windows, they would
probably consider doing so to be a bug. I'll suggest removing this
upstream, but currently
Symlinks are followed, but I don't think Nasal can create symlinks (and
if it could, I agree we'd have a bigger problem).
I'm assuming that there's no good reason for anyone ever to be running
flightgear in a privileged context
Agreed: that's one reason I have a 'create an unprivileged user'
On 18/03/15 21:32, Markus Wanner wrote:
On 03/18/2015 09:09 PM, Adam D. Barratt wrote:
++write_allowed_paths.push_back(/tmp/*.xml);
Is that really intended? (Both the hardcoding of /tmp/ rather than using
something respecting TMPDIR and being allowed to write any .xml
there.)
It
If you don't want a (permanent) epoch, there's also the option of
calling it 3.4.13.really.3.4.11-1 or similar (see #767961).
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
18:56:35.0 +
@@ -1,3 +1,25 @@
+beignet (0.9.3~really.0.8+dfsg-1) unstable; urgency=medium
+
+ [ Andreas Beckmann ]
+ * Set Maintainer to Debian OpenCL Maintainers with Simon's permission.
+ * Add Simon Richter, Rebecca N. Palmer and myself to Uploaders.
+ * Repack upstream tarball
I didn't look at the details of the patch for #768090, but the bug log
suggests that there are remaining failures. Is that still the case with this
patch?
Assuming you mean
The remaining test failures are:
-cospi/sinpi/tanpi, powr/pown/pow, tgamma are less accurate than the
OpenCL spec
, update versioned-llvm-tools.patch.
+(Closes: #764930)
+ * Replace broken pow(n), rootn, erf(c), tgamma. (Closes: #768090)
+ * Document in the description what hardware this supports.
+
+ -- Rebecca N. Palmer rebecca_pal...@zoho.com Wed, 12 Nov 2014 12:34:41
+
+
+beignet (0.9.3~dfsg-1
However, I'm now tracking that [Alioth] git
repo (I was only pushing to my github.com repo for packaging chagnes)
but can't seem to push into it.
Have you registered your SSH key on Alioth? If so,
git push
ssh://mcpierce-gu...@anonscm.debian.org/git/pkg-middleware/qpid-proton.git
--
To
Please unblock package beignet
That's already been requested and declined in #767961: we are already
too late for 0.9.3 in jessie, we need to decide whether 0.8 in jessie +
1.0 (expected soon) in jessie-backports is better or worse than just 1.0
in jessie-backports.
Backporting the relevant
I haven't looked in enough detail [yet] to see if those rdepends need
binNMUing, and I don't know if there's a clear-cut way to determine
codesearch.debian.net says remove(Update|Event|Cull)Callback (the
affected methods) are only called from simgear (done), osgearth, and one
of the OSG
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
Severity: normal
X-Debbugs-CC: pkg-fgfs-c...@lists.alioth.debian.org
openscenegraph 3.2.1-5 fixed crash bug #765855, but as the fix is in an
inline method, a rebuild of simgear is needed to pick it up.
openscenegraph is now in testing, flightgear and fgrun successfully
built everywhere; should this bug now be closed?
Upstream talk of openscenegraph 3.2.1 has died down again, but uploading
the fixed ossim would still be a good idea.
--
To UNSUBSCRIBE, email to
We have fixed versions of flightgear and fgrun, and I expect (but can't
promise, I'm not the maintainer) that they will be uploaded soon.
If you want to remove libopenscenegraph80 and end this now, go ahead,
it's uninstallable anyway (but note that a previous request (#737676)
was rejected).
Perhaps Alberto or Rebecca (who follow upstream mailing lists) have
better guesses about the current state of mind of upstream.
They recently released 3.2.1rc2, and said the release date of 3.2.1
final would depend on the test results from that; they did not give an
estimate.
Also, for the
The choreonoid maintainer has agreed to my fix.
(This starts to be offtopic, so perhaps would be better to stop
discussing it in the bug report).
Where would you suggest: #718381 (the openwalnut breakage) or a new
wishlist bug against openscenegraph?
I don't understand why this would not be
The tracker is now working again.
decrufting openscenegraph
will have to wait until we have fixed all the packages that we can.
That means choreonoid needs to be fixed; the patch is in #735891.
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe.
The state of openscenegraph itself isn't the problem here: what we're
waiting for is for simgear to clear NEW and for Release Team to give
official permission (britney hint??) to ignore openwalnut for now.
There is the separate question of whether you want an ~rc in an Ubuntu
LTS (14.04
Not being sure whether to go to 3.2.0rc, 3.2.0 final or wait for the
(indefinitely delayed) 3.2.1 is what has already made this drag on for
months.
[3.2.1] should be binary compatible. (And their current 3.2
branch still has a SOVERSION of 100.)
3.2.1 bumps the OpenThreads soversion to 20,
The updated libcitygml package is not uploaded yet,
It was NMUd about a week ago, fixing the FTBFS bug, but I don't know if
all your planned changes were included. (By OK I meant OK for
transition, ie built against latest openscenegraph and no RC bugs.)
Making unrelated changes to
Control: reopen -1
(This may or may not be called a transition, but certainly isn't fixed.)
Current status (note that the tracker isn't currently being updated):
osgearth: OK
simgear/flightgear/fgrun: Fixed simgear uploaded (but is a new upstream
version, so has to go through the NEW queue),
choreonoid and ossim turned out to also FTBFS (for
non-openscenegraph-related reasons); I have posted a patch for
choreonoid (#735891), and suggested that ossim (#735814) move to the
already-fixed version in the UbuntuGIS PPA.
this no longer blocks anything else or needs to be handled
as a
This problem would be noticed before upload if the maintainer used a
clean chroot to (try to) build the package, and I get the impression
that this is recommended, but the Developers' Reference and New
Maintainers' Guide don't actually say so.
Upstream have now said they are waiting for more reports of whether
3.2.1 works before releasing it (their original request for such got
only one response), and that a release can happen quickly if they get
them:
We decided that we would wait a bit to see if the last -rc became
final, to avoid unneeded breakages/binNMUs, etc. in the case that they
changed the ABI or even API again. This was also partially motivated
because of the breakage in alioth which happened around that time.
I don't know if
On 12/11/13 20:59, Manuel A. Fernandez Montecelo wrote:
We will discuss it and come up with a plan.
Did you decide anything? As the libav transition has now been
completed, this bug makes openscenegraph uninstallable.
If the problem is that you are busy elsewhere, would you be happy with
Sorry for not notifying you earlier; given the names on the git commits,
I thought Alberto was effectively the maintainer and you his sponsor.
Would you like to set up a maintainer-team mailing list to avoid such
problems in future? Are you still looking for help (#392266), and if so
with
That's why I'm not so
keen on uploading a RC again, given the grief that caused the last one.
Maybe we can just patch 3.2.0 and then wait for the 3.2.1,
If you mean real 3.2.0 as opposed to the current 3.2.0rc, that could be
a good compromise: it has soname 100 (so no need for binNMUs when
As several packages have already been built against libopenscenegraph99,
and at least ossim depends only on the libopenthreads(13|14|15) part of
openscenegraph, those also need to be included:
title = openscenegraph;
is_affected = .build-depends ~ /libopenscenegraph-dev/;
is_bad = .depends ~
The spek test crash (#725385, s390x) happens inside libav, and the
yorick-av test crash (#722610, armhf) occurs on dereferencing a pointer
that should come from libav; it is hence possible that these are fixed
by the new (9.10) libav. Can someone try that?
--
To UNSUBSCRIBE, email to
Is there a tracker for the OpenSceneGraph 3.2 transition (tied to this
one by #720816)? Status as far as I can find:
libcitygml, choreonoid, ossim, simgear (sid only), flightgear (sid only)
_probably_ just need a rebuild (the libcitygml and choreonoid build
failures should go away when non-rc1
It doesn't look to me that a transition was coordinated for openscenegraph?
Exactly my point: it's a transition in the sense of API-breaking
change, but not one with an official tracker.
(possibly temporary) [openscenegraph] build issue on mips,
That *is* #720816 (and hence should go away in
Is there a libav 9 porting guide available somewhere?
The 0.8 deprecated (= 9 removed) list
(http://libav.org/doxygen/release/0.8/deprecated.html) has suggested
replacements for most of them.
PixelFormat is now AVPixelFormat, and its entries are similarly renamed:
69 matches
Mail list logo
