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
Control: forwarded -1 https://sourceforge.net/p/mcj/tickets/120/
Control: tags -1 + patch
This was reported upstream by Michael Hudson-Doyle .
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
Hi Ole
On Thu, 6 May 2021 at 14:13, Ole Streicher wrote:
> You are right, however it should be ensured to migrate before Bullseye,
> as it downgrades an RC bug. This is not directly visible, since I
> downgraded the bug already after the upload.
>
> --> if you plan to release before May 24, the m
Control: severity -1 serious
This same issue prevents lmfit-py/1.0.1-5 from migrating to testing.
Issues preventing migration:
blocked by freeze: autopkgtest not fully successful
I'll make a team upload shortly, disabling test_model_nan_policy and
test_manypeaks_speed during the build and autopk
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package htop
[ Reason ]
Fix a division by zero in ZfsCompressedArcMeter
[ Impact ]
Users of ZFS-on-Linux, with ZfsCompressedArcMeter enabled in htop, but
no ZFS volumes moun
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
Control: tags -1 + moreinfo confirmed
Hi Ryan
On Mon, 26 Apr 2021 at 06:24, Ryan Tandy wrote:
> I would like to upload mgba with the following changes:
>
> - fix undefined references in libretro-mgba (breaks using it with
> gnome-games-app; RC bug #986986);
> - backport some targeted fixes spe
Source: sift
Version: 4.0.3b-6
Severity: important
Hi Maintainer
This package has 'XS-Autobuild: yes' in debian/control[1], yet it does
not seem to autobuild.
Was step 3 from `Marking non-free packages as auto-buildable`[2] omitted?
Regards
Graham
[1] https://salsa.debian.org/med-team/sift/-/b
Hi Andreas
On Fri, 16 Apr 2021 at 11:12, Andreas Beckmann wrote:
> nmu tcpreplay_4.3.3-2 . ANY . unstable . -m "Rebuild to update symbol size
> for pcap_version."
> nmu ipband_0.8.1-5.1 . ANY . unstable . -m "Rebuild to update symbol size for
> pcap_version."
> nmu mpqc3_0.0~git20170114-4.1 . A
Control: retitle -1 [pre-approval] unblock: gutenprint/5.3.3-5
Control: tags -1 + moreinfo + confirmed
Hi Didier
On Sat, 24 Apr 2021 at 17:48, Didier 'OdyX' Raboud wrote:
> This is a pre-approval request for package package gutenprint.
Please go ahead and upload, and remove the moreinfo tag onc
Control: retitle -1 unblock: ircii/20210314-1
Contro: tags -1 + moreinfo
Hi Jan
On Sat, 24 Apr 2021 at 16:21, Jan Wagner wrote:
> [ Risks ]
> While the diffstat looks huge, a significant part is removed code.
This debdiff is unreviewable. Please provide a filtered debdiff along
with the comman
Control: tags -1 + moreinfo confirmed
Hi Andrej
On Fri, 23 Apr 2021 at 13:12, Andrej Shadura wrote:
> I finally came back from lunch, the latest debdiff and the diffoscope output
> are attached.
The diffoscope output of a no-change rebuild of 1.7.22-1 and 1.7.22-2
should show fewer differences
Control: tags -1 + moreinfo
Hi Javier
On Mon, 19 Apr 2021 at 23:27, Chris Hofstaedtler wrote:
>
> > $ debdiff snort_2.9.15.1-4_i386.deb snort_2.9.15.1-5_i386.deb
> [..]
>
> The debdiff does not seem to show any actual packaging changes. Are
> you sure you diffed the correct files?
This looks li
Control: tags -1 + moreinfo
Hi Frédéric
You didn't include a source debdiff with your unblock request. Also,
the Vcs-Browser URL [1] in debian/control returns 404.
I generated a diff and got the following:
61 files changed, 19938 insertions(+), 2005 deletions(-)
This is unreviewable by us. On
Source: pexpect
Version: 4.8.0-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky
Hi Maintainer
The autopkgtests of pexpect fail regularly and are therefore
unsuitable for regression testing. I've copied below what I hope is
the relevant
Source: boxer-data
Version: 10.8.20
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
The autopkgtest of boxer-data fails in testing where it succeeded in
the past [1].
The current failure seems to be due to the removal
Control: tags -1 + fixed-upstream
Fixed in Matrix upstream svn rev 3376 [1].
[1]
https://r-forge.r-project.org/scm/viewvc.php?view=rev&root=matrix&revision=3376
Control: forwarded -1 https://deb.li/6f4z
TMB upstream have submitted a bug report [1] to R-forge.
> Headers need update corresponding to new SuiteSparse version 5.7.1
>
> SuiteSparse was recently updated from version 4.2.1 to 5.7.1, however without
> updating the header `inst/cholmod.h` accordi
Control: reopen -1
This is still occurring with simka 1.5.3-3, see:
https://ci.debian.net/packages/s/simka/testing/amd64/
Control: reopen -1
The autopkgtest now fails with:
dpkg-architecture: warning: cannot determine CC system type, falling
back to default (native compilation)
Skip Test 3 on armhf (see bug #986307)
autopkgtest [08:53:06]: test run-unit-test: ---]
autopkgtest [08:53:06]: test run
Source: libkainjow-mustache
Version: 4.1+ds-1
Severity: important
Tags: patch
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: fails-always
Hi Maintainer
The autopkgtests of libkainjow-mustache fail on armhf[1] and
ppc64el[2] due to output on stderr. As these a
Source: python-fakeredis
Version: 1.4.1-1
Severity: important
Forwarded: https://github.com/jamesls/fakeredis/issues/295
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: fails-always
Hi Maintainer
Since the upload of python-fakeredis/1.4.1-1, its autopkgtests fa
Control: tags -1 + moreinfo
Hi Andreas
On Tue, 9 Mar 2021 at 19:03, Andreas Tille wrote:
> [ ] attach debdiff against the package in testing
> (I do not see any reason for a debdiff of the autogenerated package)
Autogenerated or not, the debdiff is the thing we need to review, in
order
Control: severity -1 serious
Control: retitle -1 sks: autopkgtest failure since git snapshot update
Autopkgtest regressions are RC for bullseye.
Hi Russell
Neither refpolicy nor policycoreutils are in the list of key packages.
In the upcoming hard freeze, for non-key packages with (non-trivial)
autopkgtests, the rules of the soft freeze still apply [1].
So you could avoid the need for unblocks for these packages by adding
an autopkgtest t
Control: tags -1 - fixed-upstream + upstream
Control: notforwarded -1
>From TMB upstream [1]:
> Digging a bit deeper I found that after calling
>
> M_cholmod_factorize_p(A, mm, (int*)NULL, 0 /*fsize*/, f, &c)
>
> the cholmod_common struct contains bogus, e.g. c.status=14903956 and
> c.dtype=152
Hi Andreas
On Mon, 8 Mar 2021 at 17:43, Andreas Tille wrote:
> it would be great if someone could have a look at this.
I have a fix. I will upload shortly.
Regards
Graham
psi4 1:1.3.2+dfsg-2 and libint 1.2.1-5 uploaded which should be able
to migrate together.
Source: r-cran-effectsize
Version: 0.4.3-1
Severity: serious
Tags: bullseye sid
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Since r-cran-rstanarm has migrated to testing, the autopkgtests of
r-cran-effectsize are succeeding again on
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
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 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 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
Control: reopen -1
Hi Andreas
Please drop your changes from 0.9-7+dfsg-3 and 0.9-7+dfsg-4 and revert
the package to the state it was in 0.9-7+dfsg-2.
Now is not the time to be dropping architectures as r-cran-sf has
several reverse-dependencies that will need to be taken care of.
Also, this is n
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 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
Mo, Norbert, do you think we should add libjulia-dev to julia's Recommends?
Hi Greg
On Mon, 1 Mar 2021 at 01:57, Gregory None wrote:
>> Instead of adding the symlink, try installing the libjulia-dev package.
>
> That worked like a charm, thanks!
Thanks for the feedback.
Regards
Graham
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
With bash 5.1, python-argcomplete's tests now fail if TERM is set.
Unexporting TERM allows the tests to succeed with old and new versions
of bash (tested with 4.4.18, 5.0 and 5.1).
Hi Gregory
On Fri, 26 Feb 2021 at 02:48, Gregory wrote:
> Try for example:
> $/usr/share/julia/julia-config.jl --allflags
>
> It will return (among other things):
> libjulia.so: cannot open shared object file: no such file or directory
>
> Adding a symlink libjulia.so that points to libjulia.so.1
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
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
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
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
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
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
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 Sun, 14 Feb 2021 at 15:57, Dirk Eddelbuettel wrote:
> Sure. Just fire up R on the box, don't install anything beyond r-base-core
> (and maybe r-recommended accounting for a few of the ones above) and then say
Perfect, thank you!
I installed only r-base-core and r-base-dev (gfortran,
glmmTMB upstream came up with a minimal reproducer (see forwarded bug):
stopifnot(require("testthat"),
require("glmmTMB"),
require("lme4"))
data("Orthodont", package="nlme")
fm1 <- glmmTMB(distance ~ age + (age|Subject), data = Orthodont)
I can confirm this fails on the s390x
On Fri, 5 Feb 2021 at 08:30, Sebastiaan Couwenberg wrote:
> No, riscv64 is not a release architecture and the soft freeze is next
> week. Ubuntu will have to carry this patch a little longer.
Ack, thanks.
Hi Maintainers
Any chance of an upload soon?
Regards
Graham
Control: forwarded -1 https://github.com/glmmTMB/glmmTMB/issues/665
After another detour via #981623, r-cran-glmmtmb is now also rebuilt.
Even with the rebuilt r-cran-glmmtmb, I still see the "gradient
function must return a numeric vector of length" errors on s390x and
ppc64, which are both big-e
Source: r-cran-glmmtmb
Version: 1.0.2.1-1
Forwarded: https://github.com/glmmTMB/glmmTMB/issues/615
Hi Maintainer
Since the upload of r-cran-tmb 1.7.18-1, r-cran-glmmtmb's autopkgtests
show hundreds of similar errors [1]:
Error in .Call("FreeADFunObject", ptr, PACKAGE = DLL) :
"FreeADFunObject"
Hi Dirk
On Sun, 31 Jan 2021 at 16:13, Dirk Eddelbuettel wrote:
> This is a bug in glmmTMB.
I don't see how you can be so sure.
> All the 'gradient function must ...' errors are from its tests and
> points to me to a recent change in R (where boolean comparisons can now check
> if the compared v
Control: reopen -1
Hi Dirk
Paul's test results showed that the run-unit-test autopkgtest still
fails with the same errors (
Error: gradient function must return a numeric vector of length...) as
in my original report.
The "Package version inconsistency detected" warning is now gone (due
to #9809
Source: mpich
Version: 3.4-4
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Since the upload of mpich 3.4-4, its own autopkgtests have been
failing on s390x [1] and continue to fail in the same way with
3.4.1-1.
I've
Hi Dirk
On Thu, 28 Jan 2021 at 01:12, Dirk Eddelbuettel wrote:
> Any update here? It still points at Matrix aka rmatrix aka r-cran-matrix,
> and I still think wrongly.
I'm still waiting for the results of the autopkgtest against the
rebuilt r-cran-tmb on s390x.
Unfortunately, it went into the q
Control: tags -1 - patch + pending
Control: severity -1 normal
Fix committed in git. Still waiting on s390x autopkgtest results
before uploading.
https://salsa.debian.org/r-pkg-team/r-cran-tmb/-/commit/b951d154765262656a43973fec5412c6df37cefa
Hi Michael
On Mon, 25 Jan 2021 at 11:51, Michael R. Crusoe wrote:
> Please rebuild all packages that build-dep on libsimde-dev so they may
> gain the benefits of the new release.
Let's schedule these as soon as simde 0.7.2-2 has migrated to testing.
There is an autopkgtest failure on s390x, but
Hi Dirk
On Mon, 25 Jan 2021 at 16:13, Dirk Eddelbuettel wrote:
> But upstream had that choice too and selected a warning not a stop. It
> appears to be a non-fatal issue.
My deviation from upstream here was intentional. The purpose being to
fail the autopkgtest, and our users should never ever
On Mon, 25 Jan 2021 at 11:24, Andreas Tille wrote:
> Looks sensible. As I mention before team uploads are always welcome. So
> please go for it.
Thanks Andreas! I will do once the autopkgtests have finished on s390x.
For reference, this is what the failing output looks like with my
patch in p
Control: tags -1 + patch
The attached patch upgrades the warning() to a stop().
This will cause r-cran-tmb's autopkgtests to fail whenever rmatrix is upgraded.
Then we will know it is time for a rebuild, or a new upload.
Let me know if this seems a reasonable solution, and I'll do a team upload.
Hi
On Sun, 24 Jan 2021 at 18:06, Graham Inggs wrote:
> I'm awaiting autopkgtest results on the binNMU'd r-cran-tmb. I will
> update this bug and #980809 when they are in.
The autopkgtests for r-cran-tmb [1] and r-cran-glmmtmb [2] have
completed on all architectures except for
Hi Dirk
On Sun, 24 Jan 2021 at 14:47, Dirk Eddelbuettel wrote:
> R code can promote warnings to errors on a per-session basis:
Thanks! This could be useful in the r-cran-tmb autopkgtest.
> I am still not quite sure what the best way here is. With hard '==' warnings
> we get ourselves the need
Hi Andreas
On Sun, 24 Jan 2021 at 09:55, Andreas Tille wrote:
> dh-r injects versioned dependencies if this is specified in the
> DESCRIPTION file of an r-* package. If this is not specified we
> need to add this manually (which I can do - but for sure the
> automatic solution would be more conv
Hi Dirk
On Sun, 24 Jan 2021 at 07:10, Dirk Eddelbuettel wrote:
> There is a confusion here. You filed this again rmatrix (aka "Matrix").
> Matrix does not impose dependencies -- dependent packages do.
I filed against rmatrix, as this was the package that started this
"transition". Also, I reall
Source: rmatrix
Version: 1.3-2-1
Severity: important
Control: affects -1 src:r-cran-tmb
X-Debbugs-CC: debia...@lists.debian.org
Hi R Maintainers
While investigating #980809 [1], I found the following output in the
autopkgtest logs of and r-cran-glmmtmb and r-cran-tmb:
Warning message:
In checkMa
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 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
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
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
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
Might be fixed by binNMU of slepc, see #980749.
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
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: 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 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.
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.
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
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: 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/
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.
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
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: 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
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.
On Tue, 12 Jan 2021 at 01:15, Norbert Preining wrote:
> So I would like to know what remains to be done form my side?
Well Julia still needs to upgrade to llvm-toolchain-11 for bookworm,
so I suggest to leave this bug open until then.
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
Hi Maintainer
The autopkgtests of simde 0.7.0-2 still fail on armhf in what looks to
me to be the same way.
Regards
Graham
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: dh-python
Version: 4.20201102
Hi Maintainer
Pybuild's build system detection is not consistent across
architectures. While building src:python-blosc, the build system was
detected as distutils for most architectures, except for ia64 [1],
riscv64 [2], sparc64 [3] and x32 [4] it was detecte
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: severity -1 serious
Hi Jonas
Happy Holidays!
On Sun, 27 Dec 2020 at 19:12, Jonas Smedegaard wrote:
> I tightened the test checking - enabled them during build and made them
> more verbose (and explicitly passed environment variable "srcdata" which
> might have previously failed).
>
> T
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
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
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: 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/
On Mon, 14 Dec 2020 at 22:03, Andreas Beckmann wrote:
> Preparing to unpack .../libgtkdatabox-doc_1%3a0.9.3.1-1.1_all.deb ...
> Unpacking libgtkdatabox-doc (1:0.9.3.1-1.1) ...
> dpkg: error processing archive
> /var/cache/apt/archives/libgtkdatabox-doc_1%3a0.9.3.1-1.1_all.deb (--unpack):
>
1101 - 1200 of 2742 matches
Mail list logo
