Hi,
On Sat, 31 May 2025 13:56:22 +0300 Adrian Bunk wrote:
> On Fri, May 30, 2025 at 06:00:14PM -0700, Chris Lamb wrote:
> > Adrian Bunk wrote:
> >
> > > Easiest for security support would be keeping Redis/trixie with
> > > identical licence (and with a closer codebase) to Valkey, and
> > > then
On Fri, May 30, 2025 at 06:00:14PM -0700, Chris Lamb wrote:
> Adrian Bunk wrote:
>
> > Easiest for security support would be keeping Redis/trixie with
> > identical licence (and with a closer codebase) to Valkey, and
> > then treat Valkey as upstream for Redis/trixie security support.
>
> I see
Adrian Bunk wrote:
> Easiest for security support would be keeping Redis/trixie with
> identical licence (and with a closer codebase) to Valkey, and
> then treat Valkey as upstream for Redis/trixie security support.
I see your point. I think we are simply comparing the subjective
difference betw
On Fri, May 30, 2025 at 12:32:56PM -0700, Chris Lamb wrote:
>...
> Please unblock redis for trixie.
>...
> Otherwise we are shipping a rather old version of the server (7.0.15)
> that upstream will have absolutely no interest in supporting over the
> lifetime that we want to support it, and it will
Hi,
On 30-05-2025 21:32, Chris Lamb wrote:
For example, python-redis (6.1.0-1, 6.1.0-2), python-fakeredis
(2.29.0-1 through 2.29.0-4), and fixes for libtest-redisserver-perl
and python-hypothesis (they reverse-depend on Redis in its tests).
As you noticed, I've been watching out too.
At the
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: re...@packages.debian.org
Control: affects -1 + src:redis
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock redis for trixie.
The recent Redis 8 licensing change came really late in Debian's
release cycle, but
6 matches
Mail list logo
