Package: rust-laurel
Version: 0.6.2-1
Severity: serious
rust-laurel's autopkgtest fails on s390x. I belive the patch
skip-parse_syslog-on-big-endian.patch should be reinstated
but I do not want to get into a revert war with the
maintainer.
So I feel I need to lay out, in more detail than
is
I got the following error when trying the same thing.
I have no idea why, since the ioctl_write_ptr and ioctl_read macros are
still supposed to be around. I can't spot any relevant change in nix
that would cause this to happen. Help would be appreciated.
The relavent change is.
All Cargo
relaxing that in Cargo.toml to >= 0.19 lets the build succeed (and build
with python3-defaults from experimental).
I was doing a test build of lintian brush to test I could build it
with the version of rust-distro-info I was preparing (now uploaded)
and ran into a couple of other issues.
Unsatisfiable build-dependency on librust-heck-0.5+default-dev
There seems to be an error here. the version of librust-prost-dev in sid
(build-)depends on librust-heck-0.4+default-dev.
The version in experimental does depend on librust-heck-0.5+default-dev
as it's first choice, but that's
Package: rust-multihash-derive-impl
Version: 0.7.0-1
Severity: serious
rust-synstructure was recently updated to version 0.13.1
I tried bumping the dependency but that caused failures due to
mismatched versions of syn. Bumping the dependency on syn as well
resulted in.
error[E0609]: no field
Package: rust-failure-derive
Version: 0.1
Tags: trixie, sid
Severity: serious
rust-synstructure was recently updated to version 0.13.1
I tried bumping the dependency but that caused failures due to
mismatched versions of syn. Bumping the dependency on syn as well
resulted in.
error[E0433]:
Package: rust-abscissa-derive
Version: 0.7.0-1
Severity: serious
rust-synstructure was recently updated to version 0.13.1
I tried bumping the dependency but that caused failures due to
mismatched versions of syn. Bumping the dependency on syn as well
resulted in.
error[E0432]: unresolved
Looking at the changelog, I see
Build with --as-needed.
I suspect this is responsible for the build failure on armel
On 14/04/2024 20:21, Yves-Alexis Perez wrote:
On Sat, 2024-04-13 at 16:11 +0100, Peter Green wrote:
>> Hi, thanks for the patch. It looks a bit strong though, undefining stuff
>> like
>> that unconditionally. Do you have pointers to the Ubuntu bug or something?
>> I've lo
Package: libvdeplug-slirp
Version: 0.1.0-2
Tags: trixie, sid
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t
After being rebuilt for the time64 transition, libvdeplug-slirp
still depends on the pre-time64 libraries libvdeplug2 and
libvdeslirp0. It also depends on
kalzium needs to be rebuilt for the time64 transition, but it has had
a FTBFS bug with no maintainer response for 4 months. The only reverse
dependencies seem to be a number of metapackages.
In particular, the kdeedu package is a key package and has a hard
dependency on kalzium. This means that
Hi, thanks for the patch. It looks a bit strong though, undefining stuff like
that unconditionally. Do you have pointers to the Ubuntu bug or something?
I've looked at upstream commits and issues and couldn't see anything there.
My understanding of the issue.
In glibc _FILE_OFFSET_BITS=64 is
Since there was no apparent maintainer response (the only responses were from
me and from one of the people working on the time64 transition) I went ahead
and uploaded a NMU'd with Ubuntu's fix.
Debdiff is attatched.
diff -Nru system-config-printer-1.5.18/debian/changelog
Tags 1068159 +patch
Thanks
The build failure is caused by the following in
modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/projects/build/linux/common/config.h
> /* Number of bits in a file offset, on hosts where this is settable. */
> #undef _FILE_OFFSET_BITS
Looking at the
block 1036884 by 1066134
tags 1066134 +patch
thanks
Hi.
The build failure of ppp in unstable is a blocker for the time_t
transition, since ppp needs to be rebuilt against the new versions
of libpcap and openssl. The version in experimental seems to build fine.
Can you fix this, either by
Package: haskell-hourglass
Version: 0.2.15-5
Severity: serious
User: debian-...@lists.debian.org
Usertag: time-t
The recent binnmus of haskell-hourglass on armel and armhf
failed to build with test failures.
calendar: FAIL
*** Failed!
Ubuntu has made a couple of changes that look like they may relate to this
issue.
Changelog for version 1.5.18-1ubuntu6 says
"Fix installation of cupshelpers module with Python 3.12."
Changelog for version 1.5.18-1ubuntu7 says
"Drop build dependency on python3-distutils."
Diffs are
Package: urfkill
Version: 0.5.0-7.1
Tags: trixie, sid
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t
After being rebuilt for the time64 transition, urfkill
depends on both libglib2.0-0 and libglib2.0-0t64. As a
result it is uninstallable on architectures that are undergoing
Package: tpm2-initramfs-tool
Version: 1.0.1-1
Tags: trixie, sid
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t
After being rebuilt for the time64 transition, tpm2-initramfs-tool
depends on both libtss2-esys-3.0.2-0 and libtss2-esys-3.0.2-0t64. As a
result it is uninstallable
Package: samba-dsdb-modules
Version: 2:4.19.5+dfsg-4
Tags: trixie, sid
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t
After being rebuilt for the time64 transition, samba-dsdb-modules
depends on both libgpgme11 and libgpgme11t64. As a
result it is uninstallable on
Package: riseup-vpn
Version: 0.21.11+ds1-5
Tags: trixie, sid
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t
After being rebuilt for the time64 transition, riseup-vpn
depends on both libqt5widgets5 and libqt5widgets5t64. As a
result it is uninstallable on architectures that are
Package: reapr
Version: 1.0.18+dfsg-5
Tags: trixie, sid
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t
After being rebuilt for the time64 transition, reapr
depends on both libtabixpp0 and libtabixpp0t64. As a
result it is uninstallable on architectures that are undergoing
the
Package: rakarrack
Version: 0.6.1-8
Tags: trixie, sid
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t
After being rebuilt for the time64 transition, rakarrack
depends on both libasound2 and libasound2t64. As a
result it is uninstallable on architectures that are undergoing
the
Package: libqt5-ukui-style1
Version: 1.0.8-1
Tags: trixie, sid
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t
After being rebuilt for the time64 transition, libqt5-ukui-style1
depends on both libqt5widgets5 and libqt5widgets5. As a
result it is uninstallable on architectures
Package: populations
Version: 1.2.33+svn0120106+dfsg-6
Severity: grave
Tags: trixie, sid
User: debian-...@lists.debian.org
Usertag: time-t
After being rebuilt for the time64 transition,
populations still depends on libqt5xml5,
rather than libqt5xml5t64. As a result it is uninstallable on
Package: pidgin-gnome-keyring
Version: 2.0-2
Severity: grave
Tags: trixie, sid
User: debian-...@lists.debian.org
Usertag: time-t
After being rebuilt for the time64 transition,
obs-advanced-scene-switcher still depends on libpurple0,
rather than libpurple0t64. As a result it is uninstallable on
Package: perdition
Version: 2.2-3.3
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t
After being rebuilt for the time64 transition, perdition
depends on both libvanessa-socket2 and libvanessa-socket2.
As a result it is uninstallable.
Interesting in this case, the
Package: obs-advances-scene-switcher
Version: 1.23.1-2
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t
After being rebuilt for the time64 transition,
obs-advanced-scene-switcher still depends on libcurl4,
rather than libcurl4t64. As a result it is uninstallable on
architectures
tags 1065980 +patch
thanks
This build failure was caused by missing "feature test macros" meaning that
the relevant functions were not enabled in the system headers.
A debdiff adding them is attached.diff -Nru gfarm-2.7.20+dfsg/debian/changelog gfarm-2.7.20+dfsg/debian/changelog
---
Package: mariadb-plugin-s3
Version: 1:10.11.7-3
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t
After being rebuilt for the time64 transition, mariadb-plugin-s3
depends on both libcurl4 and libcurl4t64. As a
result it is uninstallable on architectures that are undergoing
the
Package: mariadb-plugin-hashicorp-key-management
Version: 1:10.11.7-3
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t
After being rebuilt for the time64 transition,
mariadb-plugin-hashicorp-key-management
depends on both libcurl4 and libcurl4t64. As a
result it is
Package: lua-lxc
Version: 1:3.0.2-2
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t
After being rebuilt for the time64 transition, lua-lxc
depends on both liblxc1 and libliblxc1t64. As a
result it is uninstallable on architectures that are undergoing
the time64 transition
Package: ltrsift
Version: 1.0.2-9
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t
After being rebuilt for the time64 transition, ltrsift
depends on both libgenometools0 and libgenometools0t64. As a
result it is uninstallable on architectures that are undergoing
the time64
Package: lomiri-filemanager-app
Version: 1.0.4+dfsg-1
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t
After being rebuilt for the time64 transition, lomiri-filemanager-app
depends on both libsmbclient and libsmbclient0. As a
result it is uninstallable on architectures that are
Package: lomiri-system-settings
Version: 1.1.0-2
Severity: grave
lomiri-system-settings depends on lomiri-system-settings-security-privacy, which
is not availble on armel, armhf or mips64el.
The reason, or at least one reason, it is not available is because
Package: qml-module-lomiri-components-extrasVersion: 0.10.0-5
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t
After being rebuilt for the time64 transition,
qml-module-lomiri-components-extras
depends on both libqt5printsupport5 and libqt5printsupport5t64. As a
result it is
Package: indi-apogee
Version: 0.10.0-5
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t
After being rebuilt for the time64 transition, indi-apogee depends
on both libapogee3 and libapogee3t64. As a
result it is uninstallable on architectures that are undergoing
the time64
Package: gpa
Version: 0.10.0-5
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t
After being rebuilt for the time64 transition, gpa depends
on both libgpgme11 and libgpg11t64. As a
result it is uninstallable on architectures that are undergoing
the time64 transition (armel, armhf
Package: gir1.2-keybinder-0.0
Version: 0.3.1-2.3
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t
libkeybinder0 has been renamed to libkeybinder0t64, however gir1.2keybinder0.0
still depends on the former on most architectures. As a result it is
uninstallable on architectures
Also, the bootstrapping procedure is only required when icmake isn't avaialble
yet. For the construction of the bobcat library icmake 11.01.02-1 is required,
and icmake.01.02-1 needs libbobcat-dev >= 5.07.00, which is available since
bullseye (oldstable).
So maybe you can also provide some info
Package: qtwebengine-opensource-src
Version: 5.15.15+dfsg-2
Severity: serious
qtwebengine-opensource-src failed to build on armhf when binnmu'd for the time_t
transition due to symbol changes.
(qtwebengine does not support any of the other architectures affected by
the time64 transition.
grep
Package: atril
Version: 1.26.2-2
Severity: serious
The latest version of atril depends on both libatrildocument3 and
libatrildocument3t64. As a result it is uninstallable on
architectures that are undergoing the time64 transition
(armel, armhf and some debian-ports archictures).
Package: rust-coreutils
Version: 0.0.24-2
Severity: serious
rust-coreutils FTBFS with the new version of rust-uutils-term-grid.
The Debian build-dependency allows the new version, but the Cargo
dependency does not.
After bumping the cargo dependency, the code fails to build with a
bunch of
git failed to build when binnmu'd for the time64 transition and also
in lucas's test build a few days earlier. This was filed as bug 1066794.
Andrey Rakhmatullin responded to the bug report saying he was unable to
reproduce the failure. Michael Hudson replied with a post suggesting
that the
On 17/03/2024 13:01, Jérémy Lal wrote:
The last missing piece seems to be version >= 3 of
https://tracker.debian.org/pkg/rust-pem
I've uploaded this to experimental, please tell me when you are ready for it
to be uploaded to unstable.
severity 1066972 important
thanks
Indeed, there is no librust-rfc2047-decoder-0.2+default-dev package.
librust-rfc2047-decoder-0.2+default-dev is a virtual package provided
by librust-rfc2047-decoder-dev which is built from the
rust-rfc2047-decoder source package.
Following the dependency
Package: railway-gtk
Version: 2.4.0-1
Severity: serious
railway-gtk FTBFS on i386 (and will probablly FTBFS on other
32-bit architectures but builds on those architectures are
currently blocked by the time64 transition).
error[E0283]: type annotations needed for `std::option::Option`
-->
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
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] -->
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
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
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
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
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
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=all=15.0.0%2Bdfsg-3=1701097543=0
error[E0599]: no function or associated item named `from_str` found for struct
`Triple` in the current
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
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
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
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|
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
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,
rust-libslirp has no reverse dependencies in Debian.
https://codesearch.debian.net/search?q=path%3Adebian%2Fcontrol+rust-libslirp=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-libslirp-sys
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,
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
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
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
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
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
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
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.
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
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
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
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: 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
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
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
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
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
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
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
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
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
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 update
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
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.
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
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
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
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
1 - 100 of 1819 matches
Mail list logo
