l; urgency=medium
* New upstream release
- Rebase patches as needed
-- Mathias Gibbens Sat, 07 Jun 2025 14:57:57 +
openrct2 (0.4.22+ds-1~exp1) experimental; urgency=medium
* New upstream release
- Drop patch to disable version check and rely on new cmake flag
- Rebase patches as nee
I think I have occasionally been encountering this (or a very
similar) issue. Like Abdurahman, I'm running trixie with KDE Plasma and
three times now in the past month the GPU has totally locked up. Two of
those times I had music playing in the background, and it continued
playing even after the
Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
* Package name: golang-github-hugelgupf-socketpair
Version : 0.0~git20240723.9246f21-1
Upstream Author : Chris K
* URL : https://github.com
control: tags -1 - moreinfo
On Thu, 2025-05-22 at 19:17 +, Helge Kreutzmann wrote:
> Am Wed, May 21, 2025 at 05:48:43PM +0100 schrieb Richard Lewis:
> > cant hurt - you can also do this locally:
> >
> > systemctl edit logcheck
> > # in the editor add:
> > [Service]
> > ExecStart=sleep 180
> >
control: tags -1 + pending
Added a NEWS entry and updated README.Debian.
Mathias
signature.asc
Description: This is a digitally signed message part
control: retitle -1 nlohmann-json3 3.12.0-1 causing FTBFS in openrct2
control: reassign -1 nlohmann-json3 3.12.0-1
control: affects -1 src:openrct2
Version 3.12.0-1 of nlohmann-json3 was recently uploaded to unstable,
which is now causing openrct2 to fail to build.
Looking at the changelog fo
control: reassign -1 lxc 1:6.0.4-2
control: tags -1 - moreinfo + confirmed pending upstream
control: forwarded -1 https://github.com/lxc/lxc/pull/4555
I've been able to reproduce this in a local VM, and verified that
indeed the fix is quite easy. :) Once merged upstream I'll cherry-pick
it back
control: tags -1 + moreinfo unreproducible
Having reviewed the messages so far in this bug report, it's clear
that something different is happening when logcheck runs under the
systemd timer/service, but not cron. However, we don't have a
reproducer yet.
Since this weekend I've now got four s
control: tags -1 + confirmed pending
That is interesting, and I see the same thing when I inspect some of
the logcheck emails sent via exim. On my server running postfix I don't
see this behavior.
Adding a post-run sleep seems a bit hacky, but it won't negatively
impact anything either and wi
Indeed, that looks unusual. I did find one old report on the debian-
user list that's similar, but was ultimately unsolved[0].
If you're getting two duplicate emails, that indicates logcheck is
running from both the crontab and new systemd timer. In that case, can
you share the contents of /et
Looks like the fix was included in the 6.15-rc6 kernel:
https://lkml.org/lkml/2025/5/11/398. So just need to wait for the 6.15
stable release and then inclusion into 6.12.y.
Mathias
signature.asc
Description: This is a digitally signed message part
Uploaded, thanks!
Mathias
signature.asc
Description: This is a digitally signed message part
One minor regression involving NVME hotplugging has been identified;
I've just opened bug #1104889 about this. While not a show-stopper, it
does make the use of NVME virtual devices impossible in Incus.
Mathias
signature.asc
Description: This is a digitally signed message part
Package: src:qemu
Version: 1:10.0.0+ds-1
Severity: important
Tags: fixed-upstream
A regression in QEMU 10's handling of NVME hotplugging has been
identified[0], with a proposed fixed already submitted[1]. I've
verified that the patch fixes the issue in my test environment.
I'm not sure what t
g logcheck-1.4.2+deb12u1/debian/changelog
--- logcheck-1.4.2/debian/changelog 2023-03-01 22:49:39.0 +
+++ logcheck-1.4.2+deb12u1/debian/changelog 2025-05-04 16:43:20.0 +
@@ -1,3 +1,16 @@
+logcheck (1.4.2+deb12u1) bookworm; urgency=medium
+
+ [ Mathias Gibbens ]
+ * Upda
control: tags -1 - moreinfo
I have verified that the patch "0004-drm-amdgpu-hdp6-use-memcfg-
register-to-post-the-writ.patch" posted at
https://gitlab.freedesktop.org/drm/amd/-/issues/4119 fixes the issue
for me with the 6.12.25 kernel.
Mathias
signature.asc
Description: This is a digitally s
control: tags -1 + confirmed upstream
Hi Martin,
This is caused by an apparmor bug in the 6.1 kernel series. The main
Debian bug is #1050256.
Mathias
signature.asc
Description: This is a digitally signed message part
control: tags -1 + moreinfo
Hi Paul,
I think this might be a simple fix where lxc just needs to recognize
loong64 as another "known" personality. I can't test this on the
porterbox, but I've attached the single line patch for lxc that I think
would fix the issue. If you can share access with a
Updated with a few more ignore rules.
Mathias
diff --git a/debian/logcheck/postfix-policyd-spf-python b/debian/logcheck/postfix-policyd-spf-python
index 07a87b1..8524af6 100644
--- a/debian/logcheck/postfix-policyd-spf-python
+++ b/debian/logcheck/postfix-policyd-spf-python
@@ -1 +1,4 @@
+^(\w{3
On Thu, 2025-05-01 at 13:15 +0200, Salvatore Bonaccorso wrote:
> There is some progress in the upstream issues,
> https://gitlab.freedesktop.org/drm/amd/-/issues/3908 and saying we
> should look at the commits for
> https://gitlab.freedesktop.org/drm/amd/-/issues/4119 . Do you have
> resources to t
control: tags -1 + pending
signature.asc
Description: This is a digitally signed message part
control: tags -1 + pending
signature.asc
Description: This is a digitally signed message part
control: tags -1 + pending
signature.asc
Description: This is a digitally signed message part
control: tags -1 + pending
signature.asc
Description: This is a digitally signed message part
control: tags -1 + pending
signature.asc
Description: This is a digitally signed message part
control: tags -1 + pending
signature.asc
Description: This is a digitally signed message part
control: tags -1 + pending
signature.asc
Description: This is a digitally signed message part
control: tags -1 + pending
signature.asc
Description: This is a digitally signed message part
control: tags -1 + pending
signature.asc
Description: This is a digitally signed message part
control: tags -1 + pending
signature.asc
Description: This is a digitally signed message part
control: tags -1 + pending
signature.asc
Description: This is a digitally signed message part
as
On Fri, 2024-12-20 at 03:18 +0000, Mathias Gibbens wrote:
> Hi Security Team,
>
> I've just uploaded incus 6.0.3-1 that contains a fix for CVE-2024-
> 6156, which I mentioned in its changelog.
>
> For LXD, I'm pretty sure the fix is commit fb0525e[1], but cleanly
On Wed, 2025-04-23 at 22:01 -0600, dann frazier wrote:
> > Please see NEWS.Debian:
> https://salsa.debian.org/qemu-team/edk2/-/blob/08d4411d458eefc4df5d48acce4f995d4ae6087d/debian/qemu-efi-aarch64.NEWS
Thanks for pointing that out; since the NEWS entry is specific to
arm64 it hadn't popped up as
I've added a very simple timer and service definition for
logcheck[0], which should make it into the trixie release.
I'm hesitant to go too crazy adding systemd hardening options to the
service, although I'd be open to ones that don't require specific
changes to support a given MTA, such as so
Package: src:spf-engine
Version: 3.1.0-2
Severity: wishlist
Tags: patch
Please find attached a patch to update the logcheck rules for this
package.
Thanks,
Mathias
diff --git a/debian/logcheck/postfix-policyd-spf-python b/debian/logcheck/postfix-policyd-spf-python
index 07a87b1..6d3ff00 100644
control: retitle -1 qemu-efi-aarch64: Secure Boot regression for some arm64 VMs
control: reassign -1 qemu-efi-aarch64 2025.02-7
control: severity -1 serious
control: affects -1 incus
Release 2025.02-5 of src:edk2 dropped the patch Revert-ArmVirtPkg-
make-EFI_LOADER_DATA-non-executabl.patch. This
Source: logcheck
Version: 1.4.3
Severity: serious
On a fresh minimal trixie install, logcheck fails to read the systemd
journal and exits with the following error:
> Logcheck failed: Your log entries may not have been checked.
>
> Details:
> Could not run journalctl or save output
Adding th
control: tags -1 + confirmed
Hi Antonio,
I have successfully reproduced the issue on a RaspberryPi 5 with its
apt sources set to trixie. While not a pure Debian environment, it's
the only arm64 system I have full access to. :)
TL;DR: As a workaround, try disabling secure boot:
$ incus cr
Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
* Package name: golang-github-adhocore-gronx
Version : 1.19.5-1
Upstream Author : Jitendra Adhikari
* URL : https://github.com/adhocore
Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
* Package name: golang-github-linbit-golinstor
Version : 0.55.0-1
Upstream Author : LINBIT
* URL : https://github.com/LINBIT/golinstor
Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
* Package name: golang-github-flosch-pongo2.v6
Version : 6.0.0-1
Upstream Author : Florian Schlachter
* URL : https://github.com/flosch
Interesting; I haven't seen the build fail in this way before, and as
Jeremy pointed out Incus builds properly in other places on official
infrastructure.
For background on this particular part of the build, when I was
working on LXD packaging the TZ and HOME environment variables were set
to
This isn't an i386-specific issue, but rather a flaky test (or maybe
more than one) that do some sort of time sampling. I've previously
filed #1102485 about this showing up as flaky autopkgtests which pass
when re-run.
I'd strongly prefer the tests actually be fixed than just skipped,
but I ha
Source: golang-gopkg-yaml.v3
Version: 3.0.1-3
Severity: important
Affects: golang-yaml.v2
As of April 1, 2025, the upstream project is unmaintained and
archived on github. An alternative may be golang-github-goccy-go-yaml.
signature.asc
Description: This is a digitally signed message part
Source: golang-github-go-kit-kit
Version: 0.13.0-5
Severity: important
golang-github-go-kit-kit has autopkgtests that are flaky, and often
fail when migration tests are run for other packages[0]. Rather than
marking these tests as flaky, we should properly fix them so they
become reliable.
[0]
It is claimed that this was fixed in the 3.20.0 release[0,1,2] (or
maybe 3.21.0[3]), which would have been fixed in Debian with the
3.21.0-1 upload.
However, the upstream bug report[4] is still open, and I don't see
anything in the commit or release notes indicating a fix for this
issue. Since
On Thu, 2025-03-27 at 09:33 +0300, Michael Tokarev wrote:
> I uploaded qemu 10.0.0-rc1 to unstable yesterday, now it is already built
> and installed on all architectures, ready for testing.
So far just one minor issue has been found, and is already fixed
upstream[1]. I'll be updating the Incus
Any progress investigating this? Otherwise I fear keepassxc will fall
out of testing before the trixie release.
Mathias
signature.asc
Description: This is a digitally signed message part
On Tue, 2025-03-25 at 12:14 +0300, Michael Tokarev wrote:
> 21.03.2025 18:34, Mathias Gibbens wrote:
> > Just a heads up that this might impact Incus/LXD. The release of qemu
> > 9.2 required several updates due to API changes; I haven't looked at
> > qemu 10 at all,
Just a heads up that this might impact Incus/LXD. The release of qemu
9.2 required several updates due to API changes; I haven't looked at
qemu 10 at all, so I don't know what sort of changes were made in the
upcoming release.
I don't think this should block the upload of qemu to unstable, jus
On Wed, 2025-03-12 at 18:09 +, Martin Dosch wrote:
> Dear all,
>
> I'd like to see crowdsec in trixie, as I am using it myself.
> Is there any chance to get [1081196] fixed by delivering upstreams
> sshd-logs.yaml? This file is not in the repo and I failed to figure out
> how it is created.
Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
* Package name: golang-github-minio-crc64nvme
Version : 1.0.1-1
Upstream Author : MinIO
* URL : https://github.com/minio/crc64nvme
* License
In my testing I needed to make one additional change to the base lxc
apparmor profile, and I've replied to the upstream bug report asking
for feedback, since I'm not an apparmor expert. Once I get an ACK on
that I'll update the lxc package for Debian.
Mathias
signature.asc
Description: This is
Control: tags -1 + pending
The runit scripts have been merged, and will be included in the next
upload of incus.
Mathias
signature.asc
Description: This is a digitally signed message part
Control: tags -1 + pending
The runit scripts have been merged, and will be included in the next
upload of lxcfs.
Mathias
signature.asc
Description: This is a digitally signed message part
[ While your message is dated earlier, looking at email headers it
wasn't actually sent until 20:41 UTC, and I'm only seeing it now after
being away from my computer most of the day. Apologies if it seemed
like I was blindly ignoring your response when I modified the bug's
severity at 15:22 UTC. ]
On Mon, 3 Mar 2025 14:43:30 +0100 Helmut Grohne wrote:
> [Y]ou moved the systemd units formerly present in incus to the incus-base
> package. The way this is done is normally correct and works for trixie
> -> sid upgrades. Unfortunately, the earlier version has also been
> backported to bookworm-b
On Tue, 13 Aug 2024 20:06:11 +0200 Santiago Vila
wrote:
> During a rebuild of all packages in unstable in the year 2028, your
package failed to build:
[snip]
Any progress looking into this? Currently dput-ng is ~9 days from
autorm, although this email should reset the countdown. Still, we're
Control: tags -1 + confirmed pending
Yes, cgroupfs-mount was only useful on SysV init systems, and only
supported cgroups v1. The next upload of src:lxc will remove it from
the list of suggested packages for liblxc1t64.
Mathias
On Thu, 2025-02-27 at 16:19 +0100, Andreas Tille wrote:
> Package:
On Mon, 2025-01-20 at 21:00 +0100, Simon Josefsson wrote:
> Although shouldn't the FTBFS bug really on 'sigstore-go' rather than
> 'golang-github-google-certificate-transparency'? The former is what is
> failing to build, not the latter. It would have been nice if the
> g-g-g-c-t test suite trigg
Any thoughts on this? I'm leaning towards disabling the dqlite tests;
I don't know if we want to consider doing that for this package as
well.
Mathias
signature.asc
Description: This is a digitally signed message part
I'm seriously considering just disabling the tests for this package.
I can't reproduce the most recently reported failure on any of my
machines, although I don't doubt that it is reproducible for Lucas.
Upstream knows about the tests being flaky, and there's a similar bug
against the package i
Source: yubikey-manager
Version: 5.5.1-1
Severity: serious
Justification: Renders yubioath-desktop unusable
python3-ykman 5.5.1-1 recently migrated to testing, and it appears to
be incompatible with yubioath-desktop 5.1.0-3, rendering it totally
unusable as it no longer recognizes my yubikeys. M
Control: retitle -1 ITA: golang-github-gosexy-gettext -- Gettext support for
the Go language
Control: owner -1 !
I'll adopt this package and move it to team-maintenance within the Go
Packaging Team.
Mathias
signature.asc
Description: This is a digitally signed message part
Source: oci-seccomp-bpf-hook
Version: 1.2.10+ds-1
Severity: serious
Justification: FTBFS
Tags: sid ftbfs
> dh binary --builddirectory=_build --buildsystem=golang --with=golang
>dh_update_autotools_config -O--builddirectory=_build -O--buildsystem=golang
>dh_autoreconf -O--builddirectory=_bu
Source: golang-github-google-certificate-transparency
Version: 1.3.1-1
Severity: serious
Justification: FTBFS
Tags: sid ftbfs
Affects: sigstore-go
X-Debbugs-CC: si...@josefsson.org
The recent update of golang-github-google-certificate-transparency is
missing (at least) golang-github-jackc-pgerrc
Package: ftp.debian.org
Severity: normal
Please remove golang-github-grafana-gomemcache. It is a dependency
for golang-github-grafana-dskit (RFP#1001989), but there's been no
activity on that bug in over a year[1]. Since golang-github-grafana-
gomemcache has never been part of a Debian release,
Ah, also just noticed #1093217 reporting the same issue. Looks like
we've got the same motherboard but different GPUs.
(I haven't tried to merge the two bugs, but I think it would make
sense to do so.)
Mathias
signature.asc
Description: This is a digitally signed message part
Control: found -1 linux/6.12.10-1
signature.asc
Description: This is a digitally signed message part
Control: found -1 src:linux/6.12.10-1
Control: forwarded -1 https://gitlab.freedesktop.org/drm/amd/-/issues/3908
Confirmed that the issue is still present with the 6.12.10 kernel,
and created a report in the upstream gitlab instance.
Mathias
signature.asc
Description: This is a digitally sign
Package: src:linux
Version: 6.12.8-1
Severity: normal
X-Debbugs-Cc: gib...@debian.org
I have been running testing on this machine for the past four months,
and the AMD GPU has worked just fine with the 6.10 and 6.11 series
kernels. However, a couple of weeks ago when 6.12.5 migrated to
testing,
Control: found -1 lxc/1:5.0.2-1
Control: fixed -1 1:5.0.2-1+deb12u3
signature.asc
Description: This is a digitally signed message part
On Thu, 2025-01-02 at 20:39 +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
>
> On Sun, 2024-12-22 at 18:59 +, Mathias Gibbens wrote:
> > The version of lxc in bookworm segfaults when attempting to use a
> > shared host rootfs. Originally reported agai
Package: release-notes
Severity: normal
X-Debbugs-CC: debian-de...@lists.debian.org, gib...@debian.org
TL;DR -- It is expected that trixie will be the last release of
Debian to include LXD, and users are encouraged to migrate to Incus
after upgrading.
(CC'ing debian-devel for broader awarenes
Control: tags -1 + confirmed pending
I've cherry-picked an updated test certificate generated by upstream
that's valid through 2033-10-23. Later today I'll also spin up a VM
configured with a future date to verify there aren't any other time-
related build failures.
Mathias
signature.asc
Desc
Control: tags -1 + pending
Added a patch to skip the two flaky tests.
Mathias
signature.asc
Description: This is a digitally signed message part
Control: retitle -1 dh-make-golang: FTBFS: dh_auto_test: error: cd _build && go
test -vet=off -v -p 4 github.com/Debian/dh-make-golang returned exit code 1
It looks like this FTBFS was caused by the recent update to golang-
github-charmbracelet-glamour. In an otherwise up-to-date amd64 sid
envi
+
@@ -1,3 +1,10 @@
+lxc (1:5.0.2-1+deb12u3) bookworm; urgency=medium
+
+ * Cherry-pick upstream fix for null pointer dereference when using a shared
+rootfs (See #1085241)
+
+ -- Mathias Gibbens Sun, 22 Dec 2024 18:35:15 +
+
lxc (1:5.0.2-1+deb12u2) bookworm; urgency=medium
Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
* Package name: golang-github-johanneskaufmann-dom
Version : 0.1.0-1
Upstream Author : Johannes Kaufmann
* URL : https://github.com
Source: golang-github-biogo-hts
Version: 1.4.5+dfsg1-1
Severity: serious
Justification: FTBFS
Tags: sid ftbfs
This package fails to build on 32bit architectures:
>dh_auto_test -O--buildsystem=golang
> cd obj-i686-linux-gnu && go test -vet=off -v -p 22
> github.com/biogo/hts/bam githu
Source: golang-github-biogo-hts
Version: 1.4.5+dfsg1-1
Severity: serious
Justification: FTBFS
Tags: sid ftbfs
A test is failing when this package is built. Maybe related to the
sbuild unshare backend switch?
> === RUN TestEOF
> bgzf_test.go:118: Expected error:read /tmp/TestEOF2778629558/
Control: retitle -1 incus: Incus VMs don't start on QEMU 9.2
Control: forwarded -1 https://github.com/lxc/incus/issues/1522
The next Incus LTS release should land at the end of this week. :) As
Stéphane mentioned, hopefully this will be an easy fix that won't upset
older versions of QEMU. If the
Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
* Package name: golang-github-minio-cli
Version : 1.24.2-1
Upstream Author : MinIO
* URL : https://github.com/minio/cli
* License
Control: retitle -1 RM: golang-github-eapache-go-resiliency -- ROM; accidental
duplicate
Control: reassign -1 ftp.debian.org
Control: severity -1 normal
Please remove golang-github-eapache-go-resiliency. I packaged the
library not realizing it was already in the archive as golang-gopkg-
eapache
Hi Martin,
Yes, of course I'd welcome a runit service script that lxcfs can
include in its own packaging. Please feel free to open a MR when you
are ready.
Mathias
signature.asc
Description: This is a digitally signed message part
Hi Martin,
Please see my replies inline below:
On Sat, 2024-11-09 at 11:46 +0100, Martin Steigerwald wrote:
> I have received a thorough review of my current approach from Lorenzo. I
> do have a few remarks and questions for you, Mathias:
>
> I will be using apache-2.0 license so that is comp
Awesome, thanks!
Mathias
signature.asc
Description: This is a digitally signed message part
Control: retitle -1 golang-github-eapache-go-resiliency-dev: duplicate of
golang-gopkg-eapache-go-resiliency.v1-dev
Control: reassign -1 golang-github-eapache-go-resiliency-dev
Oops, somehow I missed that go-resiliency had already been packaged.
I've updated the single rdep using golang-github-
Control: retitle -1 lxd: Flaky tests causing FTBFS
Control: forwarded -1 https://github.com/canonical/lxd/issues/14455
It looks like something has caused these two tests to become flaky,
and isn't related to the change in date when building. (See for example
the reproducible builds[1]).
I've
Package: ftp.debian.org
Severity: normal
Please remove golang-github-uber-jaeger-lib. It had been in the
dependency chain for Incus, but that is no longer the case. Since it's
never been part of a Debian release, I think it would be better to
remove now, rather than including an unused leaf pack
Source: zabbix
Version: 1:7.0.3+dfsg-1
Severity: serious
Justification: FTBFS
Tags: sid ftbfs patch
Affects: src:golang-github-go-logr-logr src:golang-github-go-sql-driver-mysql
src:golang-github-mattn-go-sqlite3
Recently a couple golang libraries were updated, and unfortunately
they're causing
Package: ftp.debian.org
Severity: normal
Please remove golang-github-goccy-go-json. It's a supposedly faster
encoder/decoder than the standard library that ships with golang, and
is used by various MinIO projects. However, this library doesn't work
on big endian systems; fixing it is more comple
Source: go-cve-dictionary
Version: 0.3.1-5
Severity: serious
Justification: Failure to migrate to testing
src:go-cve-dictionary has been stuck migrating to testing for 429
days. The last Debian release to include this package was bullseye.
I think this package is a good candidate to RM prior
Control: retitle -1 goval-dictionary: Migration blocked for 429 days, consider
RM'ing
Control: tags -1 - sid ftbfs
The root cause of the FTBFS is in another package (#1085474),
although this package should still be considered for RM.
signature.asc
Description: This is a digitally signed messa
Source: gost
Version: 0.1.2-2
Severity: serious
Justification: Failure to migrate to testing
src:gost has been stuck migrating to testing for 429 days. The last
Debian release to include this package was bullseye.
I think this package is a good candidate to RM prior to trixie.
signature.asc
Source: golang-github-go-sql-driver-mysql
Version: 1.8.1-1
Severity: serious
Justification: FTBFS
Tags: sid ftbfs
X-Debbugs-Cc: vs...@debian.org
The recent upload of src:golang-github-go-sql-driver-mysql 1.8.1-1
missed adding golang-filippo-edwards25519-dev to the Depends: stanza
for the corresp
Additionally, this package has been stuck migrating to testing for
301 days. It has never been included in a Debian release.
I think this package is a good candidate to RM prior to trixie.
signature.asc
Description: This is a digitally signed message part
Source: go-exploitdb
Version: 0.0~git20181130.7c961e7-3
Severity: serious
Justification: Failure to migrate to testing
src:go-exploitdb has been stuck migrating to testing for 430 days.
The last Debian release to include this package was bullseye.
I think this package is a good candidate to R
Source: vuls
Version: 0.6.1-5
Severity: serious
Justification: Failure to migrate to testing
src:vuls has been stuck migrating to testing for 408 days. The last
Debian release to include this package was bullseye.
I think this package is a good candidate to RM prior to trixie.
signature.asc
Source: golang-github-go-redis-redis
Version: 6.15.0-2
Severity: serious
Justification: Failure to migrate to testing
src:golang-github-go-redis-redis has been stuck migrating to testing
for 1015 days. The last Debian release to include this package was
bullseye.
I think this package is a goo
1 - 100 of 471 matches
Mail list logo
