Sandro wrote:
> I was probably overthinking this. In practice it will turn out to be a
> new package submission indeed. Moreover, the last remaining active
> branch of the retired package (F38) is now EOL.
>
> I've submitted the review [1] without any Obsoletes.
Since we support upgrades from
Julian Sikorski wrote:
> are there guidelines advising how to handle upstream desktop filename
> change in a stable fedora release? For gnumeric I just followed upstream
> [1], which led to a bug report [2]. Now I am facing similar situation
> with pavucontrol [3]. Should I rename the desktop file
Michael J Gruber wrote:
>> %patchlist and %auto* should just go away, or at least banned from Fedora
>> by a git hook rejecting such specfiles.
>
> We also have unnumbered patch source definition lines, don't we?
IIRC, unnumbered Source: or Patch: just defaults to Source0: resp. Patch0:.
But it
Pedro Moura wrote:
> To add blog posts in Fedora Planet you basically need to update RSS URL
> field at https://accounts.fedoraproject.org/
Which means that basically all blogs are going to vanish from Fedora Planet
unless people re-add them manually.
There are 809 blogs on the old Planet
Neal Gompa wrote:
> I have the question of why is dnf5 running as if "--allow-erasing" is
> always passed to it? Older versions of DNF explicitly didn't do that
> because we get weird behaviors like this.
Without --allow-erasing (which was actually passed explicitly, as Petr Pisar
pointed out),
Panu Matilainen wrote:
> Patch and source numbers start from zero, that goes for automatically
> numbered patches too. So there's an off by one in the application, and
> the latter %autopatch which is supposed to apply patches >= 2 simply has
> nothing to do, and falls through silently. That's a
Adam Williamson wrote:
> The shortest syntax is just to use Patch: foo.patch , and %autosetup .
That is not a syntax to apply a patch, it is an automagic that blindly
applies all patches in numeric order. Cannot reorder patches, cannot apply
them conditionally (e.g., based on the 0%{?fedora}
Florian Festi wrote:
> We have an even easier solution for you: You can just run the script at
> [3] with -n on your own spec files to get them changed to the %patch N
> variant. If you do that right now they will not break nor will they be
> touched during the mass change.
>
> As I said the
Neal Gompa wrote:
> On Mon, May 6, 2024 at 8:17 AM Leon Fauster via devel
> wrote:
>>
>> Am 06.05.24 um 13:56 schrieb Florian Festi:
>> > Hi everyone,
>> >
>> > RPM has deprecated the %patchN syntax in favor of %patch -PN where N is
>> > the patch number for a year now. See the RPM documentation
Carlos Rodriguez-Fernandez wrote:
> How could that be expressed so that those are caught quickly at build
> time? Someone wants to depend on a java lib that has been tested only in
> JRE 8 to 11, but wants to build the package with JRE 17+, or vice-versa,
> for example. Perhaps, the only feasible
Christopher wrote:
> So, I actually think that building with the *latest* JDK that we ship,
> and using the `--release` flag during compilation is actually safer
> than building against the lowest that we support, because it is most
> likely to strictly enforce correct byte code generation for the
Carlos Rodriguez-Fernandez wrote:
> Regarding the proposal as a whole, I think the proposal idea makes a lot
> of sense, but for apps depending on system jar libraries, there should
> be a way to specify that the app depends on a specific java bytecode
> version range. System libraries packages
Miro Hrončok wrote:
> If you wish to help, I guess you can send a pull request to the release
> notes...
Or Mattia could simply unretire and adopt the package.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To
Fabio Valentini wrote:
> No, that's just wrong.
> The "upgrade path" (wrt/ NVRs) is no longer enforced across release
> boundaries. AFAIK, all supported release-upgrade methods now use
> distro-sync or something equivalent, so NVR-based "upgrade path" is just
> not important any more.
That just
Michael J Gruber wrote:
> A minor bump (as in %{?dist}[.]) only comes into play
> if a "lower" branch needs to move forward without creating a version
> ahead of a "higher" branch. And (independent of autorelease) you cannot
> do that unless you use divergent git branches and cherry-picks in
>
Julian Sikorski wrote:
> I need to rebuild mame on F40 only for qt-6.7. On rawhide,
> mame-0.265-1.fc41 is already built against it so I only need to build
> mame-0.265-1.fc40.1. Can it be done using %autorelease?
No, which is why you should not be using %autorelease.
I would just replace
Adam Williamson wrote:
> Well, it really wants to write to /lib , not to /usr. But of course, on
> Fedora, /lib is /usr/lib .
Sigh… Time for a UsrUnmerge? :-)
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To
Julian Sikorski wrote:
> In this case defaulting to cherry-picking would be a safer bet. Branches
> unintentionally separated can be merged, but branches unintentionally
> merged cannot be unmerged.
This is only true if you are talking about merge-commit merges. Not if we
are keeping the
David Abdurachmanov wrote:
> We currently use a symlink (as Richard) mentioned, but it's not ideal
> and causes problems (e.g. meson generates wrong paths breaking some
> packages [one example: libplacebo]).
Which I would say is a bug in Meson and should be fixed there.
I do not think having
Nathan Scott wrote:
> - it could be advantageous if the new compat sub-package contained
> the redis binary symlinks & not the primary valkey package (this could
> allow valkey and redict packages to coexist, for example). Long-term
> we may want to drop those entirely (along with the compat
Kilian Hanich via devel wrote:
> The fact that you can share the keys is actually part of the design and
> wanted. Apple for exmaple has (or wants to) implement easy sharing of
> passkeys via AirDrop.
So the Apple Cloud can see your private key, but you cannot? Sounds like
GREAT "security", LOL…
Gary Buhrmaster wrote:
> [2] As I understand it, the issue is the
> lack of the required trusted environment
> in generic Linux. There are software
> implementations that do not have the
> hardware enclave protections,
And to be honest, I do not see the problem there. I will use whatever will
Richard W.M. Jones wrote:
> As gcc -Os was mentioned too, that is -O2 with the following
> optimizations disabled:
>
> -falign-functions -falign-jumps
> -falign-labels -falign-loops
> -fprefetch-loop-arrays -freorder-blocks-algorithm=stc
Last I checked, there were also some hardcoded if
Neal Gompa wrote:
> I would like for us to consider evaluating a global change to -O3. I
> am not convinced that there's a good reason anymore to remain at -O2.
>
> If we get this kind of benefit from Python, I would be interested in
> seeing what we'd get elsewhere.
How much larger is Python
Adam Williamson wrote:
> Also, these days, most authenticator apps support some kind of backup
> mechanism. FreeOTP lets you back up to a file (which you should, of
> course, keep somewhere safe and ideally encrypted). Google
> Authenticator can backup To The Cloud.
If you use Keysmith, you can
Zbigniew Jędrzejewski-Szmek wrote:
> So… this is what I'm talking about: there is no obvious way to
> figure out what to set. Looking at the logs and trying to figure out
> some variables from that is not very attractive.
The comments at the top of the relevant Find*.cmake module are the best
Zbigniew Jędrzejewski-Szmek wrote:
> And sorry, but saying to "process pull requests quickly" is just naive.
> Busy packages often have many different pull requests concurrently, and
> some of them need discussion and fixes and work in other places before
> they can be merged.
Generally, there
Zbigniew Jędrzejewski-Szmek wrote:
> I'm revisting the topic of rpmautospec because I was doing some work
> on various packages, and it's annoying that some packages are using
> rpmautospec and others are not.
The fix for that inconsistency would be to ban rpmautospec. It just makes
everything
Emmanuel Seyman wrote:
> I've noticed a trend in proposed changes in the way Fedora works.
I am fed up of this salami tactic as well. When we complain about the new
stuff, we invariably get told "don't worry, you don't have to use it, it's
all optional", but the plan is always to make it
I wrote:
> On Sun, Apr 7 2024 at 13:52:26 +00:00:00, Zbigniew Jędrzejewski-Szmek
> wrote:
>> Hmm, why? Oh, rpm uses cmake, and cmake has it's own special
>> detection of python, and it found /usr/bin/python3.13t that I have
>> installed, and subsequently it got all the paths wrong.
>
> That's why
That's why you should never build packages outside of mock.
Kevin Kofler
On Sun, Apr 7 2024 at 13:52:26 +00:00:00, Zbigniew Jędrzejewski-Szmek
wrote:
On Sat, Mar 30, 2024 at 10:15:47PM +, Zbigniew
Jędrzejewski-Szmek wrote:
One particular issue I have with CMake as a downstream
Peter Boy wrote:
> Well, a switch from Gnome to KDE would require a lot of changes in
> everyday applications, e.g. Mail. That is not required when you update
> from Gnome 2 to Gnome 3.
Well, in principle, GNOME applications will usually work under Plasma and
the other way round. But in practice
Leslie Satenstein via devel wrote:
> The Cellphone user is very comfortable with Gnome. So much so, that I
> believe that if he was given KDE as the interface, two things would
> happen. a) The user will switch to Gnome, or b) The user will find a way
> to add his favourite applications to the
Tomasz Torcz wrote:
> GNOME (Mutter) maximizes windows if they initially take 80% of more
> screen space.
And I believe that that, too, was a refinement added in later releases.
IIRC, GNOME 3.0 just maximized everything.
Kevin Kofler
--
___
Peter Boy wrote:
> I'm probably not the right person to comment on this, because I completely
> abandoned Fedora Desktop when it was hit (badly) by Gnome 3. That
> destroyed my daily workflow and work routines and made it unusable (for
> me), or at least barely usable for serious professional work
I wrote:
> That is exactly the problem with autotools code, almost nobody understands
> what the heck it does, almost everybody just copies and pastes somebody
> else's snippet hoping it does not do bad things. And gnulib is a
> particularly ugly piece of the puzzle.
PS: Here is a pretty good
Neal Gompa wrote:
> By default, GNOME only presents the close window button. The other
> buttons are missing, and there isn't really an intuitive way to
> discover the other window management actions.
In the version I tried, and judging from end user reports, for several
years, it did not even
Leon Fauster via devel wrote:
> 10 minutes is not enough to do a remodeling of the "familiar"
> experience, so that you reaches the so called realm of intuition.
> The latter is something that we learn over time and the desktop
> environment does not offer this on its own. It provides only a
>
Kilian Hanich via devel wrote:
> About the release cycle: After the initial release of Plasma 6 when dust
> has mostly settled down (approx. 2 point releases), they want to switch
> over to a release cycle which would align (which is likely also the
> reason why F42 was choosen in this proposal).
Gordon Messmer wrote:
> If RPM's ELF dependency generator were better, the importance of
> stability would be debatable, but as it is, I really think Fedora should
> be more stable than it is, especially for whatever it defines as "the
> OS." Today, dnf/rpm will happily allow users to install an
Gordon Messmer wrote:
> "When you are using the Linux mark pursuant to a sublicense, it should
> never be used as a verb or noun. It should be used only as an adjective
> followed by the generic name/noun. In other words, “Super Dooper Linux
> OS” is okay, but “Super Dooper Linux” isn’t."
>
>
Aaron Rainbolt wrote:
> Still, one could make some case for this. Plasma is, for one, obviously
> going to be more familiar to newcomers to the Linux world simply by
> virtue of the fact that the paradigms presented by its initial
> configuration are more familiar to those coming from the Windows
Leon Fauster via devel wrote:
> I already had RHL installed on a Sun IPX with Gnome, so I'm biased.
Interesting that you were not put off by the changes that have happened to
GNOME since the old RHL days. I tried GNOME 1 at one point long ago, it was
actually pretty good. (It was very
Stephen Smoogen wrote:
> Downloads are very hard to measure because too many things are grabbing
> everything from mirrors for different reasons. [Plus various people seem
> to think manipulating the stats for their particular spin on the number of
> downloads will make it more popular (I am
Steve Cossette wrote:
> Another route would be to go the Ubuntu route, if you really don't want to
> stop having Workstation as the default: Spin (pun intended) the KDE spin
> on it's own branding. Though I do understand that is an undertaking on
> it's own. It would still be Fedora, about as much
Andreas Tunek wrote:
> From Red Hat's POV it is not Fedora Gnome Workstation (
> https://blogs.gnome.org/uraeus/2020/05/07/gnome-is-not-the-default-for-fedora-workstation/
> ).
TL;DR: "We do not want 'GNOME' in the name because we want to only support
GNOME in Workstation, whereas 'GNOME
Kevin Fenzi wrote:
> to you? They are quite relevent to others...
I would really like to see what the proportion of users downloading the
Server, IoT, Cloud, and CoreOS Editions is compared to Workstation or the
Spins. I would not expect it to be very high. Most Fedora users are desktop
users.
Luis Correia wrote:
> I'm mostly a user and I can accept a change from GNOME to KDE, IF and only
> if I'm not forced to use Wayland.
>
> For me it isn't usable in my setup and most things are plain broken.
As the maintainer of plasma-workspace-x11 and kwin-x11, I can assure you
that that will
Peter Boy wrote:
> We would be pretty silly if we did that. This differentiation and the
> associated quality and safeguarding criteria are a model for success and
> one of our differentiation criteria.
I think that is a quite pointless "differentiation criteria". Most users do
not even
Joe Orton wrote:
> Given that the ENGINE API is deprecated upstream since OpenSSL 3.0, the
> API is optional upstream, and its use has produced compiler warnings
> since it was introduced in Fedora 36, it seems perfectly reasonable to
> disable this API in Fedora 41.
I disagree. Disabling an API
Steve Cossette wrote:
> Putting aside that i heard from Neal Gompa that anaconda cannot
> accommodate a « multi-flavor » media, can you imagine how big that iso
> would be? Forget 4gb, it’d probably be closer to 20gb!
We used to have multiboot live images that let you pick the live image
flavor
Eric Blake wrote:
> The upstream autoconf discussion says that 'autoreconf -fi' behavior
> on which 'serial NN' .m4 files to update is determined by automake,
> not autoconf, in part inspired by semantics desired in gnulib. And
> the automake and gnulib developers have argued that the upstream
>
Kevin Fenzi wrote:
> Why not the opposite:
>
> Download Workstation
>
> [I'm a linux user and know what I want, just show me the full list of
> downloads, click here]?
Because that still leads people to click that "Download Workstation" link
before even seeing the options. "I do not want to
Adam Williamson wrote:
> I mean, we really don't need to speculate about this much. We did an
> entire overhaul of the project - Fedora.next
That was for Fedora 21 in 2014! As you stated it, I know you and I have been
around forever and 2014 feels like yesterday, but it was really quite a long
Steve Cossette wrote:
> Sorry, that's pretty much how things are right now, is that what you were
> trying to demonstrate?
>
> I'm not really following.
Not really. The current design is better than those old designs that
immediately served you an ISO when you clicked "Download now", but the
Kevin Fenzi wrote:
> Ok, thats obvously somewhat tounge in cheek, but if we promote multiple
> things, we need some way to describe them to uses who might not know the
> history of things and do it in a quick enough way that they won't decide
> it's all confusing and go do something else.
It is
Steve Cossette wrote:
> We essentially just want more visibility on the website, if that makes
> sense.
Back when I was still a KDE SIG member, whenever we brought that up with the
Websites Team, they would just point us to the Board (what is now the
Council), and the Board would point us back
Adam Williamson wrote:
> Change proposals can be, and frequently are, rejected.
If you look at the statistics, they very rarely are. A lot of bad changes
with lots of criticism on the mailing list were waved through by FESCo. But
if they dare touching a Red Hat holy cow such as the dogma of
Richard W.M. Jones wrote:
> Yes, in this case the attacker had set the serial number to 30, but
> the latest upstream serial number was 3. autoreconf won't replace the
> file in this case unless it is deleted. There really should be an
> "always replace if you can" option in autoreconf.
Is that
Gary Buhrmaster wrote:
> And, more importantly, the industry has agreed
> to use the term supply chain. Is the term
> perhaps overloaded, or perhaps too
> ill-defined/imprecise? Sure. But if one wants
> to use a different term one would need to work
> across the industry to change the term, and
Adam Williamson wrote:
> It occurs to me - maybe you don't agree, but this is how it looks to me
> - that, ironically, you and I usually argue the exact *opposite* side
> of this case, no? I argue in *favor* of somewhat-arbitrary delays to
> packages appearing in 'stable', and you argue *against*
Gordon Messmer wrote:
> Purely as trivia, and as I haven't seen it discussed elsewhere, the
> malware steals a different set of symbols on Fedora, where
> RSA_public_decrypt doesn't seem to appear in the GOT at all.
This proves again that this is a very targeted attack that carefully
analyzed
Aoife Moloney wrote:
> Switch the default desktop experience for Workstation to KDE Plasma.
> The GNOME desktop is moved to a separate spin / edition, retaining
> release-blocking status.
It is funny that the KDE SIG is proposing that now. I have a sense of déjà-
vu:
Chris Adams wrote:
> However, it's a good trigger to review Fedora's security approach in
> general (like 2FA use).
Using such an issue that made it through upstream 2FA and would also have
made it through any 2FA enforcement in Fedora as an excuse to force 2FA on
us is just pure nonsense.
Matthew Miller wrote:
> I sometimes see unit test failures. The developer ran the tests, but not
> on S390.
Why would I want a test failure on such an exotic architecture to fail my
build? The only reason Fedora supports that architecture at all is pressure
from IBM. Basically nobody uses it.
Lennart Poettering wrote:
> It *literally* is just sending a text string "READY=1" in an AF_UNIX
> datagram to a socket whose path is provided to you in the
> $NOTIFY_SOCKET env var.
I see so many ways one can get this wrong. E.g., using some abstraction for
the socket write that can also write
Adam Williamson wrote:
>> * Deleting ALL files automatically generated or imported by autotools in
>> %prep, THEN running "autoreconf -i -f". (DO NOT trust autoreconf, it
>> would NOT have done the right thing here. Delete the files, THEN run
>> autoreconf.)
>
> No. This would not have avoided
Adam Williamson wrote:
> I would argue there's a danger of getting too tied up in very specific
> technical details of this attack.
But the fact is:
What WOULD have stopped this attack: (one or more of:)
* Deleting ALL unit tests in %prep (and then of course not trying to run
them later).
*
Adam Williamson wrote:
> Maybe this needs to go on the growing pile of reasons why the
> traditional Linux model *does* need to go away. Maybe Fedora, with its
> foundation of First, should be kind of at the forefront of making that
> happen.
Switching to a container-based model is just going to
Adam Williamson wrote:
> Do we require 2FA for provenpackager yet?
No. I am a provenpackager and do not have 2FA enabled (nor do I want it to
be).
> People would say, justifiably so, that it was absolutely unacceptable for
> us to be allowing single-factor authentication for contributors to a
>
Neal Gompa wrote:
> Well, an easy solution is to make it so "dnf update" is coerced to
> "dnf distro-sync" for development releases.
That would not have helped containing this vulnerability. Keeping updates-
testing disabled by default would have.
Kevin Kofler
--
Otto Liljalaakso wrote:
> So, I would actually much prefer if package retirement automatically
> added the package to fedora-obsolete-packages. Perhaps there are special
> cases where that would not be a good idea - if there are some, `fedpkg
> retire` could have a flag to prevent that from
Adam Williamson wrote:
> 1. We *still don't have compulsory 2FA for Fedora packagers*. We *still
> don't have compulsory 2FA for Fedora packagers*. *WE STILL DON'T HAVE
> COMPULSORY 2FA FOR FEDORA PACKAGERS*.
This 2FA nonsense needs to stop! GitHub has enforced compulsory 2FA for
contributors
Kevin Fenzi wrote:
> Branched enables updates-testing... so if you installed f40 anytime, you
> will have it enabled and if you then applied updates it would be in them
Yet another thing I always said was a bad idea, and this incident proves it.
This would have been filtered before reaching most
Miroslav Suchý wrote:
> 4) Fetch build artifacts before executing tests
>
> https://github.com/rpm-software-management/mock/issues/1352
Or better: Do not execute tests to begin with! rm -rf test in %prep and
NEVER run tests during builds. Even when the tests are all legitimate, all
it does is
Zbigniew Jędrzejewski-Szmek wrote:
> I think there's some useful points here, but this would need to be
> qualified and/or made more flexible to be applied.
>
> For example, systemd repo has fuzzer case files, which are a mix of
> text, mojibake, and actual binary protocol samples. For example,
Artem S. Tashkinov via devel wrote:
> There must be a website or a central authority which includes known to be
> good/safe/verified/vetted open source packages along with e.g.
> SHA256/384/512/whatever hashes of the source tarballs. In addition, the
> source tarballs (not their compressed
Gary Buhrmaster wrote:
> What I do think we should start with is look at the
> list of dependencies in the list of whatever we
> can agree are security critical packages (running
> as root and opening network ports is always a
> good start) and dependencies which are not
> supported by a large-ish
Zbigniew Jędrzejewski-Szmek wrote:
> In fact, we should probably make the effort to add pkgconf files for the
> few libraries that don't have it to make it completely standard and
> expected.
That is a particularly bad idea. Downstream .pc files are a nuisance. If
someone develops upstream
Zbigniew Jędrzejewski-Szmek wrote:
> CMake for many years fought against pkgconf and pushed people towards
> copying those scripts into sources. It is still very common for projects
> using CMake to come with a whole directory of badly written detection
> scripts that each replace a single-line
Neal Gompa wrote:
> And in CMake's favor, there's a huge ecosystem of helpers and
> integrations that make it easier for people to understand what CMake
> is doing as it's being developed, built, and shipped. That makes it
> much more attractive than Autotools simply because the knowledge and
>
Kilian Hanich via devel wrote:
> Meson doesn't allow you do create your own functions. While one should
> try to avoid them in build systems, there are cases where you need them.
> I work on a project where they are needed, but it also wouldn't make
> sense to upstream it because it's too project
Neal Gompa wrote:
> Note that dlopen() doesn't fix the problem of the giant libsystemd in
> the first place. It just obfuscates the true dependency graph of
> libsystemd.
At least it (hopefully) means liblzma will not be opened if you do not use
an API that needs liblzma. But it makes it even
Zbigniew Jędrzejewski-Szmek wrote:
> Meson outclasses CMake in functionality,
LOL, how so? Everything in Meson is hardcoded, you have very little
flexibility (but still enough to plant a backdoor if that is what you want,
because you can just invoke a shell script or any other external
Neal Gompa wrote:
> This is not helpful in the slightest and the tone is not appreciated at
> all.
Well, I have been arguing against this exception (exempting prebuilt
autotools output) from the "no prebuilt blobs" rule for years, and it
saddens me that something like this had to happen for
Dominique Martinet wrote:
> I'm not 100% sure about the theory, but it looks like `autoreconf -fi`
> looks at the 'serial' in the first line of the script.
> The one bundled in the xz sources was marked very high:
> # build-to-host.m4 serial 30
> But the one in the system (as of f39) is only
Richard W.M. Jones wrote:
> (1) We should routinely delete autoconf-generated cruft from upstream
> projects and regenerate it in %prep. It is easier to study the real
> source rather than dig through the convoluted, generated shell script
> in an upstream './configure' looking for back doors.
>
Mikel Olasagasti wrote:
> And they wayback WayBackMachine[3] doesn't have previous versions.
We have the previous versions in the dist-git lookaside cache and in the old
SRPMs.
Kevin Kofler
--
___
devel mailing list --
Hi,
wow: https://www.openwall.com/lists/oss-security/2024/
I think at this point we clearly cannot trust xz upstream anymore and should
probably fork the project.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To
Daniel Alley wrote:
>>ry xz -9, it should be better than zstd. It will take longer to compress,
>>but should actually be FASTER (!) to decompress, which is what really
>>matters.
>
> Please provide data - any data - to support this claim, because it flies
> completely in the face of every
Daniel Alley wrote:
>>ry xz -9, it should be better than zstd. It will take longer to compress,
>>but should actually be FASTER (!) to decompress, which is what really
>>matters.
>
> Please provide data - any data - to support this claim, because it flies
> completely in the face of every
Pekka Oinas via devel wrote:
> The package for edb, a GUI debugger application, has been orphaned in
> Fedora for many years: https://src.fedoraproject.org/rpms/edb
>
> I like this application and think it's useful, and would like to see it
> unorphaned. I have been building it in COPR at
>
Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Mar 25, 2024 at 04:50:28PM -0400, Neal Gompa wrote:
>> Keep in mind we also want to make the compose process faster too, I
>> don't know if it's worth it to spend 20x more time compressing
>> repodata when we keep trying to get back hours and minutes
Miroslav Suchý wrote:
> I just upgraded my workstation to F40 and it surprised how many packages
> were reported by `remove-retired-packages`. There was lots of orphaned
> packages - there is nothing to do about them. But there was lot of
> packages that were removed intentionally. See the list at
Daniel Alley wrote:
> One more point: createrepo_c uses zstd compression level 10, but the range
> goes all the way up to level 22. I would oppose making the default much
> computationally heavier than it is currently, but if spending 20x longer
> to compress the repo 10% more is desirable to the
Neal Gompa wrote:
> 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
> Fedora.
>
> All I can say is... :(
Amazon (AWS) is setting up a
Kevin Kofler via devel wrote:
> Once concern I have with this is the use of LGPL 3.0 *only*. This will not
> be compatible with a GPL 4 or newer. (The upgrade clause in the LGPLv2
> that allowed that was unfortunately dropped in the LGPLv3, now you have to
> put the "or later"
Kevin Kofler via devel wrote:
> Neal Gompa wrote:
>> I think the immediate fix is pulling in redict once it makes its first
>> release: https://codeberg.org/redict/redict
>
> Once concern I have with this is the use of LGPL 3.0 *only*. This will not
> be compatib
Scott Williams wrote:
> 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.
It is actually already packaged in Fedora:
https://src.fedoraproject.org/rpms/dotnet8.0
But yes, it is bloat.
Kevin Kofler
--
Neal Gompa wrote:
> I think the immediate fix is pulling in redict once it makes its first
> release: https://codeberg.org/redict/redict
Once concern I have with this is the use of LGPL 3.0 *only*. This will not
be compatible with a GPL 4 or newer. (The upgrade clause in the LGPLv2 that
allowed
1 - 100 of 888 matches
Mail list logo
