On Thu, Mar 21, 2024 at 11:04:13AM +0800, Ming Lei wrote:
> Hello Richard and Guys,
>
> I plan to package rublk to Fedora, and it is one Rust project.
Hi, I'm on holiday at the moment, but please do look at how we
packaged libblkio in Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=2124697
On Wed, Mar 20, 2024 at 06:19:28PM -0400, Neal Gompa wrote:
> Hey everyone,
>
> It looks like Redis, Inc. has announced that future versions of Redis
> are no longer OSS and will be dual-licensed SSPL and RSAL[1]. Absent a
> fork of Redis coming up, we will likely need to remove Redis from
> Fedor
On Wed, Mar 20, 2024 at 2:36 PM Dmitry Belyavskiy wrote:
>
...
>> > == Detailed Description ==
>> > We are going to build OpenSSL without engine support. Engines are not
>> > FIPS compatible and corresponding API is deprecated since OpenSSL 3.0.
>> > The engine functionality we are aware of (PKCS#
On Thu, Mar 21, 2024 at 9:25 AM Richard W.M. Jones wrote:
>
> On Thu, Mar 21, 2024 at 11:04:13AM +0800, Ming Lei wrote:
> > Hello Richard and Guys,
> >
> > I plan to package rublk to Fedora, and it is one Rust project.
>
> Hi, I'm on holiday at the moment, but please do look at how we
> packaged l
Stephen Gallagher writes:
> That said, I agree that it's completely reasonable to have the default
> version also `Provides: nodejsXX` and I'll look into it.
Provides is something I did not consider at all, and it looks like the
easiest way forward! Let me know when you get around to it;
alternat
Miro Hrončok writes:
> Python does this similarly to nodejs (we have python3.11, pytohn3,
> python3.13 in rawhide today), with one difference. The python3 package
> provides python3.12. So when you do:
>
> requires:
> - python3.12
>
> It just works.
>
> I believe nodejs should provid
On Thu, Mar 21, 2024 at 6:28 AM Jan Staněk wrote:
> Stephen Gallagher writes:
> > That said, I agree that it's completely reasonable to have the default
> > version also `Provides: nodejsXX` and I'll look into it.
>
> Provides is something I did not consider at all, and it looks like the
> easie
Dear Jun,
On Thu, Mar 21, 2024 at 11:04 AM Jun Aruga (he / him)
wrote:
> On Wed, Mar 20, 2024 at 2:36 PM Dmitry Belyavskiy
> wrote:
> >
> ...
> >> > == Detailed Description ==
> >> > We are going to build OpenSSL without engine support. Engines are not
> >> > FIPS compatible and corresponding
On Thu, Mar 21, 2024 at 12:15:43PM +0100, Dmitry Belyavskiy wrote:
> Dear Jun,
>
>
>
> On Thu, Mar 21, 2024 at 11:04 AM Jun Aruga (he / him)
> wrote:
>
> > On Wed, Mar 20, 2024 at 2:36 PM Dmitry Belyavskiy
> > wrote:
> > >
> > ...
> > >> > == Detailed Description ==
> > >> > We are going to b
Dear Zbyszek,
On Thu, Mar 21, 2024 at 12:41 PM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:
> On Thu, Mar 21, 2024 at 12:15:43PM +0100, Dmitry Belyavskiy wrote:
>
> > > Hi Dmitry,
> > > Could you provide the upstream OpenSSL project's issue ticket(s) or
> > > pull-request(s) about th
Dear all,
You are kindly invited to the meeting:
ELN SIG on 2024-03-22 from 12:00:00 to 13:00:00 US/Eastern
At fedora-meet...@irc.libera.chat
The meeting will be about:
Source: https://calendar.fedoraproject.org//meeting/10568/
--
___
devel ma
On Wed, 20 Mar 2024 at 22:01, Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:
> Aoife Moloney wrote:
> > The zstd compression type was chosen to match createrepo_c settings.
> > As an alternative, we might want to choose xz,
>
> Since xz consistently compresses better than zstd, I w
On Thu, Mar 21, 2024 at 8:20 AM Stephen Smoogen wrote:
>
>
>
> On Wed, 20 Mar 2024 at 22:01, Kevin Kofler via devel
> wrote:
>>
>> Aoife Moloney wrote:
>> > The zstd compression type was chosen to match createrepo_c settings.
>> > As an alternative, we might want to choose xz,
>>
>> Since xz con
Stephen Smoogen wrote:
> There are two parts to this which users will see as 'slowness'. Part one
> is downloading the data from a mirror. Part two is uncompressing the data.
> In work I have been a part of, we have found that while xz gave us much
> smaller files, the time to uncompress was so muc
On Thu, Mar 21, 2024 at 12:16 PM Dmitry Belyavskiy wrote:
>
> Dear Jun,
>
>
>
> On Thu, Mar 21, 2024 at 11:04 AM Jun Aruga (he / him)
> wrote:
>>
>> On Wed, Mar 20, 2024 at 2:36 PM Dmitry Belyavskiy
>> wrote:
>> >
>> ...
>> >> > == Detailed Description ==
>> >> > We are going to build OpenSSL
Hi Jan,
> On 21. Mar 2024, at 14:28, Jun Aruga (he / him) wrote:
>
>
> * https://github.com/ruby/openssl/issues/722
>> The Engine API was deprecated in OpenSSL 3 and there seems to be
> no alternatives for it at the moment using Provider API. The providers
> can only be loaded, but there seems
On Thu, Mar 21, 2024 at 08:29:09AM +, Richard W.M. Jones wrote:
> On Wed, Mar 20, 2024 at 06:19:28PM -0400, Neal Gompa wrote:
> > Hey everyone,
> >
> > It looks like Redis, Inc. has announced that future versions of Redis
> > are no longer OSS and will be dual-licensed SSPL and RSAL[1]. Absent
OLD: Fedora-Rawhide-20240320.n.0
NEW: Fedora-Rawhide-20240321.n.0
= SUMMARY =
Added images:3
Dropped images: 1
Added packages: 5
Dropped packages:0
Upgraded packages: 84
Downgraded packages: 0
Size of added packages: 554.60 KiB
Size of dropped packages:0
Dear Jun,
On Thu, Mar 21, 2024 at 2:29 PM Jun Aruga (he / him)
wrote:
> On Thu, Mar 21, 2024 at 12:16 PM Dmitry Belyavskiy
> wrote:
> >
> > Dear Jun,
> >
> >
> >
> > On Thu, Mar 21, 2024 at 11:04 AM Jun Aruga (he / him)
> wrote:
> >>
> >> On Wed, Mar 20, 2024 at 2:36 PM Dmitry Belyavskiy
> wr
OLD: Fedora-40-20240320.n.0
NEW: Fedora-40-20240321.n.0
= SUMMARY =
Added images:1
Dropped images: 0
Added packages: 0
Dropped packages:0
Upgraded packages: 35
Downgraded packages: 0
Size of added packages: 0 B
Size of dropped packages:0 B
Size of
(NOTE: Some packages in this report were already retired in distgit but
still show up in the orphaned packages list due to
https://pagure.io/releng/issue/12028)
Report started at 2024-03-21 16:05:32 UTC
The following packages are orphaned and will be retired when they
are orphaned for six weeks,
Il 21/03/24 03:00, Kevin Kofler via devel ha scritto:
> Since xz consistently compresses better than zstd, I would strongly suggest
> using xz everywhere to minimize download sizes. However:
>
>> especially after zlib-ng has been made the default in Fedora and brought
>> performance improvements.
On Thu, Mar 21, 2024 at 08:29:09AM +, Richard W.M. Jones wrote:
> just noticed one fork, might be worth keeping eye on:
> https://codeberg.org/redict/redict
On the newly launched "Write Free Software" Discourse[0], Drew noted
that he is creating and leading this fork due to his reliance on Re
Assuming KeyDB gets accepted (it looks close from the Bugzilla review), we
should obsolete redis for KeyDB in Fedora 40+ and consider eventually doing
likewise with EPEL as well, since we aren't going to be able to ship any redis
patches moving forward. I feel less strongly about that for EPEL
Anything that was new in Redis 7 is not currently in KeyDB. This is a
decent list of features I found that would be impacted.
https://www.instaclustr.com/blog/redis-7-new-features/
KeyDB has it on their roadmap to merge in the latest features from Redis 7
but that's not complete yet (nor can I f
On 2024-03-21 09:22, Maxwell G wrote:
gnome-shell-extension-freon orphan 2
weeks ago
I've picked this up.
Cheers
Davide
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-l
Redis-6 is currently shipped in EPEL9, so it seems like a more obvious
step-forward wrt EPEL.
> Honestly trying to replace redis with KeyDB in Fedora would be a step
> backwards and cause headaches so I don't think it's feasible, at least
> until redis v7 features are merged into KeyDB.
Unfortu
> If we have some clue that a v7 merge/release
> is on the very near horizon for KeyDB
This doesn't look promising for v7 in time for Fedora 40 or shortly after,
unfortunately: https://github.com/Snapchat/KeyDB/issues/420
The choice of shipping an ever-stale v7 database versus a maintainable v
On Thu, Mar 21, 2024 at 2:24 PM Scott Williams wrote:
>
> > If we have some clue that a v7 merge/release
> > is on the very near horizon for KeyDB
>
> This doesn't look promising for v7 in time for Fedora 40 or shortly after,
> unfortunately: https://github.com/Snapchat/KeyDB/issues/420
>
> The
In Addition to that, I would rather wait a little bit and see about another
fork (s) and see ship possible redis-7+ versions instead of downgrading it.
Also PR shows very slow process so I wouldn't go for it.
On Thu, Mar 21, 2024 at 9:24 PM Scott Williams wrote:
> > If we have some clue that a
FYI - It looks like there is a redis-7 to keydb-6 path:
https://github.com/Snapchat/KeyDB/issues/527#issuecomment-1370606311
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
F
My concern there is that it has 7 code contributors with just one person having
the vast majority of those commits. That's not a problem for including the
package, but it could be a concern for replacing redis with it given how young
the project is and for it having significantly less resources
On Thu, Mar 21, 2024 at 1:28 PM Neal Gompa wrote:
> On Thu, Mar 21, 2024 at 2:24 PM Scott Williams
> wrote:
> >
> > > If we have some clue that a v7 merge/release
> > > is on the very near horizon for KeyDB
> >
> > This doesn't look promising for v7 in time for Fedora 40 or shortly
> after, un
> On Wed, Mar 20, 2024 at 2:53 PM Tomasz Kłoczko
>
> While I agree with some of what you're saying here, the problem is
> that it is, in fact, *not trivial* in many cases.
> Migrating the License tag from Callaway to SPDX identifiers is only
> the "easy" part of the transition.
> Re-reviewing pa
The Fedora Linux 40 Beta RC 1.10 compose is GO and will be shipped
live on Tuesday, 26th March 2024.
For more information please check the Go/No-Go meeting minutes[1] or log[2].
[1]
https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-03-21/f40-beta-go-no-go-meeting.2024-03-2
Hi,
Some days ago I notice that shogun-data still in Fedora [1] but shogun
is retired for 4 years [2], just run `fedpkg retire DESCRIPTION` is
enough ?
Thank you,
[1]
https://src.fedoraproject.org/rpms/shogun-data
[2]
https://src.fedoraproject.org/rpms/shogun
--
Sérgio M. B.
--
_
Dne 21. 03. 24 v 19:47 kloc...@fedoraproject.org napsal(a):
Those trivial substs probably would cover +90% of all packages in time in my
estimation.
See
https://docs.google.com/spreadsheets/d/1QVMEzXWML-6_Mrlln02axFAaRKCQ8zE807rpCjus-8s/edit#gid=0
The "trivial" conversion is possible for 499
Yeah, I was going to say it depends on the dotnet8 runtime. There are
containers for it, but that's a lot of extra dependency load. Otherwise, it
would be viable.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email
Redis is not shipped in EPEL9, because it's in RHEL9. Same with EPEL8
and RHEL8. It is shipped in EPEL7 at version 3.2, presumably because
updating any further would be an incompatible update.
The license change announcement clearly states it will only be for 7.4
and up. The prior branches (6.2
On Fri, Mar 22, 2024 at 12:22 AM Maxwell G wrote:
> botan orphan 0 weeks
> ago
Is botan1 still considered safe? Perhaps the python which causes the FTI
apparently could be removed?
Of course we have botan2 (but not botan3) in Fedora...
(I
40 matches
Mail list logo
