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]
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]
On Wed, 06 May 2020 13:28:53 -0700, Sean Whitton wrote:
> Quoting from #904302:
>
> > The Committee therefore resolves that:
> >
> > 1. Any use of dpkg's vendor-specific patch series feature is a bug for
> >packages in the Debian archive (including contrib and non-free).
> >
> >This should
On Thu, 7 May 2020 at 09:42, Gianfranco Costamagna
wrote:
> Hello, please consider dropping it. It makes the package FTBFS with newer
> boosts and it is unused.
If it makes the package FTBFS, shouldn't there be a Build-Conflicts on
libboost-signals-dev?
Control: found -1 src:synaptic/0.90
Hi Maintainer
Upon further investigation, I found the failure happened before the
last NMU, and was caused by the merging of PR #45 [1].
I believe debian/patches/00list.Ubuntu contradicts Debian Policy 4.17
"Vendor-specific path series" [2], see also Tech
Control: tags -1 + confirmed
Hi Dirk
On Wed, 29 Apr 2020 at 21:33, Dirk Eddelbuettel wrote:
> GNU GSL 2.6 was release last fall; the package is stable and does not move
> too much upstream. It has been in 'auto transition' for a while following my
> initial upload to experimental. Could we
Hi Julien
On Thu, 30 Apr 2020 at 10:03, Julien Puydt wrote:
> I have been the most active maintainer of scilab in Debian recently,
> and I'm reviewing old bugs : is ubuntu still having issues with the
> scilab packaging in Debian?
Looking at Ubuntu's publishing history for scilab [1], it seems
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
Source: synaptic
Version: 0.90+nmu1
Tags: ftbfs
X-Debbugs-CC: Julian Andres Klode
Hi Maintainer
The recent NMU of synaptic 0.90+nmu1 FTBFS in Ubuntu.
I've copied what I hope is the relevant part of the log below.
Regards
Graham
make[1]: Leaving directory '/<>/synaptic-0.90+nmu1'
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
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
Control: tags -1 + fixed-upstream
Committed upstream:
https://github.com/alexmurray/indicator-sensors/commit/8ba2e583345126281558b8c8e1eece5c4e7873bd
Control: tags -1 + pending
Committed:
https://salsa.debian.org/debian/modem-manager-gui/-/commit/8ba795408ea10f0d411d025300de8e098ce7fe69
Hi Drew
On Sat, 18 Apr 2020 at 08:46, Drew Parsons wrote:
> I've uploaded scipy 1.4 to unstable. Tests run normally on my system.
> Could we trigger some debci tests to check if the new version has
> resolved the test problem?
>
> Ideally, say, 2 a day for the next 5 days to get a sample size
Hi
Looking at the upstream commit from the 5.5 branch [1], the following
seems to be the only part relevant to the 5.0 branch:
--- a/tools/make_unicode
+++ b/tools/make_unicode
@@ -193,7 +193,8 @@
"Top_And_Bottom_And_Right" => 0x0c,
"Overstruck" => 0x0d,
"Invisible" => 0x0e,
-
This looks like #943600
On Fri, 17 Apr 2020 at 13:10, peter green wrote:
> The backport of arm64 support to FPC 3.0.x has been found to be somewhat
> shaky in the past.
The failure occurs on amd64 as well, just not as often.
https://ci.debian.net/packages/l/lazarus/testing/amd64/
Source: mercurial
Version: 5.3.1-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky
Hi Maintainer
Mercurial's autopkgtests are flaky [1].
I examined the logs of several failed tests and found the following:
Failed
Source: unrardll
Version: 0.1.3-6
Severity: serious
Tags: ftbfs
Hi Maintainer
The package unrardll requires a binary upload since it is in contrib
and cannot be built on the buildds [1].
Please upload the binary package python3-unrardll_0.1.3-6_amd64.deb to
the archive.
There is no need for
Source: spyder
Version: 3.3.6+dfsg1-4
Severity: serious
Tags: bullseye sid
The binary package spyder has a dependency on python3.7 [1].
Since this is an arch:all package, it cannot be binNMU'd.
Please make a source-only upload so that it picks up a dependency on
python3.8 instead.
Regards
Graham
Source: pympress
Version: 1.5.1+dfsg-3
Severity: serious
Tags: bullseye sid
The binary package pympress has a dependency on python3.7 [1].
Since this is an arch:all package, it cannot be binNMU'd.
Please make a source-only upload so that it picks up a dependency on
python3.8 instead.
Regards
Source: fparser
Version: 0.0.10-2
Severity: serious
Tags: bullseye sid
The binary package python3-fparser has a dependency on python3.7 [1].
Since this is an arch:all package, it cannot be binNMU'd.
Please make a source-only upload so that it picks up a dependency on
python3.8 instead.
Regards
Source: geophar
Version: 18.08.6+dfsg1-1
Severity: serious
Tags: ftbfs bullseye sid
Hi Maintainer
Since Python 3.8 is now the only Python 3 interpreter, geophar FTBFS [1].
I've copied what I hope is the relevant part of the log below.
Regards
Graham
[1]
Hi
On Sat, 7 Mar 2020 at 12:24, Matsievskiy S.V. wrote:
>
> Looks like it is an upstream issue. I've opened a PR
> https://github.com/JuliaLang/PackageCompiler.jl/pull/367
Thanks for the update. I see your PR was accepted.
Is the issue fixed for you now?
I tried the example create_app("MyApp",
Control: severity -1 important
Downgrading severity since julia was removed on ppc64el.
Per upstream's currently supported platforms [1]:
PowerPC (64-bit) is tier3:
Julia may or may not build. If it does, it is unlikely to pass tests.
Binaries may be available in some cases. When they are, they should be
considered experimental. Ongoing support is dependent on community
efforts.
I
Package: ftp.debian.org
Dear FTP Team
Please remove binaries of julia on ppc64el. It no longer builds on
the buildds, see #953996.
Its only reverse-dependency, cantor-backend-julia, is on amd64 only.
Regards
Graham
[1] https://julialang.org/downloads/
Control: severity -1 serious
Comparing the build logs from when the package was uploaded [1] to the
current reproducible builds [2], one can see 'debian/rules build-arch'
is missing. This bug is RC as cbp2make is unable to be binNMU'd.
[1]
Hi
On Thu, 9 Apr 2020 at 17:36, Yangfl wrote:
> As libwhereami-dev is now available, please consider linking against
> system library using -lwhereami instead of bundled whereami.c.
Thanks for letting me know!
I see libwhereami FTBFS on hurd and kfreebsd [1].
Would you please consider
Hi
On Wed, 8 Apr 2020 at 07:06, Yangfl wrote:
> libwmf is released with package split, and old-style config script
> dropped with pkg-config file introduced. There are three packages
> needing patches against `libwmf-config':
>
> wv
> gimp
> abiword
Please file bugs against these packages
On Wed, 1 Apr 2020 at 09:36, wrote:
> Any follow-up/update on this? Looks like 11 April package will be auto-
> removed if not fixed? Is this even fixable?
I bisected the commits between 1.3.0 and 1.3.1 and found that
reverting the following commit allows the build to succeed on ppc64el:
ccall:
On Tue, 7 Apr 2020 at 16:22, Ralf Treinen wrote:
> Thanks, but it will fail on all the other release architectures. Building
> coq on slow architectures takes > 5h, so that seemed like a waste of
> resources to me.
binNMUs don't get scheduled on architectures that are Build-Attempted
or Failed,
Control: tags -1 + confirmed
Control: forwarded -1
https://release.debian.org/transitions/html/auto-schroedinger-maeparser.html
Hi Andrius
On Sat, 4 Apr 2020 at 07:12, wrote:
> I would like to request a transition slot for schroedinger-maeparser
> (experimental -> unstable) due to the changed
Hi Dirk
On Fri, 3 Apr 2020 at 20:27, Dirk Eddelbuettel wrote:
> I am still (as always) lost by the process. Does that mean an upload to
> unstable is now ok? Or not? I am unsure what "hand shake" from the ftp /
> release team I should be waiting for.
Please not yet. Once r-base is uploaded
Hi Dirk
On Sat, 28 Mar 2020 at 15:57, Dirk Eddelbuettel wrote:
> R does change internals every now and then with the annual releases; this is
> a major one which will require rebuilds of all packages.
I've set up a transition tracker [1] where we can see the magnitude of
the transition.
Source: r-cran-sf
Version: 0.9-0+dfsg-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Since the upload of 0.9-0+dfsg-1, r-cran-sf fails its own autopkgtests
[1], which passed previously. I've copied what I hope is
Control: severity -1 serious
Hi Alexander
On Wed, 25 Mar 2020 at 18:15, Alexander van der Meij
wrote:
> As described in bug 951634, Debian is currently distributing a broken
> development build of the software of which I am the developer; gummi.
>
> Hereby my request to either bump the package
Source: joblib
Version: 0.14.0-3
Severity: serious
Control: affects -1 src:spades src:circlator
Hi Maintainer
While attempting to run the autopkgtests triggered by python3-defaults
for spades [1] and circlator [2], python3-joblib fails to install with
the following error:
Setting up
Source: fdroidserver
Version: 1.1.4-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: needs-update
Hi Maintainer
The autopkgtests of fdoidserver started to fail in testing some time
around 2019-09-21 [1], where they passed previously.
I've
Hi Paul
On Sun, 15 Mar 2020 at 14:55, Paul Gevers wrote:
> Which tracker do you mean here?
>
> tracker.d.o
> ddpo.d.o
> release.debian.org/transitions (don't think you mean this one)
> britney itself
Trackers, trackers everywhere! [1]
Sorry, I meant the transition tracker for this transition
On Sun, 15 Mar 2020 at 10:55, Carsten Schoenert wrote:
> Look's like the check to find Python is now failing for Python 3.8.
> The relevant part in configure.ac (line 676 to 688) is this:
I think you'll need at least this patch from Ubuntu:
galpy's autopkgtests passed [1] after a binNMU.
I don't know why it wasn't picked up by the tracker.
[1] https://ci.debian.net/packages/g/galpy/unstable/amd64/
Source: python-boto
Version: 2.49.0-2.1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: needs-update
Hi Maintainer
The autopkgtests of python-boto started to fail with Python 3.8 as the
default Python3 interpreter [1].
I've copied what I
Source: onioncircuits
Version: 0.6-2
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: needs-update
Hi Maintainer
The autopkgtests of onioncircuits started to fail with Python 3.8 as
the default Python3 interpreter [1].
I've copied what I
Source: junitparser
Version: 1.4.1-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: needs-update
Hi Maintainer
The autopkgtests of junitparser started to fail with Python 3.8 as the
default Python3 interpreter [1].
I've copied what I hope
Source: grip
Version: 4.2.0-3
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 grip started to fail with Python 3.8 as the
default Python3 interpreter [1].
I've copied what I
Source: buildbot
Version: 2.6.0-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: needs-update
Hi Maintainer
The autopkgtests of buildbot started to fail with Python 3.8 as the
default Python3 interpreter [1].
I've copied what I hope is the
Source: breezy
Version: 3.0.2-4
Severity: serious
Tags: ftbfs bullseye sid
Hi Maintainer
Your package FTBFS when built with Python 3.8 [1].
Please find what I hope is the relevant part of the log below.
Regards
Graham
[1] https://tests.reproducible-builds.org/debian/history/amd64/breezy.html
Hi Matthias
I had a look at the Testing Excuses for python3-defaults [1]. Of the
84 packages listed there, most are already passing in unstable and
some had regressed in testing. The breakdown of the remaining 22
packages is as follows:
kopanocore FTBFS (#953549)
causing the autopkgtests of
Control: severity -1 important
Hi Sudip
On Sat, 14 Mar 2020 at 02:21, Sudip Mukherjee
wrote:
> I was looking at this bug today and I did not get any error in building
> the current version.
Thanks for checking! Reproducible builds [1] show FTBFS from October
through December, but recent
Source: freecad
Version: 0.18.4+dfsg2-1
Severity: serious
Tags: ftbfs
Hi Maintainer
In a recent rebuild for Python 3.8, freecad FTBFS [1].
Ubuntu are carrying some patches which may be relevant [2].
Regards
Graham
[1] https://buildd.debian.org/status/package.php?p=freecad
[2]
Source: mailutils
Version: 1:3.7-2
Severity: serious
Tags: ftbfs bullseye sid
Hi Maintainer
mailutils FTBFS when rebuilt with Python 3.8 [1].
I've copied what I hope is a relevant part of the log below.
Regards
Graham
[1] https://buildd.debian.org/status/package.php?p=mailutils
/bin/bash
Source: kopanocore
Version: 8.7.0-6
Severity: serious
Tags: ftbfs bullseye sid
Hi Maintainer
kopanocore FTBFS when rebuilt with Python 3.8 [1]
I hope the following is the relevant part of the log:
checking for PYTHON... yes
configure: error: python requested but not satisfiable
cd
Source: kawari8
Version: 8.2.8-9
Severity: serious
Tags: ftbfs bullseye sid
Hi Maintainer
kawari8 FTBFS when rebuilt with Python 3.8 [1].
I've copied what I hope is a relevant part of the log below.
Regards
Graham
[1] https://buildd.debian.org/status/package.php?p=kawari8
g++
On Sun, 8 Mar 2020 at 04:06, Mo Zhou wrote:
> binNMU src:opencv and rebuild against python3.8
It's on the tracker for the Python 3.8 as default transition [1].
It will be binNMU'd in due course.
[1] https://release.debian.org/transitions/html/python3.8-default.html
Source: libpeas
Version: 1.22.0-5
Severity: serious
Tags: ftbfs
Hi Maintainer
libpeas FTBFS when rebuilt with Python 3.8 [1].
There are several undefined references, similar to the following:
/usr/bin/ld: .libs/peas-plugin-loader-python.o: in function
Source: ldb
Version: 2:2.0.8-1
Severity: serious
Tags: ftbfs patch
Hi Maintainer
ldb FTBFS on some architectures when rebuilt with Python 3.8 [1].
dpkg-gensymbols: error: new libraries appeared in the symbols file:
libpyldb-util.cpython-38-x86-64-linux-gnu.so.2
dpkg-gensymbols: error: some
On Fri, 6 Mar 2020 at 19:09, Dennis Braun wrote:
> Can you please make binNMUs for ir.lv2, pulseeffects and x42-plugins?
Scheduled, thanks!
Hi Daniel
On 2020/03/04 02:44, Daniel Leidert wrote:
Can yóu please schedule a rebuild of facter too? At least three FTBFS reports
are caused by factor only providing the Ruby2.5 library (#952024, #952022,
#952070). I cannot upload the fixed packages. If this is not the right place,
please let
Hi Lucas
I notice kamailio and klayout still appear red in the Debian tracker
[1], but went green in Ubuntu [2].
Do you have any ideas? Do we miss something in Debian?
Regards
Graham
[1] https://release.debian.org/transitions/html/ruby2.7.html
[2]
Control: tags -1 + confirmed
Hi Matthias
gnuradio / volk / gr-osmosdr and gnat / plplot have all recently migrated.
Please go ahead in unstable.
Regards
Graham
Control: tags -1 + moreinfo
Hi Alastair
On Fri, 14 Feb 2020 at 16:27, Alastair McKinstry wrote:
> The SOVERSION revision in 3.1.5rc1 was an error; its not bumping the
> soversion until the 4.x releas, expected Q2 this year.
>
> I am postponing any changes on pmix until then as reverting
Source: icingaweb2-module-nagvis
Version: 1.1.1-1
Severity: serious
Hi Maintainer
icingaweb2-module-nagvis has a dependency on nagvis, which was removed
from testing, see #851771.
Regards
Graham
On Fri, 21 Feb 2020 at 21:36, Lucas Kanashiro wrote:
> Could you please also rebuild src:mecab? It FTBFS due to this swig bug
> #951623 and the fix was already uploaded to unstable [1]. I rebuilt it
> locally and it works fine now.
Given back, thanks.
On Fri, 21 Feb 2020 at 00:15, Lucas Kanashiro wrote:
> I'd like to request some rebuilds:
Thanks for the info, ruby-god, libsemanage and unicorn given back now.
All binNMUs have been scheduled.
There were some packages that seem to have been rebuilt unnecessarily,
but no harm done.
I noticed Ubuntu's ben file is quite different.
Should we update the Debian one to match?
https://people.canonical.com/~ubuntu-archive/transitions/html/ruby2.7-add.html
On Tue, 18 Feb 2020 at 14:39, Lucas Kanashiro wrote:
> Could you please start the rebuild process of the first level
> of dependencies reported in the transition page?
All packages in level 1, and packages only build-depending on
ruby-defaults in level 2, scheduled.
On Tue, 18 Feb 2020 at 01:16, Lucas Kanashiro wrote:
> I just uploaded ruby-defaults version 1:2.5.7 to unstable with both
> versions of the ruby interpreter enabled (2.5 and 2.7).
Great!
> We (the Ruby team) should start to request some binNMUs soon.
OK, you can send them to this bug, and no
Control: tags -1 + confirmed
Hi Lucas
Please go ahead in unstable.
Regards
Graham
Control: tags -1 + confirmed
Hi Nicolas
Please go ahead in unstable.
Regards
Graham
Control: severity -1 serious
Raising severity, all autopkgtest failures are considered release-critical for
bullseye [1].
[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html
Package: ftp.debian.org
Severity: normal
android-tools builds android-tools-mkbootimg 5.1.1.r38-1.1, but it is
superceded by android-tools-mkbootimg 1:8.1.0+r23-5 built by
android-platform-system-core
android-tools is no longer maintained by the Android Tools team (#949149)
and blocks Python2
Source: haskell-hledger-lib
Version: 1.14.1-1
Severity: serious
Tags: ftbfs
Control: affects -1 + src:haskell-hledger
Control: affects -1 + src:haskell-hledger-ui
Control: affects -1 + src:haskell-hledger-web
Hi Maintainer
Since the upload of haskell-hledger-lib 1.14.1-1, it has FTBFS on s390x.
Hi Andreas
On Fri, 24 Jan 2020 at 11:21, Andreas Tille wrote:
> and I have no idea how to fix this. May be there is some unspecified
> versioned Build-Depends or something like this.
This is the kind of bug that autopkgtests blocking testing migration
is supposed to catch.
I see you uploaded
Source: r-cran-parameters
Version: 0.3.0-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Sometime between 2020-01-13 and 2010-01-18, r-cran-parameters'
autopkgtests started to fail in unstable [1] with the
Source: r-cran-rlang
Version: 0.4.2-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Since the upload of r-cran-rlang 0.4.2-1, its own autopkgtests have been
failing when tested against packages in testing [1],
Control: reopen -1
Control: retitle -1 kazoo: autopkgtest regression
Hi Thomas
Just to be clear, the problem is an autopkgtest regression.
I'm re-opening this bug as it is still not fixed [1].
You can run the autopkgtests locally to check that they are fixed before
uploading.
More
On 2020/01/20 19:12, Hans-Christoph Steiner wrote:
If the android-tools maintainer doesn't respond, then yes, I suppose
removing it is the right option. Its no longer maintained by the
Android Tools team, I suppose we should correct that in the package.
Who is the android-tools maintainer
Source: r-cran-ranger
Version: 0.12.1-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Since the upload of r-cran-ranger 0.12.1-1, its own autopkgtests have
been failing [1] on at least arm64, ppc64el and s390x.
Control: tags -1 - moreinfo
Control: tags -1 + confirmed
Control: block -1 by 949288 949290
On Sun, 19 Jan 2020 at 13:12, Matthias Klose wrote:
> these are now filed, with patches.
Thanks! Please go ahead.
Source: r-bioc-tximport
Version: 1.14.0+dfsg-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Since the upload of r-bioc-tximport 1.14.0+dfsg-1, it has been failing its
own autopkgtests [1].
I've copied what I hope
Source: r-cran-devtools
Version: 2.2.1-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Since the upload of r-cran-devtools 2.2.1-1, it has been failing its
own autopkgtests [1].
I've copied what I hope is the
Source: python-limits
Version: 1.3-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: needs-update
Hi Maintainer
The autopkgtests of python-limits started to fail some time around
2018-10-20 [1].
I've copied what I hope is the relevant part
Control: forwarded -1
https://release.debian.org/transitions/html/auto-libffi.html
Control: tags -1 + moreinfo
On Fri, 17 Jan 2020 at 23:33, Matthias Klose wrote:
> libffi is finally released. There are two packages needing patches:
>
> ecl
> polyml
Please file bugs for these.
Source: android-tools, android-platform-system-core
Control: found -1 android-tools/5.1.1.r38-1.1
Control: found -1 android-platform-system-core/1:8.1.0+r23-5
Hi Maintainer
Both android-tools and android-platform-system-core build an
android-tools-mkbootimg binary package.
Should
Source: python-pyepsg
Version: 0.3.2-2
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
Forwarded: https://github.com/rhattersley/pyepsg/issues/15
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Autopkgtests of python-pyepsg recently regressed [1] with the
Source: cp2k
Version: 6.1-3
Hi Maintainer
Since switching from libint to libint2 in cp2k 6.1-3, the builds on
armhf and i386 have been showing many failures similar to the
following [1]:
>>>
I think this is #948803 in binutils.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948803
Hi Christoph
On 2020/01/13 15:20, Christoph Berg wrote:
I think this is a bug in lazarus on arm64, but maybe I'm wrong:
https://buildd.debian.org/status/fetch.php?pkg=cqrlog=arm64=2.4.0-3=1578918606=0
700 291.337/324.064 Kb Used
800 291.987/324.064 Kb Used
(9009) Assembling dlogupload
(9009)
Control: tags -1 + patch
On Wed, 8 Jan 2020 at 21:57, Paul Gevers wrote:
> autopkgtest [07:15:08]: test f2py: [---
> /tmp/autopkgtest-lxc.jhh9qajz/downtmp/build.odB/src/debian/tests/f2py:
> 24: Syntax error: Unterminated quoted string
> autopkgtest [07:15:08]: test f2py:
Hi Dmitry
On Sun, 5 Jan 2020 at 10:51, Dmitry Shachnev wrote:
> And binNMU all packages marked as bad.
I only see 8 packages marked bad.
Many of those, e.g. qt-gstreamer and kadu, FTBFS during the previous
rebuild to pick up libqt5gui5-gles.
I've only binNMU'd piperka for now.
Regards
Graham
Source: libimobiledevice
Version: 1.2.1~git20190929.60823f9-2
Severity: normal
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: python3.8 python3-all-dev
The package build-depends on python3-all-dev, but does not build
extensions/libraries for all supported python3 versions.
Source: ceph
Version: 14.2.4-8
Severity: normal
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: python3.8 python3-all-dev
The package build-depends on python3-all-dev, but does not build
extensions/libraries for all supported python3 versions. This
is seen on the transition
Source: getfem++
Version: 5.3+dfsg1-3
Severity: normal
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: python3.8 python3-all-dev
The package build-depends on python3-all-dev, but does not build
extensions/libraries for all supported python3 versions. This
is seen on the
Source: stimfit
Version: 0.16.0-1
Severity: normal
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: python3.8 python3-all-dev
The package build-depends on python3-all-dev, but does not build
extensions/libraries for all supported python3 versions. This
is seen on the transition
Source: libguestfs
Version: 1:1.40.2-4
Severity: normal
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: python3.8 python3-all-dev
The package build-depends on python3-all-dev, but does not build
extensions/libraries for all supported python3 versions. This
is seen on the
Source: fontforge
Version: 1:20190801~dfsg-2
Severity: normal
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: python3.8 python3-all-dev
The package build-depends on python3-all-dev, but does not build
extensions/libraries for all supported python3 versions. This
is seen on the
As of now, lazarus 2.0.6+dfsg-3 has failed its autopkgtests 2 out of
11 times on amd64 [1], and 3 out of 11 times on arm64 [2].
I am hesitant to re-open this bug as RC, as it potentially removes all
packages built with lazarus for no good reason.
[1]
Control: reopen -1
Hi Drew
The test gets a little further [1], and now fails at:
___ test_inr ___
def test_inr():
this_dir = os.path.dirname(os.path.abspath(__file__))
mesh = pygalmesh.generate_from_inr(
Source: watson
Version: 1.6.0-6
Severity: serious
Tags: ftbfs
Hi Maintainer
Both watson 1.6.0-6 in bullseye and 1.7.0-5 in sid FTBFS [1].
The upload to sid did not migrate to testing [2]. Please do
source-only uploads, unless there are NEW binaries.
Not built on buildd: arch all binaries
Hi Sandro
Are you planning to upload the new version of sphinx-copybutton soon?
sphinx-copybutton [1] is currently blocked for migration:
Not built on buildd: arch all binaries uploaded by morph, a new
source-only upload is needed to allow migration
...which in turn blocks skimage [2]:
1301 - 1400 of 2698 matches
Mail list logo
