Source: optuna
Version: 3.0.5-1
Severity: serious
Tags: ftbfs
Hi Maintainer
optuna currently Build-Depends on:
python3-scipy (>= 1.7.0), python3-scipy (<< 1.9.0)
but this is unsatisfiable since the upload of scipy 1.10.0 to unstable.
Regards
Graham
Source: nipy
Version: 0.5.0-6
Severity: serious
Tags: ftbfs
Hi Maintainer
While rebuilding nipy for the removal of Python 3.10, it FTBFS [1].
I've copied what I hope is the relevant part of the log below.
Regards
Graham
[1] https://buildd.debian.org/status/package.php?p=nipy
===
Source: python-hypothesis
Version: 6.64.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Recently, the autopkgtests of python-hypothesis regressed in testing
[1]. I've copied what I hope is the relevant part of the log below.
Regards
Graham
[1] https:/
Control: reopen -1
yade 2022.01a-13 seems to fail in the same way
Control: tags -1 + patch
Hi Maintainer
Since setuptools 66.0.0, support for PEP 440 non-conforming versions
has been removed [1].
It appears '1.0a-SNAPSHOT' is not a PEP 440 conforming version, so I
think simply dropping this test scenario is sufficient. Please see
patch below.
Regards
Graham
Control: tags -1 + fixed-upstream patch
Hi Maintainer
Please find attached, a patch that was applied in Ubuntu to address this issue.
Regards
Graham
Description: Fixed URLValidator crash in some edge cases
Origin: upstream, https://github.com/django/django/commit/e8b4feddc34ffe5759ec21da8fa027e8
Hi
On Sun, 23 Jul 2023 at 13:11, Nilesh Patra wrote:
> How do you conclude that?
> The versions of affected packages are same in unstable and testing. They
> fail in i386 with a newer version of lme4.
For what it's worth, r-cran-afex[1] and r-cran-mertools[2] **are**
passing in unstable. So per
Source: pycoast
Version: 1.6.1+dfsg-1
Severity: serious
Tags: ftbfs
Hi Maintainer
As can be seen on reproducible builds [1], pycoast fails to build from
source since the upload of pillow 9.4.0. I've copied what I hope is
the relevant part of the log below.
Regards
Graham
[1] https://tests.rep
Source: cluster3
Version: 1.59+ds-4
Severity: serious
Hi Maintainer
cluster3 is non-free and is not auto-buildable, so requires a manual
rebuild for the Python 3.11 transition. Please upload a build with
Python 3.11 as default, including binaries.
Regards
Graham
Control: reopen -1
Hi Anton
It seems dyssol 1.1.0+ds1-2 still fails in the same way.
Regards
Graham
Source: yade
Version: 2022.01a-13
Severity: serious
Tags: ftbfs patch
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Hi Maintainer
yade FTBFS with Python 3.11 as default version, although the build
doesn't fail, it is mislinked against Python 3.10.
I believe this is the relevant part
Source: libsbml
Version: 5.19.7+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults
Hi Maintainer
The autopkgtests of libsbml fail with Python 3.11 as the default
versio
Source: mailman3
Version: 3.3.7-3
Severity: serious
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults
Hi Maintainer
The autopkgtests of mailman3 fail with Python 3.11 as the default
version (a
Source: mdtraj
Version: 1.9.7-4
Severity: serious
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults
Hi Maintainer
The autopkgtests of mdtraj fail with Python 3.11 as the default
version (and P
Source: python-configshell-fb
Version: 1:1.1.28-2
Severity: serious
Tag: bookworm sid
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults
Hi Maintainer
The autopkgtests of python-configshell-fb
Source: python-glyphsets
Version: 0.5.2-2
Severity: serious
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults
Hi Maintainer
The autopkgtests of python-glyphsets fail with Python 3.11 as the
de
Source: python-stem
Version: 1.8.1-1.1
Severity: serious
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults
Hi Maintainer
The autopkgtests of python-stem fail with Python 3.11 as the default
ve
Source: yoyo
Version: 7.3.2+dfsg1-5
Severity: serious
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults
Hi Maintainer
The autopkgtests of yoyo fail with Python 3.11 as the default version
(and
Control: tags -1 + ftbfs
With #1025658 fixed in boost1.74, the autopkgtest of cctbx now fails as follows:
Testing dxtbx with python3.10:
= test session starts ==
platform linux -- Python 3.10.9, pytest-7.1.2, pluggy-1.0.0+repack
rootdir: /tm
Source: pyobjcryst
Version: 2.2.1-2
Severity: serious
Tags: ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.11 python3-all-dev
Hi Maintainer
This package build-depends on python3-all-dev, but does not build
extensions/libraries for all supported python3 versions. This is seen
on the
Source: psi4
Version: 1:1.3.2+dfsg-3
Severity: serious
Tags: ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Hi Maintainer
Psi4 fails its build-time tests with Python 3.11 as the default
version, although the build doesn't fail outright, probably because of
the following in debian
Control: found -1 0.17.8-1
Now that chardet 5.1.0+dfsg-2 migrated to testing, datalad FTBFS there too.
Source: kamailio
Version: 5.6.2-1
Severity: serious
Tags: ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Hi Maintainer
Kamailio's python extension fails to build with Python 3.11 as the
default version, and kamailio-python3-modules misses
/usr/lib/x86_64-linux-gnu/kamailio/module
Source: dyssol
Version: 1.1.0+ds1-1
Severity: serious
Tags: ftbfs
Hi Maintainer
As can be seen on reproducible builds [1], dyssol 1.1.0+ds1-1 FTBFS
without network access. I've copied what I hope is the relevant part
of the log below.
Regards
Graham
[1] https://tests.reproducible-builds.org/d
Source: renpy
Version: 8.0.2+dfsg-1
Severity: serious
Tags: ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Hi Maintainer
renpy fails to build from source with Python 3.11 as the default
version. I've copied what I hope is the relevant part of the log
below.
Regards
Graham
gen
Source: adonthell
Version: 0.3.8-2
Severity: serious
Tags: ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Hi Maintainer
adonthell fails to build from source with Python 3.11 as the default
version. I've copied what I hope is the relevant part of the log
below.
Regards
Graham
Control: reopen -1
The tests on i386 [1] still fail.
There have been a couple of attempts at closing this bug, perhaps the
i386 porters can help?
[1] https://ci.debian.net/packages/p/python-xarray/unstable/i386/
Source: datalad
Version: 0.17.10-1
Severity: serious
Tags: ftbfs
Hi Maintainer
As can be seen on reproducible builds [1], datalad 0.17.10-1 FTBFS
without network access. I've copied what I hope is the relevant part
of a successful build below.
Regards
Graham
[1] https://tests.reproducible-bui
Source: sundials
Version: 6.4.1+dfsg1-1
Severity: serious
User: debian-ci at lists.debian.org
Usertags: regression
Control: affects -1 src:deal.ii
Hi Maintainer
With the upload of sundials 6.4.1+dfsg1-1, the binary package
libsundials-nvecparallel-mpi4 contains the files:
/usr/lib/x86_64-linux-gn
Hi Drew
>From a comment to upstream issue #456 [1]:
Just as a reference, the commit that solved the problem in upstream is
coin-or/Ipopt@4c36f88 [2]. The GitHub reference in the commit name is
wrong because since then the coin-or/Ipopt repo has been replaced with
the one migrated from trac, and a
Hi Drew
On Sun, 16 Jun 2019 at 10:09, Graham Inggs wrote:
> Just as a reference, the commit that solved the problem in upstream is
> coin-or/Ipopt@4c36f88 [2]. The GitHub reference in the commit name is
> wrong because since then the coin-or/Ipopt repo has been replaced with
> the
Hi Bas, Alastair
On Sat, 13 Jul 2019 at 07:57, Bas Couwenberg wrote:
> The autopkgtest failures for python-xarray are blocking the testing migration
> of netcdf4-python.
>
> Please fix the tests in your package or remove them.
The tests of python-xarray 0.12.1-1 are passing [1].
So I think netcd
On Sat, 13 Jul 2019 at 12:10, Graham Inggs wrote:
> So I think netcdf4-python needs to add a:
>
> Breaks: python-xarray (<< 0.12.1-1)
>
> or so, to ensure the correct versions are tested together.
Actually, a Breaks is not needed since these packages do need to
migrate to
Control: reopen -1
Control: tags -1 + patch
Hi Andreas
Your patch fixed the autopkgtest on amd64 and armhf, but now it fails
on i386, arm64, ppc64el and s390x.
Instead of a patch, how about simply filtering the offending line from
the saved results, as below?
If you agree, I'll upload with this
Source: pyresample
Version: 1.12.3-2
Severity: serious
Tags: bullseye
Hi Maintainer
As can be seen on reproducible builders [1], pyresample FTBFS in
bullseye because it Build-Depends on python-xarray which is no longer
available. Unfortunately, britney does not take into consideration
Build-Depe
Hi Laurent
On Sat, 20 Jul 2019 at 14:42, Laurent Bigonville wrote:
> If nobody has any plans to work on this, I'll request to remove the
> package from the archive then? Any objections about this?
Last I read, upstream is still working on this.
Does not removing the package now cause any proble
Control: severity -1 important
Downgrading severity, since the autopkgtests now pass in unstable [1],
to avoid autoremoval warnings in several other packages.
[1] https://ci.debian.net/packages/r/r-bioc-biocparallel/unstable/amd64/
Control: severity -1 important
Downgrading severity, since the autopkgtests now pass in unstable [1],
to avoid autoremoval warnings in several other packages.
[1] https://ci.debian.net/packages/r/r-cran-etm/unstable/amd64/
Control: reopen -1
This does not appear to be fixed, see reproducible builds [1] and
autokpkgtest [2] failures.
[1] https://tests.reproducible-builds.org/debian/history/amd64/satpy.html
[2] https://ci.debian.net/packages/s/satpy/unstable/amd64/
Source: r-cran-boolnet
Version: 2.1.5-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Since the upload of 2.1.5-1, r-cran-boolnet has been failings its own
autopkgtests [1] with the following error:
> Stangle("Boo
Source: r-cran-ggplot2
Version: 3.2.0+dfsg-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Since the upload of 3.2.0+dfsg-1, r-cran-ggplot2 has been failings its
own autopkgtests [1] with the following error:
> libr
Source: r-cran-fs
Version: 1.3.1+dfsg-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Since the upload of 1.3.1+dfsg-1, r-cran-fs has been failing its own
autopkgtests [1] with the following error:
+ test_check("r
Control: tags -1 + patch
The patch below got the test passing in Ubuntu.
--- a/debian/tests/run-unit-test
+++ b/debian/tests/run-unit-test
@@ -10,7 +10,7 @@
cp /usr/share/doc/$pkg/examples/vignettes/* $ADTTMP
find . -name "*.gz" -exec gunzip \{\} \;
for rnw in `ls *.[rRS]nw` ; do
-rfile=`echo
Hi Andreas
On 2019/08/11 23:02, Andreas Tille wrote:
Can you please simply do team uploads if you found a patch.
I'm busy with real life for the next 10 days.
Sure, I filed the bug because I wasn't sure **why** this change was
necessary, and thought it needed further investigation.
Looking
Source: python-fabio
Version: 0.11.0+dfsg-2
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: needs-update
Hi Maintainer
Sometime around 2021-04-28, python-fabio's autopkgtests started to
fail in testing [1].
I've copied what I hope is the relev
Source: node-millstone
Version: 0.6.19-3
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: needs-update
Hi Maintainer
Sometime around 2021-04-21, node-millstone's autopkgtests started to
fail in testing [1].
I've copied what I hope is the releva
Control: forwarded -1 https://sourceforge.net/p/mcj/tickets/120/
Control: tags -1 + patch
This was reported upstream by Michael Hudson-Doyle .
Source: lintian-brush
Version: 0.99
Severity: serious
Tags: ftbfs
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: needs-update
Hi Maintainer
Sometime between 2021-03-30 and 2021-04-06, lintian-brush's
autopkgtests started to fail in testing [1]. I've copied wh
Source: libyang
Version: 1.0.184-2
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
The autopkgtest of libyang fails in testing where it succeeded in the past [1].
The current failure seems to be due python3-yang being
Control: affects -1 src:python-biopython
On Tue, 14 Apr 2020 at 17:39, Andreas Tille wrote:
> Control: reassign -1 clustalo
> Control: retitle -1 "clustalo: Bus error on mipsel"
> Control: tags -1 upstream
> Control: forwarded -1 clust...@ucd.ie
Marking this bug as affecting src:python-biopython
Source: btfs
Version: 2.20-1
Severity: serious
Tags: ftbfs bullseye sid
Hi Maintainer
A recent rebuild of btfs against libtorrent-rasterbar10 FTBFS on
release architectures armel and mipsel, among others [1].
I've included what I hope is the relevant part of the log below.
I believe the solutio
Control: tags -1 + fixed-upstream
Hi Tobias
On Wed, 29 Apr 2020 at 21:39, Tobias Frost wrote:
> I've prepared an NMU for deal.ii (versioned as 9.1.1-9.1) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer.
Mattias Maier pointed out this is already fixed up
Source: freefem++
Version: 3.61.1+dfsg1-5
Severity: serious
Tags: ftbfs bullseye sid
Hi Maintainer
In a recent rebuild for the gsl 2.6 transition, freefem++ FTBFS on all
architectures.
I 've copied what I hope is the relevant part of the log below.
Regards
Graham
[1] https://buildd.debian.org/
Source: libmath-gsl-perl
Version: 0.40-1
Severity: serious
Tags: ftbfs bullseye sid
Hi Maintainer
In a recent rebuild for the gsl 2.6 transition, libmath-gsl-perl FTBFS
on all architectures [1].
I've copied what I hope is the relevant part of the log below.
Regards
Graham
[1] https://buildd.de
Source: sagetex
Version: 3.4+ds-1
Severity: serious
Tags: ftbfs
Hi Maintainer
Sagetex currently FTBFS in unstable [1].
I've copied what I hope is the relevant part of the log below.
Regards
Graham
[1]
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/sagetex.html
kpathsea:
Source: lammps
Version: 20200303+dfsg1-2
Severity: serious
Tags: ftbfs bullseye sid
Hi Maintainer
The recent upload of lammps FTBFS in bullseye and sid [1].
I've copied what I hope is the relevant part of the log below.
Regards
Graham
[1]
https://tests.reproducible-builds.org/debian/rb-pkg/un
Source: giac
Version: 1.5.0.87+dfsg1-1
Severity: serious
Tags: ftbfs bullseye sid
Hi Maintainer
d-workaround-armhf-hang.patch was recently dropped [1], however, as
can be seen on buildds [2] and reproducibles builds [3], that giac
still FTBFS on armhf with:
E: Build killed with signal TERM after
Source: freecad
Version: 0.18.4+dfsg2-2
Tags: patch
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Freecad fails its autopkgtests with opencascade 7.4 [1]:
testTaperedHole (PartDesignTests.TestHole.TestHole) ... FAIL
Source: r-cran-treescape
Version: 1.10.18+dfsg-1
Severity: serious
Tags: ftbfs bullseye sid
Hi Maintainer
In the recent rebuild for r-api4.0, r-cran-treescape FTBFS on ppc64el [1].
I've copied what I hope is the relevant part of the log below.
Upstream's homepage has a note:
Package ‘treescape’
> This was fixed in an upload done slightly before the bug was filed, though
> with
> a different patch; I'll probably replace it with this one in a subsequent
> upload.
Great, thank you! Would you like a merge request, or I could even
push directly to salsa, if you prefer?
Source: osmcoastline
Version: 2.2.4-2
Severity: serious
Tags: ftbfs bullseye sid
Hi Maintainer
As per Reproducible Builds [1], osmcoastline FTBFS in bullseye and sid.
I've copied what I hope is the relevant part of the log below.
Regards
Graham
[1] https://tests.reproducible-builds.org/debian/
HI Nilesh
On Thu, 24 Dec 2020 at 10:48, Nilesh wrote:
>
> I can't seem to reproduce this, can you initiate a rebuild for this?
>
> I suspect if new apertium upload fixed this somehow. Attaching the log in any
> case.
Reproducible builds [1] shows apertium-kaz-tat is currently building
successfu
Source: python-cobra
Version: 0.19.0-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
The autopkgtests of python-cobra recently started to fail in testing [1].
I've copied what I hope is the relevan
Source: pmix
Version: 4.0.0~rc1-1
Severity: serious
Tags: ftbfs
Control: affects -1 + src:deal.ii
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks
Hi Maintainer
The upload of pmix 4.0.0~rc1-1 to unstable causes the autopkgtests of
openmpi in testing to fa
Control: reopen -1
Hi Jonas
The build of link-grammar/5.8.0-3 has already failed on ppc64el [1]
(details below).
As fun as it is, please let's avoid the BTS sports and leave this bug
open until link-grammar builds and passes its autopkgtests reliably.
Regards
Graham
[1]
https://buildd.debian
Control: reopen -1
pmix/4.0.0~rc1-2 from unstable still causes the autopkgtests of
openmpi 4.0.5-7 in testing to fail [1], see for example:
4.0.5-7 2020-12-29 13:13:26 UTC pmix/4.0.0~rc1-2 src:pmix from
unstable 2m 14s fail britney test log (9.92 KB) artifacts (3.17
KB)
Does libpmix2 n
Source: mpi4py
Version: 3.0.3-7
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
Tags: bullseye sid
User: debian...@lists.debian.org
Usertags: needs-update
Hi Maintainer
The autopkgtests of mpi4py have been failing since the upload of
openmpi 4.1.0-1 to unstable. I'm reporting this for
Control: reopen -1
pmix/4.0.0-2 from unstable still causes the autopkgtests of openmpi
4.0.5-7 in testing to fail
If it is not intended that this combination should work together,
please add Breaks: libopenmpi3 (<< 4.1.0-3) or similar to libpmix2.
Source: r-bioc-shortread
Version: 1.48.0-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
Tags: bullseye sid
User: debian...@lists.debian.org
Usertags: needs-update
Hi Maintainer
The autopkgtests of r-bioc-shortread are failing in testing and unstable [1].
I've copied what I hope is
Source: r-cran-dbplyr
Version: 2.0.0-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
Control: block 980011 by -1
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Since the upload of 2.0.0-1, r-cran-dbplyr has been failing its own
autopkgtests.
This prevents its mi
Source: libextractor
Version: 1:1.10-2
Severity: serious
Tags: ftbfs
Hi Maintainer
During a recent rebuild against librpm9, libextractor FTBFS on several
architectures where it built previously [1].
I've copied what I hope is the relevant part of the log below.
Regards
Graham
[1] https://buil
Control: reopen -1
libucx0 1.10.0~rc1-4 still has a dependency on libbinutils.
It seems you have a typo:
--disable-backtrace-details
instead of
--disable-backtrace-detail
Please also remove the Build-Depends on binutils-dev.
Control: reopen -1
Still failing [1], see e.g.
4.0.5-72021-01-18 01:04:56 UTC pmix/4.0.0-3 src:pmix from unstable
1m 46s fail britney test log (10.4 KB) artifacts (3.18 KB)
[1] https://ci.debian.net/packages/o/openmpi/testing/amd64/
Source: ucx
Version: 1.10.0~rc1-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks
Hi Maintainer
The upload of ucx/1.10.0~rc1-1 to unstable causes the autopkgtests of
openmpi/4.0.5-7 in testing to fail [1]. I've copied what I hope is th
Control: retitle -1 libextractor: FTBFS (flaky tests)
It turns out these are just flaky tests.
Giving back the failed builds eventually resulted in success.
Reproducible builds [1] shows a history of failures in bullseye and
unstable, across all architectures.
[1] https://tests.reproducible-bu
Control: severity -1 normal
Llvmlite has switched back to using LLVM 9 in 0.35.0-2.
Lowering severity, but leaving this bug open for switching to LLVM 11.
Hi Alastair
On Wed, 20 Jan 2021 at 16:44, Alastair McKinstry
wrote:
> Can these bugs be closed ?
Not until they are fixed.
> pmix tests are failing because of an openmpi bug , but its no longer due
> to pmix.
>
> Ditto, ucx errors that caused the failure are fixed in openmpi-4.1.0-6.
ucx 1.10.
Source: r-bioc-geoquery
Version: 2.58.0+dfsg-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky
Hi Maintainer
The autopkgtests of r-bioc-geoquery seem to download large amounts of
test data from the internet, and these
Hi Andreas
On Thu, 21 Jan 2021 at 11:19, Andreas Tille wrote:
> so what is you suggestion? Simply droping the test is possibly
> not the best solution. Marking it flaky comes to mind. What
> do you think?
If it were my package, I would probably drop the tests that download
from the internet,
Source: petsc
Version: 3.14.3+dfsg1-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks
Control: affects -1 deal.ii dolfin meshr slepc4py
Hi Maintainer
The recent upload of petsc 3.14.3+dfsg1-1 appears to have caused the
autopkgtests of a
Might be fixed by binNMU of slepc, see #980749.
Control: severity -1 important
Indeed, these autopkgtests were fixed by the binNMU of slepc.
Lowering severity so openmpi and petsc can migrate, but we need to
figure out what happened here so we can prevent it in future.
Does slepc need a tighter dependency on the version of slepc that it
was b
Source: rmatrix, r-cran-glmmtmb
Control: found -1 rmatrix/1.3-0-1
Control: found -1 r-cran-glmmtmb/1.0.2.1-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update
Hi Maintainers
The upload of rmatrix/1.3-0-1 ca
While investigating this failure, I noticed the following output in
the test log:
> library('glmmTMB')
Warning message:
In checkMatrixPackageVersion() : Package version inconsistency detected.
TMB was built with Matrix version 1.2.18
Current Matrix version is 1.3.2
Please re-install 'TMB' from so
Hi Dirk
On Fri, 22 Jan 2021 at 22:39, Dirk Eddelbuettel wrote:
> Matrix 1.3.0 from December has long been known to fail. Please use release
> 1.3.2.
The test at [2], run at 2021-01-22 17:34:51 UTC was against
r-cran-matrix/1.3-2-1, see below:
Get:61 http://deb.debian.org/debian testing/main s
Hi Dirk
On Fri, 22 Jan 2021 at 23:38, Dirk Eddelbuettel wrote:
> Can you still please talk to the corresponding Debian maintainer for glmmTMB
> so that he/she can walk it upstream?
I have assigned this bug to both packages, until we can figure out
where the fix needs to happen.
> The package is
Hi Martin
On Wed, 17 Feb 2021 at 11:45, Martin Maechler wrote:
> 1) I think I might simply disable the check *on* that platform .. or
> platforms with similar characteristics.
I was able to reproduce the issue on our big-endian PowerPC
architecture as well, so maybe you can use the following i
Hi Dirk
On Wed, 17 Feb 2021 at 15:10, Dirk Eddelbuettel wrote:
> Graham: What does that bigendian box say for Sys.info()[["machine"]] ?
The other big-endian box I tested was perotto.debian.net [*], it says:
> Sys.info()[["machine"]]
[1] "ppc64"
> Should we test for endianness instead? An
Source: r-bioc-plotly
Version: 4.9.3+dfsg-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Since the upload of 4.9.3+dfsg-1, r-cran-ploty has been failing its
own autopkgtests [1] with the output be
Control: reassign -1 src:rmatrix 1.3-0-1
Control: tags -1 - fixed-upstream
Control: forwarded -1 https://github.com/kaskr/adcomp/issues/340
Hi Dirk
On Thu, 18 Feb 2021 at 19:58, Dirk Eddelbuettel wrote:
> Thanks for the bug tracker follow-up which made me aware of the ongoing
> discussion in #6
Control: affects -1 src:r-cran-glmmtmb
Control: affects -1 src:r-cran-tmb
Hi Andreas
On Tue, 23 Feb 2021 at 10:30, Andreas Tille wrote:
> If we do not find a timely solution what do you think about excluding
> s390x temporarily from the list of architectures of this package and set
> this bug to
Hi Dirk
On Tue, 23 Feb 2021 at 15:34, Dirk Eddelbuettel wrote:
> If it were me I would turn off the autopkgtest in r-cran-glmmtmb (maybe just
> on s390x) and move on.
That would just be hiding the problem.
If it is the kind of bug I described previously, it shows up more
often on big-endian sys
Hi
On Mon, 15 Feb 2021 at 10:07, Matthias Klose wrote:
> On 2/14/21 5:58 PM, Simon McVittie wrote:
>> Obviously, the transitional packages would ideally be built by src:gcc-10
>> rather than being a separate source package, and Ryan only prototyped them
>> as a separate source package to be able
Source: dh-r
Version: 20210218
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: issue
Hi Maintainer
The recent upload of dh-r causes autopkgtests using pkg-r-autopkgtest
to fail. See for example the output of r-bioc-affy [1
Hi Andreas
On Mon, 1 Mar 2021 at 10:49, Andreas Tille wrote:
> However, the issue should have been become obvious even in unstable
> 10 days ago.
Well, it was visible in unstable, e.g. in r-bioc-destiny [1], and also
on the tracker page [2] it says "Debci reports failed tests", but
certainly not
Control: reopen -1
Hi Andreas
This didn't work [1]. You need root in order to run 'apt-get install':
E: No packages found
E: Could not open lock file /var/lib/dpkg/lock-frontend - open (13:
Permission denied)
E: Unable to acquire the dpkg frontend lock
(/var/lib/dpkg/lock-frontend), are you roo
Hi Andreas
On Wed, 3 Mar 2021 at 12:12, Andreas Tille wrote:
> My motivation for the change was that for
> example in r-bioc-mutationalpatterns (see bug #983027) the
> autopkgtest-pkg-r script failed to install all needed packages
> to run its test. This was not the only package that was affecte
Hi Andreas
On Thu, 4 Mar 2021 at 15:09, Andreas Tille wrote:
>https://ci.debian.net/packages/r/r-bioc-mutationalpatterns/
>
> I discussed several times with Paul Gevers about this view. I consider
> it not helpful to print test results of very outdated versions for
> unstable (even older the
Hi Andreas
On Thu, 4 Mar 2021 at 16:57, Andreas Tille wrote:
> I fail to understand this. Before version 3.0.1+dfsg-1 has migrated to
> testing tests of this version were done in unstable, right?
No, the tests that britney schedules for migration are run in testing,
and usually only the package
Hi Dirk
Is there a bug opened for this issue with Matrix upstream?
I may have some useful feedback from TMB upstream to add.
Regards
Graham
101 - 200 of 1310 matches
Mail list logo
