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
Package: rust-ahash
Version: 0.8.11-2
rust-hashbrown was recently updated to 0.14.5, and as a result the autopkgtest
for rust-ahash is failing.
https://ci.debian.net/packages/r/rust-ahash/testing/ppc64el/46811732/
97s error: failed to select a version for the requirement `hashbrown =
Package: rust-roadmap
Version: 0.6.0-2
I hope to update rust-serde-yaml to 0.9 in unstable soon
(this was requested a long time ago, but squeekboard
stalled the process)
rust-serde-yaml 0.9 is available in experimental. I
have built a version of rust-roadmap with the dependency
bumped and was
Package: ftp.debian.org
Please remove the cruft 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
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
On 04/03/2024 23:24, Peter Green wrote:
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
A debdiff is attatched, if I get no response I will likely NMU this when the
new rust-nix is uploaded to unstable.
As promised I have uploaded this.
During a rebuild of all packages in sid, your package failed to build
on arm64.
This fit the zero-day NMU guidelines, and my NMU would have
On 29/02/2024 12:22, Marc Dequènes (duck) wrote:
I do not have a proper Internet connexion in my new Pond yet so I'd gladly let you upload it :-).
Done
Final debdiff is attatched.diff -Nru greetd-0.9.0/debian/changelog greetd-0.9.0/debian/changelog
--- greetd-0.9.0/debian/changelog
if I get no response I will likely NMU this when the
new rust-nix is uploaded to unstable.
I have now uploaded rust-nix to unstable and uploaded
the nmu for this package.
Final debdiff is attatched (really this time)
diff -Nru aardvark-dns-1.4.0/debian/changelog
if I get no response I will likely NMU this when the
new rust-nix is uploaded to unstable.
I have now uploaded rust-nix to unstable and uploaded
the nmu for this package.
Final debdiff is attatched.
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 23/04/2024 15:52, Arnaud Ferraris wrote:
Hi,
On Thu, 27 Jul 2023 20:19:19 +0100 Peter Green wrote:
> squeekboard - not investigated yet.
Tests fail after bumping dependency.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042405
I've just uploaded the new version of squeekbo
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`
-->
rust-symphonia-core appears to FTBFS from an i386 sbuild chroot with a
test 'units::tests::verify_timebase' panicking
units::tests::verify_timebase stdout
thread 'units::tests::verify_timebase' panicked at 'assertion failed:
`(left == right)`
left: `4503599627370496`,
right:
preliminary analysis
upstream changelog doesn't look too scary, no obvious breakage there.
rdeps:
0123456789001234567890012345678900123456789001234567890012345678900123456789001234567890
oxigraph (librust-sparesults-dev):
jonas package, upstream version in Debian uses 0.30, upstream did
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
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
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
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
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
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
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
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
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,
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
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
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']
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
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] -->
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
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
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
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
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
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
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
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
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
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
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: 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
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
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
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
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
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
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
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
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
1 - 100 of 2745 matches
Mail list logo