Michael Catanzaro wrote:
> Thing is, Kevin has a point here.
You are simulating agreement here, but you are still opposed to the solution
I am actually proposing, so we are still actually in diametral disagreement.
> I've lost track of the number of times annobin troubles have resulted in
> grat
Ralf Corsépius wrote:
> I do not agree with this statement. Like previous "Legacy SIGs" this is
> a red herring to obfuscate RHATs lack of disinterest with topics, which
> do not match into their business objectives.
I am also worried that this is just a delayed retirement, as it was for 32-
bit
Gordon Messmer wrote:
> I've gotta ask... How much memory does the new dnf daemon take while idle?
As I understand it, the new DNF daemon would mostly only replace/upgrade the
already existing dnfdaemon, for users of tools like Dnfdragora. It would not
be required otherwise, or would it?
Jóhann B. Guðmundsson wrote:
> In this case that SIG would be created for no good reason since the
> outcome is inevitable.
I still do not see what is inevitable about the outcome. Keeping legacy, no
longer changing, interfaces working forever should require next to no
effort.
> For how long sh
Jóhann B. Guðmundsson wrote:
> Then there is the fact that clinging to legacy bios is working against
> Fedora's own foundation "First" in which is stated "Fedora always aims
> to provide the future, first".
How is it against "First" to continue providing the future also for hardware
of the past?
Jóhann B. Guðmundsson wrote:
> Trying to support that legacy scenario where certain hw may or may not
> work is a nightmare for developers, support teams and Fedora since
> Fedora is not a distribution with a long term support, LTS distributions
> are better suited to support legacy hw then Fedora
Jóhann B. Guðmundsson wrote:
> No but it does mean that they cant run indefinitely
Only if the spare parts that are not available actually fail (and if you
cannot find the spare parts through less official channels, such as buying
another broken computer where the part you need is still working)
Justin Forbes wrote:
> The i686 SIG was given multiple releases to organize. The original
> proposal which triggered the SIG to form was for F27, the proposal to
> finally kill it and declare the SIG inactive was F31.
But, the way I remember it, the SIG was declared inactive just because of
*one*
Adam Williamson wrote:
> Right now it's not entirely clear whether this is considered part of
> the Change scope or not. The paragraph about the `uvesafb` driver seems
> kind of aspirational and doesn't seem to commit to anything. The
> "Benefit to Fedora" section states "Verified modern supported
Adam Jackson wrote:
> Turns out the support story is less bad than I thought, the simpledrm
> change was more powerful than I knew. I've updated the change again
> but the short story is vga= on kcmdline will give you just as good of
> support as UEFI framebuffer.
Or rather, as bad of support, bec
Mikolaj Izdebski wrote:
> Using side tags for single build updates is an overkill.
If the update includes ABI or even API breaks that may require rebuilding
other packages, possibly even with patches, then it is NOT a "single build
update".
Kevin Kofler
_
Mikolaj Izdebski wrote:
> Do you have any evidence for this claim that the update will break any
> package? If so, please share it.
You wrote yourself: "The new major version introduces API break and packages
may need to be ported to work with the new version." So it has to be assumed
that depen
Ian Pilcher wrote:
> It sure feels like we're reaching the point where anyone who has to work
> with any sort of older equipment or servers is going to to forced to
> switch their entire system to the LEGACY policy, which seems really
> unfortunate.
Even worse is that even the LEGACY policy is get
Ben Cotton wrote:
> == Summary ==
> This is initial step to move JDKs to be more like other JDKs, to build
> proper transferable images, and to lower certification burden of each
> binary. Long storyshort, first step in:
> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
>
> This
Andrew Hughes wrote:
> On 01:07 Wed 11 May , Kevin Kofler via devel wrote:
>> Let me join the train of -1 votes. I consider this a step entirely in the
>> wrong direction. The JDK should be linked to system libraries wherever
>> possible just like our other packages. Langu
Jiri Vanek wrote:
> see the clarifications of most concerns:
Unfortunately, your mail does not clarify all that much for me. I actually
see several contradictions, e.g.:
> > Are people really installing OpenJDK RPM packages, taking the
> > "/usr/bin/java" binary, and putting it onto some other
Neal Gompa wrote:
> Yeah, I think that proposal was not workable because of AVX2. The
> x86_64-v2 subarch adds SSSE3, SSE4.2, POPCNT, and CMPXCHG16B to the
> current x86_64 baseline. All of these instructions were present in the
> first Intel Macs launched in 2007, as I recall.
Still means my Core
Florian Weimer wrote:
> Right, I have yet to encounter anyone who can't run the new el9 binaries
> on their hardware. We had a few issues, but they were all
> misconfiguration of hypervisors or software emulators.
Let me introduce you to my notebook:
[kevin@laptop64 ~]$ cat /etc/fedora-release
F
Otto Urpelainen wrote:
> Also, if the intent is to get rid of the package completely, should not
> adding it to fedora-obsolete-packages be required as well?
Why? Adding working packages to fedora-obsolete-packages forces removing
them from users' machines just because they are no longer in the r
Aleksei Bavshin wrote:
> 4 and 5 (and 6) are not backward compatible. Glyphs are missing,
> replaced, changed codepoints, etc... Not all things could be ported and
> I don't believe we'll ever get rid of 4.
>
>
>
> Good thing is that _some_ of the packages with `Requires:
> fontawesome-fonts` al
Sérgio Basto wrote:
> That is the point for me, if we have an replacement there is no point
> on keeping old code.
That is the same argument they used to justify desupporting plasma-
workspace-x11 and kwin-x11 in favor of their Wayland counterparts.
I do not see a valid reason for removing workin
Adam Williamson wrote:
> Yeah, I was more worried about vesa.
>
> I've now tested and basic graphics mode works OK on UEFI and BIOS on
> both GNOME and KDE with a recent F41 image, so that's good. It uses
> Wayland in all cases so no X drivers involved. The other case I'm
> concerned about is doin
Hi,
the recent EPEL 10 branch request for ufw reminded me of this:
I would like to hand out UFW, the Uncomplicated FireWall, (Fedora package
"ufw") to one or more packagers who are more interested in it than me.
I packaged UFW a few years ago as part of the Kannolo effort, because
ufw-kde wa
Neal Gompa wrote:
> I know the idea of moving to -O3 has been briefly mentioned before in
> other contexts when we've discussed uplifting the flags, but it looks
> like Ubuntu is moving to -O3 for Ubuntu 25.04[1]. Is there a reason
> why we shouldn't consider doing the same for Fedora Linux 42?
Ye
Zbigniew Jędrzejewski-Szmek wrote:
> With python3-pyqt6-6.8.0-0.1.fc42.x86_64, we get a difference in how the
> icons are rendered:
>
> calibre-7.20.0-1.fc42.x86_64
> modified-S.5
> /usr/share/icons/hicolor/16x16/apps/calibre-gui.png
> modified-S.5
>
Dominik 'Rathann' Mierzejewski wrote:
> Dirac codec support is optional in the above.
It still means that the claim that nothing is using this library anymore is
false.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
T
Michael Catanzaro wrote:
> * We do expect smartcards to work on immutable systems where
> installing extra packages is either inconvenient (Silverblue and
> Kinoite require overlays) or not possible (future Fedoras, hopefully)
Quite a distopian future you paint there!
My vision of the future does
Zbigniew Jędrzejewski-Szmek wrote:
> Heh, that's a cool idea. But that's not how standards work.
> You cannot just insert things at random points in low-level config
> files or protols. How do you think this would work?
> You insert "$tuned_params", I insert "{tuned_params}", and GNU people
> inser
Adam Williamson wrote:
> specifically, for releases past the Beta freeze point, *all* updates
> require +2 karma to be pushed stable before the minimum wait. That is,
> if you want your non-critpath update to go stable sooner than 7 days
> after it reached testing, it needs +2 karma. For critpath,
Kevin Kofler via devel wrote:
> When was this decided? I only remember FESCo ever having decided to
> require +2 for critpath updates, not for non-critpath ones.
>
> At some point, those values were written down in the documentation, but
> under what authority? Where was the FES
Kevin Kofler via devel wrote:
> PS: I suspect the documentation was actually just an attempt to document
> the previous broken Bodhi policy implementation. (See
> https://github.com/fedora-infra/bodhi/issues/772 and
> https://github.com/fedora-infra/bodhi/issues/1033 – both got close
Vitaly Zaitsev via devel wrote:
> On 16/12/2024 21:43, Aoife Moloney via devel-announce wrote:
>> removed support for GPU Generations prior to the
>> 12th Gen GPUs. This effectively means that any hardware released
>> before 2020 is no longer supported for OpenCL and oneAPI workloads.
>
> If it re
Mikel Olasagasti wrote:
> Go-SIG has raised a ticket with FESCo [1] to propose a significant
> shift in Fedora's packaging approach for Go dependencies: moving to
> vendoring/bundling by default. This would represent a major departure
> from our current guidelines [2].
I am opposed to this. Bundli
Mario Torre wrote:
> OpenJDK 11 is EOL in Fedora regardless of the Fedora version, it hasn’t
> been updated in January for example.
This is entirely unacceptable. The package shipped with Fedora 41, so it
MUST get security backports until the Fedora 41 EOL. If the maintainers do
not want to take
Adam Williamson wrote:
> The situation in the old code was actually rather more complicated, and
> weird, than "the non-settable threshold was fixed to the wrong value" -
> there were multiple check functions that applied different logic to
> different operations, which is why you could sometimes p
Björn Persson wrote:
>> == Release Notes ==
>> The /etc/pki/tls/cert.pem file has been deprecated
>
> Removed, not deprecated, according to the rest of the proposal.
> Sysadmins who read "deprecated" in the release notes will think they
> can upgrade Fedora and look into migrating off /etc/pki/tls
Mario Torre wrote:
> On Tue, Feb 11, 2025 at 2:11 AM Kevin Kofler via devel
> wrote:
>>
>> Mario Torre wrote:
>> > OpenJDK 11 is EOL in Fedora regardless of the Fedora version, it hasn’t
>> > been updated in January for example.
>>
>> This is
Cristian Le via devel wrote:
> Coming back to `LIB_SUFFIX` and `*_INSTALL_DIR`, those should have never
> been added globally [2]
Why not?
LIB_SUFFIX might not be standard, but is used across many projects and has
clear semantics. If the project does not use it, it will just ignore it. So
why r
Kevin Fenzi wrote:
> On Wed, Apr 09, 2025 at 03:35:06PM -0400, Eduard Lucena wrote:
>> Can we go ahead in time and let kevin to create the gdm-x11 package? We
>
> Sure, if he wants to?
I do not currently have plans to introduce that package, though I would
encourage people who care enough about
Dominik 'Rathann' Mierzejewski via devel wrote:
> It has been mentioned in various places [1][2] that GDM has dropped
> support for running X11 session in F42. However, I cannot find the
> corresponding Change in the F42 Change list [3]. Has this been done
> without raising a Change? If yes, I'd ar
Nishant Mishra wrote:
> It's all good but then in Plasma also you can install X11 session
Yes, but only because *I* packaged kwin-x11 and plasma-workspace-x11
separately and went through a long argument in the FESCo issue tracker with
the KDE SIG trying to block me from introducing those 2 packa
Benson Muite wrote:
> enchant still uses it:
> https://src.fedoraproject.org/rpms/enchant2/blob/rawhide/f/enchant2.spec
But Enchant is an abstraction layer that can be built without the aspell
backend, which…
> Other dependencies on f41 are limited:
> enchant-aspell
… as you can see, is a speci
Cristian Le via devel wrote:
> It would be unfair to require upstream to support that pattern when
> CMake does not provide the tools to do so (I know about approaches with
> $ and configure_package_config_file(PATH_VARS), but
> these are not easy to adapt and support for older versions).
if(IS_AB
Sérgio Basto via devel wrote:
> "It is being explicitly dropped from GDM as the code to X11 greeter
> mode is also tied to supporting X11 sessions. If you want to
> use X11 sessions, you need to use something else. "
>
https://lists.pagure.io/archives/list/devel@lists.fedoraproject.org/thread/7RLN
Neal Gompa wrote:
> You need to switch to another display manager, as GDM no longer
> supports X11 sessions.
Time to fork GDM.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@
Kevin Fenzi wrote:
> Ideally things would just be more resistant to being able to make the
> mistakes in the first place, but sometimes thats not easy to do.
As far as I can see, things are quite resistant already considering that the
gating has blocked this from going into Rawhide. :-)
If this
Jared K. Smith wrote:
> On Wed, Apr 9, 2025 at 12:59 PM Kevin Kofler via devel <
> devel@lists.fedoraproject.org> wrote:
>
>> This crusade against X11 in Fedora needs to stop NOW!
>>
>
> I'm not involved in this change -- but I take exception to your l
Nishant Mishra wrote:
> Do you know you still can use X11 sessions on Gnome on Fedora by
> installing the X Packages? This does not mean that X11 support has
> completely been dropped !
Only by using an alternate display manager, and GNOME is known for not
supporting some functionality if GDM is
Samuel Sieb wrote:
> On 2/22/25 6:50 PM, Benson Muite wrote:
>>
>> Fedora has a policy to support only one kernel. Projects such as
>> OpenHarmony support multiple kernels to enable reuse of components on
>> devices with a wide range of compute capabilities - in particular mobile
>> and edge devi
Leigh Scott wrote:
>> == Benefit to Fedora ==
>> * The size of the default wallpaper is drastically reduced when using
>> JXL format compared to PNG. An example is on this [Fedora 42 Default
>> Wallpaper
>> ticket](https://gitlab.com/fedora/design/team/release-artwork/default-wallpaper/-/is...)
>>
Orion Poplawski wrote:
> I did come across this:
>
> https://reviews.llvm.org/D32668
>
> which seems promising, but not sure I'll be able to adapt that to
> SuiteSparse or not.
That looks like the right approach in any case: export the static targets to
a separate file and include that file w
Chris Adams wrote:
> Given the questionable changes made to X.Org by the lead (only?)
> developer of X11Libre before being removed from the project, including
> possible license violations
The "license violations" are actually moving a few lines of mostly trivial
declarations from one header file
Leigh Scott wrote:
> x264 is superior for playback,
Playback in the FFmpeg/libx264 stack is actually done by a builtin decoder
in FFmpeg, NOT by libx264. FFmpeg has no builtin H.264 encoder. libx264 has
no decoder. So they have to be used together. (But both are actually more
featureful than th
Hi,
in the discussion about my now withdrawn change proposal, I found this
comment (by someone going by "PASRC") interesting:
https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/x-org-drm/1555670-fedora-s-fesco-to-decide-whether-to-replace-upstream-x-org-server-with-xlibre-fork/pa
Michal Ruprich wrote:
> I've re-added the original wget as wget1 in Rawhide
Thanks a lot!
> wget binary is provided by wget1-wget subpackage.
IMHO, this should be the default. wget2 should be installed as wget2, not as
wget. It should never have been installed as wget to begin with, because it
Peter Robinson wrote:
> This and other details have been outlined in updates to devel-announce:
>
> https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/thread/CKIQPKWLISZNJZWWFFWVDENBUGHJW6R7/
>
> If you're not on devel-announce it's likely worthwhile and a mode
Jelle van der Waa wrote:
> I just want to point out that this is completely false, Anubis does not
> break search engines they are allowlisted to go through without a
> challenge. Only the useragents with "Mozilla" in them are being "checked".
Is that not configuration-dependent? Checking only use
Kevin Kofler via devel wrote:
> Why should they? Anubis is a scourge that wastes massive energy for all
> legitimate browsers, breaks search engines, and if configured in a
> particularly aggressive way as on the GNOME GitLab, even entirely locks
> out some browsers (though that is a
Mateus Rodrigues Costa wrote:
> Important: Secure Boot certificates used by most Windows devices are
> set to expire starting in June 2026.
Ouch! Yet another epic Microsoft FAIL. Setting an expiry date (ANY expiring
date) on this sort of signing key, which gets embedded into all sorts of
firmwar
Neal Gompa wrote:
> But those are hand-written directives, no? That approach doesn't scale at
> all.
Handwritten unwinding information for handwritten assembly. C code has
compiler-generated unwinding information.
Kevin Kofler
--
___
devel ma
Solomon Peachy via devel wrote:
> Also, the numbers are purely *GPU* load, ignoring the rest of the system
> (eg the CPUs). Given that Wayland was designed to offload *more* work
> onto the GPU, a higher GPU load in of itself isn't surprising.
There (from the same author, I am only linking to his
Leigh Scott wrote:
> Why isn't fedora infra using Anubis to block LLM scrappers?
Why should they? Anubis is a scourge that wastes massive energy for all
legitimate browsers, breaks search engines, and if configured in a
particularly aggressive way as on the GNOME GitLab, even entirely locks out
> Wiki - https://fedoraproject.org/wiki/Changes/X11Libre
Considering the overwhelmingly negative feedback, **I am hereby withdrawing
this Change proposal**.
The reasoning is twofold:
1. I have always argued that Changes that are overwhelmingly rejected by the
community should not be approved by
Hi,
this benchmarks has some performance metrics for the same desktop
environment (Plasma 6.4) using Wayland vs. X11:
https://www.dedoimedo.com/computers/plasma-6-4-performance-wayland-x11-comparison.html
As you can see, X11 is faster and consumes fewer resources. (And that is
with X11 composit
Hi,
while packaging GTK 4.19.2 with the GLES2 patchset from my GitHub fork, I
ran into a file list error, which made me stumble upon this upstream GTK
commit:
https://github.com/GNOME/gtk/commit/e8694e0e7f71aa2e1a3ac4299ab675170a051145
(I am linking to the GitHub mirror because the GNOME GitLab
Erico Nunes wrote:
> This is on the Asahi FAQ, so I think Asahi in particular is not going to
> be a convincing argument and use case:
> https://asahilinux.org/docs/project/faq/#i-am-having-performancetearingfeature-issues-on-xorg
But that is exactly what the user claims X(11)libre fixed for them.
Leigh Scott wrote:
> Are you going to submit x11libre for package review without the obsoletes
> and provides?
Currently, I am rather thinking of just putting up a Copr, with
Obsoletes/Provides for seamless migration, but one has to dnf copr enable
the Copr to opt in to begin with.
Shipping par
Hi,
look at those benchmark results:
https://www.phoronix.com/review/framework-12-linux-os/7
As you can see, Fedora and Ubuntu, which both decided to enable frame
pointers distrowide, are at the absolute bottom of this benchmark. The
competition performs at least 5% better, up to 10% better for
Am Freitag, 25. Juli 2025 04:07:24 CEST schrieb Michel Lind:
For frame pointers, this might be a better comparison -- RHEL 10 vs
Rocky 10 vs Alma 10. The former two don't have frame pointers enabled,
the latter does. As you can see the performance is within margins of
error - Alma is not consiste
901 - 969 of 969 matches
Mail list logo
