Package: rust-rustls-native-certs
Severity: serious
Tags: trixie, sid
I just updated the serial-test crate to version 2.0. rust-rustls-native-certs
needs a small update to the Debian dependency to match. (the Cargo
dependency already allows both versions).
Debdiff attatched.
diff -Nru rust-rustl
Package: precious
Severity: serious
Tags: trixie, sid
I just updated the serial-test crate to version 2.0. Precious
needs a small update to the Debian dependency to match. (the Cargo
dependency already allows both versions).
Debdiff attatched.diff -Nru precious-0.5.1+20230704/debian/changelog
p
Package: squeekboard
Version: 1.22.0-3
Severity: serious
The rust gtk stack is currently being updated in Debian,
squeekboard needs a small patch
Please test that squeekboard works with this patch and
if-so apply it.diff -Nru squeekboard-1.22.0/debian/changelog
squeekboard-1.22.0/debian/changel
On 28/07/2023 08:07, Jonas Smedegaard wrote:
Control: block -1 by 1042427
Quoting Peter Green (2023-07-28 05:20:53)
I just updated rust-cookie-store. Ureq needs it's debian
dependencies adjusting to account for this (the cargo
dependencies already allow the new version.
Thanks for the u
Package: rust-ureq
Tags: trixie, sid
Severity: serious
I just updated rust-cookie-store. Ureq needs it's debian
dependencies adjusting to account for this (the cargo
dependencies already allow the new version.
Debdiff attatched, I may or may not NMU this later.diff -Nru rust-ureq-2.7.1/debian/ch
Package: rust-rustls-webpki
Version: 0.101.1
Severity: serious
building the rustls-webpki crate with only the alloc feature
(and not the std feature) is broken. I took a look at fixing
it but came to the conclusion that doing so was beyond what
was reasonable to do in a distribution patch.
Since
block 1025912 by 1042405
thanks
On 22/07/2023 06:16, peter green wrote:
rust-test-case - jonas package, only seems to be used for tests, further
investigation needed.
Seems to build and run autopkgtests fine after bumping the dependency. Debdiff
attatched.
squeekboard - not investigated
Package: squeekboard
Severity: important
Tags: trixie, sid
The rust team are currently looking at updating serde-yaml to 0.9.x
(specifically 0.9.21).
I tried patching squeekboard to use the new version but I get a bunch
of test failures. Can someone who is familiar with the codebase take
a look.
Package: sccache
Version: 0.5.4
Severity: serious
sccache has a couple of FTBFS issues.
The first is that a couple of dependencies have been updated, dealing
with this is a simple matter of dropping patches and updating
dependencies.
The second is that the build runs out of address space on mip
I've just patched rust-droid-juicer to use the new version of goblin.
It built fine, but given the lack of any meaningful tests in the
package I don't feel comfortable uploading it to unstable until
someone more familiar with the software has tested it.
I have uploaded the patched version to expe
Package: rust-rustls-0.20
Version: 0.20.8-8
Severity: serious
The autopkgtests for rust-rustls-0.20 fail due to a missing test CA.
I missed this when filing my previous bug due to not testing in a
clean environment.
I can think of several potential solutions for this.
1. Have the tests for the
Package: rust-rustls
Version: 0.21.5-4
Severity: serious
The autopkgtest for rust-bencher depends on librust-bencher-0.4+default-dev,
however version 0.4 of bencher does not exist, so I presume this was a typo.
After fixing the dependency the autopkgtest passed in my local testing.
A debdiff is
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
in the Debian packaged
environment.
On 22/07/2023 03:14, Peter Green wrote:
I just did a preliminary analysis of the reverse dependencies and it's looking
pretty good.
(details below). Though I would like to wait until I have confirmation that
rust-selectors
has migrated to testing.
Mat
I looked through some of the reverse dependencies.
lintian-brush - no changes seem to be needed.
rust-alacritty builds and passes smoke test after pointing at patched
alacritty-config and alacritty-terminal
rust-alacritty-config cargo test --all --all-targets --all-features passes
after bumping
I just did a preliminary analysis of the reverse dependencies and it's looking
pretty good.
(details below). Though I would like to wait until I have confirmation that
rust-selectors
has migrated to testing.
Matthias, would you object to me updating rust-ruma-common to 0.11.x as part of
this u
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
tags 1024134 +pending
thanks
Please upgrade to newer upstream release v0.2.1 (or newer), needed by
projects I am preparing for Debian.
noctis has prepared an update for rust-chrono-humanize and I have prepared
one for it's reverse dependency rust-lsd, however I think it is prudent to
wait unti
Package: filespooler
Tags: trixie, sid
We have ended up with three versions of the clap crate in Debian.
I'd like to reduce that number. Ideally to only one, but reducing
it from three versions to two would be an improvement.
I'm looking at clap v3 first for a few reasons.
* it was only the "la
Package: precious
Tags: trixie, sid, fixed-upstream
We have ended up with three versions of the clap crate in Debian.
I'd like to reduce that number. Ideally to only one, but reducing
it from three versions to two would be an improvement.
I'm looking at clap v3 first for a few reasons.
* it was
reassign 1040877 netavark
thanks
> Package: aardvark-dns
Sorry this bug report was supposed to be for netavark
Tags: trixie, sid, fixed-upstream
We have ended up with three versions of the clap crate in Debian.
I'd like to reduce that number. Ideally to only one, but reducing
it from three ve
>
https://github.com/containers/netavark/commit/f0d5cc86ba3460a2c8e73d734f32a5095d60813a
Sorry, the homepage link for aardvark-dns pointed me to the netavark repo,
the commit for aardvark-dns is.
https://github.com/containers/aardvark-dns/commit/e6ce1a5bb8b2a91edb1424a6f32d7281c0dfce03
Package: aardvark-dns
Tags: trixie, sid, fixed-upstream
We have ended up with three versions of the clap crate in Debian.
I'd like to reduce that number. Ideally to only one, but reducing
it from three versions to two would be an improvement.
I'm looking at clap v3 first for a few reasons.
* it
Package: aardvark-dns
Tags: trixie, sid, fixed-upstream
We have ended up with three versions of the clap crate in Debian.
I'd like to reduce that number. Ideally to only one, but reducing
it from three versions to two would be an improvement.
I'm looking at clap v3 first for a few reasons.
* it
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: 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: 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: 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-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 contains a patch to remove feature block-padding, with no DEP-3
patch headers indicating why
I did it to get the new rust-aes into testing quicker while we wait for
either rust-block-buffer-0.9 and it's rdeps to get autoremoved from
testing, or some other resoloution that allows rust-bl
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: 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
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: 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: 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
severity 1020890 serious
tags 1020890 +trixie +sid
thanks
Jonas recently requested updates of two more rustcrypto packages block-buffer
and block-padding, on the
one hand I think these should be updated, on the other hand I don't really want
to further increase the
number of packages for whic
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
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: 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
+
@@ -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: 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.
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: 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
Package: hippotat
Version: 1.1.7
Tags: trixie, sid, ftbfs, patch
hippotat FTBFS with the new version of rust-base64.
I attach a patch which makes the package build.
I have not tested it beyond that (and the build said it was
skipping tests due to lack of unshare).
Also your clean target is horr
severity 1036794 serious
tags 1036794 +pending
thanks
In Ubuntu, we've noticed the pangocairo test suite fails because it
depends on the Errors struct of gir-format-check implementing Display.
Updating gir-format-check to 0.1.2 or above should solve the issue.
Thanks, this is happening on deb
After the bat binary was renamed from batcat to bat and back to batcat, the man
page is no longer installed:
This appears to have not been directly related to the renames, instead
it appears that Sylvestre disabled the manpage in version 0.18.3-1,
unfortunately the commit message does not say w
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: tracker.debian.org
The "news" on the tracker pages seems to be updating, but the information
on package versions does not. This is most noticable for new Packages
where the page still says "Package is gone" over a week after the
package was first uploaded.
https://tracker.debian.org/pkg
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
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
reassign 1034865 rust-virtiofsd
thanks
On 28/04/2023 05:23, Michael Tokarev wrote:
I'm sorry about this.. - I planned but forgot to include the link,
here it is:
https://buildd.debian.org/status/fetch.php?pkg=rust-virtiofsd&arch=riscv64&ver=1.5.1-2&stamp=1682451850&raw=0
The real error seems
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
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: 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
It would be nice to have a new upstream version with support for fetching keys
via DANE.
I tried to update to the new upstream version but ended up running into
a number of missing build-dependencies.
Not in Debian at all
* librust-dot-writer-0.1+default-dev (>= 0.1.3-~~)
Newer version neede
I've uploaded the new version of rust-bstr to experimental, I have also
prepared but
not uploaded updates for the reverse dependencies, notes on rdeps below.
assert_cmd - new upstream 2.0.8 prepared and patch dropped in debcargo-conf
(even newer upstream releases are available but have new depe
https://rustsec.org/advisories/RUSTSEC-2023-0031.html
https://github.com/mvdnes/spin-rs/issues/148
0123456789001234567890012345678900123456789001234567890012345678900123456789001234567890
https://codesearch.debian.net/search?q=try_call_once&literal=1 returns 8
results.
4 in rust-pnce-cell and
On 13/04/2023 15:31, Peter Green wrote:
I've filed a bug with sequoia upstream. I haven't investigated the other
packages at this time.
I just did a quick test of sniffglue, ron and ureq, sniffglue and ron were
all able to run "cargo test --all --all-targets --all-features&qu
BTW, Fabian messages sent to bug reports are not sent to the sumbitter
by default, if you are replying to a submitter you need to put them
in to/cc or they may not see your reply.
Fabian Grünbichler wrote:
hope that's okay for the time being :) feel free to ping the bug if you
have the feeling t
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/
reopen 1032854
reassign 1032854 rust-lock-api-0.1
retitle 1032854 rust-lock-api-0.1: RUSTSEC-2020-0070: lock_api: Some lock_api
lock guard objects can cause data races
thanks
I was made aware on IRC that RUSTSEC-2020-0070 also affects
rust-lock-api-0.1.
The only reverse dependency of rust-lock-
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
Please try to update this tool in order to have a more recent version
in Bookworm!
I tried to update sequoia-wot and got
dpkg-checkbuilddeps: error: Unmet build dependencies:
librust-clap-mangen-0.2+default-dev librust-openpgp-cert-d-0.1+default-dev
librust-sequoia-cert-store-0.2+default-dev
retitle 1032446 rust-brotli fails to build with std and unsafe features enabled
together
thanks
Would it be possible to consider addressing the compilation errors or
the package removal?
The compile errors only happen when both the "std" (enabled by default)
and "unsafe" (disabled by default
At the time you wrote this, i think the sq package description was
pretty similar to what it is today:
It looks like the description we have today was written when sq was
first packaged, but wasn't actually incorporated into the package
until later because of https://bugs.debian.org/cgi-bin/bugr
I recently became aware that mumble's build-dependencies were no longer
satisfiable on armhf due to a missing zeroc-ice. I looked at the build
logs for zeroc-ice and all were green. So I looked at the removal log
and found the following.
[Date: Sun, 12 Feb 2023 17:56:51 -] [ftpmaster: Scott
please package versione 0.13.0 of rust-asn1.
It's a semver bump, which given how dependencies are typically specified
in the rust world probablly counts as a transition. Unfortunately upstream
doesn't provide a changelog so it's difficult for me to tell how
substantial the changes actually are.
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
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
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
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
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: xraylib
While working on the python 3.11 transition in raspbian bookworm I ran
into a build failure of xraylib. I went and checked Debian reproducible
builds and found failures there too on armhf and i386 but not on arm64
or amd64. I also looked at the official build logs for Debian armh
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
Package: dgit
mkdir dgittest
cd dgittest
dget -d
http://deb.debian.org/debian/pool/main/p/python-coverage/python-coverage_6.5.0+dfsg1-2.dsc
mkdir repo
cd repo
git init
dgit import-dsc ../python-coverage_6.5.0+dfsg1-2.dsc +workingbranch
Dgit metadata in .dsc: NO git hash
using existing python-co
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: zeroc-ice
Severity: wishlist
zeroc-ice currently builds a python library package which is only built against
the default python 3 version. The result of this is that zeroc-ice is tying
together the "php 7.2" transition with the "python3 as default" transition.
If zeroc-ice was to build
Package: pushpin
pushpin build-depends on librust-clap+derive-dev and librust-clap+term-size,
librust-clap+default-dev is both an uninstallable cruft physical package, and a
virtual package provided by both librust-clap-dev, librust-clap-3-dev.
librust-clap+term-size-dev is both an uninstallable
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
Package: mdevctl
Severity: important
mdevtcl build-depends on librust-clap-derive-dev, librust-clap-complete-dev
and librust-clap+strsim-dev. There are a few issues here, firstly it seems you
are depending on clap-derive when your cargo.toml depends on the clap feature
of the derive crate. Second
Package: elan
Severity: serious
01234567890123456789012345678901234567890123456789012345678901234567890123456789
elan build-depends on a number of unversioned clap feature packages. Some of
these are virtual packages provided by multiple versions of clap. Some of them
are also cruft physical pac
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: 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
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
severity 1026875 serious
thanks
On 23/12/2022 03:24, Peter Green wrote:
At the present time, this bug report is filed for information, I still need
to check out the other reverse dependencies of rust-zip, and I would also like
feedback from upstream on this issue if possible.
Upstream merged
Package: elan
Version: 1.4.2-2
We would like to update the zip crate to 0.6, I have uploaded the new version
to experimental to allow testing with it.
I bumped the dependency in elan and most of the code built fine, but there was
one chunk of code that failed.
let mtime = entry.last
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`
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-trust-dns-proto
Version: 0.22.0-1
Severity: serious
01234567890123456789012345678901234567890123456789012345678901234567890123456789
rust-trust-dns-proto has an "optional" (in the cargo sense) dependency on
rustls, since collapse_features is used*, this results in it depending but n
Control: severity -1 serious
On 14/12/2022 15:42, Marc Dequènes (duck) wrote:
Control: tags -1 + pending
Quack,
On 2022-12-08 22:21, Peter Green wrote:
I have updated rust-nix in experimental, and intend to do so in unstable
soon, the code in your package builds fine with the new version
Sylvestre Ledru wrote:
clap should be updated to 4. I just didn't find the time to do it (if you want
to give it a try ;)
I just took a look at this.
The new version of clap depends on new versions of clap_derive and clap_lex,
the old version of clap builds fine with it's dependency on clap_l
reassign 1025690 rust-clap
thanks
Please upgrade to newer upstream branch v4
normal practice in the rust team when packaging multiple versions is that the
package with no version in it's name is the most recent version packaged, and
packages with versions in their name are used for older versi
Package: rust-smol
Version: 1.3.0-1
Severity: important
I have uploaded rust-nix 0.26 to experimental and am now working through the
reverse dependencies before uploading it to unstable.
Generally I have been setting the upper limit on version to <1.0, this is
clearly a compromise, there is some
Source: deepin-log-viewer
Version: 5.9.7+ds1-1
Severity: serious
Tags: bookworm, sid
Justification: rc policy - "Packages must be buildable within the same release"
User:debian...@lists.debian.org
Usertags: edos-uninstallable
deepin-log-viewer build-depends on libfftw3-3, this was previously a
t
Source: gsequencer
Version: 4.4.1-1
Severity: serious
Tags: bookworm, sid
Justification: rc policy - "Packages must be buildable within the same release"
User:debian...@lists.debian.org
Usertags: edos-uninstallable
gsequence build-depends on fftw3-dev, this is a virtual package that was
previousl
Source: libreflectasm-java
Version: 1.11.9+dfsg-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
libreflectasm-java build-depends on libasm-java-doc which is longer
Source: docopt
Version: 0.6.2-4
Severity: serious
Tags: bookworm, sid
Justification: rc policy - "Packages must be buildable within the same release"
User:debian...@lists.debian.org
Usertags: edos-uninstallable
docopt build-depends on dh-sequence-python2, this is a virtual package that was
previo
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
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
Package: greetd
Version: 0.8.0-1
Severity: important
I have updated rust-nix in experimental, and intend to do so in unstable
soon, the code in your package builds fine with the new version, but
the Cargo dependencies don't allow it to be used. The attached patch
updates the Debian and Cargo depe
201 - 300 of 2565 matches
Mail list logo
