I downloaded the build logs and filtered them to show the missing symbols that
were not already marked as optional.
plugwash@thinkpad:~$ wget -O zimlib.log
'https://buildd.debian.org/status/fetch.php?pkg=zimlib&arch=amd64&ver=4.0.4-5%2Bb1&stamp=1591384179&raw=0'
plugwash@thinkpad:~$ html2text
Package: pglogical
Version: 2.3.1-1
Severity: serious
Tags: ftbfs
It seems pglogical recently started failing to build.
http://buildd.raspbian.org/status/fetch.php?pkg=pglogical&arch=armhf&ver=2.3.1-1%2Bb1&stamp=1591473342
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/pglog
Some googling lead me to
https://svnweb.freebsd.org/ports/head/multimedia/mkvtoolnix/files/patch-boost-1.69?view=markup&pathrev=482787
which suggests it is now necessary to manually convert from tribool to bool by
writing bool{value}
Unfortunately after doing that I get
In file included from
Tags 959439 +patch
thanks
I was able to apply the upstream fixes to the Debian supercollider packaging,
in order to do so I had to make some formatting adjustments to the code(it
seems upstream reformatted their codebase since the version that is in Debian)
I did builds in Debian sid and Raspb
Yes, that. I look regularly at
https://qa.debian.org/dose/debcheck/src_testing_main/ as we (the release
team) require packages to be buildable in testing (we have some
tolerance as the migration of build dependencies isn't guaranteed when
checking if a package may migrate). Please help the rust m
Package: apper
Version: 1.0.0-2
Severity: serious
Tags: bullseye, sid, patch
http://buildd.raspbian.org/status/fetch.php?pkg=apper&arch=armhf&ver=1.0.0-2%2Bb4&stamp=1591727741
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/apper.html
CMake Error at /usr/share/cmake-3.16/Mod
I have now gone ahead with the NMU, the final debdiff is attatched (same as
previous debdiff apart from changelog tweaks)
diff -Nru vanguards-0.3.1/debian/changelog vanguards-0.3.1/debian/changelog
--- vanguards-0.3.1/debian/changelog2019-07-26 16:30:09.0 +
+++ vanguards-0.3.1/de
Package: qbittorrent
Version: 4.1.7-1
Severity: serious
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/qbittorrent.html
./../src/base/bittorrent/infohash.cpp: In constructor
'BitTorrent::InfoHash::InfoHash(const sha1_hash&)':
../../src/base/bittorrent/infohash.cpp:44:43: er
This bug has now caused xfsdump to be kicked out of testing which is making
amanda unbuildable in testing.
Yes, what's really needed here is for a change to be merged upstream
(as all other deb packaging artifacts are) otherwise this will keep
getting lost in time.
To make it easier to upstre
Putting the debian bug back in cc, previous mails are visible at
https://marc.info/?l=linux-xfs&m=159253950420613&w=2
On 19/06/2020 23:43, Dave Chinner wrote:
Isn't the configure script supposed to handle install locations?
Both xfsprogs and xfsdump have this in their include/builddefs.in:
PK
Putting the Debian bug back in cc, for earlier mails please see
https://marc.info/?l=linux-xfs&m=159253950420613&w=2
Eric Sandeen wrote:
How does debian fix this for xfsprogs? Doesn't the same issue exist?
I'm not seeing any cases like xfsdump where a binary is located in /sbin but
symlink
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 "
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
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
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
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: 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
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: 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
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: 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: 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: 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: 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: 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: 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: 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: 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
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: 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
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: 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: 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: 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: 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: 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: 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: 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: 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: 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
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: 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
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
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,
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
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
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
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.
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: 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: 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: 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: 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: 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
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.
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
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
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'
Looking at the changelog, I see
Build with --as-needed.
I suspect this is responsible for the build failure on armel
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
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-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 `
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
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
Package: breezy
Version: 3.3.4-1
Severity: serious
Tags: patch
Breezy build-depends on librust-regex+aho-corasick-dev which is no longer
provided (in either physical or virtual form) by rust-regex.
Looking at the Cargo.toml files I belive the correct build-dependency is
librust-regex-1+default-d
Package: rust-rustls-webpki
Version: 0.101.6-1
Severity: serious
The autopkgtest for rust-rustls-webpki fails with
238s error[E0583]: file not found for module `test_utils`
238s --> src/lib.rs:65:1
238s|
238s 65 | pub(crate) mod test_utils;
238s| ^^
238s|
2
Please see https://rustsec.org/advisories/RUSTSEC-2023-0070.html
I have read the upstream advisory and the linked bug report and while
I don't fully understand the nitty gritty details my understanding of
the issue is.
* It was discovered that code (which was not marked as unsafe)
could mis-
Tags 1055099 +patch
thanks
The autopkgtests for rust-async-task began failing after the upgrade
to from 4.4.1-1 to 4.5.0-1. This prevents its migration to Testing.
I have prepared a patch which adds a feature guard to the example in
question and hence fixes the autopkgtest. A debdiff is attatc
On 21/11/2023 11:41, Jonas Smedegaard wrote:
Quoting Peter Green (2023-11-21 09:16:21)
Tags 1055099 +patch
thanks
The autopkgtests for rust-async-task began failing after the upgrade
to from 4.4.1-1 to 4.5.0-1. This prevents its migration to Testing.
I have prepared a patch which adds a
Package: rust-leptonica-sys
Version: 0.4.6-3
Severity: serious
The Debian dependencies for rust-leptonica-sys allow versions of
rust-bindgen from 0.60.x to 0.66.x, however the Cargo dependencies
only allow versions from 0.64.x to 0.66.x. This is causing
autopkgtest failures and blocking rust-lept
Package: rust-async-task
Version: 4.4.0-3
Severity: serious
Tags: patch
rust-async-task's build-dependencies are unsatisfiable in testing/unstable
due to a recent update to rust-flume.
upstream bumped the dependency with no code changes, and after adding the
patch to the Debian package and adjus
Package: rust-matchers
Version: 0.1.0-1
Severity: serious
tas: trixie, sid
rust-regex-automata was recently updated to 0.3, rendering
the dependencies and build-dependencies of rust-matchers
uninstallable.
The changes seem to be fairly major, there is an upstream
pull request but details are sti
Package: rust-grep-regex
Version: 0.1.11-1
Severity: serious
rust-grep-regex depends on an old version of rust-regex-syntax, this
is fixed in upstream git, but looking at the commit messages it's not
something I feel comfortable cherry-picking.
I have opened an upstream issue enquiring about the
Package: rust-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: squeekboard
Version: 1.22.0-4
Severity: serious
Tags: patch
The rust gtk stack was recently updated, and squeekboard needs a few
tweaks to build with the new version.
I have whipped up a patch and tested that squeekboard builds with it,
I have not tested it beyond that.diff -Nru squeekb
Package: flask-dance
Version: 6.2.0.2-1
Severity: serious
Justification: rc policy - "packages must be buildable within the same release".
Tags: trixie, sid
flask-dance build-depends on python3-sphinxcontrib.seqdiag which is not in
testing,
it was removed because it FTBFS and was badly broken, b
rust-libslirp has no reverse dependencies in Debian.
https://codesearch.debian.net/search?q=path%3Adebian%2Fcontrol+rust-libslirp&perpkg=1
It is also one of the blockers for removing the old rust-zbus-1 from
Debian. See https://bugs.debian.org/1053631
Can we remove rust-libslirp and rust-libsli
Package: 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,
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`
--> src
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 cha
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.
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: 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: 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
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: hime
Version: 0.9.11+dfsg-2
Severity: serious
Tags: trixie, sid
Justification: rc-policy - packages must be buildable within the same release.
User: debian...@lists.debian.org
Usertags: edos-uninstallable
Hime build-depends on libayatana-indicator-dev which is no longer built
by the liba
tags 105121 +patch
thanks
rust-palette is unable to migrate to Testing because its
autopkgtests are failing.
I prepared a fix for the autopkgtest issues. While I was at
it I also bumped the clap dev-dependency and the associated
build and test dependencies to version 4 as we would like
to phas
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
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: 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: 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
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
tags 1042194 +patch
thanks
During a rebuild of all packages in sid, your package failed to build
on amd64.
The attached patch makes netavark build again (note: some of the packages
it depends on have only just been accepted, so it may be a little time
before binaries are available in sid).diff
tags 1043418 +patch
thanks
The autopkgtest for rust-rustls-webpki is failing with a bunch of file not
found errors.
Investigating a bit more, the issue is that the data files in question are
included in the source package, but not in the binary package. I'm not sure if
this is
a result of yo
Package: calculix-cgx
Version: 2.17+dfsg-2
Severity: serious
Tags: trixie, sid
calculix-cgx build-depends on libgl1-mesa-glx which is no longer built by the
mesa source package. It is still present in unstable and on a couple of
architectures in testing as a cruft package, but it is completely go
Package: massxpert
Version: 7.0.0-2
Severity: serious
Justification: rc-policy - packages must be buildable within the same release.
User: debian...@lists.debian.org
Usertags: edos-uninstallable
x-debbugs-cc: lopi...@debian.org
daps 3.3.2+cleaned1-4 moved calibre from suggests to depends.
This me
Package: 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: rust-hyper-rustls
Version: 0.23.2-4
Severity: serious
I just updated tokio-rustls to 0.24.1, hyper-rustls needs updating to 0.24.1
to match.
Package: rust-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
A bunch of packages just cleared new, and I made a bunch of follow up uploads.
The result is that the situation surrounding the log package has improved
a bit, but it still less than ideal.
The "kv_unstable" and "kv_unstable_sval" features are now enabled, the
"kv_unstable_serde" feature is curre
701 - 800 of 1842 matches
Mail list logo
