On 28/04/2023 18:58, Fabian Grünbichler wrote:
I see no practical issue with 2 meaning we can't have multiple semver
suffix packages variants of a single crate installed - having the
unversioned and one semver suffix package in one suite at any given time
should already be the exception, having
On 28/04/2023 06:05, Helmut Grohne wrote:
Can you go into more detail as to what you mean with "don't support
version ranges"?
You can place a lower bound on the version, place an upper bound
on the version or constrain to a precise version. But you can't
constrain to a range of versions.
Summarising a number of bug reports by Helmut Ghrone:
Please ensure that librust---dev has sufficient Breaks and
Replaces declarations.
The issue specifically appears to be that the breaks+replaces are declared
against a virtual package, it seems dpkg is honoring the breaks against the
Package: singular
Version: 1:4.3.1-p3+ds-1
Severity: serious
Justification: rc-policy - "Packages must be buildable within the same release"
singular build-depends on python3-brial. python3-brial recently added a
dependency on python3-sage making it uninstallable on many architectures.
As a
On 23/04/2023 21:07, Paul Gevers wrote:
Can you point to a discussion where we might draw the conclusion that
this is common practice or consensus? I *personally* [no hats on] find
that distinction a bit weird although I can see how we would come to
it and also why.
No, I can't point to a
On 23/04/2023 19:19, Paul Gevers wrote:
I claim this is wrong. Would python3-sage one day build on more
architectures, this list would need manual updating. Instead of
hard-coding the list, it's better to ensure the build doesn't happen
or fails on architectures where python3-sage is not
Package: python3-brial
Version: 1.2.11-2
Severity: serious
X-debbugs-cc: singu...@packages.debian.org
python3-brial recently added a dependency on python3-sage, however python3-sage
is only available on amd64, arm64, i386 and riscv64.
This also means that the build-depends of singular on those
severity 103 normal
retitle 103 rust-encoding is unmaintained upstream
severity 104 normal
retitle 104 rust-boxfnonce is unmaintained upstream
severity 105 normal
retitle 105 rust-const-cstr is unmaintained upstream
(summarising several bugs)
there is
I've prepared an NMU for rust-kvm-bindings (versioned as 0.5.0-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I should cancel it.
It's not my place to tell you to cancel it, but I can tell you that it
it will not clear the path for testing migration.
The new version of
On 2023-03-02 19:53:12 +0100, Peter J. Holzer wrote:
> So it seems that my suspicion that {% compress js %}...{% endcompress %}
> wasn't working properly was correct. But of course that raises the
> question why that would fail on one system and work on another. I'll
>
On 2023-03-02 01:32:55 +, James Addison wrote:
> Package: python3-django-hyperkitty
> Followup-For: Bug #1031928
> X-Debbugs-Cc: h...@hjp.at
> Control: tags -1 moreinfo
>
> Hi Peter,
>
> I'd like to gain some experience with configuring email infrastructure, and
>
Package: python3-django-hyperkitty
Version: 1.3.4-4
Severity: grave
Tags: patch
Justification: renders package unusable
Dear Maintainer,
I set up mailman3 including the web interface and the hyperkitty
archiver with Apache2 and a test mailing list.
Upon accessing the archive at
On Tue, Feb 21, 2023 at 12:39:53AM +0200, Peter Pentchev wrote:
> On Mon, Feb 20, 2023 at 05:23:28PM -0500, Boyuan Yang wrote:
> > Hi,
> >
> > 在 2023-02-21星期二的 00:38 +0530，Nilesh Patra写道：
> > > On Fri, 17 Feb 2023 07:51:48 +0100 Lucas Nussbaum
> > >
of. Sorry about that. I guess I didn't consider the python-zstandard
package at all until now.
As I am a member of both the pkg-rpm and pkg-python teams, I could try to
update the packages in sync from now on, possibly adding something like
Breaks: python-zstandard (<< version-I-am-about-to
.
+
+ [ Jochen Sprickerhof ]
+ * Add patch to fix FTBFS on i386.
+Thanks to Adrian Bunk (Closes: 1004869)
+ * Use execute_after_ in d/rules
+ * Set R³ in d/control
+
+ -- Peter Michael Green Sun, 19 Feb 2023 00:50:57 +
+
python-xarray (2023.01.0-1) unstable; urgency=medium
* Mew
for this issue:
https://github.com/yt-dlp/yt-dlp/commit/149eb0bbf34fa8fdf8d1e2aa28e17479d099e26b
Best regards,
Peter
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-3-amd64 (SMP w/16 CPU threads
is a problem which was introduced by fuse3 3.13.1. A fix has
been provided by upstream:
https://github.com/libfuse/libfuse/commit/d7560cc9916b086bfe5d86459cc9f04033edd904
Best regards,
Peter
the rebuilding manually and then upload
binaries+source. The binaries can rebuild the sources, but the old binaries
cannot.
Is this setup still supported with the new rules or is this the last hurrah
from the cmucl package?
Best regards, Peter
On 09/02/2023 23:43, Michele Martone wrote:
On 20230209@17:50, Peter Green wrote:
Package: librsb
Version: 1.3.0.2+dfsg-1
Tags: bookworm, sid
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
User: debian...@lists.debian.org
User
The following packages have unmet dependencies:
librust-rspotify-dev : Depends: librust-base64-0.12+default-dev
Depends: librust-itertools-0.9+default-dev
Depends: librust-rand-0.7+default-dev
Depends:
The following packages have unmet dependencies:
librust-rust-code-analysis-dev : Depends: librust-petgraph-0.5+default-dev
Depends: librust-phf-0.8+default-dev
Depends: librust-phf-0.8+macros-dev
reopen 1007026
thanks
* Revert to nom 4, porting to nom 7 seems to be non-trivial and I do not
want to further increase the proliferation of nom versions in Debian.
As I said in the initial mail, I did indeed patch weedle to revert
to nom 4. However in doing so I caused an API break. As
Package: librsb
Version: 1.3.0.2+dfsg-1
Tags: bookworm, sid
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
User: debian...@lists.debian.org
Usertags: edos-uninstallable
librsb build-depends on coccinelle which appears to have been removed
on
Package: rust-sequoia-keyring-linter
Version: 1.0.0-1
Severity: serious
rust-rpassword was recently updated to version 6.x, but sequoia-keyring-linter
still depends on version 5.x. I have checked crates.io and upstream git, and
there does not appear to be an upstream patch available.
on bumping
Control: tag -1 pending
Hello,
Bug #997130 in acmetool 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:
Package: dask.distributed
Version: 2022.12.1+ds.1-1
Severity: serious
X-debbugs-cc:
pkg-grass-de...@lists.alioth.debian.org,debian-science-maintain...@lists.alioth.debian.org
The autopkgtest for dask.distributed is failing.
Package: pushpin
Version: 1.36.0-1
Severity: serious
The new version of pushpin added a dependency on jsonwebtoken,
unfortunately jsonwebtoken depends in ring, which is only available
on x86* and arm*. There is work upstream to make ring more
portable but it seems unlikely to feature in a stable
Package: libgraphicsmagick-q16-3
Version: 1.4+really1.3.39-2
Severity: serious
libgraphicsmagick-q16-3 has a hardcoded dependency on libtiff5,
so even after binnmuing for the tiff transition it still depends on it
This affects both the version in bookworm and the version in sid,
I have not
- netavark-1.4.0/debian/changelog 2023-01-02 13:45:36.0 +
+++ netavark-1.4.0/debian/changelog 2023-01-14 10:48:58.0 +
@@ -1,3 +1,10 @@
+netavark (1.4.0-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Update debian dependency on clap to match cargo
lap.
+
+ -- Peter Michael Green Sat, 14 Jan 2023 08:53:08 +
+
aardvark-dns (1.4.0-2) unstable; urgency=medium
* update dns-proto-server patch with upstream, verified to
diff -Nru aardvark-dns-1.4.0/debian/control aardvark-dns-1.4.0/debian/control
--- aardvark-dns-1.4.0/debian/control 2023-01-09
y the upload of mk-configure/0.37.0-2, which
actually installed the package files (including the mkcmake program).
I believe this bug can be closed; a manual rebuild of libmaa in
an unstable-amd64 chroot (with mk-configure-0.37.0-2) worked for me just now.
Thanks for your periodic full archive rebuilds
Package: cctbx
Version: 2022.9+ds2+~3.11.2+ds1-5
Severity: serious
Despite the fix uploaded for bug 1024859 the cctbx autopkgtest is still
failing
and preventing the package from migrating to testing.
Testing cctbx with python3.10:
Sorry: Please run this program in an empty directory.
Source: commons-vfs
Version: 2.1-2
Tags: bookworm, sid
Severity: serious
Justification: rc policy - "packages must be buildable within the same
release"
User: debian...@lists.debian.org
Usertags: edos-uninstallable
commons-vfs build-depends on libcommons-net-java-doc which
is no longer built
Package: open-vm-tools
Version: 2:12.1.5-1
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
User: debian...@lists.debian.org
Usertags: edos-uninstallable
open-vm-tools build-depends on libprocps-dev which is no longer built
by the procps source
Package: guymager
Version: 0.8.13-1
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
User: debian...@lists.debian.org
Usertags: edos-uninstallable
guymager build-depends on libprocps-dev which is no longer built
by the procps source package. It
-maintainer upload.
+ * Depend on librust-zip-0.6-dev instead of rust-zip-0.5-dev
+
+ -- Peter Michael Green Wed, 28 Dec 2022 16:57:19 +
+
sccache (0.4.0~~pre1-1) unstable; urgency=medium
[ upstream ]
diff -Nru sccache-0.4.0~~pre1/debian/control sccache-0.4.0~~pre1/debian/control
--- sccache
Package: ruby-aruba
Version: 2.1.0-1
Severity: serious
Justification: rc policy - "Packages must be buildable within the same release"
User:debian...@lists.debian.org
Usertags: edos-uninstallable
ruby-aruba build-depends on rubocop (<< 1.0) but bookworm and sid have version
1.39.0+dfsg-1
Package: rust-svgdom
Version: 0.18.0-2
Severity: serious
svgdom depends on version 0.7 of the roxmltree crate. Debian sid now has version
0.16.
I tried bumping the dependency but it fails to build with the following errors.
error[E0599]: no method named `write_buf` found for struct
During a rebuild of all packages in sid, your package failed to build
on amd64.
I make the following observations about this package.
* It relies on perma-unstable rustc features and this is the third time it
has broken in the last two years due to changes in rustc.
* It has no long-term
Package: rust-trust-dns-proto
Version: 0.22.0-1
Severity: serious
01234567890123456789012345678901234567890123456789012345678901234567890123456789
rust-trust-dns-proto has an "optional" (in the cargo sense) dependency on
rustls, since collapse_features is used*, this results in it depending but
Package: obantoo
Version: 2.1.12+ds1-3
Severity: serious
Justification: rc policy - "packages must be buildable within the same
release"
User: debian...@lists.debian.org
Usertags: edos-uninstallable
obantoo build-depends on libitext5-java-doc which is no longer built
by the libitext5-java
Source: deepin-log-viewer
Version: 5.9.7+ds1-1
Severity: serious
Tags: bookworm, sid
Justification: rc policy - "Packages must be buildable within the same release"
User:debian...@lists.debian.org
Usertags: edos-uninstallable
deepin-log-viewer build-depends on libfftw3-3, this was previously a
Source: gsequencer
Version: 4.4.1-1
Severity: serious
Tags: bookworm, sid
Justification: rc policy - "Packages must be buildable within the same release"
User:debian...@lists.debian.org
Usertags: edos-uninstallable
gsequence build-depends on fftw3-dev, this is a virtual package that was
Source: libreflectasm-java
Version: 1.11.9+dfsg-2
Severity: serious
Tags: bookworm, sid
Justification: rc policy - "Packages must be buildable within the same release"
User:debian...@lists.debian.org
Usertags: edos-uninstallable
libreflectasm-java build-depends on libasm-java-doc which is longer
Source: docopt
Version: 0.6.2-4
Severity: serious
Tags: bookworm, sid
Justification: rc policy - "Packages must be buildable within the same release"
User:debian...@lists.debian.org
Usertags: edos-uninstallable
docopt build-depends on dh-sequence-python2, this is a virtual package that was
Source: byte-buddy
Version: 1.8.2-2
Severity: serious
Tags: bookworm, sid
Justification: rc policy - "Packages must be buildable within the same release"
User:debian...@lists.debian.org
Usertags: edos-uninstallable
byte-buddy build-depends on libasm-java-doc which is longer built by the asm
Source: tiledb-py
Version: 0.18.2-1
Severity: serious
Justification: rc policy - "Packages must be buildable within the same release"
x-debbugs-cc: e...@debian.org
User: debian...@lists.debian.org
Usertags: edos-uninstallable
tiledb-py build-depends on libtiledb-doc, which is no longer built by
Source: mir
Version: 1.8.2+dfsg-3
Severity: serious
Tags: ftbfs
mir FTBFS on all architectures with symbols files issues
(there was previously a bug report for hppa, but since it now fails on release
architectures I feel a seperate bug report is deserved).
On 30/11/2022 07:29, Andreas Tille wrote:
3. Declare your package unsupported on 32-bit architectures and file a
removal bug with the ftpmasters.
For what architecture should we file a removal bug?
armel armhf i386 mipsel s390x
(390x is not 32-bit but is also affected, I missed that when
Package: ntcard
Version: 1.2.2+dfsg-4
Severity: serious
ntcard build-depends on libnthash-dev which is no longer available on
32-bit architectures.
There are in general 3 potential soloutions for this (in roughly
descending order of preference)
1. Fix your build-dependencies so they are
Package: pplacer
version: 1.1~alpha19-6
Severity: serious
Justification: rc policy: "packages must be buildable within the same
release"
pplacer build-depends on libmcl-ocaml-dev which is no longer built by the
mcl source package. It is still present in unstable as a cruft package, but
is
1001_serial_test.patch to bump serial_test dev-dependency to 0.9
+and update build-depedencies accordingly.
+
+ -- Peter Michael Green Thu, 17 Nov 2022 20:57:47 +
+
precious (0.3.0-1) unstable; urgency=medium
[ upstream ]
diff -Nru precious-0.3.0/debian/control precious-0.3.0/debian/control
Package: rust-test-case
Version: 2.2.2-2
Severity: serious
rust-test-case depends on librust-once-cell-1.14+default-dev but Debian
now has version 1.16.
Generally, in line with semver, you shouldn't be depending on specific minor
versions once a crate is at version 1.0 or higher.
Package: rust-cargo-outdated
Version: 0.10.2-3
Severity: serious
Rust-cargo-outdated depends on version 0.57 of rust-cargo, debian has 0.62.
There is a new upstream version, but it still only depends on version 0.60
of the cargo crate.
I tried patching the new upstream version to use version
Control: tag -1 pending
Hello,
Bug #1024173 in python-cfg-diag 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:
y
next day - it includes a bumped dependency on python-cfg-diag >= 0.4 in
both debian/control and debian/tests/control. I just realized that maybe
I should have given a hint about that breakage in the python-cfg-diag
package itself; would it be a good idea to upload a new Debian revision
with
On 11/11/2022 16:02, Jonas Smedegaard wrote:
My work on other packages (rust-test-case) recently revealed that my
approach to embedding crates is broken, so I will do some more poking to
get it to not only succeed building on its own but also builds as
dependency of other Rust crates.
Note
Cargo.toml was at 0.3 while the Debian
+ Dependency and the cast dependency in the plot subcrate were at 0.2.
+ * Fix clean target.
+
+ -- Peter Michael Green Thu, 10 Nov 2022 20:23:39 +
+
rust-criterion (0.3.6-1) unstable; urgency=medium
[ upstream ]
diff -Nru rust-criterion-0.3.6/debian
Dear Helmut,
On 04.11.22 10:36, Helmut Grohne wrote:
Would someone handle dnstwist, which is the only remaining dependency?
I opened a corresponding upstream request:
https://github.com/elceef/dnstwist/issues/170
Peter
On 31/10/2022 16:17, Jonas Smedegaard wrote:
Quoting Peter Green (2022-10-31 03:39:28)
src:rust-rustls: fails to migrate to testing for too long: blocked by build
dependency
Specifically rust-async-std has taken some time to package, because of the
large number
of dependencies. There has
src:rust-rustls: fails to migrate to testing for too long: blocked by build
dependency
Specifically rust-async-std has taken some time to package, because of the
large number
of dependencies. There has been effort on this front both by the rust team and
by Jonas
who currently packages rust
Package: rust-coreutils
Version: 0.0.15-1
Severity: serious
cargo build --features "arch base32 base64 basename basenc cat chcon
chgrp chmod chown chroot cksum comm cp csplit cut date dd df dir
dircolors dirname du echo env expand expr factor false fmt fold groups
hashsum head hostid
Package: rust-async-std
Version: 1.12.0-5
Severity: serious
The autopkgtest for rust-async-std is failing and preventing it's migration to
testing.
error[E0425]: cannot find function `block_on` in module `task`
--> src/io/read/take.rs:231:15
|
231 | task::block_on(async move {
... and of course I managed to make a typo.
It should be Kernel: 5.10.0-19-amd64 x86_64 as in the original report.
Apologies for the noise.
Peter
Van: Debian Bug Tracking System
Verzonden: donderdag 20 oktober 2022 14:12
Aan: Kroon P C, Peter
Onderwerp
]
speed: 1367 MHz
min/max: 1400/2700 MHz
Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Renoir
driver: amdgpu
v: kernel
Display server: X.org 1.20.11
loaded: amdgpu,ati
unloaded: fbdev,modesetting,vesa
Happy to help, let me know if I can provide more details.
Peter
posting to -quiet as I already sent pretty much the same mail to two other
rust-team bugs.
It appears that rust-deflate was uploaded a bit prematurely, it depends on a new
version of rust-gzip--header which can't be packaged with the cargo/debcargo
currently in Debian.
Hi.
It appears that rust-deflate was uploaded a bit prematurely, it depends on a new
version of rust-gzip--header which can't be packaged with the cargo/debcargo
currently in Debian.
Once cargo/debcargo are updated we can move on to updating/fixing the image
stack.
To clarify the situation for people stumbling across this bug.
The issue in cereal was fixed, however slic3r-prusa still FTBFS because of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021566
Package: php-xmlrpc
Version: 3:1.0.0~rc3-2.1
Severity: serious
Trying to install php-xmlrpc results in.
The following packages have unmet dependencies:
php-common : Breaks: php-xmlrpc (< 3:1.0.0~rc3-4~)
Package: racon
Version: 1.5.0-2
Severity: serious
racon build-depends on libthread-pool-dev which is no longer available on 32-bit
architectures, this means that the package can no longer be built on those
architectures but the binaries are still in testing/unstable.
In general there are three
Package: rust-zoxide
Version: 0.4.3-4
Severity: serious
The rust-zoxide package depends on version 0.2 of the float-ord
crate, but testing/unstable now has version 0.3
Unfortunately when I try to prepare an update with debcargo I get.
REALVER=0.4.3 SOURCEONLY=1 DEBFULLNAME="Peter Michael
https://ci.debian.net/data/autopkgtest/testing/s390x/r/rust-object/26973632/log.gz
test round_trip::elf::symtab_shndx ... FAILED
I noticed this and filed a bug upstream soon after the package was uploaded.
https://github.com/gimli-rs/object/issues/456
And a fix appeared fairly shortly.
ors.
https://mentors.debian.net/package/mp3guessenc/
Cheers,
Peter
Package: rust-smol
Version: 1.2.5-2
Severity: serious
rust-smol build-depends on librust-nix-0.24+default-dev but the nix
crate in debian testing/unstable is now at 0.25
There is a new upstream version of petgraph that uses the new version of
fixedbitset, I suspect the most sensible way to fix this bug is
uploading it and it has been prepared in debcargo-conf (initially
byBlair Noctis with some further tweaking by myself)
However before I upload it, I wanted
Package: rust-ahash
Version: 0.7.6-4
Severity: serious
The autopkgtest of rust-ahash is failing
https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-ahash/25673987/log.gz
Testing aeshash/u8
thread 'main' panicked at 'aes must be enabled', tests/bench.rs:20:5
stack backtrace:
0:
On Tue, Aug 30, 2022 at 02:42:04PM +0300, Martin-Éric Racine wrote:
> Greetings,
>
> On Fri, Aug 19, 2022 at 3:15 PM Peter Zijlstra wrote:
> >
> > On Fri, Aug 19, 2022 at 01:38:27PM +0200, Ben Hutchings wrote:
> >
> > > So that puts the whole __FILL
Package: rust-pleaser
Version: 0.5.1-4
Severity: serious
rust-pleaser fails to build with the new version of rust-nix.
error[E0061]: this function takes 0 arguments but 1 argument was supplied
--> src/lib.rs:416:19
|
416 | ro.hostname = gethostname( buf)
|
I have written a merge request [1] to fix FTBFS on all platforms. Tested on my
dev machine on amd64 and riscv64. If more helps are needed, please let me know.
Thanks for the patch,
Was this patch just a result of general QA activity or is there some
program you are trying to package?
We can
On Fri, Aug 19, 2022 at 01:38:27PM +0200, Ben Hutchings wrote:
> So that puts the whole __FILL_RETURN_BUFFER inside an alternative, and
> we can't have nested alternatives. That's unfortunate.
Well, both alternatives end with the LFENCE instruction, so I could pull
it out and do two consequtive
On Fri, Aug 19, 2022 at 10:47:21AM +0200, Peter Zijlstra wrote:
> On Fri, Aug 19, 2022 at 02:33:08AM +0200, Ben Hutchings wrote:
> > From: Ben Hutchings
> >
> > The mitigation for PBRSB includes adding LFENCE instructions to the
> > RSB filling sequence. However,
On Fri, Aug 19, 2022 at 02:33:08AM +0200, Ben Hutchings wrote:
> From: Ben Hutchings
>
> The mitigation for PBRSB includes adding LFENCE instructions to the
> RSB filling sequence. However, RSB filling is done on some older CPUs
> that don't support the LFENCE instruction.
>
Wait; what? There
load.
+ * Add patch for rust-uuid 1.x and update dependencies accordingly
+ * Fix clean target.
+
+ -- Peter Micheal Green Sun, 14 Aug 2022 23:04:02 +
+
mdevctl (1.2.0-1) unstable; urgency=medium
[ Athos Ribeiro ]
diff -Nru mdevctl-1.2.0/debian/control mdevctl-1.2.0/debian/control
---
Package: hedgewars
Version: 1.0.0-16
Severity: serious
Hedgewars failed to build on all architectures when binnmu'd (note: the binnmu
sat
in BD-Uninstallable for a long time due to issues with haskell packages).
[ 41%] Linking Pascal executable ../bin/hwengine
cd
which in turn
requires changes in sphinx-markdown-tables which in turn is a build
dependency of python-lark. More information on this issue can be found
in the following sphinx-markdown-tables issue:
https://github.com/ryanfox/sphinx-markdown-tables/issues/36
Best regards,
Peter
cular gdcm is a key package due to the fact that opencv build-depends
on it.
Description: Support ffmpeg 5.
This patch is inspired by https://gitlab.kitware.com/vtk/vtk/-/commit/34276346ac379fecbd615322f18de837bd2c9ea2
but practically rewritten due to differences between the two versions.
Aut
dependencies on gettext-sys, gettext-rs and proptest crates.
+(Closes: #1011620, #1013539)
+
+ -- Peter Michael Green Sat, 16 Jul 2022 19:13:03 +
+
newsboat (2.21-1.2) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru newsboat-2.21/debian/control newsboat-2.21/debian/control
The rust-zstd package has both a dependency and a build-dependency on
librust-zstd-safe-2.0.3+experimental-dev, which does not exist anywhere in
Debian. Presumably it would be built by a rust-zstd-safe package, but no
such package exists, including in the Debian NEW queue.
Specifically looking
Package: deepin-movie
Version: 5.7.15-3
Severity: serious
The deepin-movie-reborn source package was recently binnmu'd for the
ffmpeg transtion,
unfortunately though the resulting binary packages still depend on the
old libav* packages.
Package: rust-hdrhistogram
Version: 7.5.0-1
Severity: serious
I recently updated the hdrhistogram package and as part of that I
resolved the issues that were blocking the tests from running on as
autopkgtests.
Unfortunately when running the autopkgtests on i386 two tests failed, I
can also
On Fri, Jun 24, 2022 at 01:28:57PM +0200, Vincent Bernat wrote:
> On 6/24/22 13:05, Peter Pentchev wrote:
> > Source: xnee
> > Version: 3.19-8
> > Severity: serious
> > X-Debbugs-Cc: r...@debian.org
> >
> > Hi,
> >
> > First of all, thanks for t
anks again, and keep up the great work!
G'luck,
Peter
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.18.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=bg_BG.UTF-8
dependencies on sha2 to allow version 0.10
++ update cargo dependency on wait-timeout to allow version 0.2
++ fix debian dependency on time so it can't be satisfied by time-0.1
package.
+
+ -- Peter Michael Green Thu, 23 Jun 2022 13:14:20 +
+
elan (1.3.1-3) unstable; urgency=medium
, gettext-rs and proptest crates.
+
+ -- Peter Michael Green Thu, 23 Jun 2022 16:45:39 +
+
newsboat (2.21-1.2) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru newsboat-2.21/debian/control newsboat-2.21/debian/control
--- newsboat-2.21/debian/control2022-03-05 21:46
On 21/06/2022 14:39, Jonas Smedegaard wrote:
Quoting Peter Green (2022-06-21 15:35:59)
What is status of this bug?
Status is that h2 still needs tower-service, Fabian prepared it but noone
got around to sponsoring it. I've just updated and uploaded it. Now it
needs to get through NEW.
Thanks
Package: ntopng
Version: 5.2.1+dfsg1-1
Severity: serious
It seems that ntopng recently started failing to build, I first noticed this on
a Raspbian
autobuilder, but it's also happening on the reproducible builds test
infrastructure so it's
not a raspbian specific issue.
Package: rust-copypasta
Version: 0.7.1-2
Severity: serious
The dependencies and build-dependencies of rust-copypasta are unsatisfiable.
The first issue is that "disable-smithay-clipboard.diff" removes the
smithay-clipboard feature from the default set, but does not remove the
smithay-clipboard
Package: faiss
Version: 1.7.2-5
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
faiss build-depends on libblis3-serial which is no longer built by the blis
source package.
It is still present in unstable as a cruft package, but is completely
reopen 1012221
thanks
On 02/06/2022 13:29, Sylvestre Ledru wrote:
4. Remove the stdweb features in instant and parking-lot and allow
stdweb to be removed from testing.
I think I implemented this solution.
Thanks,
That solves the issue for instant, parking-lot and their reverse
Package: elan
Version: 1.3.1-3
Severity: serious
Tags: patch
A number of rust crates have been updated recently, as a result your
package no longer builds, I have updated the patches to relax the
dependencies and was able to succesfully build the package, I have not
tested it beyond that.
201 - 300 of 3615 matches
Mail list logo
