All three failures give the error message
OverflowError: Python int too large to convert to C long
from
File "sage/rings/polynomial/polynomial_integer_dense_flint.pyx", line 284, in
sage.rings.polynomial.polynomial_integer_dense_flint.Polynomial_integer_dense_flint.__init__
(build/cythonized/
tags 931695 +patch
thanks
Some poking around revealed that upstream fixed this by removing the last (NULL)
parameter from the call. This was done in a commit titled "minor fixes".
https://github.com/jacquesg/p5-Git-Raw/commit/30f7a4491ab453d28ae1fa1b393fcd023f6c344d .
There was also another ap
Package: python-sponge
Severity: serious
x-debbugs-cc: debian-pyt...@lists.debian.org
While looking at some python2 removal issues, I came across python sponge. I
noticed the following about the package.
* Python 2 only.
* Only one maintainer upload (and one NMU) ever.
* Not in stable or testin
On 28/11/2019 16:19, gregor herrmann wrote:
A debdiff should appear soon at
https://debdiffs.raspbian.org/main/libg/libgit-raw-perl
… this is still a 404 (and the pool/ directory also still has the old
version)
Apologies, it appears that rust built-using generation does not like binnmus
and t
Package: rust-url-serde
Version: 0.2.0-1
Severity: serious
Tags: bullseye, sid
librust-url-serde-dev depends on and rust-url-serde build-depends on
librust-url-1+default-dev which is no longer provided by rust-url. It seems to
have been replaced by librust-url-2+default-dev
Package: rust-tiff
Version: 0.3.1-2
Severity: serious
Tags: bullseye, sid
librust-tiff-dev depends on and the rust-tiff source package build-depends on
librust-num-derive-0.2+default-dev which is no longer provided by
librust-tiff-dev. It seems to have been replaced by
librust-num-derive-0.3+d
Package: aptly
Version: 1.3.0+ds1-2.3
Severity: serious
aptly build-depends on golang-go.tools which has been dropped by the
golang-golang-x-tools source package. It is still present in unstable as a
cruft package but is completely gone from testing.
Please update your build-dependency to gola
Package: beads
Version: 1.1.18+dfsg-3
Tags: bullseye, sid
Severity: serious
beads build-depends on libquazip5-headers which is no longer built by the
libquazip source package and is gone from testing and unstable. I believe you
need to change your build-dependency to libquazip5-dev.
Package: creduce
Version: 2.10.0-2
Severity: serious
creduce build-depends on frama-c-base which is built by the frama-c source
package which is not currently in testing.
Either frama-c needs to be fixed to get it back in testing, creduce needs to
eliminate the dependency (no idea if this is p
Package: lilypond
Version: 2.19.81+really-2.18.2-13
Severity: serious
Tags: patch
lilypond build-depends on texlive-generic-recommended, which has been dropped
by the texlive-base source package. It is still present in unstable as a cruft
package but is completely gone from testing.
Please upd
Package: mtree-netbsd
Version: 20180822-4
Severity: serious
Tags: patch
mtree-netbsd build-depends on bsdtar which is no longer built by the libarchive
source package. It is still present in unstable as a cruft package but is
completely gone from testing.
Please update your build-dependency to
Package: octave-dicom
Version: 0.2.2-4
Severity: serious
octave-dicom failed to build on armel, armhf, i386 and mips64el. It seems the
problem was a failure to find gdcm.
checking for GDCM... CMake Error: Problem processing arguments. Aborting.
CMake Error: Problem processing arguments. Abort
Package: obfs4proxy
Version: 0.0.7-4
Severity: serious
Tags: bullseye, sid
obfs4proxy build-depends on golang-go.net-dev which has been dropped by the
golang-golang-x-net-dev source package. It is still present in unstable as a
cruft package but is completely gone from testing.
Please update y
Package: pathspider
Version: 2.0.1-2
Severity: serious
Pathspider build-depends on pylint3, which is no longer built by the pylint source
package. Please consider changing your build-dependency to pylint (>= 2.2.2-2).
I have not done a test build in this case, because your package already has a
I'm deleting this from deferred for now, until reverse-dependencies are kicked
out from testing or fixedT
The current pysvn is already rc buggy thanks to the removal of python-cxx-dev.
If not fixed this will cause pysvn and all it's rdeps to be kicked out of
testing. So IMO it makes more sens
Package: rust-rusty-tags
Version: 3.5.1-1
Severity: serious
Tags: bullseye, sid
rust-rusty-tags build-depends on librust-dirs-1+default-dev which is no longer
provided by rust-dirs. It seems to have been replaced by
librust-dirs-2+default-dev.
Package: zeroinstall-injector
Version: 2.14.1-3
Severity: serious
zeroinstall-injector build-depends on libcurl-ocaml-dev which is not currently
in testing, either libcurl-ocaml-dev needs to be fixed so it can return to
testing, zeroinstall-injector needs to eliminate the dependency (no idea if
Package: gitlab-workhorse
Version: 8.8.1+debian-3
Severity: serious
Tags: patch
gitlab-workhorse build-depends on golang-logrus (>= 1.0~), golang-logrus used
to be a transitional package, but is now (in testing) only an unversioned virtual
package that does not satisfy your build-dependency.
P
reopen 936710
severity 936710 normal
thanks
Thank you for fixing the rc aspect of this issue, reopening and downgrading for
the broader issue.
Should the package attempt to clean this up (and if so is there a better
method than unconditionally deleting those directories), or is
permanently leaving this behind (to become more and more obsolete, and
potentially be read by users looking for the current documentation) the
best that can be sa
Package: oggvideotools
Version: 0.9.1-4.1
Severity: serious
Tags: patch
oggvideotools FTBFS in buster. I first noticed this in raspbian, but it's also
visible on the reproducible builds tests.
http://buildd.raspbian.org/status/fetch.php?pkg=oggvideotools&arch=armhf&ver=0.9.1-4.1&stamp=155257297
i tried to modify the testsuite to use stronger keys (patch attatched), however
after doing so the testsuite now hangs (relavent output pasted at end of
message). Not sure what is going wrong here (I am neither a ruby expert or an
openssl expert).
I have attached a patch with my changes so-far
It seems that ruby-eventmachine has a hardcoded 1024 bit CA certificate and
key, I tried replacing this with a 4096 bit one but the testsuite still failed,
I then tried replacing the client cert in the test with one signed by the new
CA but that didn't fix things either.
Description: Replace
I literally poked that patch into debian/patches{/series}, quilt
applied it and rebuilt, and it started working for me. Maybe there's
something different about our configs?
Strange, that patch seems to slightly change how the hardcoded dh params are
loaded, but it doesn't seem to change the size
(note: I'm just a guy taking a flyby look at bugs)
The following script is used to generate the key:
/usr/share/synergy/gen_ssl_pem.sh
Fixing that script is easy enough, but that is only the start of fixing the
issue.
Firstly grepping the source finds a couple of other places where it seems t
> how is a versioned break helping anything? The minimal key limit, hash
> and TLS version can be overriden via config file and this what is
> causing the problems from what I can tell. So either the remote side
> upgrades their things or the users enabled "lower security" mode.
> Is there anythin
package: varnish-modules
version: 0.12.1-1+b1
severity: serious
x-debbugs-cc: team+varnish-t...@tracker.debian.org
varnish-modules depends on libvarnishapi1 which is no longer built by varnish,
it seems to have been replaced by libvarnishapi2
There does not seem to have been any attempt to re-b
package: python-hiredis
version: 0.2.0-3
severity: serious
python-hiredis failed to build during the re-build for libhiredis0.14, this
failure does not seem to be architecture specific
Traceback (most recent call last):
File "/<>/test.py", line 4, in
import test
File "/<>/test/__in
Package: syslog-ng
Version: 3.13.2-4.1
Severity: serious
syslog-ng failed to build on all release architectures during binnmus for the
hiredis transition. The failure seems to be in a python related test but the
build log doesn't seem to indicate why exactly it failed.
https://buildd.debian.or
pygame in Debian testing is currently python2 only, I am sure I am not alone in
thinking this is not a good state of affairs given that pygame is frequently
used for introducing people to programming.
pygame in sid has python3 support but is held back from migrating to testing by
three rc bugs
On 18/10/18 23:37, Steve McIntyre wrote:
That "vld1.8 {d16-d17}, [r3]" is a direct consequence of incorrectly
targetting NEON - the target registers don't exist on platforms
without it. Please fix the build of your package to do this correctly.
BTW there is a patch to rip out the incorrect compi
package: ipe-tools
severity: serious
version: 1:7.2.7-1
ipe-tools failed to build from source during the re-builds for the poppler
transition.
https://buildd.debian.org/status/fetch.php?pkg=ipe-tools&arch=amd64&ver=1%3A7.2.7-1%2Bb3&stamp=1540034720&raw=0
pdftoipe.cpp: In function 'int main(in
Package: libcoq-ocaml
Version: 8.6-5
Severity: serious
libcoq-ocaml depends on liblablgtksourceview2-ocaml- (where is a
string that varies between different architectures) which is a virtual package provided by
liblablgtksourceview2-ocaml . Similarly libcoq-ocaml-dev depends on
liblablgtksour
package: timbl
version: 6.4.8-1
severity: serious
timbl and libtimbl4 depend on libticcutils2v5 and the timbl source package
depends on libtimbl4-dev. These packages are no longer build by the ticcutils
source package.
I notice there is a new version in new that looks like it probablly fixes t
package: openscenegraph
version: 3.2.2+dfsg1-2
severity: serious
libopenscenegraph100v5 depends on libcoin80-5 and the openscenegraph source
package bulid-depends on libcoin80-dev. These packages are no longer built by
the coin3 source package. They appear to have been replaced by libcoin80c an
Package: pivy
Version: 0.6.4-1
Severity: serious
pivy cannot be built on mips/mipsel because of a depedency on pyside2 which is
not built on mips/mipsel pyside2 is not being built on those architectures due
to a dependency on patchelf. patchelf is not currently building on mips* due to
a tests
Package: pyside2
Version: 5.11.2-1
Severity: serious
It seems that patchelf has been removed on mips64el due to testsuite failures,
but pyside2 still bulid-depends on it. So pyside cannot be built on mips64el
anymore.
Possible fixes (in roughly descending order of preferences)
1. Fix the tests
package: petsc4py
version: 3.10.0-2
severity: serious
While trying to get the petsc/slepc/etc stack in raspbian buster into a
consistent state I ran into the following error with petsc4py. I was also able
to reproduce this in a Debian sid amd64 environment, so it's not raspbian
specific.
mpic
Package: elkcode
Version: 4.0.15-2
Severity: serious
During binnmus for the libxc5 transition elkcode failed with the following
error.
mpif90 `dpkg-buildflags --get FFLAGS` `dpkg-buildflags --get CPPFLAGS` -Wall
-ffast-math -funroll-loops -fopenmp `dpkg-buildflags --get LDFLAGS` -o elk
modm
Found 917598 3.10.0-3
thanks.
Unfortunately it seems it still fails with the same error.
On 29/12/18 20:21, Debian Bug Tracking System wrote:
This is an automatic notification regarding your Bug report
which was filed against the petsc4py package:
#917598: petsc4py FTBFS error: ‘SNESTEST’ unde
Package: python-escript
Version: 5.2-4
Severity: serious
The most recent upload of python-escript failed to build on armhf, mipsel,
mips64el and mips. All seemed to fail while linking a C++ library.
g++ -o debian/tmp2/posix/weipa/src/libescriptreader.so -Wl,-z,relro -Wl,-z,now
-fopenmp -shared
Tags 911976 +patch
Thanks
This seems to be a simple case of a missing include, I just uploaded a fix to
raspbian. A debdidf should appear soon at
https://debdiffs.raspbian.org/main/b/bind-dyndb-ldap . No intent to NMU in
Debian.
package: mixxx
version: 2.1.3~dfsg-1
severity: serious
tags: patch
mixxx unconditionally uses -mfloat-abi=hard and -mfpu=neon on arm*. These are
inappropriate in Debian.
On armhf "-mfloat-abi=hard" is redundant but not harmful "-mfpu=neon" will
likely result in binaries that will break on the
found 902036 1.9.4.post1+dfsg-1
thanks
Unfortunately while the 1.9.4.post1+dfsg-1 upload fixed the ppc64el failure, it
did not fix the s390x failure.
found 902036 1.9.4.post1+dfsg-1
tags 902036 +patch
thanks
On 30/10/18 02:03, peter green wrote:
Unfortunately while the 1.9.4.post1+dfsg-1 upload fixed the ppc64el failure, it
did not fix the s390x failure.
I just took a look at this, turned out to be a typo in a #if causing a 32-bit
value
Package: vibe.d
Version: 0.8.4-1
Severity: serious
Vibe.d fails to build with the following error. Presumablly this was triggered
by the upgrade to ldc 1.12.0.
https://buildd.debian.org/status/fetch.php?pkg=vibe.d&arch=amd64&ver=0.8.4-1%2Bb1&stamp=1540811095&raw=0
/usr/include/d/common/deimos
severity 908670 important
unblock 908345 by 908670
thanks
> I think this solution makes the least effort for all involved parties
> and is in line with the practical use of this package on armhf.
I went ahead and filed the removal
requesthttps://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908920
Package: tpm2-abrmd
Version: 1.3.1-1.1
Severity: serious
tpm2-abrmd build-depends on libsapi-dev and depends on libsapi0, these packages
are no longer built by source package tpm2-tss. They appear to have been
replaced by libtss2-dev and libtss2-esys0 .
Package: tpm2-pk11
Version: 0~git20180426-1
Severity: serious
tpm2-pk11 build-depends on libsapi-dev and depends on libsapi0, these packages
are no longer built by source package tpm2-tss. They appear to have been
replaced by libtss2-dev and libtss2-esys0 .
package: gmrender-resurrect
version: 0.0.7~git20180618.d0f46f5-2
severity: serious
gmrender-resurrect build-depends on libupnp1.8-dev and it's binary package
gmrender depends on libupnp10. These packages are no longer built by pupnp-1.8.
They appear to have been replaced by libupnp-dev and libu
On 11/11/18 19:14, Nicolas Boulenguez wrote:
Package: src:gnat-gps
Followup-For: Bug #913371
Control: reopen -1
Version: 18-3
With parallelism disabled, the build should use (at least) two times
less memory at a given moment.
Virtual address space is per-process. So while disabling make-level
p
Package: keymapper
Version: 0.5.3-11
Severity: serious
keymapper depends on python-yapps2 which does not appear to exist, did you mean
to depend on python-yapps?
tags 913708 +patch
thanks
This was one of the few remaining blockers for the icu transition in raspbian
buster, so I hacked up a fix.
I am far from an expert (just a maintainer of a Debian derivative who ran into
this build failure) but here is my interpretation of what is going on.
mapbox::g
Package: plaso
Version: 1.5.1+dfsg-4
Severity: serious
plaso depends on python-dfwinreg which is no longer built by the dfwinreg
source package.
tags 914596 +patch
thanks
I noticed that python-casacore has a build-dependency on the cruft package
libcasa-python3-2 , if it is mixing libraries from different versions of
casacore then I imagine that could easily explain segfaults.
I went ahead and set the build-depends/conflicts for a cons
Package: shibboleth-resolver
Severity: serious
Version: 1.0.0-1
Tags: sid, patch
shibboleth-resolver FTBFS, there are three issues.
Firstly it fails to find log4shib because it tries to use log4shib-config which
no longer exists. I patched configure.ac to use pkg-config instead and enabled
aut
Package: openstack-deploy
Version: 0.25
Severity: serious
Tags: bullseye, sid
openstack-deploy depends on the python-keystoneclient binary package which is
no longer built by the corresponding source package.
Should this dependency be changed to python3-keystoneclient ?
Severity: serious
i'm not entirely convinced on the severity, IIRC established practice in Debian
is that arch all packages need to be buildable on at least one release
architecture, not all release architectures.
python-os-win/experimental FTBFS on i386 while building the (arch:all)
package
Package: python-os-win
Version: 4.0.0-3
Severity: serious
Tags: bullseye
Python-os-win in testing (build-)depends on a number of python2 packages that
are no longer built by the corresponding source packages.
This is already fixed in unstable, by dropping python 2 support, but the
unstable ver
Package: heudiconv
Severity: serious
Version: 0.5.3-1
heudiconv build-depends on the python-datalad binary package which in turn
depends on the python-fasteners binary package, which in turn depends on the
python-monotonic binary package which is no longer built by the
python-monotonic source
Package: rekall
Severity: serious
x-debbugs-cc: sa...@debian.org
x-debbugs-cc: ben...@debian.org
While sending https://lists.debian.org/debian-python/2019/08/msg00072.html I got
forensics-de...@lists.alioth.debian.org
(generated fromrek...@packages.debian.org)
host alioth-lists-mx.debi
Package: gst-plugins-good1.0
Version: 1.16.0-2
Severity: serious
The release team have decreed that non-buildd binaries can no longer migrate to
testing, please make a source-only upload so your package can migrate.
So the libvpx transition prompted me to take a look at this, I added some code
to debian/rules to create a fake homedir, use it for the build and remove it in
the clean target.
Unfortunately I then ran into another failure.
/firefox-esr/media/webrtc/trunk/webrtc/modules/video_coding/codecs/vp
Package: python-keepkey
Severity: serious
Version: 0.7.3-1
Tags: bullseye, sid
python-keepkey depends on the python-ecdsa binary package which is no longer
built by the corresponding source package.
If you want your package to stay around you need to migrate to python 3.
Package: sshpubkeys
Severity: serious
Version: 3.1.0-1
Tags: bullseye, sid
The python-sshpubkeys package depends on and the sshpubkeys source package
build-depends on the python-ecdsa binary package which is no longer built by
the corresponding source package.
It's probablly time to drop pytho
Package: python-trezor
Severity: serious
Version: 0.9.0-1
Tags: bullseye, sid
python-trezor (build-)depends on the python-ecdsa binary package which is no
longer built by the corresponding source package.
It's probablly time to drop python 2 support.
Package: design-desktop-graphics
Version: 3.0.13
Severity: serious
design-desktop-graphics depends on python-cairosvg which is no longer built by
the cairosvg source package.
Looking at the stated intent of this package and the content of the packages
built by the cairosvg source package I bel
Package: printrun
Version: 1.6.0-2
Severity: serious
Tags: bullseye, sid
printrun depends on python-cairosvg which is no longer built by the cairosvg
source package.
If you want your package to stay around you probably need to migrate to python
3.
Package: m2crypto
Version: 0.31.0-5
Severity: serious
The release team have decreed that binaries not built on a buildd can no longer
migrate to testing. Please make a source-only upload so your package can
migrate.
Package: python-novnc
Version: 1:1.0.0-1
Severity: serious
Tags: bullseye, sid
The python-novnc package depends on the python-oslo.config binary package which
is no longer built by the corresponding source package.
As far as I can tell if you want to keep novnc around you will need to migrate
Package: presentty
Version: 0.2.0-1
Severity: serious
Tags: bullseye, sid
Presentty (build-)depends on the python-pbr binary package which is no longer
built by the corresponding source package.
There is a bug report questioning whether said dependency is really necessary (
https://bugs.debian
Package: planet-venus
Version: 0~git9de2109-4.2
Severity: serious
Tags: bullseye, sid
planet-venus depends on python-portalocker which is no longer built by the
portalocker source package.
If you want your package to stay around you probably need to migrate to python
3.
Package: goopg
Version: 0.3.1-9
Severity: serious
goopg depends on the python-oauth2client binary package which is no longer
built by the python-oauth2client source package.
If you want your package to be in bullseye you need to migrate to python 3 (and
fix the other rc bug)
Package: kazoo
Version: 2.6.1-1
Severity: serious
python-kazoo depends on and the kazoo source package build-depends on the
python-eventlet binary package which is no longer built by the python-eventlet
source package.
It's probably time to drop python 2 support from this package.
Package: octave-octclip
Version: 1.0.8-6
Severity: serious
It seems that the new octave-octclip FTBFS in bullseye. I initially noticed
this in Raspbian, but it's also appearing on the reproducible builds site so it
doesn't seem to be raspbian specific.
fgeneral.c: In function 'Minimo':
fgener
Package: fmcs
Version: 1.0-1
Severity: serious
Tags: bullseye, sid
python-fmcs depends on and the fmcs source package build-depends on
python-rdkit which is no longer built by the rdkit source package.
If you want to keep this package around then you need to migrate to python 3
Package: haskell-blaze-html
Version: 0.9.1.1-3
Severity: serious
Tags: sid
haskell-blaze-html build-depends on libghc-quickcheck2-dev (< 2.12) but
unstable now has version 2.12.6.1-2
It looks like that class was dropped from vala-panel in
https://gitlab.com/vala-panel-project/vala-panel/commit/87493a6dfab9868f77b7b19b57fca40a06fe80af
Unfortunately the commit message doesn't give any clues to what if-anything it
should be replaced with.
If a proper fix cannot be found then
Package: rust-pangocairo
Version: 0.6.0-1
Severity: serious
Tags: sid
According to wanna-build rust-pangocairo's build-dependencies are
unsatisfiable. It looks like librust-cairo-rs-0.5+default-dev has been replaced
with librust-cairo-rs-0.7+default-dev .
Found 935015 0.11.2-2
Thanks
This bug also affects the version in testing.
Package: python-ceilometerclient
Version: 2.9.0-2
Severity: serious
Tags: bullseye, sid
The python-ceilometerclient binary package depends on and the
python-ceilometerclient binary package build-depends on a number of python 2
binary packages that are no longer built by their corresponding sour
On 28/08/2019 09:12, Debian Bug Tracking System wrote:
This is an automatic notification regarding your Bug report
which was filed against the virtualenvwrapper package:
#933822: virtualenvwrapper depends on cruft package python-stevedore
Is there a reason that the fix was only uploaded to expe
Package: gdcm-doc
Version: 2.8.8-9
Severity: serious
Tags: bullseye, sid
gdcm-doc depends on vtk6-doc which is no longer built by the vtk6 source
package.
Package: sbcl
Version: 2:1.5.6-1
Severity: serious
sbcl build-depends on texlive-generic-recommended which is no longer built by
texlive-base. The old texlive-generic-recommended is still present in unstable
as a cruft package, but is completely gone from testing.
Please update your build-depe
Package: metview
Version: 5.6.1-3
Severity: serious
It seems metview has recently started to fail to build on 32-bit,
/<>/atlas/src/tests/mesh/test_halo.cc: In function 'void
atlas::test::traced_test_105(std::string&, int&, int)':
/<>/atlas/src/tests/mesh/test_halo.cc:142:40: error: narrowing
Package: gnss-sdr
Version: 0.0.11-1
Severity: serious
gnss-sdr seems to have recently started failing to build with the following
error.
cd /build/1st/gnss-sdr-0.0.11/obj-x86_64-linux-gnu/src/utils/front-end-cal && /usr/bin/c++
-DBOOST_GREATER_1_65 -DGNSSSDR_INSTALL_DIR=\"/usr\" -DGNSS_SDR_V
Package: gr-gsm
Version: 0.42.2-1
Severity: serious
Tags: bullseye, sid
gr-gsm failed to build with the following errors when an attempt was made to
binnmu it for the new gnuradio.
CMake Warning at CMakeLists.txt:135 (find_package):
Found package configuration file:
/usr/lib/x86_64-li
Package: gr-limesdr
Version: 0.9~beta-1+b2
Severity: serious
Tags: bullseye, sid
gr-limesdr failed to build with the following errors when an attempt was made
to binnmu it for the new gnuradio.
-- Could NOT find MPIR (missing: MPIRXX_LIBRARY MPIR_LIBRARY MPIR_INCLUDE_DIR)
CMake Error at
/usr/
Package: gr-radar
Version: 0.0.0.20180308-1
Severity: serious
Tags: bullseye, sid
gr-radar failed to build with the following errors when an attempt was made to
binnmu it for the new gnuradio.
CMake Error at CMakeLists.txt:120 (find_package):
Could not find a configuration file for package
Package: sdaps
Version: 1.9.7-0.1
Severity: serious
sdaps build-depends on texlive-generic-recommended which is no longer built by
texlive-base. The old texlive-generic-recommended is still present in unstable
as a cruft package, but is completely gone from testing.
Please update your build-de
tags 939561 +fixed-upstream
tags 939561 +patch
thanks
Some googling revealed that upstream had fixed this issue
https://github.com/pothosware/SoapyBladeRF/pull/19 . I was able to take the
upstream pull request, turn it into a patch series and apply it to the Debian
package.
I have uploaded my
severity 938919 serious
thanks
python-zope.testrunner in testing depends on python-zope.exceptions which has
already been dropped by the zope.exceptions source package.
This has been addressed in unstable by dropping the python-zope.testrunner
binary package, however that fix cannot currently
Package: srslte
Version: 3.14.1.0-2
Severity: serious
srslte FTBFS in bullseye and sid due to the new versions of bladerf and uhd
changing some data types. I patched the errors and was able to get a successful
build in raspbian bullseye which I uploaded to the raspbian archive, I have not
test
Package: rust-async-std
Version: 1.12.0-5
Severity: serious
The autopkgtest for rust-async-std is failing and preventing it's migration to
testing.
error[E0425]: cannot find function `block_on` in module `task`
--> src/io/read/take.rs:231:15
|
231 | task::block_on(async move {
src:rust-rustls: fails to migrate to testing for too long: blocked by build
dependency
Specifically rust-async-std has taken some time to package, because of the
large number
of dependencies. There has been effort on this front both by the rust team and
by Jonas
who currently packages rust st
On 31/10/2022 16:17, Jonas Smedegaard wrote:
Quoting Peter Green (2022-10-31 03:39:28)
src:rust-rustls: fails to migrate to testing for too long: blocked by build
dependency
Specifically rust-async-std has taken some time to package, because of the
large number
of dependencies. There has
Package: ntopng
Version: 5.2.1+dfsg1-1
Severity: serious
It seems that ntopng recently started failing to build, I first noticed this on
a Raspbian
autobuilder, but it's also happening on the reproducible builds test
infrastructure so it's
not a raspbian specific issue.
https://tests.reproduci
On 21/06/2022 14:39, Jonas Smedegaard wrote:
Quoting Peter Green (2022-06-21 15:35:59)
What is status of this bug?
Status is that h2 still needs tower-service, Fabian prepared it but noone
got around to sponsoring it. I've just updated and uploaded it. Now it
needs to get through NEW.
T
tags 1011620 +patch
thanks
In addition to the gettext crates, proptest has also just received an update.
I bumped the dependencies in newsboat and it built fine, I haven't tested it
beyond that though.
Debdiff attatched, no intent to NMU.diff -Nru newsboat-2.21/debian/changelog newsboat-2.21/de
Another dependency just got updated. Debdiff to make the package build with
what is currently in sid attatched.
As before I have tested the package builds but not beyond that.diff -Nru elan-1.3.1/debian/changelog elan-1.3.1/debian/changelog
--- elan-1.3.1/debian/changelog 2022-02-24 04:54:40.000
401 - 500 of 1842 matches
Mail list logo
