Package: python-cryptography
Version: 43.0.0-2
Severity: serious
Tags: patch, ftbfs
python-cryptography cannot be built in sid (and soon trixie) due to
an overly strict Debian build-dependency for the cc crate (the
upstream cargo dependency is fine).
A debdiff fixing this is attached.diff -Nru p
Package: storm
Version: 1.0-1
Severity: serious
storm has binaries on 32-bit architectures (i386, armel, and armhf),
however it's build-dependencies cannot be satisified there
package: storm
version: 1.0-1
architecture: any
type: src
status: broken
reasons:
-
missing:
pk
The debdiff patch
is in the attachment.I have tested that locally,and it works well.Please
let me know whether this solution can be accepted.
You seem to have totally ignored the existing built-using.patch and added
a new patch, furthermore your new patch hardcodes the version number of
ring, so
On 15/04/2025 16:07, Jing Luo wrote:
X-Debbugs-Cc: debian-am...@lists.debian.org, debian-...@lists.debian.org,
debian-powe...@lists.debian.org, debian-ri...@lists.debian.org
I understand CC'ing the porters when you have an issue that is specific to the
port, but
if it's failing on every damn
Package: rust-pprof
Version: 0.13.0-5
Severity: serious
X-debbugs-cc: alexander.kj...@gmail.com
A soundness issue was reported in rust-prost 0.13,
https://rustsec.org/advisories/RUSTSEC-2024-0408.html
which is reported as causing real-world failures in
downstream applications.
I looked at updati
Package: pydantic
Version: 2.10.6-1
Severity: serious
After the update of pydantic-core to build against the new rust-url,
pydantic's autopkgtests are failing.
https://ci.debian.net/packages/p/pydantic/testing/amd64/59623497/
63s E Differing items:
63s E {'msg': 'Input should
Is there something I can improve on this front? In other words, how can
the design become smarter?
It's hard to answer this because I don't really understand exactly
how the scheduler works, but what I frequently see is.
1. The set of pins that britney chooses don't work.
2. The fallback depend
> ∙ ∙ Built-Using: rust-rebuildctl rust-rustls-native-certs (not considered)
rust-rustls-pemfile and friends have been trying to migrate to testing for
nearly a month, but a combination of a few real issues, a number of
well-intentioned
but poorly timed uploads, britney's autopkgtest scheduler b
Package: rust-skeptic
Version: 0.13.7-4
Severity: serious
rust-skeptic's dependencies are no longer satisfiable in unstable
after the upload of rust-cargo-metadata 0.15
(a removal request for this package has already been filed)
Package: rust-unzip
Version: 0.1.0-1
severity: serious
rust-unzip is no longer installable in unstable after the upload
of rust-zip 2.0
(a removal request for this package has been filed already)
Package: railway-gtk
Version: 2.7.3-1
Severity: serious
railway-gtk depends on librust-chrono-tz-0.8+default-dev but rust-chrono-tz
is now at version 0.10.
After relaxing the dependency I was able to succesfully build railway-gtk.
diff -Nru railway-gtk-2.7.3/debian/changelog railway-gtk-2.7.3/d
Package: rust-hyper-rustls
Version: 0.27.5-1
Severity: serious
Tags: patch
Since version 0.26, upstream no longer provides an "acceptor" feature
(see
https://github.com/rustls/hyper-rustls/commit/e19a299b6b08c17bf8307b59b071caa7f6f5a83b
)
the acceptor feature was removed from debian/control in
On 19/03/2025 11:03, Adrian Bunk wrote:
It's easy to reproduce even with the binary package when you remove
openssl (see #1099669).
I've now reproduced the bug.
It seems the package will build successfully as long as /etc/ssl/certs
exits, but will fail if that directory does not exist. Install
In addition to the new version of zbus, there is also now a new version of
tonic, which will
need to be dealt with if this package is to remain in trixie. I had a quick
poke in the
upstream git history and there seems to be a commit doing the update.
https://github.com/containers/netavark/commi
severity 1099728 important
retitle 1099728 unmaintained upstream since 2021
thanks
The crate yaml-rust have seen no upstream activity since 2001, and have
been flagged as unmaintained in RUSTSEC since 2004:
These dates are off by 20 years, rust didn't even exist in 2001.
I'm downgrading this
I couldn't compile it because it rnetlink deps
are not satisfied. I tried to prepare an NMU today but the rnetlink
changes are beyond my rust skills.
For what it's worth, the attatched debdiff will make rust-if-watch
build and pass it's autopkgtests in current sid.
diff -Nru rust-if-watch-3.2
Package: mdevctl
Version: 1.4.0-1
Severity: serious
Your packages build-dependency for the env-logger crate is overly
specific and no-longer satisfiable. The attatched patch adjusts
it to match the Cargo dependency.diff -Nru mdevctl-1.4.0/debian/changelog mdevctl-1.4.0/debian/changelog
--- mdevct
Package: rust-imap-client
Version: 0.1.5
Severity: serious
I recently introduced a semver-suffix package rust-tokio-rustls-0.24, and
updated the
main rust-tokio-rustls package to 0.26.
Unfortunately rust-imap-client's debian dependency is inconsistent with it's
cargo
dependency. The Debian dep
I fixed the dependency installability issues with librust-ntp-proto-dev but
rust-ntp-os-clock seems to be incompatible with the new version of
ntp-proto and also seems to be abandoned upstream and has no rdeps
in Debian.
sylvestre, should we remove it?
Package: librust-rustls-0.21-dev
Version: 0.21.12-12
Severity: serious
While attempting to update one of my development chroots I ran into the
following error.
> Unpacking librust-rustls-0.21-dev (0.21.12-12) ...
> dpkg: error processing archive
/var/cache/apt/archives/librust-rustls-0.21-dev_
Package: python-libcst
Version: 1.4.0-1.1
Severity: serious
Tags: patch
python-libcst's Cargo.toml asks for version 1.x of the thiserror
crate. Currently Debian has two versions of the crates, version
1.x in the librust-thiserror-1-dev package and version 2.x in
the librust-thiserror-dev package.
Tags 1095393 +path
thanks
With the attatched patch I was able to build sourmash succesfully.diff -Nru sourmash-4.8.14/debian/changelog sourmash-4.8.14/debian/changelog
--- sourmash-4.8.14/debian/changelog2025-01-20 10:50:45.0 +
+++ sourmash-4.8.14/debian/changelog2025-02-11 14
Package: rust-serde-yml
Severity: serious
(I will be cloning this bug against rust-libyml once I have a bug number)
rust-serde-yml is a fork of rust-serde-yaml and rust-libyml is
a fork of rust-unsafe-libyaml.
Serious concerns have been raised about the quality of code in
rust-serde-yml.
https
tags 1091017 +patch
thanks
A merge request addressing this issue can be found at
https://salsa.debian.org/debian/elan/-/merge_requests/1
Package: rust-lazy-regex
Version: 3.3.0+20241210-1
Severity: serious
rust-lazy-regex's autopkgtests are failing in most test
configurations due to lack of feature gates on tests.
The attatched debdiff adds said feature gates.
diff -Nru rust-lazy-regex-3.3.0+20241210/debian/changelog
rust-lazy-re
Package: rust-lazy-regex
Version: 3.1.0-6
Severity: serious
The no features autopkgtest for rust-lazy-regex is failing.
78s error[E0432]: unresolved import `regex`
78s--> src/lib.rs:203:9
78s |
78s 203 | self,
78s | no external crate `regex`
Doing some di
Package: fragments
Version: 3.0.1-3
Severity: serious
fragments has an overly-tight build-dependency on rust-regex, which is
unsatisifable since the upload of rust-regex 1.11
The attatched patch relaxes the build-dependency to match the cargo
dependency. I have tested that the package builds wit
Package: jameica-datasource
Version: 2.8.1+dfsg-4
Severity: serious
Justification: rc-policy - packages must be buildable within the same release.
User: debian...@lists.debian.org
Usertags: edos-uninstallable
jameica-datasource build-depends on libmckoisqldb-java-doc which is
no longer built by t
Package: rust-tealdeer
Version: 1.7.0-1
Severity: serious
Justification: rc-policy - packages must be buildable within the same release.
User: debian...@lists.debian.org
Usertags: edos-uninstallable
tealdeer build-depends on versoin 0.5 of rust-yansi, but trixie/sid
now has version 1, so it is no
Package: libpdb-redo3
Version: 3.1.5-3
Severity: serious
libpdb-redo3 has a hard coded dependency on libcifpp5, so after
building aginst the new version it ends up with dependencies
on both libcifpp5 and libcifpp7
Please remove or update the dependency.
This bug affects both 3.1.5-3 in testing
Version: 0.7.0~beta.2-2
During a rebuild of all packages in unstable, your package failed to build:
This was fixed just before the bug was filed.
I intend to remove this package:
* It has no rev dependencies
From what I can see, haskell-hopenpgp-tools build-depends on it.
It seems after jonas's revert of his debian/rules restructuring the vendored
libs
were no longer being located. Some small tweaks fixed that.
There has also been an update of rust-base64 recently which needed to be
accounted
for.
Debdiff is attatched.
diff -Nru matrix-synapse-1.116.0/debian/ch
Package: mricron
Severity: serious
Tags: trixie, sid
Justification: rc-policy - packages must be buildable within the same release.
User: debian...@lists.debian.org
Usertags: edos-uninstallable
mricron build-depends on lazarus-src-3.0 which is no longer built
by the lazarus source package, it is
The build-depends need to be changed from librust-cbindgen-dev to
librust-cbindgen-0+default-dev to properly reflect the cargo
dependency.
Package: rust-coreutils
Version: 0.0.26-3
Severity: serious
rust-coreutils fails to build on 32-bit architectures. I first noticed
this after uploading 0.0.26-4 to fix the build with the new version of
rust-half, but according to reproducible builds it also seems
to affect 0.0.26-3
> make[1]: En
I tried in raspbian trixie changing the build-dependency to libhdf5-mpi-dev,
but the build
failed with.
/usr/bin/mpicc -g -O2 -Werror=implicit-function-declaration
-ffile-prefix-map=/vtk9-9.3.0+dfsg1=. -fstack-protector-strong
-fstack-clash-protection -Wformat -Werror=format-security -D_LA
Package: qtsystems-opensource-src
Version: 5.0~git20230712.81e08ee+dfsg-2
Severity: serious
libqt5publishsubscribe5 was renamed to libqt5publishsubscribe5t64 and
libqt5serviceframework5 was renamed to libqt5serviceframework5t64 as
part of the time64 transition, but the package names in the
corres
Package: libsis-jhdf5-java
Version: 19.04.1+dfsg-7
Severity: serious
User: debian...@lists.debian.org
Usertags: edos-uninstallable
libsis-jhdf5-java build-depends on libeclipse-jdt-compiler-apt-java
which is no longer built by the eclipse-jdt-core source package.
This package is still present in
Package: loupe
Version: 46.2-2
Severity: serious
loupe build-depends on librust-ashpd-0.8+default-dev but testing/unstable
has version 0.9.
Package: gnome-metronome
Version: 1.3.0-5
Severity: serious
gnome-metronome build-depends on librust-gtk4-0.8+v4-10-dev but
unstable has version 0.9.
Package: glycin-loaders
Version: 1.0.1+ds-3
Severity: serious
glycin-loaders build-depends on librust-gio-0.19+default-dev but
testing/unstable now has version 0.20.
Package: camlimages
Version: 1:5.0.5-1
Severity: serious
It seems that about a fortnight ago camlimages started to FTBFS
on the "reproducible builds" tests server. This seems contempory
with the upload of ocaml 5.2.0-3
https://tests.reproducible-builds.org/debian/rbuild/unstable/arm64/camlimages
Package: gnome-metronome
Version: 1.3.0-4
Severity: serious
gnome-metronome's build-dependencies are unsatisfiable due to the recent
rust gtk stack update.
After bumping the build-dependencies and cargo dependencies I was able
to build the package and run it's (superficial) autopkgtest succesful
Package: rust-typenum
Severity: serious
rust-typenum is suffering from a failing test on i386, this
has been the case for some time as evidenced by debci and
reproducible builds test history but did not come to my
attention until a new version was uploaded and a "fails
to migrate to testing for a
Package: python-utidylib
Version: 0.10-1
Severity: serious
python3-utidylib depends on libtidy5deb0 which is no longer built by
the tidy-html5 source package. It appears to have been replaced by
libtidy58.
Since this is an arch all package, and a hard-coded depdency this
cannot be fixed by a bin
Package: python-tidylib
Version: 0.3.3~dfsg-7
Severity: serious
python3-tidylib depends on libtidy5deb0 which is no longer built by
the tidy-html5 source package. It appears to have been replaced by
libtidy58.
Since this is an arch all package, and a hard-coded depdency this
cannot be fixed by a
Found 1074652 0.8.0-5
Thanks
With the recent migration of a bunch of sequoia packages to testing,
rust-sequoia-chameleon-gnupg's build-dependencies are also unsatisfiable
in testing.
On 27/06/2024 12:33, Jeremy Bícha wrote:
Source: ffmpeg
Version: 7:6.1.1-4
Severity: serious
Tags: ftbfs
User: debian-...@lists.debian.org
Usertags: armel armhf
X-Debbugs-CC: debian-...@lists.debian.org
ffmpeg is failing to build on armel & armhf (but not arm64). This was
noticed while rebuildin
Package: slurm-wlm-basic-plugins
Version: 23.11.7-1
Severity: serious
slurm-wlm-basic-plugins depends on libpmix2t64 and slum-wlm
build-depends on , which is no longer
available on 32-bit architectures.
I notice that the build-dependency is already architecture
restricted, but the runtime depend
Package: sccache
Version: 0.8.1-3
Severity: serious
x-debbugs-cc: n...@sail.ng
sccache build-depends on librust-counted-array-0.1+default-dev which was
recently
removed from Debian. The removal request was filed by Blair Noctis who gave the
reasoning.
Please kindly remove rust-counted-array fr
Package: opensnitch
Severity: serious
Justification: rc policy - packages must be buildable within the same release.
The build-dependencies for opensnitch are no longer satisfiable
on ppc64el, because bpfcc no longer supports that architecture.
package: opensnitch
version: 1.5.8.1-1
archit
tags 1071297 +patch
thanks
It looks like e2fsprogs 1.47.1 renamed the inode_includes macro to
ext2fs_inode_includes.
A debdiff for the upload I made to raspbian to deal with this is
attached.diff -Nru btrfs-progs-6.6.3/debian/changelog btrfs-progs-6.6.3/debian/changelog
--- btrfs-progs-6.6.3/deb
Package: lime
Version: 5.2.0+dfsg-3
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
User: debian...@lists.debian.org
Usertags: edos-uninstallable
lime build-depends on boost1.74, which is no longer in testing. It seems that
lime was removed from t
Package: beast-mcmc
Version: 1.10.4+dfsg-5
Severity: serious
x-debbugs-cc: r-cran-rj...@packages.debian.org
beast-mcmc build-depends on r-cran-rjava, which is no longer available
on i386. It appears that the package failed to build, and the old
binaries were then removed.
Package: guestfs-tools
Version: 1.52.0-2
Severity: serious
User: debian...@lists.debian.org
Usertags: edos-uninstallable
guestfs-tools on armel build-depends on linux-image-marvell:armel |
linux-image-versatile:armel
neither of which is available anymore.
It looks like the only kernel now avail
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 visi
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 featu
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.
Firs
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 fine
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]: fai
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 impo
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'
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 libvdeplug2t64.
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 i
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 us
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
system-config-printer-1
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 file,
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 adding
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! (after
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 available
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
the
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 on
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 architectures
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 t
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 t
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 th
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
architec
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
ar
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 uninstallabilit
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
--- gfarm-2.7.20
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 tim
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 uninstallable
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 (armel
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 transi
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 u
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
lomiri-system-settings-security-privac
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 uni
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 transit
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 sub
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 a
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 MI
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 error
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 failu
1 - 100 of 1044 matches
Mail list logo
