Reading the upstream changelog it seems that a load of
"breaking changes" came in 0.10 with those since then
being relatively minor. I've taken a priliminary look
through the rdeps and most of the important ones seem
to have updated to at least 0.10 upstream.
So my gut feeling is to start prepari
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.
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
I am trying to get the new versions of rust-sqlx and
related packages into testing, this is a prerequisite for
getting the new version of rust-base64 into testing.
It's currently blocked b
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
Please upgrade to branch v5.
I think it probablly makes more sense to go straight to version
6. I've uploaded that to experimental, can you prepare an update
to precious.
upstream changelog analysis:
nothing that looks too massive/scary, just msrv/dependency
bumps and some slight changes to er
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
On 26/09/2024 16:02, Paul Gevers wrote:
Hi Peter,
On 26-09-2024 16:24, Peter Green wrote:
Firstly britney is scheduling tests with the old
version of rust-sequoia-keystore and the new version of
rust-sequoia-keystore-tpm, despite the fact that the old
version of rust-sequoia-keystore does not
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: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
rust-sequoia-keystore-tpm is blocked from migrating to testing
by two issues. I do not believe either of these issues represent
real issues in the rust-sequoia-keystore-tpm package and
ther
Package: sccache
Version: 3.3.1-3
I hope to upgrade itertools to 0.13 soon, I've uploaded
new version to experimental. sccache has a
dev-dependency on itertools which the debian packaging
translates to a build-dependency.
I looked at the upstream changelog and didn't see anything too
scary and a
Package: rust-test-case
Version: 3.3.1-3
I hope to upgrade itertools to 0.13 soon, I've uploaded
new version to experimental. rust-test-case has a
dev-dependency on itertools which the debian packaging
translates to build and autopkgtest dependencies.
I looked at the upstream changelog and didn'
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: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
rust-unicode-width is blocked from migrating to testing by
autopkgtest failures in rust-tui. rust-tui is abandoned
upstream and we intend to get rid of it (see bugs
1080293 and 1080400). Up
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
Please upgrade to, or separately provide, quick-xml branch v0.36.
Raising severity, since oxigraph needs the bugfixes, and is crippled by
being forced to patch to use an older branch.
The new version is in experimental.
I've started looking through the rdeps but it may take a bit of time.
I be
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: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock rust-sqlx, it is currently blocked
by an autopkgtest "regression" of rust-debversion on
riscv64, which is caused by the fact that rust-debversion
is uninstable in testing on
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock rust-debian-copyright, it is currently blocked
by an autopkgtest "regression" of rust-debian-analyzer on
riscv64, which is caused by the fact that rust-debian-analyzer
is uni
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock rust-debian-copyright, it is currently blocked
by an autopkgtest "pregression" of rust-debian-analyzer on
riscv64, which is caused by the fact that rust-debian-analyzer
is un
Package: oxigraph
I am currently working on upgrading rust-clap and it's dependencies.
rust-clap 4.4.18 -> 4.5.15
rust-clap-derive 4.4.7 -> 4.5.13
rust-clap-builder 4.4.18 -> 4.5.15
rust-clap-complete 4.4.9 -> 4.5.18
rust-clap-lex 0.6.0 -> 0.7.2
Of these only clap-lex is semver-breaking.
The n
Please upgrade to, or separately provide, upstream branch v2.
rdeps:
Package: loupe - bug report filed with patch
Package: rust-async-channel - no changes needed.
Package: rust-async-executor - no changes needed
Package: rust-async-fs - no changes needed
Package: rust-async-global-executor - fi
Package: rust-event-listener
Version: 5.3.1-6
I hope to update rust-futures-lite to version 2 in sid soon,
the new version is available in experimental.
The Cargo dev-dependencies and Debian build-dependencies
for event-listener allow the new version, but the autopkgtest
dependencies currently d
Package: rust-async-std
Version: 1.12.0-21
I hope to update rust-futures-lite in sid soon, the new
version is available in experimental.
After relaxing the dependencies (debian and cargo)
rust-async-std builds successfully with the new version
of rust-futures-lite.
Package: loupe
Version: 46.2-1
Tags: patch
I hope to update rust-futures-lite to version 2 soon,
loupe builds successfully after relaxing the dependency
(indeed version 2 is what upstream asks for)
The new version of rust-futures-lite is available
in experimental if you want to do further testin
> rust-tokio: please update to v1.38
tokio itself is not semver-breaking, but one of it's closely
coupled dependencies mio is. The new versions of tokio,
tokio-macros, mio and signal-hook-mio are now available
in experimental.
rdeps:
Package: pushpin - bug report filed with patch.
Package: rust
That's why the test timeout on riscv64 is double that of other architectures:
Unfortunately in many cases, the performance difference seems a lot more
than a factor of two.
Take rust-gix for example, looking at the results for testing migration
tests I see
18-28m on amd64
53-59m on arm64
33-47
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 01/07/2024 07:21, Jonas Smedegaard wrote:
Quoting Peter Michael Green (2024-06-30 13:41:42)
I am aware that v2 is already pending in experimental, but given the
pace of transitioning to a new branch, it is helpful to have the
rng.fill() function available faster, for packages to prepare for t
Please upgrade to (or separately provide) branch v0.12.
This looks ready to go once rust-criterion and rust-test-case are fixed.
done
Package: btm
Package: elan
Package: git-delta
Package: hippotat
Package: precious
Package: python-maturin
Package: rust-av-metrics
Package: rust-cargo
Package:
Package: rust-test-case
Version: 3.3.1-1
Tags: patch
We are currently looking at updating rust-itertools to 0.12,
the new version is available in experimental.
The Debian build-dependencies and test-dependencies have no
upper limit on the version, but the Cargo dev-dependency does,
so building r
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
Package: pesign
Version: 116-7
While working on the time64 transition in raspbian, I discovered pesign failing
to build with a linker error.
cc -g -O2 -Werror=implicit-function-declaration
-ffile-prefix-map=/build/reproducible-path/pesign-116=. -fstack-protector-strong
-fstack-clash-protectio
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: precious
Version: 0.6.0-5
I hope to update rust-itertools to 0.12 soon. The new version is
available in experimental (and has been for some time).
I was able to sucessfully build precious with the new version
after patching the dependency. The debdiff I used for testing
is attatched.
di
Package: git-delta
Version: 0.17.0-1
I hope to update rust-itertools to 0.12 soon. I was able to succesfully
build git-delta with the new version of
The new version of rust-itertools is availilable in experimental, and
the debdiff I used for the test build is attatched.diff -Nru git-delta-0.17.0
Package: btm
Version: 0.9.6-6
I hope to update rust-itertools from 0.10 to 0.12 soon. Looking at btm
the version currently in Debian uses 0.11 upstream and is currently
patched to allow 0.10. I checked the upstream git and they did not
seem to make any code changes when upgrading from 0.11 to 0.1
Package: elan
Version: 3.1.1-1
I hope to update rust-itertools to 0.12 and rust-zstd to 0.13 soon.
For itertools the debian dependency allows the new versions, but the
Cargo dependencies do not. For zstd, neither the debian or cargo
dependencies
After relaxing the dependencies I was able to bui
Please upgrade (or separately package) newer upstream branch v0.8.
I presume this was meant to say 8.x, rather than 0.8
It seems version 8 of der-parser depends on two crates that
are not currently in debian. asn1-rs and displaydoc.
I tried updating inotify and applying the upstream patch to make notify
use the new version of inotify, but after doing so I got a bunch
of test failures when building python-watchfiles.
Package: rust-rio
Version: 0.8.3-3
I hope to update rust-quick-xml to 0.31 soon. rust-rio
will need an update for this.
I was able to build rust-rio and run it's autopkgtests
successfully after bumping the dependency.
The debdiff I used for testing is attatched.diff -Nru rust-rio-0.8.3/debian/c
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
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 = ">=0.12.
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 ab
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 packag
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
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 F
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 2023
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
aardvark-dns-1.4.0/debian/chang
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.
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 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 squeek
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
1 - 100 of 1267 matches
Mail list logo
