On 07/03/2024 19:43, Peter Green wrote:
In raspbian, I removed the reference from misfortune.cabel, removed the
build-dependencies on libghc-regex-pcre* and also (for unrelated reasons)
removed the build-dependency on ghc-doc. After doing so I was able to
successfully build the package.
Scratch
Can you please investigate the situation and figure out how to resolve
it?
I'm no haskell expert, but to me the dependency looks vestigal. Grepping
the source tree for "pcre" finds a mention in the misfortune.cabal
file but no mentions in the actual code, and there are no corresponding
binary d
I have built the rust-polling successfully in my local loong64
environment, without modifications required.
Make sure you are not using DEB_BUILD_OPTIONS=nocheck
since rust crates don't have stable ABIs and cargo doesn't support
pre-built rust crates, librust* packages contain source code rathe
Package: rust-smol
I am currently preparing to update the rust-nix pacakge to version 0.27.
The smol crate has a dev-dependency on the nix crate, which the Debian
packaging translates to build and autopkgtest dependencies. After
relaxing the dependencies to allow the new version.
The new rust-n
Package: nsncd
Version: 1.4.1-2
We are preparing an update of rust-nix to version 0.27, the new version has
been uploaded to experlmental.
In the new version of the nix crate, No features are enabled by default,
you must enable the features you require.
The attached patch relaxes the cargo dep
reopen 1064490
thanks
On 23/02/2024 10:21, Debian Bug Tracking System wrote:
This is an automatic notification regarding your Bug report
which was filed against the inputplug package:
#1064490: inputplug - upcoming rust-nix and rust-x11rb updates.
It has been closed by Debian FTP Masters (rep
Package: inputplug
Version: 0.4.0-2
We are preparing an update of rust-nix to version 0.27 and rust-x11rb to 0.13,
the new versions are available in experimental.
The new version of rustix does not seem to require any code changes, but it
does require the "process" feature to be explicitly enabl
Package: greetd
Version: 0.9.0-6
We are preparing an update of rust-nix to version 0.27, the new version has
been uploaded to experlmental.
To build with this new version of nix, aardvark-dns needs a small patch
taken from upstream. A debdiff is attached, if I get no response I will
likely NMU t
Package: aardvark-dns
Version: 1.4.0-5
We are preparing an update of rust-nix to version 0.27, the new version has
been uploaded to experlmental.
To build with this new version of nix, aardvark-dns needs the cargo dependency
on nix relaxing, and needs some features of the nix crate specifying ex
I've finally finished working through the rdeps of rust-hashbrown and
rust-indexmap,
damn that took a while. Hopefully we are not far off being ready to upload,
mostly
waiting for a response from jonas on the wasmtime bug at this point.
btm:
jonas package, no changes needed for this update, th
On 15/02/2024 20:48, Ian Jackson wrote:
Hrm. Can you point me to an example dsc (eg dgit.dsc?) and semd me
the output with -D ?
dget -d https://deb.debian.org/debian/pool/main/g/giada/giada_0.22.0-4.dsc
mkdir dgittest
cd dgittest/
git init
dgit -D import-dsc ../giada_0.22.0-4.dsc +workingbranc
Package: rust-wasmtime
Now that rust-ahash 0.8 is in trixie and noble I hope to update
rust-hashbrown and rust-indexmap soon to versions 0.14
and version 2 respectively.
I have tested that simply relaxing the (build-)dependencies
is enough to make rust-wasmtime build and pass it's autopkgtests
w
Package: dgit
Something seems to be wrong with the dgit infrastructure, I've been unable to
import any dscs from Debian that include a dgit: header for a week or two now.
I get messages like
['dgit', 'import-dsc',
'/build/workingrepo/pool/main/g/giada/giada_0.22.0-4.dsc', '+workingbranch']
"my
Package: rust-regalloc2
Now that rust-ahash 0.8 is in trixie and noble I hope to update
rust-hashbrown and rust-indexmap soon to versions 0.14
and version 2 respectively.
The release of regalloc2 currently in Debian, depends on
hashbrown 0.13 as does the latest upstream release. Upstream
git has
reassign 1063601 tailspin 3.0.0+dfsg-1
retitle 1063601 tailspin FTBFS error: environment variable `CARGO_CHANNEL` not
defined at compile time
thanks
>> [eyre 0.6.8] error[E0407]: method `backtrace` is not a member of trait
`Error`
>> [eyre 0.6.8] -->
/<>/target/x86_64-unknown-linux-gnu/relea
retitle 1063475 RM: lazarus 2.2.6+dfsg2-2 -- NVIU; Newer version is available
lazarus| 2.2.6+dfsg2-2 | unstable | source, all
lazarus| 3.0+dfsg1-7 | unstable | source, all
To clarify, this is a request to remove the outdated lazarus packages that are
still hanging around, not to
Package: rust-ahash
Version: 0.8.7-3
rust-ahash has a cargo dependency on
const-random = { version = "0.1.17", optional = true } but the debian dependency
is librust-const-random-0.1+default-dev (>= 0.1.12). This discrepancy is causing
autopkgtest failures in Ubuntu.
There is also a similar disc
Please upgrade to, or separately provide, at least v2.2.1.
Hi jonas.
I've uploaded this to experimental.
In terms of uploads to unstable, This needs to be updated together
together with at least polling (which James recently uploaded to
experimental).
A number of your packages will need eithe
Package: elan
Version: 3.0.0-2
I hope to update the rust-toml package to version 0.8 soon.
I have tested that elan builds with the dependency bumped.
However, given https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061550
I think it probably makes more sense for your package to
switch back to u
Package: precious
Version: 0.6.0-2
I plan to update rust-toml to 0.8 soon, to accommodate this,
precious will need a patch dropping and an update to it's
build-dependencies.
Since this is moving closer to what upstream wants I see
it as low risk. I have tested that the package builds
succesfully
It seems that the cause of this bug is probably the Debian patch that
changes the version of the toml crate. There are breaking changes, so
the toml functions used in elan need to be updated to reflect these
changes.
We have a rust-toml-0.5 package in Debian and you are welcome to use it,
we ha
On 23/01/2024 16:07, Jonas Smedegaard wrote:
I have also searched
to see if there are any reverse dependencies of said feature
and did not find any (though it's possible that something is
using the feature without declaring it).
Virtual package librust-version-sync-0.9+default-dev, provided by
l
preliminary analysis.
rdeps of rust-toml-0.7:
elan
uses 0.5 upstream, can presumablly go back to 0.5 if going forward is not
possible.
precious
uses 0.8 upstream, debian is currently downpatching
rust-cargo
uses 0.8 upstream, debian is currently some way behind upstream, but upstream
Package: rust-version-sync
Tags: trixie, sid
I hope to update rust-toml to 0.8 soon, probably in a week or so.
The upstream changelog mentions the following under breaking changes
Serialization and deserialization of tuple variants has changed from being
an array to being a table with the
Package: rust-ahash-0.7
Version: 0.7.7-1
Severity: serious
The autopkgtests for rust-ahash-0.7 are failing, this is blocking the
migration of rust-ahash-0.7 to testing which is in turn blocking the
migration of at least one rc bug fix to testing.
There are two issues, the first is that the autop
Package: tailspin
I intend to update rust-terminal-size in unstable to 0.3 soon
(probablly a week or so).
Tailspin upstream already uses 0.3, and your Cargo.toml already
allows 0.3, so this should be a simple matter of tweaking the
Debian build-dependency.
I've tested that the package builds wi
Package: oxigraph
I am currently working on updating rust-clap, clap itself is not
semver breaking, but clap_lex is. The upstream changes seem
fairly minimal and I was able to build your package successfully
with the new version after adjusting the dependencies.
The new versions of clap_lex and
preliminary analysis of reverse dependencies.
btm
upstream uses 0.14 debian is currently down-patching.
rust-ahash
dev dependency only, tests pass with dependency bumped.
rust-chumsky
new upstream uses 0.14 and is not semver breaking.
rust-dashmap
new upstream uses 0.14 and is not semver b
tags 1057451 +patch
thanks
I just looked at the remaining autopkgtest failures in rust-ahash, I found and
fixed two issues and after doing so the autopkgtests passed.
The first issue was some arithmetic overflows in summations in tests/bench.rs
these cause panics if built/run in Debug mode (as "
Impossible to install: Depends on missing package
librust-ego-tree-0.6+default-dev
rust-ego-tree was uploaded but rejected.
https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2023-December/037170.html
tags 105121 +patch
thanks
rust-palette is unable to migrate to Testing because its
autopkgtests are failing.
I prepared a fix for the autopkgtest issues. While I was at
it I also bumped the clap dev-dependency and the associated
build and test dependencies to version 4 as we would like
to phas
Package: ftp.debian.org
Please remove the binary packages librust-bindgen+clap-dev
librust-bindgen+default-dev librust-bindgen+env-logger-dev
librust-bindgen+log-dev librust-bindgen+logging-dev librust-bindgen+runtime-dev
librust-bindgen+static-dev librust-bindgen+which-dev
These packages have b
Package: hime
Version: 0.9.11+dfsg-2
Severity: serious
Tags: trixie, sid
Justification: rc-policy - packages must be buildable within the same release.
User: debian...@lists.debian.org
Usertags: edos-uninstallable
Hime build-depends on libayatana-indicator-dev which is no longer built
by the liba
severity 1057760 serious
tags 1057760 +ftbfs
thanks
On 09/12/2023 08:06, Jonas Smedegaard wrote:
Quoting Peter Green (2023-12-08 04:09:31)
Package: settle
Version: 0.40.1-1
I intend to update rust-rusqlite in unstable to 0.29 soon.
The cargo dependencies for settle already allow 0.29 but
the
Package: rust-hyper-rustls
Version: 0.24.2-1
Severity: serious
Tags: patch
The autopkgtest for rust-hyper-rustls is failing, because the code in
test_alpn_http2 requires a runtime, but the feature requirements for
the test do not specify one.
A debdiff fixing this is attatched.diff -Nru rust-hyp
Package: settle
Version: 0.40.1-1
I intend to update rust-rusqlite in unstable to 0.29 soon.
The cargo dependencies for settle already allow 0.29 but
the Debian dependencies will need updating.
I don't expect any issues as 0.29 is what upstream asks
for and I already tested this a while ago but
On the one hand I'm not at all convinced this bug is rc, on the other
hand I don't think shipping a four year old version of env-logger
in the next release of Debian is a great idea.
So I decided to look at the reverse dependencies, I found three
safe-vdash - this is a Jonas package, the depende
Package: safe-vdash
Version: 0.15.5-1
Your Debian and Cargo dependencies on env-logger are
not consistent with each other.
> debian/control: librust-env-logger-0.7+default-dev
> Cargo.toml:env_logger = "0.10.0"
Your package built successfully because the new version of
env-logger was pulled in
The Rust Team did not react.
Too bad. Please raise the bug to RC.
Apologies for not engaging with this sooner, I had mentally
filed it as "deal with this once the cargo update is done"
but the cargo update has been taking a lot longer than hoped.
I've uploaded a new version of the rust bindin
Package: rust-wasmtime
Version: 15.0.0+dfsg-3
Severity: serious
Control: block 1055090 by -1
https://buildd.debian.org/status/fetch.php?pkg=rust-wasmtime&arch=all&ver=15.0.0%2Bdfsg-3&stamp=1701097543&raw=0
error[E0599]: no function or associated item named `from_str` found for struct
`Triple`
Please update to (at least) newer upstream release v1.8.0.
I just looked at this, the new version of rayon requires
a new version of rayon-core, unfortunately when updating
rayon-core I ran into a test failure that looks like it
may indicate an unintentional API break. I'm not
comfortable uploadi
On 21/11/2023 11:41, Jonas Smedegaard wrote:
Quoting Peter Green (2023-11-21 09:16:21)
Tags 1055099 +patch
thanks
The autopkgtests for rust-async-task began failing after the upgrade
to from 4.4.1-1 to 4.5.0-1. This prevents its migration to Testing.
I have prepared a patch which adds a
Tags 1055099 +patch
thanks
The autopkgtests for rust-async-task began failing after the upgrade
to from 4.4.1-1 to 4.5.0-1. This prevents its migration to Testing.
I have prepared a patch which adds a feature guard to the example in
question and hence fixes the autopkgtest. A debdiff is attatc
On 16/11/2023 18:41, Jonas Smedegaard wrote:
Quoting Peter Green (2023-11-16 10:55:33)
Please update to (at least) newer upstream release v0.7.8.
toml itself is not semver-breaking, but it's closely coupled dependency
toml_edit is.
[...]
My overall conclusion is that btm is the main bl
Please update to (at least) newer upstream release v0.7.8.
toml itself is not semver-breaking, but it's closely coupled dependency
toml_edit is.
Relavent parts of the upstream changelog.
0.21.0 - 2023-11-06
Breaking Change
Split default-features=false APIs into parse and display features
Please see https://rustsec.org/advisories/RUSTSEC-2023-0070.html
I have read the upstream advisory and the linked bug report and while
I don't fully understand the nitty gritty details my understanding of
the issue is.
* It was discovered that code (which was not marked as unsafe)
could mis-
On 09/08/2023 11:30, Jonas Smedegaard wrote:
Quoting Peter Green (2023-08-09 10:55:07)
2. hashbrown has moved to ahash 0.8, ahash 0.8 is available in
unstable, but is not in testing due to autopkgtest failures.
Jonas, since ahash is one of your packages can you investigate
and
preliminary analysis.
upstream changelog:
https://github.com/bluss/indexmap/blob/master/RELEASES.md
nothing looks two scary
forward dependencies:
the new version of indexmap depends on the new version of hasbrown, and my
attempts at relaxing have been
unsuccesful, so it looks like we will ne
Package: sq-wot
x-debbugs-cc: alexander.kj...@gmail.com, d...@fifthhorseman.net
Since it seems we now (fingers crossed) finally have a version of
ring that should build on all release architectures I decided it was
time to fix sequoia-sq which has been languishing in a rc buggy
state since soon a
Please upgrade to (or separately provide) newer upstream branch v0.29.
Preliminary analysis looks pretty good in general, but parsec-service
has some issues with it's migration to testing that need to be sorted
before going ahead with this in unstable. I've just made some uploads
that will hopef
On 02/11/2023 05:51, Jonas Smedegaard wrote:
That's wonderful news.
I am happy to update rust-rustls, as soon as possible. Seems to only
blocker is an transitive dependency on rust-rcgen needing an update as
well: See bug#1055132.
The package rust-sct needs relinking as well.
Thanks for pre
> Please updagre to (or separately provide) newer upstream branch v2.
I've taken a priliminary look at this and it looks like it's probably
good to go. I've uploaded it to experimental.
Four of the rdeps are your packages, can you prepare updates for them
Package: rsass
Package: rust-async-exec
Package: rust-snow
As you are probablly aware, i'm currently working on an update of
rust-ring. rust-snow depends on ring, it seems to build and run
tests fine after bumping the dependency.
Upstream, dependabot has submitted a PR to update ring, but
upstream has not responded to it yet. I've lef
Package: rust-rustls-webpki
Version: 0.101.6-1
Severity: serious
The autopkgtest for rust-rustls-webpki fails with
238s error[E0583]: file not found for module `test_utils`
238s --> src/lib.rs:65:1
238s|
238s 65 | pub(crate) mod test_utils;
238s| ^^
238s|
2
Package: rust-rustls-native-certs
Version: 0.6.3-3
As you are probablly aware, I'm preparing an update of the untrusted and ring
crates
(currently in experimental). The rustls-native-certs crate doesn't use
untrusted or
ring at runtime, but it does have dev-dependencies on them.
After bumping
Package: rust-rustls
After a long wait, ring released version 0.17 which is far more portable than
previous versions. The lack of portability of ring has been a thorn in the
side of the rust team for some time so we would really like to upgrade.
The good news is that rustls has updated to the ne
On 27/10/2023 11:37, Ian Jackson wrote:
Peter Green writes ("Bug#1054630: dgit - cant import llvm-toolchain-15."):
Now on the one hand, the changelog in llvm-toolchain-15 is indeed broken.
I filed a bug about that.
Thanks. (FMR that's #1051961)
On the other hand, the package
Package: dgit
Version: 11.3
dgit can't import the current version of llvm-toolchain-15
dgit import-dsc ../llvm-toolchain-15_15.0.7-10.dsc ..workingbranch
Dgit metadata in .dsc: NO git hash
using existing llvm-toolchain-15_15.0.7.orig.tar.xz
using existing llvm-toolchain-15_15.0.7-10.debian.tar
Package: breezy
Version: 3.3.4-1
Severity: serious
Tags: patch
Breezy build-depends on librust-regex+aho-corasick-dev which is no longer
provided (in either physical or virtual form) by rust-regex.
Looking at the Cargo.toml files I belive the correct build-dependency is
librust-regex-1+default-d
reopen 1051820
thanks
> eza was accepted into unstable
Indeed.
> replacing exa.
exa is still there. Someone still needs to decide what to do about it
(pprobablly turning it into a transitional package is appropriate)
Package: rust-fd-find
Version: 8.7.0-3
Severity: serious
This bug affects both 8.7.0-3 in testing and 8.7.0-4 in unstable.
I recently uploaded clap 4.4.6, since this was not a semver bump I was not
expecting any breakage. Unfortunately it turns out it broke fd.
There are (at least) two issues,
severity 1050678 serious
thanks
On 27/08/2023 23:19, Peter Michael Green wrote:
Package: rust-async-process
Version: 1.7.0-2
I'm preparing an update for rustix, it's a new semver but so-far everything
seems to build with just the dependency bumped. I've uploaded it to
experimental.
and assumin
rust-libslirp has no reverse dependencies in Debian.
https://codesearch.debian.net/search?q=path%3Adebian%2Fcontrol+rust-libslirp&perpkg=1
It is also one of the blockers for removing the old rust-zbus-1 from
Debian. See https://bugs.debian.org/1053631
Can we remove rust-libslirp and rust-libsli
Package: flask-dance
Version: 6.2.0.2-1
Severity: serious
Justification: rc policy - "packages must be buildable within the same release".
Tags: trixie, sid
flask-dance build-depends on python3-sphinxcontrib.seqdiag which is not in
testing,
it was removed because it FTBFS and was badly broken, b
Package: squeekboard
Version: 1.22.0-4
Severity: serious
Tags: patch
The rust gtk stack was recently updated, and squeekboard needs a few
tweaks to build with the new version.
I have whipped up a patch and tested that squeekboard builds with it,
I have not tested it beyond that.diff -Nru squeekb
Package: rust-sequoia-openpgp
Version: 1.16.0-3
Severity: serious
rust-sequoia-openpgp depends on an old version of regex-syntax, I tried bumping
the dependency but the build failed.
I have filed an issue about this upstream at
https://gitlab.com/sequoia-pgp/sequoia/-/issues/1056
Package: rust-grep-regex
Version: 0.1.11-1
Severity: serious
rust-grep-regex depends on an old version of rust-regex-syntax, this
is fixed in upstream git, but looking at the commit messages it's not
something I feel comfortable cherry-picking.
I have opened an upstream issue enquiring about the
Package: rust-matchers
Version: 0.1.0-1
Severity: serious
tas: trixie, sid
rust-regex-automata was recently updated to 0.3, rendering
the dependencies and build-dependencies of rust-matchers
uninstallable.
The changes seem to be fairly major, there is an upstream
pull request but details are sti
Package: rust-async-task
Version: 4.4.0-3
Severity: serious
Tags: patch
rust-async-task's build-dependencies are unsatisfiable in testing/unstable
due to a recent update to rust-flume.
upstream bumped the dependency with no code changes, and after adding the
patch to the Debian package and adjus
Package: rust-leptonica-sys
Version: 0.4.6-3
Severity: serious
The Debian dependencies for rust-leptonica-sys allow versions of
rust-bindgen from 0.60.x to 0.66.x, however the Cargo dependencies
only allow versions from 0.64.x to 0.66.x. This is causing
autopkgtest failures and blocking rust-lept
Severity 1051146 serious
Thanks
The new version of rust-bindgen has been uploaded to experimental so people
can test against it.
The new version of rust-bindgen has now been uploaded to unstable.
Package: llvm-toolchain-15
While trying to import the llvm-toolchain-15 package from trixie
using dgit import-dsc, dgit gave the error.>
LINE: llvm-toolchain-14 (1:14.0.6-16) unstable; urgency=medium
dgit: error: missing field Maintainer in package changelog, entry no.11
Looking at the chang
On 12/09/2023 23:30, Faidon Liambotis wrote:
Control: reassign -1 rustc 1.68.2+dfsg1-1
Control: retitle -1 Builds invalid wasm32 binaries (1.67->1.68 regression)
On Tue, Sep 12, 2023 at 10:56:57PM +0100, Peter Green wrote:
The autopkgtests for wasmedge fail with rustc 1.68, I have obser
rust-users is currently unmaintained upstream.
In a fork a proposed patch can be found.
What is the rust-users situation with respect of Debian as it is
unmantained upstream?
So we have two options, patch it or move away from it to a fork
The crate "uzers" which is a fork of this crate was re
Package: exa
Version: 0.10.1-4
It has come to my attention that exa is unmaintained, with the last
upstream release being over 2 years ago. However there is a fork
"eza" which does appear to be maintained. Should we be preparing
a transition to it?
Package: wasmedge
Version: 0.13.3+dfsg-1
Severity:serious
The autopkgtests for wasmedge fail with rustc 1.68, I have observed this with
both testing and unstable's versions of wasmedge, and with both testing and
unstable's versions of wasi-lib.
https://ci.debian.net/data/autopkgtest/unstable/amd
Please upgrade to (or separately provide) newer upstream branch v0.8.
I think this may be a bit premature. I see two reverse dependencies,
rust-palette and rust-insta. rust-palette has only a dev-dependency
upstream and a build/test dependency in debian. rust-insta is still
on 0.7.x upstream.
I think this indicates that it can indeed be safely removed from Debian? I'm
CC'ing developers that have made uploads to this packages in the past for
additiponal opinions as I suspect the issue is more subtle than that.
dak rm does not take account of virtual packages. So for rust packages
it i
Package: rust-tesseract-sys
Version: 0.5.14-3
In the rust team we are working on upgrading rust-bindgen from 0.60 to
0.66, there are a few reasons for this. Firstly it's part of the dependency
stack
for the new version of rust-cargo. Secondly the version currently in sid has a
compatibility issu
On 17/08/2023 19:26, Peter Green wrote:
It would be nice to only need a single version of rustls in Debian,
with my recent round of uploads, most of the reverse dependencies
are now moved to version 0.21, leaving oxhttp as one of the few
remaining on 0.20.
rust-oxhttp is now the last one
Package: rust-rustls
Version: 0.21.6-3
The most recent upload of rust-rustls included a binary package
and hence cannot migrate to testing. Since the package is arch
all this cannot be fixed with a binnmu.
Please make a new source-only upload so the package can migrate.
On 22/08/2023 04:47, Peter Green wrote:
Fabian: is sval-serde ready for sponsorship? if so can you add the RFS
file?
I couldn't see anything wrong with the sval-serde package, so I decided to
go ahead and upload it, it is now in NEW.
A bunch of packages just cleared new, and I made a bunch of follow up uploads.
The result is that the situation surrounding the log package has improved
a bit, but it still less than ideal.
The "kv_unstable" and "kv_unstable_sval" features are now enabled, the
"kv_unstable_serde" feature is curre
Package: rust-derive-builder-core
Version: 0.12.0-1
Severity: serious
Recently a new version of the darling crates was uploaded,
(Alexander Kajil prepared the uploads, Sylvestre uploaded
darling-core and I uploaded the rest of the darling crates).
Most of the reverse dependencies either already
Since
rust-hyper-rustls has reverse dependencies as well, its move to to v0.24
will involve NEW queue and potentially take some time.
According to my searches the only direct reverse dependency of
rust-hyper-rustls is rust-reqwest. I have the new version of that
(which is not semver-breaking) re
Package: rust-hyper-rustls
Version: 0.23.2-4
Severity: serious
I just updated tokio-rustls to 0.24.1, hyper-rustls needs updating to 0.24.1
to match.
Package: rust-oxhttp
Version: 0.1.6-2
It would be nice to only need a single version of rustls in Debian,
with my recent round of uploads, most of the reverse dependencies
are now moved to version 0.21, leaving oxhttp as one of the few
remaining on 0.20.
Upstream has moved in git, but have not y
Please update to (at least) newer upstream release v1.8.4.
regex 1.8.x bumps the aho-corasick dependency to 1.x, I took a look through
the reverse dependencies.
* elan - debian dependency but no cargo dependency probablly not an issue
* rust-cpp-macros - patch written but package has very litt
Package: minexpert2
Version: 8.6.3-1
Severity: serious
Tags: trixie, sid
Justification: rc-policy - packages must be buildable within the same release.
User: debian...@lists.debian.org
Usertags: edos-uninstallable
x-debbugs-cc: lopi...@debian.org
daps 3.3.2+cleaned1-5 moved calibre from suggests
Package: massxpert
Version: 7.0.0-2
Severity: serious
Justification: rc-policy - packages must be buildable within the same release.
User: debian...@lists.debian.org
Usertags: edos-uninstallable
x-debbugs-cc: lopi...@debian.org
daps 3.3.2+cleaned1-4 moved calibre from suggests to depends.
This me
Package: calculix-cgx
Version: 2.17+dfsg-2
Severity: serious
Tags: trixie, sid
calculix-cgx build-depends on libgl1-mesa-glx which is no longer built by the
mesa source package. It is still present in unstable and on a couple of
architectures in testing as a cruft package, but it is completely go
tags 1043418 +patch
thanks
The autopkgtest for rust-rustls-webpki is failing with a bunch of file not
found errors.
Investigating a bit more, the issue is that the data files in question are
included in the source package, but not in the binary package. I'm not sure if
this is
a result of yo
Please provide feature date-locale.
The date-locale feature in tera depends on the "unstable-locales" feature in
chrono.
There are a couple of issues I see here.
1. It's an unstable feature, it's not clear how much of a maintinance burden
that will be going forward.
2. It requires the "pure-
Please update to (at least) newer upstream release v2.0.10.
The new version of assert_cmd has switched to anstream instead of yansi,
the anstream crate is not currently in Debian. As I've said before I
don't like to package new things if they aren't personally important to me
The update als
tags 1042194 +patch
thanks
During a rebuild of all packages in sid, your package failed to build
on amd64.
The attached patch makes netavark build again (note: some of the packages
it depends on have only just been accepted, so it may be a little time
before binaries are available in sid).diff
Package: rust-rustls
Version: 0.21.6-1
Severity: serious
rust-rustls fails to build from source.
error: couldn't read rustls/build.rs: No such file or directory (os error 2)
error: could not compile `rustls` due to previous error
Package: rust-rustls-webpki
Version: 0.101.2-2
Severity: serious
The autopkgtest for rust-rustls-webpki is failing with a bunch of file not
found errors.
the first of which is pasted below.
199s error: couldn't read
src/../third-party/chromium/data/verify_signed_data/ecdsa-prime256v1-sha512-s
I've looked into updating lru and discovered the following.
The new version of lru depends on hashbrown 0.13. There are a couple of issues
here.
1. hashbrown has quite a few reverse dependencies,
I have not investigated these yet.
2. hashbrown has moved to ahash 0.8, ahash 0.8 is available i
Package: musicbrainzngs
Version: 0.7.1-4
Severity: serious
Tags: trixie, sid
Justification: rc policy - "Packages must be buildable within the same release"
User: debian...@lists.debian.org
Usertags: edos-uninstallable
musicbrainzngs build-depends on python-libdiscid-doc which is no longer built
Package: sccache
Severity: serious
Tags: trixie, sid
I just updated the serial-test crate to version 2.0. sccache
needs a small update to the Debian dependency to match. (the Cargo
dependency already allows both versions).
Debdiff attatched.
diff -Nru sccache-0.5.4/debian/changelog sccache-0.5.4
101 - 200 of 1401 matches
Mail list logo
