Package: wnpp
Severity: wishlist
Owner: plugwash <plugw...@p10link.net>
* Package name: autoforwardportergit
Version : 0.1
Upstream Author : Peter Michael Green <plugw...@debian.org>
* URL : http://github.com/plugwash/autoforwardportergit/
* License
tags 905035 +patch
thanks
After some searching around and following links from the gentoo
bugtracker I found a patch for this. I applied it to the package and was
able to get a succesful build in raspbian buster.
A debdiff can be found at
Package: wnpp
Severity: wishlist
Owner: plugwash <plugw...@p10link.net>
* Package name: python3-pgzero
Version : 1.2.post1
Upstream Author : Daniel Pope <ma...@mauveweb.co.uk>
* URL : https://bitbucket.org/lordmauve/pgzero
* License : LGPLv3
Prog
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Recently I became aware of two issues in mu-editor. A tool for beginning
python programmers.
I was informed that the "debug" button in mu-editors default python mode was
broken in the
package: caml-crush
tags: buster,sid
severity: serious
x-debbugs-cc: debian-ocaml-ma...@lists.debian.org
caml-crush build-depends on ocaml-native-compilers. In stretch this was
a real package. In buster it is a virtual package provided by ocaml-base
on most architectures, but does not seem to
tags 933348 +bullseye,sid
found 933348 1.2.0-1
thanks
This bug also affects testing.
Package: virtualenvwrapper
Severity: serious
Version: 4.3.1-2
Tags: bullseye, sid
virtualenvwapper depends on python-stevedore which is no longer built by
the stevedore source package.
severity 936229 serious
thanks
bootstrap-vz depends on the python-fysom binary package which has
already been dropped by the python-fysom source package.
Package: libparse-pidl-perl
Version: 2:4.9.5+dfsg-5+deb10u1+really0.02
X-debbugs-cc: secur...@debian.org
It seems that the recent update to samba in buster-security generated a
libparse-pidl-perl package with a lower version number than the version
already in buster. As far as I can tell this
package: ledger2beancount
version: 1.8-1
severity: serious
ledger recently migrated to python 3 (forced by boost dropping python 2
support), this has broken the ledger2beancount autopkgtest and this is
blocking ledger from migrating to testing.
autopkgtest [19:31:06]: test testsuite: - - -
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
The antimony binnmus for the python 3.9 transition failed due to bug
975109 . The maintainer made an upload fixing the bug but unfortunately it was
not source-only and the included amd64
Package: xfce4-indicator-plugin
Version: 2.3.4-2
Severity: serious
Tags: bullseye, sid
xfce4-indictor-plugin build-depends on libexo-1-dev which is no longer
built by the exo source package,
it is still present in unstable as a cruft package, but is completely
gone from testing.
Package: xfce4-mpc-plugin
Version: 0.5.2-1
Severity: serious
Tags: bullseye, sid
xfce4-mpc-plugin build-depends on libexo-1-dev which is no longer built
by the exo source package,
it is still present in unstable as a cruft package, but is completely
gone from testing.
Package: bedtools
Version: 2.29.2+dfsg-4
Severity: serious
The autopkgtests for bedtools are failing on all tested architectures
(though they are "not a regression" on i386 and armhf). When I look at
the amd64 failure logs, the failures all seem to be missing "../htsutil"
Testing bedtools
Package: xfce4-verve-plugin
Version: 2.0.0-1
Severity: serious
Tags: bullseye, sid
xfce4-verve-plugin build-depends on libexo-1-dev which is no longer
built by the exo source package,
it is still present in unstable as a cruft package, but is completely
gone from testing.
Package: rust-lazycell
Version: 1.3.0-1
Severity: serious
The upload of rust-lazycell 1.3.0-1 introduced three new binary
packages, two of which are currently
uninstallable. This is preventing the package from migrating to testing
which is annoying the release
team (see:
://github.com/plugwash/libm
<https://github.com/plugwash/libm> and also posted about them upstream
at https://github.com/rust-lang/libm/issues/243
I may or may not add these changes to the Debian package later.
tags 978219 +fixed-upstream
thanks
The immediate cause of this bug, is the addition of
-DQT_NO_CAST_FROM_ASCII to the compiler flags.
Doing some grepping, this appears like it was caused by the update of
lxqt-buildtools, and appears
to be intentional rather than a leak.
Doing some digging in
tags 971018 +patch
thanks
I did some testing on the porterbox, which showed optimizing for size is
enough to make things build on mipsel.
Debdiff attached, no intent to NMU.
diff -Nru libgnatcoll-db-21.0.0/debian/changelog
libgnatcoll-db-21.0.0/debian/changelog
---
Package: wnpp
Severity: wishlist
Owner: plugwash
* Package name: ghextris
Version : 0.9.0
Upstream Author : Mikko Rauhala
* URL : http://mjr.iki.fi/software/ghextris
* License : GPLv2+
Programming Lang: Python
Description : A Tetris-like game
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
rust-rustyline fails to build in buster due to a change of behaviour in rustc,
this has been fixed in bullseye/sid for some time and I was able to locate
the upstream commit that
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package jumpnbump
jumpnbump 1.61-3 and below crash when the player jumps and sound is enabled
(the default) on systems where type char is unsigned (e.g. arm* powerpc*).
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package rust-compiler-builtins
rust-compiler-builtins 0.1.26-2 FTBFS on armhf (and presumablly also armel
but I did not test that).
Rust upstream have renamed the old
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package rust-smallvec
The insert_many function in rust-smallvec 1.6.0 and earlier suffers from a
buffer overflow if the number of items returned by the iterator is greater
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package cross-toolchain-base
cross-toolchain-base 52 has overzelous conflicts between multilib
libc packages which make the build-dependencies of gcc-10-cross and
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
rust-stackvector recently had a memory safety bug that was reported by the
rustsec team as a security issue and the Debian security team as a rc bug.
I fixed this in rust-stackvector
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: britney
Rust packaging makes heavy use of versioned virtual packages to allow
multiple versions of a crate to coexist if needed (though this functionality
is only occasionally actually used).
package: dh-cargo
Recently a substantial number of upstream cargo packages started using
timestamps the ftpmasters
consider reject-worthy, I believe this was done in the name of
reproducibility.
After it became clear that this was a larger-scale issue and we got sick
of working around this
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
libfilezilla needs to be rebuilt on the buildds so it can migrate to testing
and restore consistency of the filezilla/libfilezilla packages there.
The binary packages are multi-arch: same,
The rust gtk stack is now installable again, but it looks like qwertone
needs some work to build with
the new version of the stack.
It looks like upstream has updated the code for 0.14 but attempting to
grab the upstream commit and
apply it as a patch resulted in a bunch of hunks failling, so
Package: ftp.debian.org
Severity: normal
rust-tokio-process depends on an old version of rust-futures and as-such
it's dependencies and build-dependencies are unsatisfiable.
Upstream the features of the tokio-process crate have been integrated into
the tokio crate and here are no reverse
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
When downloading a file greater than 2GB on a 32-bit system wget on bullseye
will truncate it to 2GB. No error is reported, the length of the file is simply
reported as less than
This appears to be fixed by version 1.6.1-1 in experimental? is there
any blocker for uploading it to unstable?
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm
James McCoy and I have been working on updating the rust-nom package from
version 5 to version 7, this is needed to enable ICMP support in sniffglue and
I belive it is also needed to facilitate
Package: ftp.debian.org
Severity: normal
Upstream incorportated functionality in the rand_os crate into the
rand_core crate and deprecated the rand_os crate over two years ago.
There have been no further releases since the release announcing the
deprecation and the crate no longer appears in the
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package rust-rustls-webpki
The package is blocked by autopkgtest failures on ppc64el and s390x. The reason
for these failures is that the package (which is arch all) is not
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package rust-ahash-0.7
Testing migration of rust-ahash-0.7 is currently blocked by a ppc64el
autopkgtest of rust-cursive. This has been in-progress for 4+ days now,
I've
reassign 1010322 ftp.debian.org
retitle 1010322 RM: rust-core-arch ROM abandoned upstream, FTBFS for
over a year, superseeded by functionality in standard library.
thanks
If noone objects I will turn this bug into a removal request in a week
or two.
There were no responses, so reassigning to
reassign 1010731 ftp.debian.org
retitle 1010731 RM: rust-semver-parser-0.9 ROM old version no longer in use.
thanks
If noone objects I will turn this bug into a removal request in a week
or two.
There were no responses, so reassigning to ftp.debian.org for removal.
On 27/06/2022 01:15, Jonas Smedegaard wrote:
Thanks for clarifying.
I consider it a *horrific* bug that an interface is explicitly
advertised as available, linking against it succeeds, yet it is
non-functional.
In my opinion this renders the whole package unsuitable for release, and
I hereby
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
It appears a liblxqt transition has started, possiblly inadvertantly.
Back in June, Simon Quigley prepared an update of the lxqt stack. He announced
that he intended to update the stack
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package rust-h2
The new version fixes CVE-2023-26964/RUSTSEC-2023-0034 it consists of two
commits backported from upstream, one for the CVE fix itself and one to fix
a
Hell All, I have just made singular independent from brial
Thanks for dealing with that part of the issue.
Otherwise it must be keep in mind that Sage is mostly umbrella software.
That means that the dependency of brian on sage material is odd.
odd as it may be, it seems the dependency of
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
It was discovered about a month ago by Bastian Germann that python3-brial needs
python3-sage, and he added a dependency.
Unfortunately this left the package uninstallable on about half of
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package rust-env-logger-0.7
A bug was raised regarding missing breaks/replaces in rust-env-logger-0.7,
analysis revealed that debcargo was setting breaks+replaces against a
Package: ftp.debian.org
Severity: normal
Please remove rust-lock-api-0.1, rust-parking-lot-0.7 and
rust-parking-lot-core-0.4
All are older versions, that are no longer in use after tokio was updated to
1.x. rust-lock-api-0.1 is also affected by RUSTSEC-2020-0070
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package rust-spin
RUSTSEC-2023-0031 was filed aginst the rust-spin package. While I do not believe
any applications in Debian are affected by this issue I would still rather
Package: 389-ds-base
Version: 2.3.1+dfsg1-1
Tags: trixie, sid, ftbfs
389-ds-base FTBFS with the new version of rust-base64.
I attach a patch which makes the package build, and also fixes some
packaging annoyances. I have not tested it beyond that. I may or may not
NMU this later.
diff -Nru
tags 1064612 +patch
thanks
rust-ahash is unable to migrate to Testing because its autopkgtests are failing:
A debdiff fixing this issue is attatched.
diff -Nru rust-ahash-0.8.9/debian/changelog rust-ahash-0.8.9/debian/changelog
--- rust-ahash-0.8.9/debian/changelog 2024-02-23
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
pypy3 needs rebuilding for the time64 transition (it currently depends on
libssl3).
nmu pypy3_7.3.15+dfsg-1 . ANY . unstable . -m "rebuild for time64"
-- System Information:
Debian
Package: swi-prolog
Version: 9.0.4+dfsg-3.1
Severity: grave
Tags: trixie, sid
User: debian-...@lists.debian.org
Usertag: time-t
It looks like the adjustments for the time64 transition in the
9.0.4+dfsg-3.1
NMU were incomplete. Resulting in unsatisfiable dependencies on armel
and armhf at least
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
The virtual package libphonenumber8-protobuf32 was renamed to
libphonenumber8t64-protobuf32 as part of the time_t transition.
Most reverse depedencies seem to have already been rebuilt, but
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
libsoup2.4.1 was renamed to libsoup-2.4.1 for the time64 transition.
It seems that the new version of libgrss was built a bit too early and, on most
architectures, picked up a dependency on
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
It seems that the new version of gyoto was built a bit too early and, on most
architectures, picked up a dependency on libcfitsio10 rather than
libcfitsio10t64.
nmu gyoto_2.0.2-1.1 . ANY .
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
As discussed in bug 1070706 gtk4 was built against a version of libpng1.6
suffering from bug 1066069, which resulted in libgtk-4-1-udeb depending on
libpng16-16t64-udeb which does not exist.
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
rust-chrono's testing excuses say (and have listed for at least a day or so)
autopkgtest for rust-trash/3.3.1-1: amd64: Test in progress, arm64: Pass, i386:
Pass, ppc64el: Pass, s390x:
I started looking into this bug and trying to gauge it's impact.
In particular what if-any applications in Debian actually use the broken
code.
First I tried to use codesearch to search for insert_many but I got way
too many
false-positives. So I tried a different approach. I did however
57 matches
Mail list logo
