Package: rust-stdweb-internal-macros
Version: 0.2.9-1
Severity: serious
rust-stdweb-internal-macros depends on version 0.6 of rust-sha1
As I understand it the new version of rust-sha1 is a completely different
code base with the old rust-sha1 having been renamed to sha1-smol
stdweb appears to
Package: android-platform-system-tools-hidl
Severity: serious
Tags: bookworm, sid
android-platform-system-tools-hidl build-depends on android-libcrypto-utils-dev.
android-libcrypt-utils-dev is built from the android-platform-system-core source
package which was recently removed from testing at
Package: newsboat
Version: 2.21-1.2
Severity: serious
rust-gettext-sys and rust-gettext-rs have been updated to new upstream versions
breaking the build-dependencies of newsboat.
Hi
Apparently since the fix for #1008015 openvpn now demands a password,
even though none was needed before.
2022-05-23 08:47:47 OpenVPN 2.6_git x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO]
[LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO] built on May 20 2022
2022-05-23 08:47:47 library
Package: xygrib
Version: 1.2.6.1-1
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
Tags: patch
xygrib build-depends on libgrib2c-dev which is no longer built by the g2clib
source package. It is still present in unstable as a cruft package, but is
Version 3.0.7 seems to be be passing most of the time on armhf, though there
were
a few failures duing attempts to migrate gcc-12. The failures appear to be
timeouts.
Unfortunately 3.0.7 seems to be pretty consistently failing on s390x :(
This issue is related to https://bugs.debian.org/1009097
Bug 1009097 has been marked as fixed in meson 0.62.1-1, but according to
"reproducible builds" libgit2-glib still FTBFS with the same error.
https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/libgit2-glib.html
Package: golang-gopkg-libgit2-git2go.v31
Version: 31.4.3-4
Severity: serious
The autopkgtest for golang-gopkg-libgit2-git2go.v31 is failing with
libgit2 1.3
and hence blocking the transition.
On 01/05/2022 14:00, Fabian Grünbichler wrote:
currently progress is blocked on
- itoa/serde_json transition (anybody working actively on that?)
I just uploaded the new itoa to experimental and took a quick look
through the reverse dependencies.
rust-cssparser - already broken and not in
I took a look at updating rust-gstreamer to 0.17.4 (this is not the
latest version, but it is the version corresponding to the current rust
gtk stack in Debian) and hence solving the dependency issues with the
current package. There were two unsatisfied dependencies: muldiv 1.x and
pretty-hex
, thus making it preserve
the HOME environment variable, rpm run as root with HOME set to
/home/something will indeed do the wrong thing.
I will take a look into making the controversial Debian local patch to
rpm for creating a per-user database perform some more checks.
G'luck,
Peter
Package: gst-plugins-bad1.0
Version: 1.20.1-1
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
gst-plugins-bad1.0 build-depends on libwpewebkit-1.0-dev which is no longer
built by the wpewebkit source package. It is still present in unstable as a
On Tue, Apr 12, 2022 at 09:18:34PM +0200, Bastian Germann wrote:
> Am 12.04.22 um 21:04 schrieb Peter Pentchev:
> > Thanks for filing this. I fixed it yesterday in the salsa Git repo for
> > zchunk packaging:
> >
> >
> > https://salsa.debian
rg/pkg-rpm-team/zchunk/-/commit/79c480ffa9df4305c3fc5b0bfc4a553625e4c811
I intend to upload this in the next day or so; I was mainly waiting for
the libzstd update to 1.5.x to hit the archive.
Thanks for all your work on Debian!
G'luck,
Peter
--
Peter Pentchev r...@ringlet.net r...@debian.org
Package: libfreecontact-perl
Version: 0.08-9
Severity: serious
Justification: rc policy - "Packages must be buildable within the same release."
libfreecontact-perl build-depends on libfreecontact-dev which was recently
removed
on armel, presumablly due to a FTBFS.
Either freecontact needs to
Package: python-freecontact
Version: 1.1-6
Severity: serious
Justification: rc policy - "Packages must be buildable within the same release."
python-freecontact build-depends on libfreecontact-dev which was recently
removed
on armel, presumablly due to a FTBFS.
Either freecontact needs to be
is some code in rust-atk that translates it to an enum
the corresponding enum value doesn't seem to actually be used for
anything.
Author: Peter Michael Green
--- rust-atk-sys-0.14.0.orig/tests/abi.rs
+++ rust-atk-sys-0.14.0/tests/abi.rs
@@ -134,6 +134,14 @@ fn cross_validate_constants_with_c
Package: librust-structopt+lints-dev
Version: 0.3.26-1
Severity: serious
clap 2.34 dropped the "lints" feature, this has left librust-structopt+lints-dev
uninstallable in unstable and is blocking the migration to testing of the new
versions of clap and textwrap.
Since rust-structopt+lints-dev
Package: bambam
Version: 1.1.2+dfsg-1
Severity: serious
Tags: bookworm, sid
Bambam's autopkgtest is failing with the new version of pygame (which is needed
to fix a FTBFS bug).
https://ci.debian.net/data/autopkgtest/testing/amd64/b/bambam/20441215/log.gz
autopkgtest [05:37:55]: test smoke:
Package: fenics-basix
Version: 0.3.0-11
Severity: serious
Justification: rc policy - "Packages must be buildable within the same release."
Your package build-depends on python3-numba.
Unfortunately numba is not ready for python 3.10, it has been removed from
testing
and since the recent upload
Package: precious
Version: 0.1.3-2
Severity: serious
The upstream of the rust which crate dropped the optional dependency on
the rust failure crate. As a result of this the rust-which source
package no longer
builds a librust-which+failure-dev package.
The librust-which+failure-dev binary
Package: android-platform-system-core
Version: 1:10.0.0+r36-9
Severity: serious
The android-platform-system-core source package builds the adb and fastboot
binary packages which are also built (with a higher version number) by
android-platform-tools, I belive this is what lead to the rejection
Package: rust-weedle
Version: 0.12.0-1
Severity: serious
x-debbugs-cc: g...@rxv.cc, james...@debian.org
James McCoy and I are currently working on updating the rust-nom package
in Debian from version 5 to version 7. Debian also has version 4 of
nom packaged as a separate source package.
The
Package: librust-phf-shared+uncased-dev
Version: 0.10.0-2
Severity: serious
x-debbugs-cc: james...@debian.org
The most recent upload of rust-phf-shared added a new feature package,
librust-phf-shared+uncased-dev which depends on librust-uncased-0.9-dev
rust-uncased is not in Debian and I cannot
+
+ * Apply workaround for ruby gtk2/openssl conflict.
+ * Fix tests with ruby 3.0.
+
+ -- Peter Michael Green Sat, 05 Mar 2022 19:11:29
+
+
origami-pdf (2.0.0-1) unstable; urgency=medium
* New upstream release
diff -Nru origami-pdf-2.0.0/debian/patches/gtk2-openssl-workaround.patch
Package: bagel
Version: 1.2.2-3
Severity: serious
x-debbugs-cc: mp...@packages.debian.org
bagel's autopkgtest is failing on amd64 with mpich 4.0.1-1 and hence
blocking it's migration to testing and hence blocking the finalisation
of the slurm-wlm transition.
to reflect
+architectures where the current version of muscle is available.
+
+ -- Peter Michael Green Tue, 01 Mar 2022 20:39:50 +
+
python-biopython (1.79+dfsg-2) unstable; urgency=medium
* Move w3-dtd-mathml from Suggests to Depends to avoid dangling symlink
diff -Nru python
n 32-bit
+architectures.
+
+ -- Peter Michael Green Sun, 27 Feb 2022 07:27:00 +
+
dask (2022.01.0+dfsg-1) unstable; urgency=medium
* New upstream release
diff -Nru dask-2022.01.0+dfsg/debian/patches/series
dask-2022.01.0+dfsg/debian/patches/series
--- dask-2022.01.0+dfsg/debian/patches/series 20
Package: sphinx-remove-toctrees
Version: 0.0.3-1
Severity: serious
The release team have decreed that only binaries build on the buildd network
can migrate to testing, please make a source-only upload so your package can
migrate.
Wookey wrote:
That seems an oversimplification. There is usually an FPU (almost
always) and a neon unit (usually). The point is that their presence is
not guaranteed
Debian armhf requires a FPU as part of the baseline. More than
that it requires a FPU as part of the ABI!
Andreas Tille wrote:
found 1000230 1.0-2
severity 1000230 normal
--
Got it. Thanks anyway, Georges!
Peter
24.02.2022, 16:56, Georges Khaznadar < mailto:georges.khazna...@orange.fr
georges.khazna...@orange.fr >
Thank you for the bug report, Peter. However, I shall not try to fix it
shortly. I suspect that
gobject-introspection/loader.rb:103:in
`block in define_singleton_method' from ./screenruler.rb:91:in `'
Since the errors are marked as CRITICAL, I presume that something wrong goes
there.
Thanks in advance for looking into it,
Peter
On 22/02/2022 12:57, Bernd Zeimetz wrote:
Hi,
I fail to understand why you are opening this bug at all.
rc bugs are how we track packages in testing that are not living up to the
standards Debian sets and ultimately trigger their removal.
"packages must be buildable within the same release"
Tags 1006141 +patch
thanks
This was fixed in ubuntu a few months ago by adding ".fpu vfp" to the
assembler file in question.
(within the block of code that is only used on systems with the hard
float ABI).
https://patches.ubuntu.com/s/supertuxkart/supertuxkart_1.3+dfsg1-2ubuntu1.patch
I
During a rebuild of all packages in sid, your package failed to build
on amd64.
I'm no expert on this particular package, but this looks to me like it
is not actually caused by a problem in python-sparse, but is instead a
symptom of python3-numba not being built against python 3.10 due to
On 25/01/2022 23:22, peter green wrote:
The upstream report at
https://github.com/pytest-dev/pytest-twisted/issues/146 was closed as the
additional warning is produced by Twisted. The Twisted fix isn't merged yet.
It looks like the twisted fix has now been merged upstream, does it make
sense
())
base.ui.notifyError("Uncaught exception at toplevel")
if getattr(opts, "enablePDB", False):
diff -Nru gavodachs-2.5+dfsg/debian/changelog
gavodachs-2.5+dfsg/debian/changelog
--- gavodachs-2.5+dfsg/debian/changelog 2021-11-17 12:55:14.0 +
+++ gavodachs-2.5
Hi Peter,
Build dependencies for qosmic have been updated.
I have uploaded the new version to Mentors.
https://mentors.debian.net/package/qosmic/
I assume the usual sponsor is busy.
If you could help with a one-off upload,
that would be much appreciated.
Cheers,
Peter B
Package: qosmic
Version: 1.6.0-4
Severity: serious
Tags: bookworm, sid
qosmic build-depends on the flam3 binary package which is no longer built by
the flam3 source package.
The flam3 source package appears to have split different parts into different
binary packages, please
assess which ones
Package: collectd
Version: 5.12.0-8
Severity: serious
Justification: rc policy: "packages must be buildable within the same release"
collectd build-depends on liboping-dev, which is rc buggy and was removed from
testing recently in an attempt to finish off the perl transition. This makes
Package: rust-csv
Version: 1.1.5-2
Severity: serious
rust-csv's autopkgtest is failing, which is blocking it's migration to
testing.
--- cookbook_read_basic stdout
thread 'cookbook_read_basic' panicked at 'command spawns successfully: Os { code: 2,
kind: NotFound, message: "No such
Package: libcmark-dev
Version: 0.9.0-1
Severity: serious
Rebuilding nheko in current sid results in the following dependencies.
Depends: libc6 (>= 2.33), libcmark0 (>= 0.30.2-4), libcmark0 (<< 0.30.2-4+), libcurl4 (>= 7.16.3), libevent-core-2.1-7 (>= 2.1.8-stable),
libevent-pthreads-2.1-7
The upstream report at
https://github.com/pytest-dev/pytest-twisted/issues/146 was closed as the
additional warning is produced by Twisted. The Twisted fix isn't merged yet.
It looks like the twisted fix has now been merged upstream, does it make
sense to apply it as a patch to the Debian
on the "vendored" feature of the openssl crate,
+it has been removed in current Debian packaging of that crate (and was a
+no-op before that)
+ * Change Debian dependency to depend on librust-semver-0.9-dev
+instead of librust-semver-dev.
+
+ -- Peter Michael Green Sat, 22 Jan 202
Package: nextpnr
Version: 0.0~git20210102.9b96280-1
Tags: bookworm, sid
Severity: serious
nextpnr build-depends on fpga-icestorm-chipdb which is no longer built by
the fpga-icestorm source package, it is still present in unstable as a cruft
package, but is completely gone from testing.
Package: arachne-pnr
Version: 0.1+20190728gitc40fb22-2
Tags: bookworm, sid
Severity: serious
arachne-pnr build-depends on fpga-icestorm-chipdb which is no longer built by
the fpga-icestorm source package, it is still present in unstable as a cruft
package, but is completely gone from testing.
Source: python-igraph
Version: 0.9.8-1
Severity: serious
Justification: rc policy - packages must be buildable within the same
release
python-igraph build-depends on libigraph-dev which was recently removed on
s390x. So the package's build-depends are no longer satisfiable on that
Package: bat
Severity: serious
While checking on the testing migration of rust source packages I noticed that
librust-bat-dev was uninstallable because the old version of syntect did not
offer all the required features. When I started looking at the issue I noticed
there was a new version of
ard (1.14.0-3.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Drop dependencies on obsolete cargo features in rust gtk stack.
+ * Use -f in rm command in clean target so it doesn't fail if the file
+is already gone.
+
+ -- Peter Michael Green Sat, 15 Jan 2022 05:09:34 +
reopen 1002164
thanks
On 21/12/2021 20:27, plugwash wrote:
The more immediate fix, which I have just uploaded as rust-signal-hook
0.1.13-3 is to do what upstream did in signal-hook 0.1.17 and use a caret
dependency instead of a tilde dependency on signal-hook-registry.
Signal-hook 0.3 has now
.
+ * Adjust dependencies for rust gtk stack 0.14
+
+ -- Peter Michael Green Wed, 29 Dec 2021 00:24:20 +
+
resvg (0.8.0-4) unstable; urgency=high
* Fix the librust-jpeg-decoder-0.1-dev dependency.
diff -Nru resvg-0.8.0/debian/control resvg-0.8.0/debian/control
--- resvg-0.8.0/debian/control
Package: nheko
Version: 0.9.0-1
Severity: serious
nheko depends on gstreamer1.0-qt5 which is not available on armel/armhf
this is blocking it's migration to testing.
Please evaluate how important the dependency is and either make it arch
specific or if your package can't live without it alter
Package: wlr-randr
Version: 0.2.0-1
Severity: serious
The wlr-randr autopkgtest is failing with the new version of phoc
https://ci.debian.net/data/autopkgtest/testing/amd64/w/wlr-randr/17846958/log.gz
autopkgtest [22:48:44]: test command1: WLR_BACKENDS=headless WLR_LIBINPUT_NO_DEVICES=1
phoc
Relevant part (hopefully):
/usr/bin/ld: CMakeFiles/cmTC_d6505.dir/src.c.o: in function `main':
./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/src.c:11: undefined reference to
`pthread_create'
/usr/bin/ld: ./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/src.c:12: undefined
reference to `pthread_detach'
Package: scipy
Version: 1.7.1-2
Severity: serious
scipy build-depends on python3-pybind11 (<< 2.8) but testing and unstable
have version 2.8.1-3
I've discovered there is a 2nd seed, so have modified the little test script.
Also, the 'echo' was superfluous with set -x
===
#!/bin/bash
#
set -e
set -x
#
while :
do env seed=$RANDOM issac_seed=$RANDOM flam3-genome > /dev/null
done
#
genome.sh
I know we
expect this for some time in the rust ecosystem, but 60 days ought to be
enough for that.
I appreciate your efforts to keep testing moving forwards.
All the crates that are used by applications in testing that had dependencies
on rust-futures have been dealt with (generally by
or the kernel?
I'm attaching a script that runs flam3-genome continuously until it crashes.
It would be very helpful if someone with easy access to ppc64el could install
flam3,
run the script, and report a seed number that triggers a segfault.
The problem should then be easily reproducible.
Cheers,
Peter
On the machine with a not working screenruler, we have this at the moment:
$ screenruler & [1] 2926 $ Loading libraries... Gtk-Message: 02:43:39.844:
Failed to load module "canberra-gtk-module" /usr/bin/screenruler:61:in `block
in ': 'Gdk::Pixbuf' has been deprecated. Use 'GdkPixbuf::Pixbuf'.
On the machine with the working screenruler, we have this at the moment: $
screenruler & [1] 82945 $ Loading libraries... /usr/bin/screenruler:61:in
`block in ': 'Gdk::Pixbuf' has been deprecated. Use 'GdkPixbuf::Pixbuf'.
/usr/lib/ruby/vendor_ruby/gdk_pixbuf2/deprecated.rb:48:in `new':
Package: php-oscarotero-gettext
Version: 4.8.2-6
Severity: serious
Justification: rc policy - "Packages must be buildable within the same release"
php-oscarotero-gettext build-depends on the php-illuminate-database binary
package,
which is built by the php-laravel-framework source package which
Package: azure-cli
Version: 2.31.0-1
Severity: serious
azure-cli build-depends on pylint3 which is no longer built by the pylint
source package, it is still present in unstable as a cruft package, but is
completely gone from testing.
Since the package was previously an empty (other than
Package: crystal
Version: 1.2.1+dfsg-6
Severity: serious
Justification: rc policy - "Packages must be buildable within the same
release"
crystal build-depends on libllvm9 or libllvm8, neither of these packages are
available in testing anymore. Please investigate migration to a newer
version
Package: pyopencl
Tags: bookworm
Severity: serious
Justification: rc policy - "Packages must be buildable within the same
release"
pyopencl build-depends on pocl-opencl-icd which is no longer in testing.
reopen 1000230
found 1000230 0.960+bzr41+deb10-6
thanks
The updated screenruler still fails to start:
$ LANG=C sudo aptitude show screenruler | egrep "(State)|(Version)" Version:
0.960+bzr41+deb10-6 State: installed $ LANG=C sudo aptitude show
libcanberra-gtk3-module | egrep "(State)|(Version)"
On the other machine, libcanberra-gtk3-module IS installed, but screenruler
still fals to start:
$ LANG=C sudo aptitude show screenruler | egrep "(State)|(Version)" Version:
0.960+bzr41+deb10-4 State: installed $ LANG=C sudo aptitude show
libcanberra-gtk3-module | egrep "(State)|(Version)"
/changelog 2021-12-09 19:43:19.0 +
@@ -1,3 +1,10 @@
+pfstools (2.2.0-1+rpi1) bookworm-staging; urgency=medium
+
+ * Reorder includes to stop macro in pm.h causing breakage in
+c++ system headers (Closes: 998498)
+
+ -- Peter Michael Green Thu, 09 Dec 2021 19:43:19
+
On 08/12/2021 23:56, Simon McVittie wrote:
> On Wed, 08 Dec 2021 at 20:11:55 +0000, peter green wrote:
>> The default -march value on Debian armhf is "armv7-a+fp". You should
>> *NOT* use "armv7-a+vfpv3" as that specifies the version of vfpv3
>> with 32
On 08/12/2021 09:48, Simon McVittie wrote:
On Wed, 08 Dec 2021 at 09:41:29 +, Simon McVittie wrote:
At a guess, perhaps the problem is that the mozjs build system is explicitly
specifying -march=armv7-a when it should be something like
-march=armv7-a+vfpv3 or accepting the compiler's
Package: rust-zbus-macros
Version: 1.0.0-3
Severity: serious
x-debbugs-cc: deb...@nilux.be
The rust-zbus-macros autopkgtest is failing:
error[E0432]: unresolved import `zbus`
--> /tmp/tmp.2o6G5gYnNc/registry/zbus-1.0.0/src/object_server.rs:54:1
|
54 | #[dbus_interface(name =
unmerge 1000467
reopen 1000467
thanks
With the fix in 4.17.0+dfsg1-2 the autopkgtest on armhf makes more progress
than before, but it still fails.
autopkgtest [04:13:12]: test rpmbuild: env PYTHONPATH="$(pwd)/debian/tests/src"
python3 -B -u -m rpmtest -b /usr/bin -d debian/tests/data
Package: parl-desktop-world
Version: 1.9.29
Severity: serious
parl-desktop-world depends on thunderbird-l10n-si which is no longer built from
the thunderbird source
package, it is still present in unstable as a cruft package but is completely
gone from testing.
Dear George,
On one of the two Debian-stable machines I manage libcanberra-gtk3-module is
installed:
$ LANG=en_US.utf8 sudo aptitude show libcanberra-gtk3-module | egrep
"(State)|(Version)" Version: 0.30-7 State: installed
On this machine, screenruler works. I'll check the other machine in
Package: glewlwyd
Version: 2.5.2-3
Severity: serious
Tags: ftbfs
Unfortunately it seems that even after the cross-fetch fix, glewlwyd still
FTBFS as a
result of changes in iddawc/rhonabwy.
/usr/bin/cc -D_GNU_SOURCE -Dschememodoauth2_EXPORTS -I/include -g -O2
-ffile-prefix-map=/<>=.
Package: rpm
Version: 4.17.0+dfsg1-1
Severity: serious
The new version of rpm added an autopkgtest, but unfortunately it's failing on
armhf
and blocking the migration to testing (and hence blocking the fixes for two
other rc bugs).
autopkgtest [04:40:50]: test rpmbuild: env
Version: 4.17.0+dfsg1-1
On Thu, Nov 18, 2021 at 12:19:10PM +0200, Peter Pentchev wrote:
> control: tag -1 + confirmed pending
>
> On Thu, Nov 18, 2021 at 09:45:06AM +0100, Laurent Bigonville wrote:
> > Source: debugedit,rpm
> > Severity: serious
> > Tags:
filing this bug for the purpose of keeping the new
version of debugedit out of testing for the present.
G'luck,
Peter
--
Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E
Package: node-regexpu-core
Version: 4.7.1-3
Severity: serious
node-regexpu-core build-depends on node-unicode-13.0.0
which is no longer built by the node-unicode-data source package. It
is still present in unstable as a cruft package but is completely gone from
testing.
The package appears to
Package: node-regenerate-unicode-properties
Version: 8.2.0+ds-2
Severity: serious
node-regenerate-unicode-properties build-depends on node-unicode-13.0.0
which is no longer built by the node-unicode-data source package. It
is still present in unstable as a cruft package but is completely gone
Package: libstdc++-arm-none-eabi
Version: 13
Severity: serious
x-debbugs-cc: kei...@debian.org
libstdc++-arm-none-eabi build-depends on the gcc-arm-none-eabi-source binary
package which is no longer built by the gcc-arm-none-eabi source package. It
is still present in unstable as a cruft package
Package: rpm
Version: 4.16.1.2+dfsg1-3
Tags: bookworm, sid
Severity: serious
rpm build-depends on libsepol1-dev which is no longer built by the libsepol
source package. The package is completely gone from testing, in unstable it is
still
present as a cruft package, but is not usable for
Package: cryptsetup
Version: 2:2.4.1-1
Severity: serious
cryptsetup build-depends on libsepol1-dev which is no longer built by the
libsepol
source package. The package is completely gone from testing, in unstable it is
still
present as a cruft package, but is not usable for building cryptsetup
Source: lix
Version: 0.9.29-1.1
Severity: serious
Tags: ftbfs
The attempts to rebuild lix against ldc 1.28.0 failed, on amd64, i386 and armhf
the build failed with.
/usr/lib/ldc/x86_64-linux-gnu/include/d/std/algorithm/comparison.d(1531,6):
Warning: skipping definition of function
Control: tag -1 pending
Hello,
Bug #996807 in djbdns reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
In addition to the (build-)dependency on an old version of rust-crossbeam-queue,
rust-tokio-process (build-)depends on version 0.1 of rust-futures. Upstream
seems to
have abandoned the crate, there was an alpha release supporting futures 0.2, but
the code appears to have been removed from the
Package: rust-tokio-signal
Version: 0.2.7-2
Severity: serious
rust-tokio-signal (build-)depends on version 0.1 of rust-futures. Upstream
seems to
have abandoned the project, there was an alpha release supporting futures 0.2,
but
the code appears to have been removed from the tokio git
f symbols that disappeard with gcc-11 as
+optional=inline
+
+ -- Peter Michael Green Mon, 08 Nov 2021 00:26:53
+
+
lomiri-app-launch (0.0.90-8) unstable; urgency=medium
* debian/control:
diff -Nru lomiri-app-launch-0.0.90/debian/liblomiri-app-launch0.symbols
lomiri-app-launch-0.0.
Tags 997203 +patch
Thanks
I ran into this issue in Raspbian and found I could fix it by disabling the
block in question
in compat.h. I have uploaded this change to raspbian, A debdiff should appear
soon at
https://debdiffs.raspbian.org/main/g/gigedit No intent to NMU in Debian.
On 05/11/2021 07:21, Timo Aaltonen wrote:
I'd have assumed that reverse build-depends are checked before migration to
testing?
They aren't :(
> bind9-dev : Depends: bind9-libs (= 1:9.16.21-1) but it is not going to be
installed
It looks like bind8 no longer builds the bind9-dev package. It's still present
in
unstable as a cruft package but is uninstallable due to version constraints,
it's
completely gone from testing.
Bind
The packages that will fix this (rust-cargo-util and rust-im-rc) are in NEW.
The new version of rust-memchr which will fix this is in NEW.
Reassign 998415 rust-cargo
Close 998415 0.57.0-1
Thanks
I believe this issue is actually in the rust-cargo package*. Googling the line
of code wit the
error lead me to https://github.com/rust-lang/cargo/issues/9124 which had a
link to a commit
fixing the issue at
It passes when run with only packages from testing.
no it doesn't, it's skipped due to unsatisfiable dependencies.
However manual testing shows that the underlying failure does
affect the version in testing, so this is not *really* a
regression it just looks like one to debci.
I copied some
severity 998027 normal
thanks.
Possible ways forward.
1. Do nothing, wait for the issue to go away when the new rustc makes it
into testing.
I don't mind 1.
In that case I'll downgrade the bug so it doesn't unnecessarily delay
testing migration after the new rustc migrates. I think it
"error[E0554]: `#![feature]` may not be used on the stable release channel" is
a red herring.
The autopkgtests for rust packages try the tests in normal mode first, then if
it fails with
E0554 they are rerun in "nightly" mode.
The real issue is further down the log.
error[E0658]: const
Package: libmodulemd
Version: 2.12.0-1
Severity: serious
libmodulemd's autopkgtest is failing during testing migration tests
for meson 0.60
https://ci.debian.net/data/autopkgtest/testing/amd64/libm/libmodulemd/16225041/log.g
=== Running meson at the configure stage
The Meson build system
Hi
It may be that this is fixed in the package, but packages depending
on libcmark0.30.1 providing 0.30.1 and not 0.30.2 are now broken:
mkvtoolnix-gui: error while loading shared libraries: libcmark.so.0.30.1:
cannot open shared object file: No such file or directory
Cheers
Seegras
--
Package: chromium
Version: 93.0.4577.82-1
Severity: serious
chromium build-depends on python-jinja2 which is no longer built by the
jinja2 source package.
It is still present in unstable as a cruft package but is completely
gone from testing.
Package: fcitx5-qt
Version: 5.0.7-1
Severity: serious
I recently noticed that fcitx5-qt failed to build in raspbian bookworm-staging.
dh_install -a
dh_install: warning: Cannot find (any matches for)
"usr/lib/*/fcitx5-qt5-gui-wrapper" (tried in ., debian/tmp)
dh_install: warning:
301 - 400 of 3615 matches
Mail list logo
