Package: pygame
Severity: serious
The most recent attempt to build pygame on ppc64el failed with the following
error.
==
FAIL: test_render_args (pygame.tests.font_test.FontTest)
---
Package: pygame
Severity: serious
Version: 1.9.3+dfsg2
The two most recent attempts to build pygame on s390x failed with the following
error.
==
ERROR: test_write (pygame.tests.bufferproxy_test.BufferProxyLegacyTest)
Package: haskell-raaz
Severity: serious
Version: 0.2.0-2
haskell-raaz recently failed to build in raspbian buster with
dh_installexamples -plibghc-raaz-dev
dh_installexamples: Cannot find (any matches for) "bin/Command/Checksum.lhs"
(tried in .)
The reproducible builds tests on amd64, armhf
Package: libsass-python
Severity: serious
Version: 0.13.4-1
A new version of libsass was recently uploaded which transitioned to a new
libary soname and appears to have changed the API in a way that causes
libsass-python to fail to build.
i686-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -W
Package: freedv
Version: 1.3-1
Severity: serious
freedv failed to build during the binnmu for the libcodec transition.
https://buildd.debian.org/status/package.php?p=freedv&suite=unstable
dh_installdocs -a -O--builddir=Build -O--build-system=cmake
dh_installdocs: Cannot find (any matches for
During a recompilation as part of the octave-4.4 transition, libsbml failed to
build (for a reason apparently unrelated to the transition):
Specifically this seems to have been caused by the change of default java
version from 9 to 10.
In raspbian buster I solved this for the time being by for
I (with my raspbian maintainer hat on) reported this to ldc upstream at
https://github.com/ldc-developers/ldc/issues/2848 and some digging has been
done. The short version is that we know what commit caused the build failures.
However that commit was a fix for mis compilation, so I don't think
Package: libpam-google-authenticator
Severity: serious
Tags: patch
libpam-google-authenticator depends on libqrencode3, which has no longer built
from the qrencode source package. It has been replaced by libqrencode4. This
dependency is hard coded and does not change after a re-build. Looking a
On 13/09/18 21:49, Andreas Tille wrote:
Hi Peter,
thanks a lot for your analysis.
On Thu, Sep 13, 2018 at 01:27:58PM +0100, peter green wrote:
4. Simply get libundead removed on armhf/raspbian. libundead seems to only have
two reverse build-dependencies neither of which has ever successfully
clang-6.0 and friends advertise their default target on armhf as
armv8l-unknown-linux-gnueabihf, which sounds like nonsense.
Not really "nonsense", armv8 is best known for adding 64-bit mode but it did
also add some enhancements for the 32-bit architecture. I don't know if clang has the
ability
Package: github-backup
Version: 1.20170301-1
Severity: serious
x-debbugs-cc: barak+...@pearlmutter.net
github-backup build-depends on haskell-github << 0.16.0 but sid has 0.16.0-1
and buster doesn't have the package at all. So github-backup's build-depends are not
satisfiable in either unstable
During a rebuild of all packages in sid, your package failed to build on
amd64.
The good news is that this particular build failure seems to have been fixed in
the most recent upload to sid.
The bad news is that when binnmuing for the python2.7 removal of "fpectl"
symbols the package failed wi
Marble currently FTBFS in unstable due to a couple of missing symbols and this
is preventing the libgps transition from finishing up. The version in
experimental fixes the issue but it looks like uploading it to unstable would
start a transition.
What are the plans here? are the symbols that d
Package: rpm2html
Severity: serious
Tags: buster sid
From the buildd logs for the rpm transition binnmus.
headerInitIterator
rpmopen.c: In function 'rpmOpen':
rpmopen.c:1052:20: error: storage size of 'lead' isn't known
struct rpmlead lead;
^~~~
rpmopen
Package: python-django-compression
Version: 2.2-3
Severity: serious
python-django-compressor depends on the obsolete transitional package
python-appconf which is no longer built by python-django-appconf. Please update
your dependency so that the obsolete transitional package can be decrufted.
Jumping straight to removing an architecture from the architecture list and filing a
removal request over a build failure with no evidence of an attempt at a fix and no
attempt to bring it up with the porters is not in line with "Packages must be
supported on as many architectures as is reasona
package: python-expyriment
severity: serious
python-expyriment still depends on the transitional package ttf-freefont which
is no longer bulit by it's source package. The dependency needs to be updated
so it can be decrufted.
I intend to put together a NMU for this issue and for the existing r
Given the lack of maintainer response to this bug I have uploaded a NMU.
Debdiff attatched.
diff -u freevial-1.3/debian/control freevial-1.3/debian/control
--- freevial-1.3/debian/control
+++ freevial-1.3/debian/control
@@ -19,7 +19,7 @@
python-pygame (>= 1.7),
python-lxml,
fonts-unfonts-
tags 872240 +pending
tags 882560 +pending
thanks
I have uploaded a NMU for python-expyriment to delayed/5 adding the missing
build-dependency and fixing the freefont dependency.
diff -Nru python-expyriment-0.7.0+git34-g55a4e7e/debian/changelog
python-expyriment-0.7.0+git34-g55a4e7e/debian/cha
tags 738260 +pending
severity 738260 serious
thanks
The package provides a transitional package but we would like to drop
it and therefore we need packages that depend on ttf-freefont to
switch their dependency to fonts-freefont-ttf.
The transitional package is no longer built by its source pa
Package: gtkdataboxmm
Version: 0.9.4-3
Tags: stretch, sid
Severity: serious
gtkdataboxmm build-depends on libgtkdatabox-0.9.2-0-dev which is no
longer built by source package libgtkdatabox
Package: xoscope
Version: 2.2-0.1
Tags: stretch, sid
Severity: serious
xoscope build-depends on libgtkdatabox-0.9.2-0-dev which is no longer built by
source package libgtkdatabox
Package: brp-pacu
Version: 2.1.1+git20111020-5
Severity: serious
brp-pacu build-depends on libgtkdatabox-0.9.2-0-dev | libgtkdatabox-dev
. Debian autobuilders only look at the first option.
libgtkdatabox-0.9.2-0-dev is now an obsolete package (no longer built by
the libgtkdatabox source).
P
Package: typerep
Severity: serious
Your package build-depends on libbin-prot-camlp4-dev which is no longer
built by the bin-prot source package.
It looks like the replacement is libbin-prot-ocaml-dev but I don't know
if it's safe to just change the build-dependency or if further changes
are
Package: rust-ripgrep
Version: 0.10.0-1
Severity: serious
While performing a test build on s390x to see if bug 916615 was actually fixed
I ran into a new error. I then did a test build on amd64 and was able to reduce
the same testsuite failure, so this doesn't seem to be architecture specific.
+
_Z27qRegisterNormalizedMetaTypeIP7QActionEiRK10QByteArrayPT_N9QtPrivate21MetaTypeDefinedHelperIS5_Xaasr12QMetaTypeId2IS5_E7DefinedntsrSA_9IsBuiltInEE11DefinedTypeE@Base
2.6~beta-4
(optional=templinst)_Z30copyPtrIntArrayToQListTemplateIP13QGraphicsItemEvPvR5QListIT_E@Base
2.6~alpha
(op
tags 888345+patch
thanks
I backported the upstream ffmpeg 4.0 patches to the version in Debian and was
able to get a successful build in raspbian buster, I have not tested the
results beyond that. A debdiff can be found at.
http://debdiffs.raspbian.org/main/f/forked-daapd/forked-daapd_25.0-2%2
package: dracut
version: 047+31-2
severity: serious
dh_installdocs -a
dh_installdocs: Cannot find (any matches for) "README.Debian" (tried in .)
install -d debian/dracut-core/usr/share/doc/dracut-core
debian/rules:8: recipe for target 'binary-arch' failed
I initially noticed this
tags 888374 +patch
thanks
Since this package has rdeps and there seemed to be no maintainer response I
decided to take a look.
The good news is I got it building, the bad news is that in order to do so I
had to disable vdpau support. It seems that struct vdpau_render_state has
disappeared and
I applied the patch that jcowgill submitted upstream plus another upstream
commit and disabled vdpau support (which has been removed upstream) and was
able to get the debian package to build, so I uploaded it to raspbian.
A debdiff should appear soon at https://debdiffs.raspbian.org/main/liba/l
Package: pygame
Version: 1.9.3+dfsg2-2
Severity: serious
pygame fails to build with python 3.7
src/pypm.c:4976:18: error: 'PyThreadState {aka struct _ts}' has no member named
'exc_type'; did you mean 'curexc_type'?
if ((tstate->exc_type != NULL) & (tstate->exc_type != Py_None)) {
I und
Package: calligra
Version: 3.1.0+dfsg-2
Severity: serious
Tags: patch
Looks like calligra recently started to FTBFS, I first saw this in raspbian but
it is also happening on the reproducible builds test infrastructure, so it's
not raspbian specific.
http://buildd.raspbian.org/status/fetch.php?
Package: python-meep-mpich2
Version: 1.7.0-2
Severity: serious
https://piuparts.debian.org/sid/fail/python-meep-mpich2_1.7.0-2.log
Setting up python-meep-mpich2 (1.7.0-2) ...
dpkg-query: package 'python-meep' is not installed
Use dpkg --contents (= dpkg-deb --contents) to list archive fil
Package: python-meep-lam4
Version: 1.7.0-2
Severity: serious
https://piuparts.debian.org/sid/fail/python-meep-lam4_1.7.0-2.log
Setting up python-meep-lam4 (1.7.0-2) ...
dpkg-query: package 'python-meep' is not installed
Use dpkg --contents (= dpkg-deb --contents) to list archive files cont
reassign 914607 dfwinreg
found 914607 20180712-1
fixed 914607 20181214-2
thanks
Britney gets confused when a bug is closed by a package other than the one it
is filed against, so I am reassinging the bug to the package that closed it.
On 01/01/19 23:09, Debian Bug Tracking System wrote:
This i
package: python3-dfwinreg
version: 20180712-1
severity: serious
It seems that with the most recent upload the build-dependencies were fixed from "dtfabric" to
"python-dtfabric" and "python3-dtfabric", but the binary dependencies for python-dfwinreg and
python3-dtwinreg are still on "dtfabric",
tags 918326 +patch +pending
tags 918645 +patch +pending
thanks
I just went ahead and uploaded a NMU fixing bugs 918326 (dependency on cruft
package) and 918645 (testsuite failure due to missing build-dependency) to
delayed/5. A debdiff is attatched, please tell me if you have any issues with
t
Package: python-gpiozero
Version: 1.4.1-1
Severity: serious
The 1.4.1-1 upload of gpiozero added the "pinout" utility, unfortunately it
added it to both the python-gpiozero and python3-gpiozero packages. The result is a file
conflict between the two packages.
I see two possible solutions.
1.
Package: cmtk
Version: 3.3.1-1.2
Severity: serious
cmtk FTBFS in sid. Preusmablly this is caused by the new dcmtk
https://buildd.debian.org/status/fetch.php?pkg=cmtk&arch=amd64&ver=3.3.1-1.2%2Bb2&stamp=1547410724&raw=0
/<>/apps/dcm2image.cxx: In function 'void AddPatternToMap(std::map >&, cons
Package: dicomscope
Version: 3.6.0-19
Severity: serious
dicomscope FTBFS in sid, I presume this is the result of the dcmtk transition
but I am not 100% positive.
/<>/interface/libsrc/DVInterface.cpp: In function '_jstring*
Java_J2Ci_jDVInterface_getTargetCipherSuite(JNIEnv*, jobject, jstring,
Package: orthanc-wsi
Severity: serious
Version: 0.5-2
orthanc-wsi fails to build in unstable, I presume this was triggered by the
dcmtk transition.
https://buildd.debian.org/status/fetch.php?pkg=orthanc-wsi&arch=amd64&ver=0.5-2%2Bb3&stamp=1547409452&raw=0
/<>/BuildApplications/Orthanc-1.3.2/C
Package: mariadb-10.1
Version: 1:10.1.37-3
Severity: serious
During rebuilds for the jemalloc transition mariadb-10.1 failed to build on
most architectures with the following error on most architectures ().
Completed: Failed 2/4906 tests, 99.96% were successful.
Failing test(s): main.mysqldum
Package: libreoffice
Version: 1:6.1.4-1
Severity: serious
The arch all build for libreoffice 1:6.1.5~rc1-1 (
https://buildd.debian.org/status/fetch.php?pkg=libreoffice&arch=all&ver=1%3A6.1.5%7Erc1-1&stamp=1547977527&raw=0
) failed with
javadoc: error - The code being documented uses modules b
package: ntomng
version: 2.4+dfsg1-4
severity: serious
ntopng fails to build from source with the new ndpi, which recently migrated to testing.
This affects both the version in buster (as evidenced by the raspbian binnmu
http://buildd.raspbian.org/status/fetch.php?pkg=ntopng&arch=armhf&ver=2.4%
Package: sagemath
Version: 8.4-2
Severity: serious
sagemath versions from 8.4-2 through to 8.6-2 have failed to build on mipsel
and mips64el.
mipsel is failing with
Success: 42 tests failed, up to 90 failures are tolerated
Error: critical test failures (e.g. timeout, segfault, etc.)
make[2]:
tags 856413 +pending
tags 919617 +patch +pending
tags 919620 +patch +pending
thanks
I have now prepared a NMU for gpiozero addressing bugs 856413, 919617 and
919620. I have uploaded this NMU to delayed/10. A debdiff is attatched to this
mail.
Please tell me if you see any issues with this NMU
tags 856413 +pending
tags 919617 +patch +pending
tags 919620 +patch +pending
thanks
I have now prepared a NMU for gpiozero addressing bugs 856413, 919617 and
919620.
I have uploaded this NMU to delayed/10. A debdiff is attatched to this mail
(really attatched this time, sorry).
Please tell me i
tags 919742 +patch
thanks
Since this seemed to be the last thing blocking the dcmtk transition in
raspbian buster I decided to take a look.
It seems that orthanc-wsi has an embedded copy of an old version orthanc, it
also build-depends on orthanc-dev,
I am not sure if the system orthanc is unu
I have uploaded a NMU fixing this bug, a debdiff is attatched. Per the NMU
guidelines since this RC bug is 7 days old with no maintainer response I have
uploaded the NMU without delay.
diff -Nru ntopng-3.8+dfsg1/debian/changelog ntopng-3.8+dfsg1/debian/changelog
--- ntopng-3.8+dfsg1/debian/chan
Since upstream claimed this issue could not be reproduced, I decided to run a
test on zelenka.debian.org
The build did fail with a testsuite failure, but it looked nothing like the one in the
buildd log. Rather than most tests passing and a few failing most tests failed, I looked
at a few of t
Package: rust-ripgrep
Version: 0.10.0-1
Severity: serious
While testing to see if 916615 was still reproducible (it is :( ) I ran into
another issue
with the testsuite. By default it uses a fixed directory name in /tmp ,
specifically
/tmp/ripgrep-tests . If this directory already exists and is
Package: llvm-toolchain-snapshot
Version: 1:3.7~svn239806-1
Severity: serious
dpkg-buildpackage: host architecture arm64
fakeroot debian/rules clean
dpkg-query: no packages found matching g++-5.2
dpkg: error: --compare-versions takes three arguments:
<--snip many similar errors-->
dpkg-archi
Oh, and by the way, it seems that the potential removal of lazarus and
its reverse dependencies is not due to this bug, but because of the
fixed bug 777970, see the tracker:https://tracker.debian.org/pkg/lazarus
Which is now fixed in testing, so no longer an issue.
And if I am correct, as l
reopen 792685
tags 792685 +jessie
thanks
You closed the bug in a nonexistant version. Furthermore the bug isn't
"fixed" per-se it's just not applicable to stretch/sid (because we don't
support direct upgrades from wheezy to stretch/sid). The correct way to
indicate that a bug is not applicabl
package: rss2irc
version: 1.0.6-3
severity: serious
tags: sid stretch
according to
https://buildd.debian.org/status/package.php?p=rss2irc&suite=unstable
rss2irc build-depends on missing:
- amd64:libghc-irc-dev (< 0.6)
packages.debian.org confirms that the version of libghc-irc-dev in sid
and
On 04/01/17 22:03, Ian Jackson wrote:
Control: severity -1 critical
peter green writes ("Bug#849041: dgit: psuedomerge commits have no author."):
Unfortunately I ran into a problem. It seems that the psuedomerge
commits generated by dgit have no author: field and this makes it
imp
Package: ceph
Severity: serious
Version: 10.2.5-4
ceph failed to build on all 32-bit architectures. The following error messages
are taken from the i386 log, armel looked similar, I haven't checked the others.
configure:23432: checking xfs/xfs.h usability
configure:23432: g++ -c -g -O2 -fdebug-
Package: ceph
Version: 10.2.5-5
Severity: serious
x-debbugs-cc: debian-...@lists.debian.org
The most recent upload of ceph fixed the build on most architectures but
unfortunately armel is still failing.
libtool: relink: g++ -fPIC -DPIC -shared -nostdlib
/usr/lib/gcc/arm-linux-gnueabi/6/../../
Summarising a number of bug reports by Helmut Ghrone:
Please ensure that librust---dev has sufficient Breaks and
Replaces declarations.
The issue specifically appears to be that the breaks+replaces are declared
against a virtual package, it seems dpkg is honoring the breaks against the
virtua
On 28/04/2023 06:05, Helmut Grohne wrote:
Can you go into more detail as to what you mean with "don't support
version ranges"?
You can place a lower bound on the version, place an upper bound
on the version or constrain to a precise version. But you can't
constrain to a range of versions.
I
On 28/04/2023 18:58, Fabian Grünbichler wrote:
I see no practical issue with 2 meaning we can't have multiple semver
suffix packages variants of a single crate installed - having the
unversioned and one semver suffix package in one suite at any given time
should already be the exception, having m
Package: rust-mysqlclient-sys
Severity: serious
I was looking at why rust-diesel was not migrating to testing
(other than the freeze obviously) and noticed that rust-mysqlclient-sys
was not built on 32-bit architectures. As with a bunch of other
packages I correctly suspected this was mostly a ca
Package: pushpin
Version: 1.36.0-2
Severity: serious
Tags: trixie, sid, ftbfs, patch
pushpin FTBFS with the new version of rust-base64 due to an upper limit
on the dependency in Cargo.toml. If I remove the upper limit then the code
builds fine.
(I prepared a debdiff, but it ended up with a bunch
sorry i over-filtered the debdiff, I think this one is correctly filtered.
diff -Nru hippotat-1.1.7/Cargo.toml hippotat-1.1.7+nmu1/Cargo.toml
--- hippotat-1.1.7/Cargo.toml 2023-01-12 18:50:36.0 +
+++ hippotat-1.1.7+nmu1/Cargo.toml 2023-06-11 19:36:36.0 +
@@ -30,7 +30
Package: rust-ureq
Version: 2.6.2-3
Severity: serious
Tags: trixie, sid, patch, ftbfs
rust-base64 was recently updated to 0.21 making rust-ureq unbuildable and
uninstallable.
Upstream already has a fix, I grabbed it and added it to the Debian package and
it
built and passed autopkgtests fine.
+
@@ -1,3 +1,10 @@
+aardvark-dns (1.4.0-3.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Remove upper limit from cargo dependency on async-broadcast.
+
+ -- Peter Michael Green Thu, 15 Jun 2023 17:16:42 +
+
aardvark-dns (1.4.0-3) unstable; urgency=medium
[ Peter
Package: sccache
Version: 0.4.0~~pre8-8
Severity: serious
Tags: patch
Recent updates to the rust crates in Debian mean that sccache needs a few
tweaks.
Firstly sccache has a dependency on librust-bstr+default-dev which seems
to be unused, we would appreciate it if you could drop this as it's
pre
reassign 1038138 rust-diesel-derives
tags 1038138 +trixie +sid
thanks
In trying to rebuild rust-diesel with the fix for bug #1038135, I've
discovered the package now fails to build from source in both Debian
unstable and Ubuntu mantic:
This is actually in issue in rust-diesel-derives, it's inc
Package: rust-sequoia-keyring-linter
Version: 1.0.0-1
Severity: serious
rust-rpassword was recently updated to version 6.x, but sequoia-keyring-linter
still depends on version 5.x. I have checked crates.io and upstream git, and
there does not appear to be an upstream patch available.
on bumping
Package: librsb
Version: 1.3.0.2+dfsg-1
Tags: bookworm, sid
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
User: debian...@lists.debian.org
Usertags: edos-uninstallable
librsb build-depends on coccinelle which appears to have been removed
on armh
reopen 1007026
thanks
* Revert to nom 4, porting to nom 7 seems to be non-trivial and I do not
want to further increase the proliferation of nom versions in Debian.
As I said in the initial mail, I did indeed patch weedle to revert
to nom 4. However in doing so I caused an API break. As
The following packages have unmet dependencies:
librust-rust-code-analysis-dev : Depends: librust-petgraph-0.5+default-dev
Depends: librust-phf-0.8+default-dev
Depends: librust-phf-0.8+macros-dev
The following packages have unmet dependencies:
librust-rspotify-dev : Depends: librust-base64-0.12+default-dev
Depends: librust-itertools-0.9+default-dev
Depends: librust-rand-0.7+default-dev
Depends: librust-reqwest-0.9+de
I've prepared an NMU for rust-kvm-bindings (versioned as 0.5.0-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I should cancel it.
It's not my place to tell you to cancel it, but I can tell you that it
it will not clear the path for testing migration.
The new version of rust-k
severity 103 normal
retitle 103 rust-encoding is unmaintained upstream
severity 104 normal
retitle 104 rust-boxfnonce is unmaintained upstream
severity 105 normal
retitle 105 rust-const-cstr is unmaintained upstream
(summarising several bugs)
there is https://rustsec.org/
Package: python3-brial
Version: 1.2.11-2
Severity: serious
X-debbugs-cc: singu...@packages.debian.org
python3-brial recently added a dependency on python3-sage, however python3-sage
is only available on amd64, arm64, i386 and riscv64.
This also means that the build-depends of singular on those a
Package: singular
Version: 1:4.3.1-p3+ds-1
Severity: serious
Justification: rc-policy - "Packages must be buildable within the same release"
singular build-depends on python3-brial. python3-brial recently added a
dependency on python3-sage making it uninstallable on many architectures.
As a resul
Package: libgraphicsmagick-q16-3
Version: 1.4+really1.3.39-2
Severity: serious
libgraphicsmagick-q16-3 has a hardcoded dependency on libtiff5,
so even after binnmuing for the tiff transition it still depends on it
This affects both the version in bookworm and the version in sid,
I have not check
Package: dask.distributed
Version: 2022.12.1+ds.1-1
Severity: serious
X-debbugs-cc:
pkg-grass-de...@lists.alioth.debian.org,debian-science-maintain...@lists.alioth.debian.org
The autopkgtest for dask.distributed is failing.
https://ci.debian.net/data/autopkgtest/testing/amd64/d/dask.distributed
Your package src:rust-sequoia-net has been trying to
migrate for 94 days [2] (yes, partially due to the freeze).
This package was uploaded to unstable by mistake, it should
have been uploaded to experimental. Since it wasn't built
on any architectures I decided the least disruptive thing
to do
Package: librust-block-buffer-0.9+block-padding-dev
Version: 0.9.0-2
Severity: serious
Tags: trixie, sid
librust-block-buffer-0.9+block-padding-dev is uninstallable after the
update of rust-block-padding to version 0.3.
It would be possible to fix this by introducing a rust-block-padding-0.2
pac
Package: hyperspy
Version: 1.7.3-1
Tags: trixie, sid
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
User: debian...@lists.debian.org
Usertags: edos-uninstallable
hyperspy build-depends on python3-ptable, which was recently removed from
Debian.
Package: facet-analyser
Version: 0.0~git20221121142040.6be10b8+ds1-3
Tags: trixie, sid
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
User: debian...@lists.debian.org
Usertags: edos-uninstallable
x-debbugs-cc: s...@debian.org
facet-analyser build
Package: newsboat
Version: 2.32-2
Severity: serious
Tags: patch
rust-lexopt was recently updated to 0.3, leaving newsboat's build-depends
unsatisfiable. The fix is trivial, just removing a hunk from a patch
and updating the build-dependency.
debdiff attatched, I may or may not NMU this later.dif
I'd be very interested in knowing what this self-conflict is supposed to
achieve.
It is common upstream for there to be multiple semver-incompatible versions
of each rust crate in use at a given time. Incompatibilities can range from
minor corner cases that are easily patched away to complete re
Package: ocaml-mm
Version: 0.8.1-1
Tags: trixie, sid
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
User: debian...@lists.debian.org
Usertags: edos-uninstallable
ocaml-mm build-depends on dune, in bullseye this was a transitional package
built by
Package: ocaml-pprint
Version: 20220103-1
Tags: trixie, sid
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
User: debian...@lists.debian.org
Usertags: edos-uninstallable
ocaml-pprint build-depends on dune, in bullseye this was a transitional packa
Package: ocaml-unix-errno
Version: 0.6.1-2
Tags: trixie, sid
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
User: debian...@lists.debian.org
Usertags: edos-uninstallable
ocaml-pprint build-depends on dune, in bullseye this was a transitional pack
Package: coq-quickchick
Version: 2.0-1
Tags: trixie, sid
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
User: debian...@lists.debian.org
Usertags: edos-uninstallable
coq-quickchick build-depends on dune, in bullseye this was a transitional
packa
Package: golang-gitlab-gitlab-org-labkit
Version: 1.17.0-2
Tags: trixie, sid
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
User: debian...@lists.debian.org
Usertags: edos-uninstallable
golang-gitlab-gitlab-org-labkit build-depends on golang-goog
Package: rust-ureq
Version: 2.7.0-1
Severity: serious
Hi.
A change to error reporting in serde_json 1.0.94, intended to prevent
duplicate error messages broke an error-handling code-path in ureq.
ureq's initial fix was to impose an upper limit on the version of
serde_json. Later a proper fix wa
Package: rust-rustls-0.20
Version: 0.20.8-7
Severity: serious
Tags: patch
rust-rustls-0.20 has test-dependencies that contain "0.20-0.20", these
are unsatisfiable and I assume are the result of a search and replace
gone wrong.
After replacing "0.20-0.20" with just "0.20" the autopkgtest passes
s
Package: aardvark-dns
Severity: serious
aardvark-dns build-depends on librust-clap+derive-dev, this is a virtual package
provided by both librust-clap-dev and librust-clap-3-dev, it is also a cruft
physical package which I would like to see decrufted as I belive is it the cause
of spurious puipar
Package: netavark
Severity: serious
netavark build-depends on librust-clap+derive-dev, this is both an uninstallable
cruft physical package, and a virtual package provided by both librust-clap-dev
and librust-clap-3-dev. Depending on which one is selected when installing
build-dependencies your p
During a rebuild of all packages in sid, your package failed to build
on amd64.
I make the following observations about this package.
* It relies on perma-unstable rustc features and this is the third time it
has broken in the last two years due to changes in rustc.
* It has no long-term fut
Package: rust-svgdom
Version: 0.18.0-2
Severity: serious
svgdom depends on version 0.7 of the roxmltree crate. Debian sid now has version
0.16.
I tried bumping the dependency but it fails to build with the following errors.
error[E0599]: no method named `write_buf` found for struct `Document`
Package: guymager
Version: 0.8.13-1
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
User: debian...@lists.debian.org
Usertags: edos-uninstallable
guymager build-depends on libprocps-dev which is no longer built
by the procps source package. It is
Package: open-vm-tools
Version: 2:12.1.5-1
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
User: debian...@lists.debian.org
Usertags: edos-uninstallable
open-vm-tools build-depends on libprocps-dev which is no longer built
by the procps source pac
Source: tiledb-py
Version: 0.18.2-1
Severity: serious
Justification: rc policy - "Packages must be buildable within the same release"
x-debbugs-cc: e...@debian.org
User: debian...@lists.debian.org
Usertags: edos-uninstallable
tiledb-py build-depends on libtiledb-doc, which is no longer built by t
Source: byte-buddy
Version: 1.8.2-2
Severity: serious
Tags: bookworm, sid
Justification: rc policy - "Packages must be buildable within the same release"
User:debian...@lists.debian.org
Usertags: edos-uninstallable
byte-buddy build-depends on libasm-java-doc which is longer built by the asm
sour
1 - 100 of 1842 matches
Mail list logo
