Re: F41 Change Proposal: Switch to DNF5 (system-wide)

[Jan Kolarik]

Hi guys,

the dnf-automatic command will be obsoleted.
>

Oh, sorry about that. This portion of the text was inadvertently altered
during the review process. I've already corrected the text on the wiki.

The dnf-automatic command will still be available, now provided as a plugin
and functionally compatible with dnf4. Although the configuration files'
location has changed, it will be documented in the dnf4 vs. dnf5 changes
documentation .

Thanks,
Jan

On Thu, Apr 4, 2024 at 12:06 AM Kevin Fenzi  wrote:

> On Wed, Apr 03, 2024 at 11:57:48AM -0700, Adam Williamson wrote:
> > On Wed, 2024-04-03 at 14:27 -0400, Przemek Klosowski via devel wrote:
> > > On 4/3/24 06:36, Aoife Moloney wrote:
> > > > the dnf-automatic command will be obsoleted.
> > >
> > > https://dnf5.readthedocs.io/en/latest/changes.html does not say
> anything
> > > about automatic updates, and
> > >
> > > https://packages.fedoraproject.org/pkgs/dnf5/dnf5-plugin-automatic/
> > >
> > > simply suggests that dns update be executed from systemd timers or
> cron
> > > jobs.
> > >
> > >
> > > dns-automatic provided a simple interface to a setup-and-forget
> > > automatic updates; will DNF5 leave it to be set up by hand?
> > >
> > > I am asking because systemd timers have surprising behavior for
> > > suspendable systems, which leads to problems if updates are scheduled
> > > for off-hours.
> > >
> > > My experience is that even |WakeSystem=true does not make them
> reliable,
> > > but I am not sure how to debug this (because the system is suspended,
> heh).
> > >
> >
> > We do use dnf-automatic quite extensively within infra, I think. Has
> > this been discussed with infra?
>
> Not that I know of. Yes, we do use dnf-automatic all over the place. ;(
>
> kevin
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Naheem Zaffar]

On Tue, 2 Apr 2024 at 10:40, Aoife Moloney  wrote:

> Wiki - https://fedoraproject.org/wiki/Changes/FedoraPlasmaWorkstation
>
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if approved
> by the Fedora Engineering Steering Committee.
>
> == Summary ==
> Switch the default desktop experience for Workstation to KDE Plasma.
> The GNOME desktop is moved to a separate spin / edition, retaining
> release-blocking status.
>
> == Owner ==
>
> * Names: [[User:joshstrobl | Joshua Strobl]], [[User:marcdeop | Marc
> Deop i Argemí]], [[User:tdawson | Troy Dawson]], [[User:farchord |
> Steve Cossette]], [[User:aleasto| Alessandro Astone]]
> * Emails: jos...@buddiesofbudgie.org, marcd...@fedoraproject.org,
> tdaw...@redhat.com, farch...@gmail.com, alea...@fedoraproject.org
>
> == Detailed Description ==
>
> With the release of Plasma 6, KDE Plasma has developed into a high
> quality, well-regarded desktop experience.
>
> === Improved end user experience ===
>
> Plasma has been at the forefront of creating a cohesive desktop
> platform that empowers the user to have full ownership of their
> computing experience.
>
> Plasma provides this approachable, highly-flexible, user-extensible
> experience with predictability across Plasma releases. Unlike other
> desktop experiences such as GNOME Shell, the APIs leveraged by Plasma
> applets / widgets have been more stable across “minor” Plasma
> releases, reducing long-term user frustration and promoting a
> healthier ecosystem for developers and users alike.
>
> This extensibility additionally applies to the underlying window
> manager, KWin, with effects and scripts that provide both utility and
> personalization, such as:
>
> * Automatically blocking compositing for full screen applications
> * Fun effects such as window glitch and portals
>
> Plasma provides a more traditional user experience that could be
> viewed as being more approachable to everyday computing users, serving
> as a smoother "on-ramp" to using Linux-based operating systems.
> Alongside its wide breadth of personalization capabilities, it
> provides an out-of-the-box desktop experience that is more predictable
> than some of its counterparts. As an example, Plasma provides a system
> tray for applications supporting StatusNotifierItem (e.g. Flameshot,
> OBS Studio, VPN clients), which is not functionality supported by
> default in GNOME Shell and requires an extension which may break
> between releases.
>
> === Standardization support ===
>
> The KDE community has a long heritage of collaborative standards
> development and supporting capabilities that application developers
> and users need for a productive experience.
>
> KDE is heavily involved in the development of cross-desktop standards
> and tools that benefit the larger open source desktop community. From
> the XDG icon theme specification to D-Bus to StatusNotifierItems and
> Wayland protocols, KDE has been front and center for evolving the
> Linux desktop platform in a manner that benefits the wider community.
>
> Many of the specifications and protocols in use today originate or are
> heavily influenced by KDE, and KDE has continued to be a bastion of
> innovation in a user-centric and community-centric manner.
>
> Notably, the following recent Wayland protocols have been driven or
> influenced by KDE:
>
> * xdg-toplevel-drag (dragging tabs in and out of windows)
> * content-type
> * drm-lease (enable applications to selectively gain privileged
> display device access)
> * tearing-control (enable faster than display framerate refreshing, ie
> no “vsync lock”)
> * ext-idle-notify
> * xdg-activation (enable notifications to bring a window to the
> foreground on user activation)
> * xdg-decoration (server side decorations, derived from KDE’s protocol)
>
> There are several upcoming protocols being driven by KDE as well, such as:
>
> * alpha-modifier (set alpha values for a surface)
> * ext-blur (enable blur effect underneath a surface)
> * xdg-toplevel-icon (enable applications to set window icons)
> * ext-placement (allow application window positioning)
> * window-id (consistent, uniform method window IDs)
> * xdg-pip (picture in picture overlays)
> * dbus-annotation (link D-Bus objects to surfaces)
>
> This demonstrates that KDE works not to just enable new technologies
> and features for Plasma Wayland, but they also do it in a way that
> drives larger community adoption, success, and growth.
>
> === Wayland support ===
>
> KDE Plasma offers the most advanced Wayland desktop experience today,
> providing support for highly-demanded features, such as:
>
> * Fractional scaling
> * Color management
> * Variable Refresh Rate for capable displays
> * Support for optionally allowing legacy X11 applications to access
> desktop resources
> * Screensharing for legacy applications
> * Global shortcut support for 

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Gerald B. Cox]

From what I've been reading it seems the path of least resistance is to just 
keep the Fedora Workstation branding and have two options:  GNOME or KDE 
Plasma.  I don't believe that it should be overly confusing to ask people to 
pick one.  I just asked Google Gemini to come up with a suggestion and here is 
the output.  Obviously, the AI output can be improved, but at least to me, it 
seems fairly straightforward:

<<>>

Here's how to communicate the option between GNOME and KDE on Fedora 
Workstation's webpage:

Headline:

Choice & Control: Choose Your Fedora Workstation Experience
Power Up Your Desktop: GNOME or KDE Plasma for Fedora

Body:

Fedora Workstation Now Offers a Choice: For the first time, you can choose 
between the streamlined GNOME desktop or the highly customizable KDE Plasma 
desktop during Fedora Workstation installation.

Find Your Perfect Fit: Whether you prefer a clean and user-friendly experience 
(GNOME) or a feature-rich and adaptable desktop (KDE Plasma), Fedora 
Workstation has you covered.

Seamless Switching (Optional): Briefly mention the ability to install both 
environments later, but emphasize the ease of choice during installation.

Icons/Visuals:
Use visuals that showcase the strengths of each desktop. A clean and modern 
image for GNOME and a feature-rich, customizable image for KDE Plasma.

Call to Action:

Download Fedora Workstation Now! (with clear links)

Learn More About GNOME & KDE Plasma (with links to informative pages)

Keep it Simple:
Avoid technical jargon. Focus on the user experience benefits of each desktop.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: activemq-cpp in epel8

[Jonathan Wright via epel-devel]

Managed to get this packed up.  Now we just wait for the peer review from
another packager.

https://bugzilla.redhat.com/show_bug.cgi?id=2273288

On Wed, Apr 3, 2024 at 10:01 AM Jonathan Wright 
wrote:

> Evan,
>
> I will look into this.  Looks like it was retired years ago for failing to
> build: https://bugzilla.redhat.com/show_bug.cgi?id=1674632
>
> It will have to be re-reviewed since it was retired/orphaned more than 6
> weeks ago so a reasonable timeframe to (potentially) get it back into repos
> and EPEL8 is a 2-6 weeks depending on how quickly a reviewer will pick it
> up, and if it will build against modern versions of Fedora/RHEL.
>
> On Wed, Apr 3, 2024 at 9:57 AM Ward, Evan M CIV USN NRL (8112) Washington
> DC (USA) via epel-devel  wrote:
>
>> Hi,
>>
>> Are there any packagers who would like to package activemq-cpp in
>> epel8? It's already in epel7.
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=2244652
>>
>> Regards,
>> Evan Ward
>> --
>> ___
>> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
>> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
>> Do not reply to spam, report it:
>> https://pagure.io/fedora-infrastructure/new_issue
>>
>
>
> --
> Jonathan Wright
> AlmaLinux Foundation
> Mattermost: chat 
>


-- 
Jonathan Wright
AlmaLinux Foundation
Mattermost: chat 
--
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

translation update for a build package

[Sundeep Anand]

Hi,

Transtats calculates translation statistics of the packages recently build in 
koji. (a background process)
How should this data be made available for other apps to consume?
(what could be better approaches to integrate)

Its in development - transtats.stg.fedoraproject.org publishes to 
fedora_messaging.

thanks
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Gordon Messmer]

On 2024-04-03 14:27, Kevin Kofler via devel wrote:

I am not sure I buy this argument. By the same argument, we should also not
call the OS "Fedora Linux" because it implies there is also a "Fedora BSD"
or "Fedora Hurd" or even "Fedora Windows"  or something.



Personally, I think the reason we should not call the OS "Fedora Linux" 
is that the trademark guidelines for the term "Linux" specifically say 
not to:


"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."


https://www.linuxfoundation.org/legal/the-linux-mark

My opinion is that Fedora should be setting a good example for others to 
follow, and this is an area where it does not, currently.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Kilian Hanich via devel]

Am 04.04.24 um 03:00 schrieb Gordon Messmer:

I think this gets to the heart of the issue.  If we set aside subjective
arguments about which desktop is better or more popular, only one of
these desktops allows Fedora to publish a stable operating system which
is a coherent whole, because only one of them has a release cycle that
aligns with Fedora's.  The other desktop's release cycle does not align,
which means that a significant component of the system rebases in the
middle of a release, which undermines the fundamental concept of a
stable release.


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).


Kilian
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Gordon Messmer]

On 2024-04-03 11:35, 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/).



I think this gets to the heart of the issue.  If we set aside subjective 
arguments about which desktop is better or more popular, only one of 
these desktops allows Fedora to publish a stable operating system which 
is a coherent whole, because only one of them has a release cycle that 
aligns with Fedora's.  The other desktop's release cycle does not align, 
which means that a significant component of the system rebases in the 
middle of a release, which undermines the fundamental concept of a 
stable release.


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 application 
that will not run because that application actually depends on newer 
versions of dependencies than are installed on the system.  If a 
significant portion of the standard desktop regularly rebased in the 
middle of a release, I expect that would be a more common problem.


--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Kilian Hanich via devel]

Am 04.04.24 um 01:46 schrieb Sam Varshavchik:

This is not going to happen.

There's going to be someone else, sitting next to them, who will be
teaching the new user how to use a computer. And that someone will
/also/ be familiar with traditional desktop concepts and paradigms.
They, like the new user, will also expect to have a traditional desktop
in front of them, that works like a traditional desktop.


Sure, but in a lot of cases that other person is a teacher, with a lot
of other children needing attention too. That means you have one
experience user vs (depending on country) 10 to 50 new users.


Kilian
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Kilian Hanich via devel]

Am 04.04.24 um 01:03 schrieb Kevin Kofler via devel:

You make a good point there. The thing is, GNOME tries really hard to design
for new users, whom they define as a user who has never before used a
computer. Such users are basically on the edge of extinction. A paradigm
that works great for someone seeing a computer for the first time in their
life does not necessarily work all that great for someone trained to use
different paradigms used in the operating system(s) they have used for
decades.


Most new Desktop users these days have prior experience of using a
smartphone or maybe even a tablet. That funnily enough has the side
effect that a lot of them try to touch the screen when they use a
Desktop for the first time. As you can maybe imagine, these people are
very young.

Now, some people would argue that Gnome is a good design for a DE for
people expecting something like a smartphone UI but made good for a
Desktop, some people say the opposite. Personally I think it's a
tradeoff. There are equally as many (and strong) arguments for and
against it.


Regards

Kilian Hanich
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Leon Fauster via devel]

Am 04.04.24 um 00:44 schrieb Kevin Kofler via devel:

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 configurable back then. Remember when it
shipped Enlightenment as the window manager, how many options that had?)
Then GNOME 2 came, removing much of the configurability of GNOME 1. And then
GNOME 3 came, removing AGAIN much of the remaining configurability of GNOME
2, leading to a very hardcoded experience. GNOME 2 was already too much for
me, and I switched back to KDE, back because I had already tried KDE 1.1.1
on another distro. And I have never looked back.



Honestly, I know both worlds of the desktop environment paradigms. 
Therefore I do not compare these two because its pointless. Both follow

some design principles and addresses different goals. If KDE do expose
some knobs to configure something in the UI, its fine. I prefer Gnome
because its more tidier (no diving into dconf/gsettings possibilities).
For the proposal: both DEs are legit, one should not substitute the other.



Well, actually, I wanted to be fair and give GNOME 3 a chance, so I tried it
out once. But it took less than 10 minutes for me to realize that it is not
for me. The user experience is just too unfamiliar (the unified application
menu and open window selector (launch menu AND task bar replacement), the
always maximized windows, the lack of a system tray, the shut down options
in the mouse menu hidden behind a keyboard dead key, etc.), and GNOME does
not make it easy for you to change it. (You can actually get a pretty
standard desktop experience nowadays if you install a lot of "unbreak this",
"unbreak that" GNOME Shell extensions, but that kinda defeats the point of
GNOME.) The default experience felt pretty much unusable to me personally.



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

framework where this can happen.



KDE Plasma not only has more familiar defaults (actually looking and feeling
much more similar to GNOME 1 than GNOME 3 does), but also lets you easily
change those defaults that you do not like.




PS: Imagine the first CLI steps and the corresponding bad
experience, but we have not given up :-)!

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Sam Varshavchik]

Kevin Kofler via devel writes:


You make a good point there. The thing is, GNOME tries really hard to design
for new users, whom they define as a user who has never before used a
computer.


So, someone who never used at a computer before sits down in front of a new,  
empty, Gnome desktop, and it is expected that they'll take to it like a fish  
takes to water?


I doubt that very much.

Besides, there's a fatal flaw in this hypothetical scenario.

No such person could possibly exist. A completely new to computers user is  
not going to be sitting down in front of a new desktop, all by themselves.  
Without anyone else in the picture.


This is not going to happen.

There's going to be someone else, sitting next to them, who will be teaching  
the new user how to use a computer. And that someone will /also/ be familiar  
with traditional desktop concepts and paradigms. They, like the new user,  
will also expect to have a traditional desktop in front of them, that works  
like a traditional desktop.


And that was the fatal flaw in the grand experiment called "Gnome 3".



pgpI4t7CKKvbD.pgp
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Kevin Kofler via devel]

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 or
> ChromeOS worlds, and (hopefully) those paradigms aren't sufficiently
> different from MacOS to be too uncomfortable for a user coming from the
> Apple world.

You make a good point there. The thing is, GNOME tries really hard to design 
for new users, whom they define as a user who has never before used a 
computer. Such users are basically on the edge of extinction. A paradigm 
that works great for someone seeing a computer for the first time in their 
life does not necessarily work all that great for someone trained to use 
different paradigms used in the operating system(s) they have used for 
decades.

As you point out, for users switching from a different operating system, 
which is a much more likely scenario, the GNOME Shell design is really 
confusing and disruptive, and GNOME's reluctance to make it easy to switch 
some things back (instead requiring you to install shell extensions for any 
such change) does not help. Even if the other operating systems' patterns 
happen to be counterintuitive if you have never seen them before, once 
trained to them, you will not only be able to work efficiently with them, 
but also be confused by GNOME's intuitive design that they carefully 
usability-tested on people with little to no computer experience.

That leaves GNU/Linux power users who have used nothing but GNU/Linux for 
decades. I am in that category, like many regulars of this mailing list. 
(Well, I am particularly extreme in that even my smartphone runs GNU/Linux, 
but that is a different story.) And I would argue that GNOME is also a very 
bad default for users in that category because of its deliberate lack of 
configurability. Not to mention that the same (concept familiarity) concerns 
applying to people switching from other operating systems also apply to 
people switching from any other GNU/Linux desktop environment. Personally, 
when I tried GNOME 3 once, it took me less than 10 minutes to decide that 
this is just completely unusable for me personally.

So I think it is pretty clear that we do NOT "have two equally good options" 
as Adam Williamson wrote (in the post to which you were replying).

Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: "fedpkg local" builds fail for rust packages

[Philip Matura via devel]

On Thu, Apr 04, 2024 at 12:03:56AM +0200, Fabio Valentini wrote:
> On Wed, Apr 3, 2024 at 11:47 PM pfed--- via devel
>  wrote:
> >
> > Maybe we could add the `--allow-dirty` to the `%cargo_install` macro -
> > from the top of my head this should not break anything, but I'm not
> > sure. There does not seem to be a general "ignore-git" option for cargo.
> >
> > Or are there other ways to get this to work?
> 
> The short answer is: No, "fedpkg local" is not expected to work for
> Rust packages, and probably won't ever work as expected for Rust
> packages.
> 
> I am not really interested in adding the "--allow-dirty" flag (not
> sure if it would even work in this case), since building Rust packages
> with "fedpkg local" is not working for other reasons. Primarily,
> "fedpkg local" does not support dynamically generated BuildRequires -
> this is only supported when building in mock.

I don't know what you mean? For me after patching the macro locally
local builds work as expected. Maybe I'm overlooking something?

Philip Matura
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Kevin Kofler via devel]

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 configurable back then. Remember when it 
shipped Enlightenment as the window manager, how many options that had?) 
Then GNOME 2 came, removing much of the configurability of GNOME 1. And then 
GNOME 3 came, removing AGAIN much of the remaining configurability of GNOME 
2, leading to a very hardcoded experience. GNOME 2 was already too much for 
me, and I switched back to KDE, back because I had already tried KDE 1.1.1 
on another distro. And I have never looked back.

Well, actually, I wanted to be fair and give GNOME 3 a chance, so I tried it 
out once. But it took less than 10 minutes for me to realize that it is not 
for me. The user experience is just too unfamiliar (the unified application 
menu and open window selector (launch menu AND task bar replacement), the 
always maximized windows, the lack of a system tray, the shut down options 
in the mouse menu hidden behind a keyboard dead key, etc.), and GNOME does 
not make it easy for you to change it. (You can actually get a pretty 
standard desktop experience nowadays if you install a lot of "unbreak this", 
"unbreak that" GNOME Shell extensions, but that kinda defeats the point of 
GNOME.) The default experience felt pretty much unusable to me personally.

KDE Plasma not only has more familiar defaults (actually looking and feeling 
much more similar to GNOME 1 than GNOME 3 does), but also lets you easily 
change those defaults that you do not like.

Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F41 Change Proposal: Switch to DNF5 (system-wide)

[Kevin Fenzi]

On Wed, Apr 03, 2024 at 11:57:48AM -0700, Adam Williamson wrote:
> On Wed, 2024-04-03 at 14:27 -0400, Przemek Klosowski via devel wrote:
> > On 4/3/24 06:36, Aoife Moloney wrote:
> > > the dnf-automatic command will be obsoleted.
> > 
> > https://dnf5.readthedocs.io/en/latest/changes.html does not say anything 
> > about automatic updates, and
> > 
> > https://packages.fedoraproject.org/pkgs/dnf5/dnf5-plugin-automatic/
> > 
> > simply suggests that dns update be executed from systemd timers or cron 
> > jobs.
> > 
> > 
> > dns-automatic provided a simple interface to a setup-and-forget 
> > automatic updates; will DNF5 leave it to be set up by hand?
> > 
> > I am asking because systemd timers have surprising behavior for 
> > suspendable systems, which leads to problems if updates are scheduled 
> > for off-hours.
> > 
> > My experience is that even |WakeSystem=true does not make them reliable, 
> > but I am not sure how to debug this (because the system is suspended, heh).
> > 
> 
> We do use dnf-automatic quite extensively within infra, I think. Has
> this been discussed with infra?

Not that I know of. Yes, we do use dnf-automatic all over the place. ;( 

kevin


signature.asc
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: "fedpkg local" builds fail for rust packages

[Fabio Valentini]

On Wed, Apr 3, 2024 at 11:47 PM pfed--- via devel
 wrote:
>
> Maybe we could add the `--allow-dirty` to the `%cargo_install` macro -
> from the top of my head this should not break anything, but I'm not
> sure. There does not seem to be a general "ignore-git" option for cargo.
>
> Or are there other ways to get this to work?

The short answer is: No, "fedpkg local" is not expected to work for
Rust packages, and probably won't ever work as expected for Rust
packages.

I am not really interested in adding the "--allow-dirty" flag (not
sure if it would even work in this case), since building Rust packages
with "fedpkg local" is not working for other reasons. Primarily,
"fedpkg local" does not support dynamically generated BuildRequires -
this is only supported when building in mock.

I wonder if "fedpkg local" shouldn't just error out when attempting to
build spec files that use %generate_buildrequires ...

Fabio
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Aaron Rainbolt]

On 4/3/24 16:49, Kevin Kofler via devel wrote:

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 looking at the several dozen ips
which were downloading  the same spin every ten minutes). The countme
stats for 'running' systems
https://data-analysis.fedoraproject.org/csv-reports/countme/ can probably
give you the data on number of active systems.

Countme stats do not tell you though how many of those users actually
downloaded their Edition from fedoraproject.org vs. getting it preinstalled
by some cloud/VPS/dedicated server provider. If people are not going to
fedoraproject.org to download, say, the Cloud Edition or the Server Edition,
then it is pointless to feature that particular Edition prominently on
fedoraproject.org. That is why I was asking for download statistics
specifically.

And is there a statistical evaluation of that data somewhere? Downloading
350 MiB (!) of raw CSV data does not sound to me like a convenient way to
work with it.
Challenge accepted. Will reply with something of an analysis in a bit 
hopefully :)


   Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


--
Aaron Rainbolt
Lubuntu Developer
Matrix: @arraybolt3:ubuntu.com
IRC: arraybolt3 on libera.chat and oftc.net
GitHub: https://github.com/ArrayBolt3
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Kevin Kofler via devel]

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 looking at the several dozen ips
> which were downloading  the same spin every ten minutes). The countme
> stats for 'running' systems
> https://data-analysis.fedoraproject.org/csv-reports/countme/ can probably
> give you the data on number of active systems.

Countme stats do not tell you though how many of those users actually 
downloaded their Edition from fedoraproject.org vs. getting it preinstalled 
by some cloud/VPS/dedicated server provider. If people are not going to 
fedoraproject.org to download, say, the Cloud Edition or the Server Edition, 
then it is pointless to feature that particular Edition prominently on 
fedoraproject.org. That is why I was asking for download statistics 
specifically.

And is there a statistical evaluation of that data somewhere? Downloading 
350 MiB (!) of raw CSV data does not sound to me like a convenient way to 
work with it.

  Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

"fedpkg local" builds fail for rust packages

[pfed--- via devel]

Hi all,

I like using `fedpkg local` builds to speed up testing of packaging, but
now encountered a problem trying to package a rust program for the first
time. It turns out a local build fails in the install step for all rust
packages (that I tried out) with an error like

error: 152 files in the working directory contain changes that were not yet 
committed into git:
[ ... file list ... ]
to proceed despite this and include the uncommitted changes, pass the 
`--allow-dirty` flag

The problem is the line

/usr/bin/env CARGO_HOME=.cargo RUSTC_BOOTSTRAP=1 RUSTFLAGS='-Copt-level=3 
-Cdebuginfo=2 -Ccodegen-units=1 -Cstrip=none -Cforce-frame-pointers=yes 
-Clink-arg=-specs=/usr/lib/rpm/redhat/redhat-package-notes --cap-lints=warn' 
/usr/bin/cargo package -l | grep -w -E -v 'Cargo.(lock|toml.orig)' | xargs -d 
'\n' /usr/bin/cp --parents -a -t $REG_DIR

coming from the `%cargo_install` macro, where `cargo package -l` is used
to generate the file list. Now, since `fedpkg local` builds inside a
subdirectory of the package repo, `cargo package` sees that it's
operating inside a git repo and issues the above warning, exiting
non-zero.

I know to work around this by using rpmbuild manually or testing with
mock builds all the time, but I think it would be great if local builds
would work, too.

Maybe we could add the `--allow-dirty` to the `%cargo_install` macro -
from the top of my head this should not break anything, but I'm not
sure. There does not seem to be a general "ignore-git" option for cargo.

Or are there other ways to get this to work?

Greetings,
Philip Matura
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Kevin Kofler via devel]

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 as Kubuntu is Ubuntu.
> (Though, I don't know about 'Kedora' as it has absolutely no meaning XD)
> Though I feel like we should really only go this route if the other ideas
> get completely exhausted...

That is what I tried with Kannolo. Success was… limited, to say the least.

Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Kevin Kofler via devel]

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 Workstation' would imply that there are 
other Workstations."

I am not sure I buy this argument. By the same argument, we should also not 
call the OS "Fedora Linux" because it implies there is also a "Fedora BSD" 
or "Fedora Hurd" or even "Fedora Windows" ;-) or something.

Giving a product a clear name does not imply existence of another product.

(And that is not even arguing the premise of the "one single Workstation 
that happens to use GNOME" concept, only the branding implications!)

> One of the best things with Fedora Workstation is that it is a complete
> user facing OS (like Windows, macOS and iOS) that you actually can develop
> applications for (if you want to). You don't have to target the extremely
> fluffy "Linux desktop", you can target Fedora Workstation. This proposal
> would totally eliminate the good points of having this single OS and app
> platform.

That "conveniently" ignores the existence of that pesky thing called "other 
distributions". The GNU/Linux version of vendor lock-in. Thanks Red Hat!

And besides, a standalone application (as opposed to a desktop widget or 
similar) developed for one of the Fedora desktop deliverables (Workstation 
Edition, desktop Spins) is also going to work on any of the others.

Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Stephen Smoogen]

On Wed, 3 Apr 2024 at 17:03, Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:

> 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


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 looking at the several dozen ips
which were downloading  the same spin every ten minutes). The countme stats
for 'running' systems
https://data-analysis.fedoraproject.org/csv-reports/countme/ can probably
give you the data on number of active systems.


>
> users. And server or cloud users will mostly install Fedora by picking
> "Fedora" in a combo box at their commercial cloud, VPS, and/or dedicated
> server provider's web interface, not from fedoraproject.org. I would be
> surprised if the percentage of users both running a home server or a
> private
> cloud (as opposed to a hosted commercial offering in a remote datacenter)
> AND picking Fedora as the OS to run on it (as opposed to a more
> conservative
> OS such as Rocky/Alma or Debian stable) were significant. CoreOS is also
> mostly a server thing, desktop users get pointed to Atomic Desktop
> variants
> (Silverblue/Kinoite/"… Atomic") instead. And IoT is just completely niche.
> So why do you expect those Editions to be more relevant to users
> downloading
> Fedora from fedoraproject.org than the Spins?
>
> Kevin Kofler
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Kevin Kofler via devel]

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. And server or cloud users will mostly install Fedora by picking 
"Fedora" in a combo box at their commercial cloud, VPS, and/or dedicated 
server provider's web interface, not from fedoraproject.org. I would be 
surprised if the percentage of users both running a home server or a private 
cloud (as opposed to a hosted commercial offering in a remote datacenter) 
AND picking Fedora as the OS to run on it (as opposed to a more conservative 
OS such as Rocky/Alma or Debian stable) were significant. CoreOS is also 
mostly a server thing, desktop users get pointed to Atomic Desktop variants 
(Silverblue/Kinoite/"… Atomic") instead. And IoT is just completely niche. 
So why do you expect those Editions to be more relevant to users downloading 
Fedora from fedoraproject.org than the Spins?

Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[CoreOS] Fedora CoreOS Community Meeting Minutes 2024-04-03

[Yasmin de Souza]

Minutes:
https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2024-04-03/epel.2024-04-03-16.30.html
Minutes (text):
https://meetbot-raw.fedoraproject.org//meeting-1_matrix_fedoraproject-org/2024-04-03/epel.2024-04-03-16.30.txt
Log:
https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2024-04-03/epel.2024-04-03-16.30.log.html

=
# #meeting-1:fedoraproject.org: epel
=

Meeting started by @ydesouza:fedora.im at 2024-04-03 16:30:37



Meeting summary
---
* TOPIC: roll call (@ydesouza:fedora.im, 16:30:54)
* TOPIC: Action items from last meeting (@ydesouza:fedora.im, 16:34:07)
* LINK: https://github.com/coreos/fedora-coreos-tracker/issues/859
(@siosm:matrix.org, 16:41:29)
* TOPIC: Join the Special Purpose Operating System Working Group (CNCF)
!link https://github.com/coreos/fedora-coreos-tracker/issues/1696
(@ydesouza:fedora.im, 16:51:36)
* TOPIC: F39 drops some firmware packages that provide wifi/BT firmware
!link https://github.com/coreos/fedora-coreos-tracker/issues/1575
(@ydesouza:fedora.im, 17:00:08)
* ACTION: dustymabe jbtrystram to meet to discuss implementation of
wifi firmwares warning/deprecation (@dustymabe:matrix.org, 17:18:27)
* AGREED: : implement wifi firmwares back for the F40 release and plan
the deprecation for at least 3 months after initial announcement on
coreos-status (@ydesouza:fedora.im, 17:30:56)
* INFO: test week for FCOS 40 is still going on
https://testdays.fedoraproject.org/events/179 (@dustymabe:matrix.org,
17:34:39)
* TOPIC: Open Floor (@ydesouza:fedora.im, 17:34:51)
* INFO: test week for FCOS 40 is still going on
https://testdays.fedoraproject.org/events/179 (@dustymabe:matrix.org,
17:35:05)
* TOPIC: aloha (@tdawson:fedora.im, 18:00:29)

Meeting ended at 2024-04-03 18:00:55

Action items

* dustymabe jbtrystram to meet to discuss implementation of wifi firmwares
warning/deprecation

People Present (lines said)
---
* @siosm:matrix.org (38)
* @ydesouza:fedora.im (35)
* @dustymabe:matrix.org (31)
* @jlebon:fedora.im (16)
* @zodbot:fedora.im (13)
* @fifofonix:matrix.org (8)
* @aaradhak:matrix.org (5)
* @tdawson:fedora.im (4)
* @meetbot:fedora.im (3)
* @jbtrystram:matrix.org (3)
* @mnguyen:fedora.im (3)
* @marmijo:fedora.im (2)
* @gurssing:matrix.org (2)
* @salimma:fedora.im (1)
* @jbrooks:matrix.org (1)
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Aaron Rainbolt]

On 4/3/24 13:56, Adam Williamson wrote:

On Wed, 2024-04-03 at 20:24 +0200, Marc Deop i Argemí wrote:

Let's assume that we all agree with what you stated ( and I personally partly
do).

Why do we promote Workstation (with Gnome) over any other alternative that
might arise? (in this case, a Fedora Workstation KDE)

It's an interesting question. I would say my answer is "because it
works better if we promote *something*". Forcing the choice on people
who just want "desktop Fedora" is awkward. The reason we default to
GNOME is because we ~always have. To me, this is a reasonable
justification. Change is always uncomfortable and disruptive. If you
have two equally good options and you already picked one, you should
stick with it, not just switch between them every so often for the sake
of it. If Plasma were demonstrably, markedly and uncontroversially
*superior* to GNOME (please don't take this as an excuse to start a
holy war, I am positing for the sake of this post that neither of the
two is demonstrably, markedly and uncontroversially better than the
other), the case would be different.


Obviously it's going to be hard to make a point for either of the 
desktops to be demonstrably (and especially uncontroversially!) better 
than the other in general, because there is no such thing. There are 
some situations where IceWM emerges as the absolute and clear winner 
above everything else, that doesn't mean that the world's greatest DE is 
IceWM. (Nor does it mean that IceWM is a DE but that's beside the point.)


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 or 
ChromeOS worlds, and (hopefully) those paradigms aren't sufficiently 
different from MacOS to be too uncomfortable for a user coming from the 
Apple world. GNOME is quite different from both, making a new user's 
first reaction to the desktop more likely to be one of "what on earth is 
going on, where is my taskbar? What happened to my minimize buttons? 
What happened to my application menus? Where is the Start button? How do 
I even turn off the computer?" That's not to say GNOME's paradigms are 
bad - indeed, once you know what you're doing, they provide a nice 
environment to work from. They're just really different for someone just 
coming to Linux.


That's not to say that the goal of any Linux distro should be to appear 
like Windows - no amount of effort will make Linux sufficiently close to 
Windows to be fully usable with zero learning curve to a Windows user. 
Trying too hard will just lead to confusion once a user digs deep enough 
in. But if the end goal is higher download rate and better user 
retention, giving the user a comfortable on-ramp into the new world of 
Linux will likely fulfill that goal better than having them immediately 
climb a mental cliff just to get started. The user will inevitably run 
into the fact that drive letters don't exist, apps don't come from 
random places on the Internet, new OS versions come out frequently, 
etc., *but* they'll be more confident and have a better foundation to 
work with if they have a semi-familiar workspace from which to learn all 
these things.


Currently the way Fedora Workstation attempts to overcome this initial 
learning curve with the desktop is by presenting a "Tour" app to tell 
the user where things are. This is quite useful, but really it's kind of 
like throwing a rope to the user to help them climb the initial mental 
cliff. There's still a cliff to climb, and a steep one at that. KDE 
Plasma has no such tour because it doesn't need one. A user can glance 
at the desktop and figure out more-or-less what they're doing without 
even touching it. Ubuntu tries to make this "understood-at-a-glance" 
thing work with GNOME by adding some familiar elements (minimize and 
maximize buttons, an app menu, a visible dock where apps are, etc)., 
which *kinda* works, but I don't think that's the path Fedora 
Workstation wants to take since it requires adding GNOME shell 
extensions to make it happen. KDE Plasma, on the other hand, is familiar 
and ready-to-use out of the starting gate, no extensions needed.


Is Plasma going to be the best for everyone? Absolutely not. Is it even 
going to be the best for most? Debatable, controversial, let's not go 
there. Is it the best for newcomers? I would argue yes, far better than 
GNOME or any other major Linux desktop. Non-newcomers can find the spins 
or alternate editions and have the setup that's perfect for them. 
Newcomers can "just grab" the Workstation edition (which will be Plasma 
with this Change Proposal) and have the setup that will be best to get 
them started.



I understand that the Change Proposal is about switching the "Workstation"
concept to using Plasma KDE and that approach might have been flawed but... 

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Przemek Klosowski via devel]

On 4/3/24 14:56, Adam Williamson wrote:

If you have two equally good options and you already picked one, you should
stick with it, not just switch between them every so often for the sake
of it. If Plasma were demonstrably, markedly and uncontroversially
*superior*  to GNOME (please don't take this as an excuse to start a
holy war, I am positing for the sake of this post that neither of the
two is demonstrably, markedly and uncontroversially better than the
other), the case would be different.


Absolutely!!

    "What's worse than a bad general?"

    "Two good generals!"

I have used both Gnome and KDE, and settled on Gnome, not because I 
didn't like KDE but simply because I don't have to think about how to 
perform basic actions. If someone persuaded me that KDE become much 
better, I would switch, but I definitely would not want to download a 
new version of Fedora to install on my new computer, and find myself 
switched.

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Kevin Kofler via devel]

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 not be the case. I have been through a whole FESCo debate 
just to be allowed to maintain those packages.

1. sudo dnf install plasma-workspace-x11
2. Select "Plasma (X11)" as the session type in your display manager.
3. Enjoy!

(It is also possible to force SDDM to itself use X11 rather than Wayland, if 
even SDDM does not work properly under Wayland for you.)

Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Leon Fauster via devel]

Am 03.04.24 um 20:56 schrieb Adam Williamson:

On Wed, 2024-04-03 at 20:24 +0200, Marc Deop i Argemí wrote:


Let's assume that we all agree with what you stated ( and I personally partly
do).

Why do we promote Workstation (with Gnome) over any other alternative that
might arise? (in this case, a Fedora Workstation KDE)


It's an interesting question. I would say my answer is "because it
works better if we promote *something*". Forcing the choice on people
who just want "desktop Fedora" is awkward. The reason we default to
GNOME is because we ~always have. To me, this is a reasonable



I second that. I prefer to have a clean path to go instead the endless
choice. Call it *nix philosophy, Hick's law or what ever. I call it
consistency and that is evidently the reason for Fedora's success, but
not alone.

Fedora's "variants" provides a coherent experience in the particular
usage. I already had RHL installed on a Sun IPX with Gnome, so I'm
biased. I would not change the place or what defines the Workstation
variant but other artifacts (editions, spins, labs) should get better 
visibility.


--
Leon

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora 40 compose report: 20240403.n.0 changes

[Fedora Branched Report]

OLD: Fedora-40-20240402.n.0
NEW: Fedora-40-20240403.n.0

= SUMMARY =
Added images:2
Dropped images:  1
Added packages:  3
Dropped packages:1
Upgraded packages:   90
Downgraded packages: 0

Size of added packages:  1.20 MiB
Size of dropped packages:7.75 MiB
Size of upgraded packages:   6.66 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   19.65 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Kinoite ociarchive ppc64le
Path: Kinoite/ppc64le/images/Fedora-Kinoite-40.20240403.n.0.ociarchive
Image: Astronomy_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-40-20240403.n.0.iso

= DROPPED IMAGES =
Image: LXQt live aarch64
Path: Spins/aarch64/iso/Fedora-LXQt-Live-aarch64-40-20240402.n.0.iso

= ADDED PACKAGES =
Package: libscfg-0.1.1-1.fc40
Summary: C library for a simple configuration file format
RPMs:libscfg libscfg-devel
Size:110.06 KiB

Package: lunasvg-2.3.9-1.fc40
Summary: Standalone SVG rendering library in C++
RPMs:lunasvg lunasvg-devel
Size:912.76 KiB

Package: mmc-utils-0~20240305gite1281d4-2.fc40
Summary: Configure MMC storage devices from userspace
RPMs:mmc-utils
Size:205.67 KiB


= DROPPED PACKAGES =
Package: arb-2.23.0-6.fc40
Summary: Arbitrary-precision floating point ball arithmetic
RPMs:arb arb-devel arb-doc
Size:7.75 MiB


= UPGRADED PACKAGES =
Package:  Cython-3.0.9-1.fc40
Old package:  Cython-3.0.8-1.fc40
Summary:  Language for writing Python extension modules
RPMs: python3-cython
Size: 15.59 MiB
Size change:  19.85 KiB
Changelog:
  * Wed Feb 21 2024 Karolina Surma  - 3.0.8-3
  - Use Python 3.13.0a4 PyCFunctionFastWithKeywords

  * Sat Mar 02 2024 Miro Hron??ok  - 3.0.8-4
  - Disable GCC warnings/errors about wrong self casts in final function
calls

  * Sun Mar 17 2024 Charalampos Stratakis  - 3.0.9-1
  - Update to 3.0.9 (rhbz#2268123)


Package:  NetworkManager-1:1.46.0-2.fc40
Old package:  NetworkManager-1:1.45.91-1.fc40
Summary:  Network connection manager and user applications
RPMs: NetworkManager NetworkManager-adsl NetworkManager-bluetooth 
NetworkManager-cloud-setup NetworkManager-config-connectivity-fedora 
NetworkManager-config-server NetworkManager-dispatcher-routing-rules 
NetworkManager-initscripts-ifcfg-rh NetworkManager-initscripts-updown 
NetworkManager-libnm NetworkManager-libnm-devel NetworkManager-ovs 
NetworkManager-ppp NetworkManager-team NetworkManager-tui NetworkManager-wifi 
NetworkManager-wwan
Size: 26.09 MiB
Size change:  121.19 KiB
Changelog:
  * Mon Feb 26 2024 Beniamino Galvani  - 1:1.46.0-1
  - Update to 1.46.0 release

  * Fri Mar 29 2024 Beniamino Galvani  - 1:1.46.0-2
  - Ignore error setting a global cloned MAC address (rh #2270062)


Package:  SDL2-2.30.1-1.fc40
Old package:  SDL2-2.28.5-3.fc40
Summary:  Cross-platform multimedia library
RPMs: SDL2 SDL2-devel SDL2-static
Size: 9.79 MiB
Size change:  200.77 KiB
Changelog:
  * Mon Mar 25 2024 Ding-Yi Chen  - 2.30.1-1
  - Update to 2.30.1


Package:  biosig4c++-2.6.0-3.fc40
Old package:  biosig4c++-2.5.2-6.fc40
Summary:  A software library for processing of biomedical signals
RPMs: biosig4c++ biosig4c++-devel
Size: 1.48 MiB
Size change:  -365.08 KiB
Changelog:
  * Fri Mar 22 2024 Sandro  - 2.6.0-1
  - Update to 2.6.0 (RHBZ#2264832)
  - Use macros consistently

  * Fri Mar 22 2024 Sandro  - 2.6.0-2
  - Migrate to SPDX license

  * Fri Mar 22 2024 Sandro  - 2.6.0-3
  - Drop i686 support (leaf package)


Package:  bolt-0.9.7-1.fc40
Old package:  bolt-0.9.6-4.fc40
Summary:  Thunderbolt device manager
RPMs: bolt
Size: 744.11 KiB
Size change:  97 B
Changelog:
  * Fri Mar 01 2024 Kate Hsuan  - 0.9.7-1
  - bolt 0.9.7 release
  - Support 'nopcie' security level
  - Bug fixes


Package:  castxml-0.6.4-2.fc40
Old package:  castxml-0.6.4-1.fc40
Summary:  C-family abstract syntax tree XML output tool
RPMs: castxml
Size: 3.24 MiB
Size change:  193.52 KiB
Changelog:
  * Wed Mar 06 2024 Mattias Ellert  - 0.6.4-2
  - Backport LLVM 18 support from upstream


Package:  clang-18.1.1-1.fc40
Old package:  clang-18.1.0~rc4-2.fc40
Summary:  A C language family front-end for LLVM
RPMs: clang clang-analyzer clang-devel clang-libs 
clang-resource-filesystem clang-tools-extra clang-tools-extra-devel 
git-clang-format python3-clang
Size: 250.58 MiB
Size change:  2.86 MiB
Changelog:
  * Fri Mar 08 2024 Tom Stellard  - 18.1.0~rc4-3
  - Remove some LTO workarounds

  * Mon Mar 11 2024 Tom Stellrd  - 18.1.1-1
  - 18.1.1 Release


Package:  compiler-rt-18.1.1-1.fc40
Old package:  compiler-rt-18.1.0~rc4-1.fc40
Summary:  LLVM "compiler-rt" runtime libraries
RPMs: compiler-rt
Size: 8.71 MiB
Size change:  -778 B
Changelog:
  * Tue Mar 12 2024 Tom Stellard  - 18.1.1-1
  - 18.1

Re: F41 Change Proposal: Switch to DNF5 (system-wide)

[Adam Williamson]

On Wed, 2024-04-03 at 14:27 -0400, Przemek Klosowski via devel wrote:
> On 4/3/24 06:36, Aoife Moloney wrote:
> > the dnf-automatic command will be obsoleted.
> 
> https://dnf5.readthedocs.io/en/latest/changes.html does not say anything 
> about automatic updates, and
> 
> https://packages.fedoraproject.org/pkgs/dnf5/dnf5-plugin-automatic/
> 
> simply suggests that dns update be executed from systemd timers or cron 
> jobs.
> 
> 
> dns-automatic provided a simple interface to a setup-and-forget 
> automatic updates; will DNF5 leave it to be set up by hand?
> 
> I am asking because systemd timers have surprising behavior for 
> suspendable systems, which leads to problems if updates are scheduled 
> for off-hours.
> 
> My experience is that even |WakeSystem=true does not make them reliable, 
> but I am not sure how to debug this (because the system is suspended, heh).
> 

We do use dnf-automatic quite extensively within infra, I think. Has
this been discussed with infra?
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Adam Williamson]

On Wed, 2024-04-03 at 20:24 +0200, Marc Deop i Argemí wrote:
> 
> Let's assume that we all agree with what you stated ( and I personally partly 
> do).
> 
> Why do we promote Workstation (with Gnome) over any other alternative that 
> might arise? (in this case, a Fedora Workstation KDE)

It's an interesting question. I would say my answer is "because it
works better if we promote *something*". Forcing the choice on people
who just want "desktop Fedora" is awkward. The reason we default to
GNOME is because we ~always have. To me, this is a reasonable
justification. Change is always uncomfortable and disruptive. If you
have two equally good options and you already picked one, you should
stick with it, not just switch between them every so often for the sake
of it. If Plasma were demonstrably, markedly and uncontroversially
*superior* to GNOME (please don't take this as an excuse to start a
holy war, I am positing for the sake of this post that neither of the
two is demonstrably, markedly and uncontroversially better than the
other), the case would be different.

> I understand that the Change Proposal is about switching the "Workstation" 
> concept to using Plasma KDE and that approach might have been flawed but... 
> how 
> do we challenge the "status quo" where everybody assumes that Fedora's 
> default 
> is Gnome?

Again personally, I would set a very high bar for this to happen,
purely on the grounds of conservatism. Don't change for the sake of
change. I would only support changing Fedora's default desktop if it
was very clear that the current default was sufficiently flawed that it
was hurting the project. I don't think we are at that point.

> And I am not arguing for the sake of arguing. I genuinely want to know how to 
> make Fedora's default to be Plasma KDE because I do believe the whole *linux* 
> (and Fedora's) community will benefit  from having a major distro like Fedora 
> not defaulting to Gnome.

There already is at least one. The most prominent download option for
openSUSE is their "Offline image" (equivalent of our old Everything
DVD), and the top item in the list of possible "roles" for the system
(effectively the choice we are discussing here) is "Desktop with KDE
Plasma" (at least in the screenshot in the install guide).
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

[Eric Blake]

On Wed, Apr 03, 2024 at 07:48:03PM +0200, Kevin Kofler via devel wrote:
> 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
> > behavior is intentional:
> > 
> > https://lists.gnu.org/archive/html/bug-autoconf/2024-04/msg5.html
> 
> Don't you love intentional bugs? Yet another reason to avoid autotools at 
> all costs.
> 
> By the way, the documentation of the serials "feature" actually warns about 
> this (and seems to imply that even without serials, --force does not work as 
> advertised for those files):
> https://www.gnu.org/software/automake/manual/html_node/Serials.html

Note - that's in the automake manual (it is the actions taken by aclocal...).

> 
> | Finally, note that the --force option of aclocal has absolutely no effect
> | on the files installed by --install. For instance, if you have modified
> | your local macros, do not expect --install --force to replace the local
> | macros by their system-wide versions. If you want to do so, simply erase
> | the local macros you want to revert, and run ‘aclocal --install’.
> 
> But the documentation of "autoreconf --force" does not include that warning. 
> And this also makes "--force" pretty much useless as it stands.

...and autoreconf is shipped by autoconf.  While the two projects are
related, they are independent (you can use autoconf without automake,
at which point autoreconf --force does update everything that autoconf
touched, since automake's semantics aren't getting in the way; it only
invokes aclocal when it is obvious that automake was also in use).
But I'm sure (speaking as one of the previous upstream autoconf
maintainers, but only as a very infrequent automake patch poster) that
a patch to autoconf's docs to mention the automake pitfalls inherited
from 'aclocal --force' into 'autoreconf --force' is worthwhile.

> 
> We and Debian both need to patch aclocal downstream immediately to make 
> --force actually work. And then of course Fedora needs to actually always 
> run autoreconf -i -f as Debian already does, or the patch will not do much 
> good.

Downstream is certainly entitled to have a different idea of best
practices than upstream, especially when downstream is targetting just
one OS, rather than the world of machines out there that the autotools
originally designed for.  That's one of the joys of open source - you
don't have to live with upstream decisions.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:  qemu.org | libguestfs.org
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F41 Change Proposal: Switch to DNF5 (system-wide)

[Przemek Klosowski via devel]

On 4/3/24 06:36, Aoife Moloney wrote:

the dnf-automatic command will be obsoleted.


https://dnf5.readthedocs.io/en/latest/changes.html does not say anything 
about automatic updates, and


https://packages.fedoraproject.org/pkgs/dnf5/dnf5-plugin-automatic/

simply suggests that dns update be executed from systemd timers or cron 
jobs.



dns-automatic provided a simple interface to a setup-and-forget 
automatic updates; will DNF5 leave it to be set up by hand?


I am asking because systemd timers have surprising behavior for 
suspendable systems, which leads to problems if updates are scheduled 
for off-hours.


My experience is that even |WakeSystem=true does not make them reliable, 
but I am not sure how to debug this (because the system is suspended, heh).

|

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Marc Deop i Argemí]

On Wednesday, 3 April 2024 01:48:47 CEST Kevin Fenzi wrote:
> On Tue, Apr 02, 2024 at 04:06:45PM -0400, Steve Cossette wrote:
> > Alright, so a substantial amount of information changed since the original
> > submission of the change proposal. We aren't necessarily thinking of
> > demoting Gnome. The overall spirit of the CP is that we think KDE, and to
> > some extent the other spins too, need a bit more visibility on the
> > website.
> > At the very least, Gnome and KDE should be up front on the frontpage.
> 
> So, I am far from a web designer, but if you aren't a Linux savvy person
> and just decided to try out this Fedora thing because you heard it was
> nice and you go to download it and get:
> 
> our website: Want a workstation?
> user: yes!
> 
> our website: great! We have Gnome and KDE!
> user: what? what does that mean? which one should I get?
> 
> our website:
> 
> Gnome: "Get things done with ease, comfort, and control.
> An easy and elegant way to use your computer,
> GNOME is designed to help you have the best possible computing experience."
> 
> KDE: "Powerful, multi-platform, and for everyone
> Use KDE software to surf the web, keep in touch with colleagues, friends
> and family, manage your files, enjoy music and videos; and get creative
> and productive at work. The KDE community develops and maintains more
> than 200 applications which run on any Linux desktop, and often other
> platforms too."
> 
> User: ok, that didn't tell me much, whats the difference?
> perhaps I will just keep using windows.
> 
> 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.
> 
> kevin

Let's assume that we all agree with what you stated ( and I personally partly 
do).

Why do we promote Workstation (with Gnome) over any other alternative that 
might arise? (in this case, a Fedora Workstation KDE)

I understand that the Change Proposal is about switching the "Workstation" 
concept to using Plasma KDE and that approach might have been flawed but... how 
do we challenge the "status quo" where everybody assumes that Fedora's default 
is Gnome?

Because somebody else has mentioned that is unlikely that the KDE Spin can be 
promoted to an Edition because it "overlaps" with the current Workstation...

And I am not arguing for the sake of arguing. I genuinely want to know how to 
make Fedora's default to be Plasma KDE because I do believe the whole *linux* 
(and Fedora's) community will benefit  from having a major distro like Fedora 
not defaulting to Gnome.

Best regards,

Marc

PS: thanks for the feedback to everybody :-)

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Kevin Kofler via devel]

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 understand the difference between an "Edition" and a "Spin" or 
"Lab". And technically, there is none. I do not see how Fedora's success has 
anything to do with such an implementation detail.

All this differentiation achieves is creating first-class ("Edition") and 
second-class ("Spin" or "Lab") spins, for no benefit whatsoever.

Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F41 Change Proposal: OpenSSL Deprecate Engine (system-wide)

[Dmitry Belyavskiy]

Dear Kevin

On Wed, Apr 3, 2024 at 8:13 PM Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:

> 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 that is still widely used and for which there
> is still no complete replacement (several replies have pointed out issues
> still preventing "providers" from working in all use cases in which
> "engines" work) is NOT reasonable.
>

You are 100% correct. That's why disabling this API is not on the table for
now anymore.

-- 
Dmitry Belyavskiy
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F41 Change Proposal: OpenSSL Deprecate Engine (system-wide)

[Kevin Kofler via devel]

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 that is still widely used and for which there 
is still no complete replacement (several replies have pointed out issues 
still preventing "providers" from working in all use cases in which 
"engines" work) is NOT reasonable.

> We have to deal with a very large numbers of FTBFS bugs from e.g. Python
> API breaks every other release cycle, or the latest compiler flag
> tuning. The fact that the transition creates work for other package
> maintainers is obviously not a reasonable blocker for a Fedora Change.

And that is exactly the kind of cultural issue we need to solve. The Python 
3 transition is exactly an example of a transition that was handled 
horribly, kicking out lots of useful packages from Fedora just because they 
were not ported to Python 3. Python 2, or a fork like Tauthon (which has the 
advantage that it supports some Python 3 features, so some Python-3-only 
libraries / library versions can be backported to Tauthon more easily than 
to stock Python 2), should have been retained as a compatibility platform in 
Fedora. (There is technically still a "python27" package, but the modules 
available for it are intentionally limited and there are strict rules on 
what packages are allowed to depend on it.) It should NEVER be considered 
reasonable to break other people's work.

Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Kevin Kofler via devel]

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 to boot and then install. At one point (for one or two, maybe three, 
releases only, then came "Fedora.next" and the Ambassadors were pressured to 
hand out only "Workstation"), we even handed DVDs with those (yes, in those 
good old days, a multiboot live image still fit on a DVD… then bloat 
happened!) out at events. (I even did a custom one once for the Vienna event 
in May 2015, which dual-booted the latest Fedora 21 KDE live-respin with 
Plasma 4 and the Fedora 22 Beta KDE live with Plasma 5. I did not put 
Workstation on those because we had tons of pressed Fedora 21 Workstation 
DVDs anyway.) Unfortunately, the scripts that generated those were unable to 
keep up with all the complications caused by UEFI and so-called "Secure 
Boot". (They used to work back when everything still booted in legacy BIOS 
mode.) So some engineering effort will probably be needed, and a lot of 
testing on different hardware will definitely be needed, to make the 
multiboot generator work (reliably) again.

Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

[Kevin Kofler via devel]

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
> behavior is intentional:
> 
> https://lists.gnu.org/archive/html/bug-autoconf/2024-04/msg5.html

Don't you love intentional bugs? Yet another reason to avoid autotools at 
all costs.

By the way, the documentation of the serials "feature" actually warns about 
this (and seems to imply that even without serials, --force does not work as 
advertised for those files):
https://www.gnu.org/software/automake/manual/html_node/Serials.html

| Finally, note that the --force option of aclocal has absolutely no effect
| on the files installed by --install. For instance, if you have modified
| your local macros, do not expect --install --force to replace the local
| macros by their system-wide versions. If you want to do so, simply erase
| the local macros you want to revert, and run ‘aclocal --install’.

But the documentation of "autoreconf --force" does not include that warning. 
And this also makes "--force" pretty much useless as it stands.

We and Debian both need to patch aclocal downstream immediately to make 
--force actually work. And then of course Fedora needs to actually always 
run autoreconf -i -f as Debian already does, or the patch will not do much 
good.

Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Leslie Satenstein via devel]

Topic change for one minute
With the Everything.iso, there is a recovery option, which presents questions 
pertaining to a Fedora installation needing a security scan (eg systemctl 
daemon-reload).
Has anyone succeeded in the recovery script working to completion?  I raise the 
question here, as it is not a distro issue, but a recovery issue, and I do not 
know to which topic I should raise the bugzilla report.
End of topic change.


Leslie Satenstein
 

On Wednesday, April 3, 2024 at 12:22:14 p.m. EDT, Michael Catanzaro 
 wrote:  
 
 

On Tue, Apr 2 2024 at 06:18:31 PM -07:00:00, 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 - which was explicitly
> based around making it much more focused and less of a 
> choose-your-own-
> adventure, specifically including making the download page much more
> opinionated. AFAIR, the numbers Matthew tracks strongly indicate this
> was associated with a very significant immediate bump in Fedora usage.

Yes, promoting Fedora Workstation over all the other desktops has been 
key to the success of Fedora over the past 10 years. I suspect it was 
the right choice, because Fedora has grown considerably from our 
unrelenting focus on attracting so many GNOME desktop users to the 
Fedora edition that receives the most investment. But there is a 
continuum of strategies we can use to promote our default desktop over 
other options, and I wonder if we've erred too far in favor of Fedora 
Workstation and against Fedora KDE Plasma Desktop here. The Plasma spin 
is much "bigger" than the other spins, it's of comparable quality to 
Fedora Workstation, and it is release blocking. It just seems strange 
to relegate it to a secondary downloads page regardless of how popular 
it is, while the non-desktop editions (some of which are frankly 
relatively niche) get featured very prominently.

I'm not sure what the solution is here. Kevin's suggestion of featuring 
all spins equally risks overloading users with difficult choices and 
diluting our focus on what we do well, and I hesitate to open the doors 
for all spins to request a place on the main download page. I suppose I 
think of KDE Plasma as "special" relative to all the others due to its 
relatively large upstream developer community and user base, so I guess 
I'd like to see some way to elevate the status of Plasma in Fedora 
without also jeopardizing the special status of Fedora Workstation. We 
should have a very compelling reason if we're going to continue hiding 
one of our strongest products, and I don't think we do anymore. Our 
reputation as a quality GNOME distro has become so strong that it's not 
going to be damaged by other Fedora desktop offerings.

So here are three brainstorming proposals:

 (a) Fedora KDE Plasma Desktop becomes a Fedora edition. We'd need to 
be careful about how we do it. I would still promote Fedora Workstation 
as the main/recommended "leading" desktop, would call Plasma an 
"alternative desktop option," and would strongly caution against use of 
the word "Workstation" anywhere in the branding for the Plasma version. 
That is, let's continue to steer undecided users towards Fedora 
Workstation, while making Plasma easier to find and presenting it more 
prominently than it is today.

 (b) Alternatively, elevate the positioning of all spins on the 
fedoraproject.org homepage. Place the link to the spins right next to 
the link to Fedora Workstation, above the atomic desktops (which are 
sadly still experimental), above the Fedora labs and ALT downloads, and 
honestly probably above the non-desktop Fedora editions. Nobody is 
going to be confused as to which one is the primary product.

 (c) Do both of the above, because they aren't mutually exclusive 
proposals.

Michael

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
  --
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Andreas Tunek]

Den ons 3 apr. 2024 kl 18:45 skrev Neal Gompa :

> On Wed, Apr 3, 2024 at 12:22 PM Michael Catanzaro 
> wrote:
> >
> >
> >
> > On Tue, Apr 2 2024 at 06:18:31 PM -07:00:00, 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 - which was explicitly
> > > based around making it much more focused and less of a
> > > choose-your-own-
> > > adventure, specifically including making the download page much more
> > > opinionated. AFAIR, the numbers Matthew tracks strongly indicate this
> > > was associated with a very significant immediate bump in Fedora usage.
> >
> > Yes, promoting Fedora Workstation over all the other desktops has been
> > key to the success of Fedora over the past 10 years. I suspect it was
> > the right choice, because Fedora has grown considerably from our
> > unrelenting focus on attracting so many GNOME desktop users to the
> > Fedora edition that receives the most investment. But there is a
> > continuum of strategies we can use to promote our default desktop over
> > other options, and I wonder if we've erred too far in favor of Fedora
> > Workstation and against Fedora KDE Plasma Desktop here. The Plasma spin
> > is much "bigger" than the other spins, it's of comparable quality to
> > Fedora Workstation, and it is release blocking. It just seems strange
> > to relegate it to a secondary downloads page regardless of how popular
> > it is, while the non-desktop editions (some of which are frankly
> > relatively niche) get featured very prominently.
> >
> > I'm not sure what the solution is here. Kevin's suggestion of featuring
> > all spins equally risks overloading users with difficult choices and
> > diluting our focus on what we do well, and I hesitate to open the doors
> > for all spins to request a place on the main download page. I suppose I
> > think of KDE Plasma as "special" relative to all the others due to its
> > relatively large upstream developer community and user base, so I guess
> > I'd like to see some way to elevate the status of Plasma in Fedora
> > without also jeopardizing the special status of Fedora Workstation. We
> > should have a very compelling reason if we're going to continue hiding
> > one of our strongest products, and I don't think we do anymore. Our
> > reputation as a quality GNOME distro has become so strong that it's not
> > going to be damaged by other Fedora desktop offerings.
> >
> > So here are three brainstorming proposals:
> >
> >  (a) Fedora KDE Plasma Desktop becomes a Fedora edition. We'd need to
> > be careful about how we do it. I would still promote Fedora Workstation
> > as the main/recommended "leading" desktop, would call Plasma an
> > "alternative desktop option," and would strongly caution against use of
> > the word "Workstation" anywhere in the branding for the Plasma version.
> > That is, let's continue to steer undecided users towards Fedora
> > Workstation, while making Plasma easier to find and presenting it more
> > prominently than it is today.
> >
>
> What would be wrong with "Fedora GNOME Workstation" and "Fedora KDE
> Plasma Desktop"? I think once we're both at the same level, the
> desktop name as a distinguishing property is valuable.
>
>
>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/
).

One of the best things with Fedora Workstation is that it is a complete
user facing OS (like Windows, macOS and iOS) that you actually can develop
applications for (if you want to). You don't have to target the extremely
fluffy "Linux desktop", you can target Fedora Workstation. This proposal
would totally eliminate the good points of having this single OS and app
platform.

/Andreas



> >  (b) Alternatively, elevate the positioning of all spins on the
> > fedoraproject.org homepage. Place the link to the spins right next to
> > the link to Fedora Workstation, above the atomic desktops (which are
> > sadly still experimental), above the Fedora labs and ALT downloads, and
> > honestly probably above the non-desktop Fedora editions. Nobody is
> > going to be confused as to which one is the primary product.
> >
>
> I think this would be rather chaotic, but I do think we need something
> to show that the spins exist more. I suspect that a big part of why
> some of them languish and fade is the lack of visibility. It makes it
> a foregone conclusion, which is a huge problem with how we handle
> non-edition variants in general.
>
> >  (c) Do both of the above, because they aren't mutually exclusive
> > proposals.
> >
>
> Indeed.
>
>
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> 

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Steve Cossette]

Hello Michael, and thanks for replying.

 (a) Fedora KDE Plasma Desktop becomes a Fedora edition. We'd need to
be careful about how we do it. I would still promote Fedora Workstation
as the main/recommended "leading" desktop, would call Plasma an
"alternative desktop option," and would strongly caution against use of
the word "Workstation" anywhere in the branding for the Plasma version.
That is, let's continue to steer undecided users towards Fedora
Workstation, while making Plasma easier to find and presenting it more
prominently than it is today.


*I semi-agree on this one. Why would Workstation remain the default? I will
admit that for new users, Gnome is best. Maybe label it as such? Something
like:**Fedora Gnome Workstation*:
- Best for new users
- Rich, beautiful user interface
- [...]

*Fedora Plasma Workstation:*
- Best for intermediate users and higher
- Superior customizability
- HDR/VRR Support
- [...]

 (b) Alternatively, elevate the positioning of all spins on the
fedoraproject.org homepage. Place the link to the spins right next to
the link to Fedora Workstation, above the atomic desktops (which are
sadly still experimental), above the Fedora labs and ALT downloads, and
honestly probably above the non-desktop Fedora editions. Nobody is
going to be confused as to which one is the primary product.

*I honestly think that would be chaotic.*

 (c) Do both of the above, because they aren't mutually exclusive
proposals.

*Fair.*

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 as Kubuntu is Ubuntu. (Though,
I don't know about 'Kedora' as it has absolutely no meaning XD) Though I
feel like we should really only go this route if the other ideas get
completely exhausted...

Steve

On Wed, Apr 3, 2024 at 12:22 PM Michael Catanzaro 
wrote:

>
>
> On Tue, Apr 2 2024 at 06:18:31 PM -07:00:00, 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 - which was explicitly
> > based around making it much more focused and less of a
> > choose-your-own-
> > adventure, specifically including making the download page much more
> > opinionated. AFAIR, the numbers Matthew tracks strongly indicate this
> > was associated with a very significant immediate bump in Fedora usage.
>
> Yes, promoting Fedora Workstation over all the other desktops has been
> key to the success of Fedora over the past 10 years. I suspect it was
> the right choice, because Fedora has grown considerably from our
> unrelenting focus on attracting so many GNOME desktop users to the
> Fedora edition that receives the most investment. But there is a
> continuum of strategies we can use to promote our default desktop over
> other options, and I wonder if we've erred too far in favor of Fedora
> Workstation and against Fedora KDE Plasma Desktop here. The Plasma spin
> is much "bigger" than the other spins, it's of comparable quality to
> Fedora Workstation, and it is release blocking. It just seems strange
> to relegate it to a secondary downloads page regardless of how popular
> it is, while the non-desktop editions (some of which are frankly
> relatively niche) get featured very prominently.
>
> I'm not sure what the solution is here. Kevin's suggestion of featuring
> all spins equally risks overloading users with difficult choices and
> diluting our focus on what we do well, and I hesitate to open the doors
> for all spins to request a place on the main download page. I suppose I
> think of KDE Plasma as "special" relative to all the others due to its
> relatively large upstream developer community and user base, so I guess
> I'd like to see some way to elevate the status of Plasma in Fedora
> without also jeopardizing the special status of Fedora Workstation. We
> should have a very compelling reason if we're going to continue hiding
> one of our strongest products, and I don't think we do anymore. Our
> reputation as a quality GNOME distro has become so strong that it's not
> going to be damaged by other Fedora desktop offerings.
>
> So here are three brainstorming proposals:
>
>  (a) Fedora KDE Plasma Desktop becomes a Fedora edition. We'd need to
> be careful about how we do it. I would still promote Fedora Workstation
> as the main/recommended "leading" desktop, would call Plasma an
> "alternative desktop option," and would strongly caution against use of
> the word "Workstation" anywhere in the branding for the Plasma version.
> That is, let's continue to steer undecided users towards Fedora
> Workstation, while making Plasma easier to find and presenting it more
> prominently than it is today.
>
>  (b) Alternatively, elevate the positioning of all spins on the
> fedoraproject.org homepage. Place the link to the spins right next 

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Kevin Fenzi]

On Wed, Apr 03, 2024 at 04:24:08AM +0200, Kevin Kofler via devel wrote:
> 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 have to choose" should be 
> a concious choice, also considering that the mostly unconfigurable (by 
> design) GNOME is very likely to be the wrong option for anybody not in that 
> category. And besides:

It's still a choice. Just a better presentation IMHO for people who 'do
not want to choose'.

> > (Which is pretty much what we have now)
> 
> Well, not quite, it is more like:
> 
> [LOGO Workstation (Download Now) (Learn More)]
> 
> [LOGO Server (Download Now) (Learn More)]
> 
> [LOGO IoT (Download Now) (Learn More)]
> 
> [LOGO Cloud (Download Now) (Learn More)]
> 
> [LOGO CoreOS (Download Now) (Learn More)]
> 
> Want more Fedora options?
> 
> Atomic Desktops (Learn More) ← no frame nor logo nor mention of "download"
> 
> Fedora Spins (Learn More) ← no frame nor logo nor mention of "download"
> 
> Fedora Labs (Learn More) ← no frame nor logo nor mention of "download"
> 
> Fedora ALT Downloads (Learn More) ← no frame nor logo
> 
> So you get offered a lot of (most likely) irrelevant (to you) options 

to you? They are quite relevent to others... 

Anyhow, I think our positions are pretty clear here, so no need to
prolong this subthread.

kevin


signature.asc
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Kevin Fenzi]

On Wed, Apr 03, 2024 at 06:17:59PM +0200, Leon Fauster via devel wrote:
> Am 02.04.24 um 23:32 schrieb Adam Williamson:
> > On Tue, 2024-04-02 at 17:37 -0300, Sergio Belkin wrote:
> > > 
> > > I am a happy KDE user, since the good old days of version 1.0. I celebrate
> > > this decision! My recognition goes to the enormous and sustained work of
> > > the entire KDE community.
> > > Cheers,
> > > Sergiio
> > 
> > To be clear, there is no 'decision'. This is a Change proposal. Any
> > Fedora community member can submit a Change proposal proposing just
> > about any change; I could submit one tomorrow proposing we abandon all
> > software development and open a yak farm instead.
> > 
> > A Change proposal existing is in no way an indication of any ultimate
> > outcome. Change proposals can be, and frequently are, rejected.
> 
> 
> Sorry, for not knowing the process right but where to vote up/down for such
> proposal?

You can provide your feedback here or in the discussion thread.

The actual voting on proposals happens with FESCo members once the
proposal has had feedback from the community (and of course if it's not
withdrawn, etc). 

kevin


signature.asc
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

[Kevin Fenzi]

On Wed, Apr 03, 2024 at 07:27:12AM -0400, Stephen Gallagher wrote:
> On Tue, Apr 2, 2024 at 7:41 PM Kevin Fenzi  wrote:
> >
> > On Tue, Apr 02, 2024 at 04:38:25PM -0400, Stephen Gallagher wrote:
> > > On Tue, Apr 2, 2024 at 3:55 PM Steve Cossette  wrote:
> > > >
> > > > I personally would very much agree with enforcing the use of 2fa on the 
> > > > Fedora Account System. Maybe take that opportunity to make it a bit 
> > > > more user friendly? (Such as the fkinit prompt requiring the 2fa code 
> > > > being added at the end of your password -- to be clear I think the 2fa 
> > > > code should be separate)
> > >
> > > https://pagure.io/fedora-packager/pull-request/179
> >
> > I agree that fixing the mismatch in prompts might be nice, but why does
> > having 2fa seperate make things any better? I mean, it's one more return
> > you get to hit. ;)
> >
> > And... I am not sure about moving the handling of passwords to a bash
> > script from a kinit prompt.
> >
> 
> The kinit is already being run inside a bash script, so if bash is
> compromised with a keylogger, you've already lost the game... I'm not
> sure how this is worse.

Well, I meant more that now $PASSWORD has your password where before
kinit was the only thing you input your password into. :) 
So, if someone does say a 'sh -x fkinit' to look at something, their
password will show up, but it's probibly fine.

> Yeah, it's an extra keystroke, but I think there's value in helping
> the user provide the input in the proper format. Right now it's
> confusing (particularly since the kinit prompt gives bad information
> that we have to warn about).

Sure.

kevin


signature.asc
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaned packages looking for new maintainers

[Sandro]

On 03-04-2024 18:35, Jens-Ulrik Petersen wrote:

I took botan as a penance for my sins in the previous thread  haha 


הַלְּלוּ־יָהּ 

Thanks!

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Neal Gompa]

On Wed, Apr 3, 2024 at 12:22 PM Michael Catanzaro  wrote:
>
>
>
> On Tue, Apr 2 2024 at 06:18:31 PM -07:00:00, 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 - which was explicitly
> > based around making it much more focused and less of a
> > choose-your-own-
> > adventure, specifically including making the download page much more
> > opinionated. AFAIR, the numbers Matthew tracks strongly indicate this
> > was associated with a very significant immediate bump in Fedora usage.
>
> Yes, promoting Fedora Workstation over all the other desktops has been
> key to the success of Fedora over the past 10 years. I suspect it was
> the right choice, because Fedora has grown considerably from our
> unrelenting focus on attracting so many GNOME desktop users to the
> Fedora edition that receives the most investment. But there is a
> continuum of strategies we can use to promote our default desktop over
> other options, and I wonder if we've erred too far in favor of Fedora
> Workstation and against Fedora KDE Plasma Desktop here. The Plasma spin
> is much "bigger" than the other spins, it's of comparable quality to
> Fedora Workstation, and it is release blocking. It just seems strange
> to relegate it to a secondary downloads page regardless of how popular
> it is, while the non-desktop editions (some of which are frankly
> relatively niche) get featured very prominently.
>
> I'm not sure what the solution is here. Kevin's suggestion of featuring
> all spins equally risks overloading users with difficult choices and
> diluting our focus on what we do well, and I hesitate to open the doors
> for all spins to request a place on the main download page. I suppose I
> think of KDE Plasma as "special" relative to all the others due to its
> relatively large upstream developer community and user base, so I guess
> I'd like to see some way to elevate the status of Plasma in Fedora
> without also jeopardizing the special status of Fedora Workstation. We
> should have a very compelling reason if we're going to continue hiding
> one of our strongest products, and I don't think we do anymore. Our
> reputation as a quality GNOME distro has become so strong that it's not
> going to be damaged by other Fedora desktop offerings.
>
> So here are three brainstorming proposals:
>
>  (a) Fedora KDE Plasma Desktop becomes a Fedora edition. We'd need to
> be careful about how we do it. I would still promote Fedora Workstation
> as the main/recommended "leading" desktop, would call Plasma an
> "alternative desktop option," and would strongly caution against use of
> the word "Workstation" anywhere in the branding for the Plasma version.
> That is, let's continue to steer undecided users towards Fedora
> Workstation, while making Plasma easier to find and presenting it more
> prominently than it is today.
>

What would be wrong with "Fedora GNOME Workstation" and "Fedora KDE
Plasma Desktop"? I think once we're both at the same level, the
desktop name as a distinguishing property is valuable.

>  (b) Alternatively, elevate the positioning of all spins on the
> fedoraproject.org homepage. Place the link to the spins right next to
> the link to Fedora Workstation, above the atomic desktops (which are
> sadly still experimental), above the Fedora labs and ALT downloads, and
> honestly probably above the non-desktop Fedora editions. Nobody is
> going to be confused as to which one is the primary product.
>

I think this would be rather chaotic, but I do think we need something
to show that the spins exist more. I suspect that a big part of why
some of them languish and fade is the lack of visibility. It makes it
a foregone conclusion, which is a huge problem with how we handle
non-edition variants in general.

>  (c) Do both of the above, because they aren't mutually exclusive
> proposals.
>

Indeed.





--
真実はいつも一つ！/ Always, there's only one truth!
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaned packages looking for new maintainers

[Jens-Ulrik Petersen]

I took botan as a penance for my sins in the previous thread ;-) haha 
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Michael Catanzaro]

On Tue, Apr 2 2024 at 06:18:31 PM -07:00:00, 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 - which was explicitly
based around making it much more focused and less of a 
choose-your-own-

adventure, specifically including making the download page much more
opinionated. AFAIR, the numbers Matthew tracks strongly indicate this
was associated with a very significant immediate bump in Fedora usage.


Yes, promoting Fedora Workstation over all the other desktops has been 
key to the success of Fedora over the past 10 years. I suspect it was 
the right choice, because Fedora has grown considerably from our 
unrelenting focus on attracting so many GNOME desktop users to the 
Fedora edition that receives the most investment. But there is a 
continuum of strategies we can use to promote our default desktop over 
other options, and I wonder if we've erred too far in favor of Fedora 
Workstation and against Fedora KDE Plasma Desktop here. The Plasma spin 
is much "bigger" than the other spins, it's of comparable quality to 
Fedora Workstation, and it is release blocking. It just seems strange 
to relegate it to a secondary downloads page regardless of how popular 
it is, while the non-desktop editions (some of which are frankly 
relatively niche) get featured very prominently.


I'm not sure what the solution is here. Kevin's suggestion of featuring 
all spins equally risks overloading users with difficult choices and 
diluting our focus on what we do well, and I hesitate to open the doors 
for all spins to request a place on the main download page. I suppose I 
think of KDE Plasma as "special" relative to all the others due to its 
relatively large upstream developer community and user base, so I guess 
I'd like to see some way to elevate the status of Plasma in Fedora 
without also jeopardizing the special status of Fedora Workstation. We 
should have a very compelling reason if we're going to continue hiding 
one of our strongest products, and I don't think we do anymore. Our 
reputation as a quality GNOME distro has become so strong that it's not 
going to be damaged by other Fedora desktop offerings.


So here are three brainstorming proposals:

(a) Fedora KDE Plasma Desktop becomes a Fedora edition. We'd need to 
be careful about how we do it. I would still promote Fedora Workstation 
as the main/recommended "leading" desktop, would call Plasma an 
"alternative desktop option," and would strongly caution against use of 
the word "Workstation" anywhere in the branding for the Plasma version. 
That is, let's continue to steer undecided users towards Fedora 
Workstation, while making Plasma easier to find and presenting it more 
prominently than it is today.


(b) Alternatively, elevate the positioning of all spins on the 
fedoraproject.org homepage. Place the link to the spins right next to 
the link to Fedora Workstation, above the atomic desktops (which are 
sadly still experimental), above the Fedora labs and ALT downloads, and 
honestly probably above the non-desktop Fedora editions. Nobody is 
going to be confused as to which one is the primary product.


(c) Do both of the above, because they aren't mutually exclusive 
proposals.


Michael

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F41 Change Proposal: OpenSSL Deprecate Engine (system-wide)

[Dmitry Belyavskiy]

Dear Zbyszek,

Thanks, I updated the Wiki page correspondingly.

On Wed, Apr 3, 2024 at 5:56 PM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> [Replying to two mails at once to conserve some electrons.]
>
> On Tue, Apr 02, 2024 at 04:03:31PM +0200, Dmitry Belyavskiy wrote:
> > Thanks. In the period between the proposal was written and published the
> > TPM2 provider has landed in Fedora.
> > PKCS#11 provider is already here for a while.
> >
> > Should I update the Wiki page to adjust this point?
>
> Please do.
>
> > > == How To Test ==
> > > > OpenSSL libcrypto.so exports the same ENGINE_* symbols as for f40.
> > > > Applications relying on the ENGINE API can't be built but still work.
> > >
> > > That's incompatible with package rebuilds…
> > >
> > > An acceptable approach would be to split out the headers to a separate
> > > -devel file, e.g. openssl-engine-devel, mark it as Provides:
> deprecated().
> > > Existing packages which need the engine headers can adjust to use the
> > > new header and new packages are prevented by the Packaging Guidelines
> > > from adding a dependency on deprecated packages.
> >
> > Thanks! I like this idea and can update the Wiki page accordingly.
>
> Thanks!
>
> On Tue, Apr 02, 2024 at 05:12:20PM +0200, Dmitry Belyavskiy wrote:
> > On Tue, Apr 2, 2024 at 4:32 PM Luca Boccassi  wrote:
> > [...]
> > The TPM2 package is suitable for all required operations, AFAIK.
> > I'm also sure about the PKCS11 provider which I follow close enough.
> >
> > Please raise detailed issues if you have something particular.
> > I remember that you mentioned a particular issue about PKCS#11, could you
> > please try the current version?
> > My colleagues working on PKCS#11 are not aware of any Yubikey issues,
> BTW.
> >
> > Third-party engines may be a problem but as we don't break ABI, it's not
> a
> > problem of the moment.
>
> On Wed, Apr 03, 2024 at 09:50:27AM +0200, Clemens Lang wrote:
> > I did try using the current pkcs11-provider with my Yubikey to
> > create a signature using openssl dgst -sign
> > 'pkcs11:serial=18c9662a9c930e9e;id=%02;type=private'. It worked just
> > fine for me, including prompting for the PIN, twice.
> >
> > I did have to enable the PKCS11 provider in my openssl.cnf, but that
> > could also be done programmatically at runtime by applications>
> > should they choose to do so.
> >
> > I was not able to reproduce the problems you faced in the systemd
> > upstream ticket you referred to earlier. It is possible that they
> > have been fixed upstream in the meantime.
>
> Thank you both, it sounds like this should work. In systemd, we'll
> need to adjust the code to use providers, but that should be doable.
>
> OK, so with discussed changes, I'm +1.
>
> Zbyszek
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 
Dmitry Belyavskiy
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Leon Fauster via devel]

Am 02.04.24 um 23:32 schrieb Adam Williamson:

On Tue, 2024-04-02 at 17:37 -0300, Sergio Belkin wrote:


I am a happy KDE user, since the good old days of version 1.0. I celebrate
this decision! My recognition goes to the enormous and sustained work of
the entire KDE community.
Cheers,
Sergiio


To be clear, there is no 'decision'. This is a Change proposal. Any
Fedora community member can submit a Change proposal proposing just
about any change; I could submit one tomorrow proposing we abandon all
software development and open a yak farm instead.

A Change proposal existing is in no way an indication of any ultimate
outcome. Change proposals can be, and frequently are, rejected.



Sorry, for not knowing the process right but where to vote up/down for 
such proposal?


--
Leon
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F41 Change Proposal: OpenSSL Deprecate Engine (system-wide)

[Zbigniew Jędrzejewski-Szmek]

[Replying to two mails at once to conserve some electrons.]

On Tue, Apr 02, 2024 at 04:03:31PM +0200, Dmitry Belyavskiy wrote:
> Thanks. In the period between the proposal was written and published the
> TPM2 provider has landed in Fedora.
> PKCS#11 provider is already here for a while.
>
> Should I update the Wiki page to adjust this point?

Please do.

> > == How To Test ==
> > > OpenSSL libcrypto.so exports the same ENGINE_* symbols as for f40.
> > > Applications relying on the ENGINE API can't be built but still work.
> >
> > That's incompatible with package rebuilds…
> >
> > An acceptable approach would be to split out the headers to a separate
> > -devel file, e.g. openssl-engine-devel, mark it as Provides: deprecated().
> > Existing packages which need the engine headers can adjust to use the
> > new header and new packages are prevented by the Packaging Guidelines
> > from adding a dependency on deprecated packages.
>
> Thanks! I like this idea and can update the Wiki page accordingly.

Thanks!

On Tue, Apr 02, 2024 at 05:12:20PM +0200, Dmitry Belyavskiy wrote:
> On Tue, Apr 2, 2024 at 4:32 PM Luca Boccassi  wrote:
> [...]
> The TPM2 package is suitable for all required operations, AFAIK.
> I'm also sure about the PKCS11 provider which I follow close enough.
> 
> Please raise detailed issues if you have something particular.
> I remember that you mentioned a particular issue about PKCS#11, could you
> please try the current version?
> My colleagues working on PKCS#11 are not aware of any Yubikey issues, BTW.
> 
> Third-party engines may be a problem but as we don't break ABI, it's not a
> problem of the moment.

On Wed, Apr 03, 2024 at 09:50:27AM +0200, Clemens Lang wrote:
> I did try using the current pkcs11-provider with my Yubikey to
> create a signature using openssl dgst -sign
> 'pkcs11:serial=18c9662a9c930e9e;id=%02;type=private'. It worked just
> fine for me, including prompting for the PIN, twice.
>
> I did have to enable the PKCS11 provider in my openssl.cnf, but that
> could also be done programmatically at runtime by applications>
> should they choose to do so.
>
> I was not able to reproduce the problems you faced in the systemd
> upstream ticket you referred to earlier. It is possible that they
> have been fixed upstream in the meantime.

Thank you both, it sounds like this should work. In systemd, we'll
need to adjust the code to use providers, but that should be doable.

OK, so with discussed changes, I'm +1.

Zbyszek
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Jens-Ulrik Petersen]

On Wed, Apr 3, 2024 at 4:08 AM Steve Cossette  wrote:

> Alright, so a substantial amount of information changed since the original
> submission of the change proposal.
>
It did?  Because the page still reads:
*"Switch the default desktop experience for Workstation to KDE Plasma."*


> We aren't necessarily thinking of demoting Gnome.
>

And continues *"**The GNOME desktop is moved to a separate spin / edition,
retaining release-blocking status."*

Or are you saying you are planning to rewrite the page??

The overall spirit of the CP is that we think KDE, and to some extent the
> other spins too, need a bit more visibility on the website. At the very
> least, Gnome and KDE should be up front on the frontpage.
>

Asking to improve KDE's visibility on the website is certainly quite
different to replacing GNOME in Workstation.

Jens
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

[Eric Blake]

On Wed, Apr 03, 2024 at 12:47:39AM +0200, Kevin Kofler via devel wrote:
> 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 not what -f is supposed to do? At least, the documentation claims 
> so, but the implementation does not actually do what is documented.

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
behavior is intentional:

https://lists.gnu.org/archive/html/bug-autoconf/2024-04/msg5.html

So the only sane way to work around the upstream behavior (if we
insist that working around it is essential, such as if we insist on
running autoreconf in order to pull in modernized config.guess that
will allow us to build on more platforms than were present at the time
the upstream package was cut), is to do something like removing all
.m4 files, then autoreconf -fi to reinstall all of them with known
versions of the same .m4 files that we somehow curate as being more
reliable than the ones that upstream tested their release tarball
with.  Lots of busy work, but if we think it will help as another
layer of reassurance to keep our customers happy, then we can sign up
for it.

However, although it is unlikely that upstream automake will accept a
patch to change the existing 'autoreconf -fi' behavior of not
overriding an already-present .m4 with a higher serial, getting some
other patch in that adds a new option such as 'autoreconf
--ignore-serial -fi' might be possible.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:  qemu.org | libguestfs.org
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: activemq-cpp in epel8

[Jonathan Wright via epel-devel]

Evan,

I will look into this.  Looks like it was retired years ago for failing to
build: https://bugzilla.redhat.com/show_bug.cgi?id=1674632

It will have to be re-reviewed since it was retired/orphaned more than 6
weeks ago so a reasonable timeframe to (potentially) get it back into repos
and EPEL8 is a 2-6 weeks depending on how quickly a reviewer will pick it
up, and if it will build against modern versions of Fedora/RHEL.

On Wed, Apr 3, 2024 at 9:57 AM Ward, Evan M CIV USN NRL (8112) Washington
DC (USA) via epel-devel  wrote:

> Hi,
>
> Are there any packagers who would like to package activemq-cpp in
> epel8? It's already in epel7.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2244652
>
> Regards,
> Evan Ward
> --
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 
Jonathan Wright
AlmaLinux Foundation
Mattermost: chat 
--
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] activemq-cpp in epel8

[Ward, Evan M CIV USN NRL (8112) Washington DC (USA) via epel-devel]

Hi,

Are there any packagers who would like to package activemq-cpp in
epel8? It's already in epel7.

https://bugzilla.redhat.com/show_bug.cgi?id=2244652

Regards,
Evan Ward


smime.p7s
Description: S/MIME cryptographic signature
--
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Steve Cossette]

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!

On Wed, Apr 3, 2024 at 09:49 Leslie Satenstein via devel <
devel@lists.fedoraproject.org> wrote:

> Perhaps something like the "Everything.iso" could be top-leveled on the
> website, to include Workstation, KDE, *et al,*   in their full
> "Everything.iso" details. That will let me decide, beforehand, what it is
> that I want to download.
>
> Keep the individual iso-webpage relationship simple, referring to the
> suggested new top-level website pages.
>
>
> Leslie Satenstein
>
>
>
> On Tuesday, April 2, 2024 at 03:37:30 p.m. EDT, Adam Williamson <
> adamw...@fedoraproject.org> wrote:
>
>
> On Tue, 2024-04-02 at 21:05 +0200, Kevin Kofler via devel wrote:
> > 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:
> > https://fedoraproject.org/wiki/Features/KDE_Plasma_Desktop_by_default
> >
> > Back then, the KDE SIG was NOT willing to support my proposal (even
> though
> > the timing would have been ideal, given that GNOME was badly hit at the
> time
> > by the GNOME 3 transition and users disappointed by the radical cuts in
> > customizability). Now they are refloating it as their own, without even
> > citing my original proposal.
>
> Kevin, I know you and I have been around forever and 2011 feels like
> yesterday, but it was really quite a long time ago.
>
> Some of the people involved in the proposal didn't even use Fedora in
> 2011. Heck, there are probably people using Fedora who weren't *born*
> in 2011.
>
> If you compare the KDE SIG member list from May 2011 (approx. time of
> your old proposal) and the current one, the only people who appear on
> both lists are Rex Dieter and Than Ngo, neither of whom is an owner of
> this Change proposal.
>
> https://fedoraproject.org/wiki/SIGs/KDE
> https://fedoraproject.org/w/index.php?title=SIGs/KDE=239023
> --
> Adam Williamson (he/him/his)
> Fedora QA
> Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
> https://www.happyassassin.net
>
>
>
>
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora rawhide compose report: 20240403.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20240402.n.0
NEW: Fedora-Rawhide-20240403.n.0

= SUMMARY =
Added images:0
Dropped images:  1
Added packages:  6
Dropped packages:4
Upgraded packages:   117
Downgraded packages: 0

Size of added packages:  2.88 MiB
Size of dropped packages:8.83 MiB
Size of upgraded packages:   2.06 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   8.51 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: LXQt live aarch64
Path: Spins/aarch64/iso/Fedora-LXQt-Live-aarch64-Rawhide-20240402.n.0.iso

= ADDED PACKAGES =
Package: projecteur-0.10-1.fc41
Summary: Virtual pointer for the Logitech Spotlight presentation remote
RPMs:projecteur
Size:2.62 MiB

Package: python-lxml-html-clean-0.1.0-1.fc41
Summary: HTML cleaner from lxml project
RPMs:python3-lxml-html-clean
Size:30.10 KiB

Package: rust-jpegxl-rs-0.8.3-1.fc41
Summary: Safe Rust wrapper for JPEG XL reference implementation
RPMs:rust-jpegxl-rs+bench-devel rust-jpegxl-rs+default-devel 
rust-jpegxl-rs+docs-devel rust-jpegxl-rs+image-devel 
rust-jpegxl-rs+threads-devel rust-jpegxl-rs-devel
Size:79.95 KiB

Package: rust-jpegxl-sys-0.8.2-1.fc41
Summary: Rust wrapper for JPEG XL reference implementation
RPMs:rust-jpegxl-sys+default-devel rust-jpegxl-sys+docs-devel 
rust-jpegxl-sys+threads-devel rust-jpegxl-sys-devel
Size:50.77 KiB

Package: rust-libseccomp-0.3.0-1.fc41
Summary: Rust Language Bindings for the libseccomp Library
RPMs:rust-libseccomp+cfg-if-devel rust-libseccomp+const-syscall-devel 
rust-libseccomp+default-devel rust-libseccomp-devel
Size:79.80 KiB

Package: rust-rctree0.5-0.5.0-1.fc41
Summary: 'DOM-like' tree implemented using reference counting
RPMs:rust-rctree0.5+default-devel rust-rctree0.5-devel
Size:22.59 KiB


= DROPPED PACKAGES =
Package: antic-0.2.5-6.fc40
Summary: Algebraic Number Theory In C
RPMs:antic antic-devel
Size:363.85 KiB

Package: arb-2.23.0-6.fc40
Summary: Arbitrary-precision floating point ball arithmetic
RPMs:arb arb-devel arb-doc
Size:7.75 MiB

Package: ktp-contact-runner-23.04.3-2.fc39
Summary: Plasma runner for KDE Telepathy
RPMs:ktp-contact-runner
Size:275.04 KiB

Package: telepathy-logger-qt-17.09.0-10.fc39
Summary: Telepathy Logging for Qt 5
RPMs:telepathy-logger-qt telepathy-logger-qt-devel
Size:462.91 KiB


= UPGRADED PACKAGES =
Package:  NetworkManager-1:1.46.0-2.fc41
Old package:  NetworkManager-1:1.46.0-1.fc41
Summary:  Network connection manager and user applications
RPMs: NetworkManager NetworkManager-adsl NetworkManager-bluetooth 
NetworkManager-cloud-setup NetworkManager-config-connectivity-fedora 
NetworkManager-config-server NetworkManager-dispatcher-routing-rules 
NetworkManager-initscripts-ifcfg-rh NetworkManager-initscripts-updown 
NetworkManager-libnm NetworkManager-libnm-devel NetworkManager-ovs 
NetworkManager-ppp NetworkManager-team NetworkManager-tui NetworkManager-wifi 
NetworkManager-wwan
Size: 26.04 MiB
Size change:  -58.77 KiB
Changelog:
  * Fri Mar 29 2024 Beniamino Galvani  - 1:1.46.0-2
  - Ignore error setting a global cloned MAC address (rh #2270062)


Package:  annobin-12.48-1.fc41
Old package:  annobin-12.46-1.fc41
Summary:  Annotate and examine compiled binary files
RPMs: annobin-annocheck annobin-docs annobin-libannocheck 
annobin-plugin-clang annobin-plugin-gcc annobin-plugin-llvm
Size: 5.39 MiB
Size change:  -6.67 KiB
Changelog:
  * Wed Mar 27 2024 Nick Clifton   - 12.47-1
  - Clang & LLVM Plugins: Allow environment to override fortification level.  
(RHEL-30579)
  - Spec File: Override fortification level and set it to 3.

  * Tue Apr 02 2024 Nick Clifton   - 12.48-1
  - Annocheck: Update heuristics for detecting glibc code in executables.  
(RHEL-30579)


Package:  ansible-collection-awx-awx-24.1.0-1.fc41
Old package:  ansible-collection-awx-awx-24.0.0-1.fc41
Summary:  Ansible modules and plugins for working with AWX
RPMs: ansible-collection-awx-awx
Size: 103.29 KiB
Size change:  183 B
Changelog:
  * Tue Apr 02 2024 Andrew Heath 
 - 24.1.0-1
  - Update to 24.1.0


Package:  ansible-freeipa-1.12.1-2.fc41
Old package:  ansible-freeipa-1.12.1-1.fc40
Summary:  Roles and playbooks to deploy FreeIPA servers, replicas and 
clients
RPMs: ansible-freeipa ansible-freeipa-collection ansible-freeipa-tests
Added RPMs:   ansible-freeipa-collection
Size: 1.23 MiB
Size change:  663.73 KiB
Changelog:
  * Tue Apr 02 2024 Thomas Woerner  - 1.12.1-2
  - New -collection sub package providing the freeipa.ansible_freeipa
collection
  - New build requires for ansible-core and python


Package:  asciigraph-0.7.1-1.fc41
Old package:  asciigraph-0.6.0-1.fc41
Summary:  Makes lightweight ASCII line graphs
RPMs: asciigraph golang-github-guptarohit-asciigraph-devel
Size: 2.47

Re: bad error on console / shell ... any idea ! ?

[Petr Pisar]

V Sat, Mar 30, 2024 at 09:40:46AM -, Cătălin George Feștilă napsal(a):
> I tried this command on the default Fedora installation... the TAB Key gave 
> me this error:
> [root@fedora mythcat]# dnf5 search scV: __reassemble_comp_words_by_ref: 
> command not found
> terminate called after throwing an instance of 'std::invalid_argument'
>   what():  stoi

This is a known issue
 triggered by
upgrading bash-completion to 2.12 version.

-- Petr



signature.asc
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Leslie Satenstein via devel]

Hi Adam,
I lived through the 2011 period, and at that time the number of people 
available for  KDE software support was insufficient. In an earlier response I 
suggested that a single website is where we should be focusing more info about 
the various isos.  

We don't need a separate set of web pages per iso, as it is a disadvange.  A 
user could browse the one Fedora site and select the ISO that suits his needs.

And by the way, I started with Fedora 0.1, when the printed computer magazines 
had CDs with Fedora included. (grin)

Yeah, I remember the big whoo-haaa when we went from 800meg CDs to 2048meg DVDS.

Leslie SatensteinGrandpa, aged 83.
 

On Tuesday, April 2, 2024 at 03:37:30 p.m. EDT, Adam Williamson 
 wrote:  
 
 On Tue, 2024-04-02 at 21:05 +0200, Kevin Kofler via devel wrote:
> 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:
> https://fedoraproject.org/wiki/Features/KDE_Plasma_Desktop_by_default
> 
> Back then, the KDE SIG was NOT willing to support my proposal (even though 
> the timing would have been ideal, given that GNOME was badly hit at the time 
> by the GNOME 3 transition and users disappointed by the radical cuts in 
> customizability). Now they are refloating it as their own, without even 
> citing my original proposal.

Kevin, I know you and I have been around forever and 2011 feels like
yesterday, but it was really quite a long time ago.

Some of the people involved in the proposal didn't even use Fedora in
2011. Heck, there are probably people using Fedora who weren't *born*
in 2011.

If you compare the KDE SIG member list from May 2011 (approx. time of
your old proposal) and the current one, the only people who appear on
both lists are Rex Dieter and Than Ngo, neither of whom is an owner of
this Change proposal.

https://fedoraproject.org/wiki/SIGs/KDE
https://fedoraproject.org/w/index.php?title=SIGs/KDE=239023
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
  --
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Issues with pytest and python-pytest-postgresql

[Mikel Olasagasti]

Hi all,

I'm trying to update python-pytest-postgresql (simple bump) and during
the %check phase I find the following error:

+ /usr/bin/pytest --postgresql-exec=/usr/bin/pg_ctl -k 'not docker' --no-cov
(...)
  File 
"/builddir/build/BUILDROOT/python-pytest-postgresql-6.0.0-1.fc41.x86_64/usr/lib/python3.12/site-packages/pytest_postgresql/plugin.py",
line 67, in pytest_addoption
parser.addoption(
  File "/usr/lib/python3.12/site-packages/_pytest/config/argparsing.py",
line 104, in addoption
self._anonymous.addoption(*opts, **attrs)
  File "/usr/lib/python3.12/site-packages/_pytest/config/argparsing.py",
line 385, in addoption
raise ValueError("option names %s already added" % conflict)
ValueError: option names {'--postgresql-exec'} already added

What I found is that once the postgresql plugin is loaded it conflicts
with the tests of the module.

Any advice on how to solve this issue?

Best regards,
Mikel
--
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Leslie Satenstein via devel]

Perhaps something like the "Everything.iso" could be top-leveled on the 
website, to include Workstation, KDE, et al,   in their full "Everything.iso" 
details. That will let me decide, beforehand, what it is that I want to 
download.
Keep the individual iso-webpage relationship simple, referring to the suggested 
new top-level website pages.


Leslie Satenstein
 

On Tuesday, April 2, 2024 at 03:37:30 p.m. EDT, Adam Williamson 
 wrote:  
 
 On Tue, 2024-04-02 at 21:05 +0200, Kevin Kofler via devel wrote:
> 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:
> https://fedoraproject.org/wiki/Features/KDE_Plasma_Desktop_by_default
> 
> Back then, the KDE SIG was NOT willing to support my proposal (even though 
> the timing would have been ideal, given that GNOME was badly hit at the time 
> by the GNOME 3 transition and users disappointed by the radical cuts in 
> customizability). Now they are refloating it as their own, without even 
> citing my original proposal.

Kevin, I know you and I have been around forever and 2011 feels like
yesterday, but it was really quite a long time ago.

Some of the people involved in the proposal didn't even use Fedora in
2011. Heck, there are probably people using Fedora who weren't *born*
in 2011.

If you compare the KDE SIG member list from May 2011 (approx. time of
your old proposal) and the current one, the only people who appear on
both lists are Rex Dieter and Than Ngo, neither of whom is an owner of
this Change proposal.

https://fedoraproject.org/wiki/SIGs/KDE
https://fedoraproject.org/w/index.php?title=SIGs/KDE=239023
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
  --
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F41 Change Proposal: OpenSSL Deprecate Engine (system-wide)

[Joe Orton]

On Wed, Apr 03, 2024 at 09:50:27AM +0200, Clemens Lang wrote:
> There will always be some effort related to such a transition, but 
> that effort will have to happen one way or the other eventually. I 
> suspect if Fedora decides to keep ENGINE support, we’ll have the exact 
> same discussion in a few years when OpenSSL 4.0 is released, and 
> people will demand that the rebase to 4.0 that removes engine support 
> should be a system-wide change proposal because it breaks engines.

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.

We have to deal with a very large numbers of FTBFS bugs from e.g. Python 
API breaks every other release cycle, or the latest compiler flag 
tuning. The fact that the transition creates work for other package 
maintainers is obviously not a reasonable blocker for a Fedora Change.

Regards, Joe
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: xz backdoor

[Petr Menšík]

Good point. Check testing it is actually expected unix socket would be 
quite nice. Especially when the file sd-daemon.c implements 
sd_is_socket_unix function, but never uses it itself. libsystemd 
verifies this using socket_address_parse_unix or 
socket_address_parse_vsock in pid_notify_with_fds_internal.


All in all, I don't see any good reason, why shared functionality should 
be copy to every project. That is the worst long-term idea 
hindering maintenance of shared functionality. I have been part of 
project having a lot of copy It was quick to write, but hard to 
maintain afterwards. Shared libraries make sense even when they are 
small, especially when that small part is needed often. Which is exactly 
the case of sd_notify variants.


Reusing easy to read and with no dependencies except libc is still much 
better idea.


I think projects having bundled implementation should mark it somehow in 
their packages. Something like Provides: bundled(systemd/sd_notify) ? Or 
bundled(systemd-libs) ? I think such functionality should be searchable 
somehow in the repository. I think we should define how it should be 
marked in case of inline copy. bundled(systemd) seems a bit too strong, 
but according to Bundling specification in packaging guidelines [1].


I like idea in marked comment [2]. It might get even 
launcher-independent way of daemon to signal its readiness. We do not 
support alternatives to systemd, but I see no reason to prevent upstream 
project to reuse the same way for any alternative, which may use 
readiness signal from the service. Other distributions still allow other 
combinations. It would be much better to support alternative process 
managers from shared library than in each project itself.


PS: once again comments are marked as spam, when they simply disagree 
with systemd team stance, but are otherwise to the point. That 
unfortunately makes no constructive discussion possible on systemd 
upstream issues.


1. https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling
2. https://github.com/systemd/systemd/issues/32028#issuecomment-2034099384

On 02. 04. 24 20:05, Kevin Kofler via devel wrote:

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 to regular files, without checking that
"$NOTIFY_SOCKET" is really a socket (or checking it with a TOCTOU
vulnerability), introducing an arbitrary file overwrite vulnerability.

 Kevin Kofler


--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

[Stephen Gallagher]

On Tue, Apr 2, 2024 at 7:41 PM Kevin Fenzi  wrote:
>
> On Tue, Apr 02, 2024 at 04:38:25PM -0400, Stephen Gallagher wrote:
> > On Tue, Apr 2, 2024 at 3:55 PM Steve Cossette  wrote:
> > >
> > > I personally would very much agree with enforcing the use of 2fa on the 
> > > Fedora Account System. Maybe take that opportunity to make it a bit more 
> > > user friendly? (Such as the fkinit prompt requiring the 2fa code being 
> > > added at the end of your password -- to be clear I think the 2fa code 
> > > should be separate)
> >
> > https://pagure.io/fedora-packager/pull-request/179
>
> I agree that fixing the mismatch in prompts might be nice, but why does
> having 2fa seperate make things any better? I mean, it's one more return
> you get to hit. ;)
>
> And... I am not sure about moving the handling of passwords to a bash
> script from a kinit prompt.
>

The kinit is already being run inside a bash script, so if bash is
compromised with a keylogger, you've already lost the game... I'm not
sure how this is worse.

Yeah, it's an extra keystroke, but I think there's value in helping
the user provide the input in the proper format. Right now it's
confusing (particularly since the kinit prompt gives bad information
that we have to warn about).
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

F41 Change Proposal: Switch to DNF5 (system-wide)

[Aoife Moloney]

Wiki - https://fedoraproject.org/wiki/Changes/SwitchToDnf5

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
Change the default package manager from dnf to dnf5.

== Owner ==
* Name: [[User:jkolarik| Jan Kolarik]]
* Email: jkola...@redhat.com

* Name: [[User:jmracek| Jaroslav Mracek]]
* Email: jmra...@redhat.com


== Detailed Description ==
This proposal will implement several topics, which are outlined below.

=== Provider of the dnf command ===
This change proposes to switch the current provider of the
/usr/bin/dnf symlink from dnf to dnf5. Currently, the symlink target
is /usr/bin/dnf-3, provided by the dnf sub-package, python3-dnf. Upon
implementation of this change, the symlink will point to
/usr/bin/dnf5, provided by the dnf5 package.

=== Prepare the upgrade path ===
The dnf5 package, serving as the new provider of the /usr/bin/dnf
symlink, will obsolete the dnf package starting with Fedora 41. Upon
the release of this dnf5 package, upgrading the system or installing
dnf5 will replace the existing dnf package on the system.
Additionally, the dnf5 package will provide a /usr/bin/yum symlink for
backwards compatibility and the dnf-automatic command will be
obsoleted.

=== Feature parity with dnf ===
We aim to cover the majority of use cases available in the existing
dnf package. However, there are some features that may not be
implemented in time. Nevertheless, we plan to deliver them at a later
stage.

 Plugins 
The progress of implementing plugins to match the current set from the
dnf-plugins-core package is tracked
[https://github.com/rpm-software-management/dnf5/issues/389 upstream].
Among the missing plugins, we still plan to implement:

* debuginfo-install plugin
* reposync plugin

 Modularity 
As support for modularity was retired in Fedora 39, dnf5 currently
only implements a basic feature set for listing and enabling/disabling
modules.

=== Background service support ===
A new daemonized service, dnf5daemon, utilizing the D-Bus interface,
is prepared for clients as a sub-package. This will serve as an
alternative or replacement for the PackageKit layer. Integration of
dnf5daemon support into the default Fedora user interface, GNOME
Software, is currently in progress

=== Documentation of API changes ===
The public interface has undergone significant changes to enhance the
user experience and remove unused and obsolete code components. To
facilitate user migration to the new CLI and API interfaces, a
[https://dnf5.readthedocs.io/en/latest/changes.html guide] was
prepared covering all differences compared to the interface provided
by the existing dnf package, along with examples of typical use cases.

=== Deployment tasks ===
During the deployment of the dnf5 package manager as the new default,
several adjustments need to be made both to the infrastructure and the
dnf5 package itself. Some of these adjustments are detailed [[#Release
engineering|below]]. To ensure synchronization and address all
necessary changes, we've established an upstream tracking
[https://github.com/rpm-software-management/dnf5/issues/1057 issue].

== Feedback ==
As this is the second iteration of such a proposal, we've gathered a
lot of feedback from various sources during the first attempt to
accept this change.

=== FESCo inputs ===
A [https://pagure.io/fesco/issue/3039 ticket] discussing the reasons
why the contingency mechanism was invoked for the first attempt of the
proposal was opened by FESCo. It includes a list of items that are
either incomplete or in progress.

Below is a list of issues from the ticket that are still unresolved or
require clarification on their current status. Other items not
mentioned below are considered completed.

 Switch in ELN 
This should not block the proposal, as the current plan is to target
RHEL 11. Integration can occur there after the proposal is implemented
for Fedora 41.

 Aligning configuration with the current state in dnf 
All overrides to match the current state of dnf configuration will be
provided to the Fedora release project, see [[#Apply downstream
configuration overrides|below]].

 System upgrade and offline transactions 
The implementation work has been completed and is already present
upstream. We anticipate extensive testing during the summer, and we
also plan to organize testing days for this purpose.

 Dropping the Snapper plugin 
In dnf5, we've adopted a new approach for implementing functionality
that was previously handled by the Snapper plugin in dnf.

We're introducing the Actions plugin, which offers more capabilities
than the Snapper plugin, including support for running external
applications before or after transactions and interacting with the
dnf5 

F41 Change Proposal: Switch to DNF5 (system-wide)

[Aoife Moloney]

Wiki - https://fedoraproject.org/wiki/Changes/SwitchToDnf5

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
Change the default package manager from dnf to dnf5.

== Owner ==
* Name: [[User:jkolarik| Jan Kolarik]]
* Email: jkola...@redhat.com

* Name: [[User:jmracek| Jaroslav Mracek]]
* Email: jmra...@redhat.com


== Detailed Description ==
This proposal will implement several topics, which are outlined below.

=== Provider of the dnf command ===
This change proposes to switch the current provider of the
/usr/bin/dnf symlink from dnf to dnf5. Currently, the symlink target
is /usr/bin/dnf-3, provided by the dnf sub-package, python3-dnf. Upon
implementation of this change, the symlink will point to
/usr/bin/dnf5, provided by the dnf5 package.

=== Prepare the upgrade path ===
The dnf5 package, serving as the new provider of the /usr/bin/dnf
symlink, will obsolete the dnf package starting with Fedora 41. Upon
the release of this dnf5 package, upgrading the system or installing
dnf5 will replace the existing dnf package on the system.
Additionally, the dnf5 package will provide a /usr/bin/yum symlink for
backwards compatibility and the dnf-automatic command will be
obsoleted.

=== Feature parity with dnf ===
We aim to cover the majority of use cases available in the existing
dnf package. However, there are some features that may not be
implemented in time. Nevertheless, we plan to deliver them at a later
stage.

 Plugins 
The progress of implementing plugins to match the current set from the
dnf-plugins-core package is tracked
[https://github.com/rpm-software-management/dnf5/issues/389 upstream].
Among the missing plugins, we still plan to implement:

* debuginfo-install plugin
* reposync plugin

 Modularity 
As support for modularity was retired in Fedora 39, dnf5 currently
only implements a basic feature set for listing and enabling/disabling
modules.

=== Background service support ===
A new daemonized service, dnf5daemon, utilizing the D-Bus interface,
is prepared for clients as a sub-package. This will serve as an
alternative or replacement for the PackageKit layer. Integration of
dnf5daemon support into the default Fedora user interface, GNOME
Software, is currently in progress

=== Documentation of API changes ===
The public interface has undergone significant changes to enhance the
user experience and remove unused and obsolete code components. To
facilitate user migration to the new CLI and API interfaces, a
[https://dnf5.readthedocs.io/en/latest/changes.html guide] was
prepared covering all differences compared to the interface provided
by the existing dnf package, along with examples of typical use cases.

=== Deployment tasks ===
During the deployment of the dnf5 package manager as the new default,
several adjustments need to be made both to the infrastructure and the
dnf5 package itself. Some of these adjustments are detailed [[#Release
engineering|below]]. To ensure synchronization and address all
necessary changes, we've established an upstream tracking
[https://github.com/rpm-software-management/dnf5/issues/1057 issue].

== Feedback ==
As this is the second iteration of such a proposal, we've gathered a
lot of feedback from various sources during the first attempt to
accept this change.

=== FESCo inputs ===
A [https://pagure.io/fesco/issue/3039 ticket] discussing the reasons
why the contingency mechanism was invoked for the first attempt of the
proposal was opened by FESCo. It includes a list of items that are
either incomplete or in progress.

Below is a list of issues from the ticket that are still unresolved or
require clarification on their current status. Other items not
mentioned below are considered completed.

 Switch in ELN 
This should not block the proposal, as the current plan is to target
RHEL 11. Integration can occur there after the proposal is implemented
for Fedora 41.

 Aligning configuration with the current state in dnf 
All overrides to match the current state of dnf configuration will be
provided to the Fedora release project, see [[#Apply downstream
configuration overrides|below]].

 System upgrade and offline transactions 
The implementation work has been completed and is already present
upstream. We anticipate extensive testing during the summer, and we
also plan to organize testing days for this purpose.

 Dropping the Snapper plugin 
In dnf5, we've adopted a new approach for implementing functionality
that was previously handled by the Snapper plugin in dnf.

We're introducing the Actions plugin, which offers more capabilities
than the Snapper plugin, including support for running external
applications before or after transactions and interacting with the
dnf5 

Orphaned packages looking for new maintainers

[Maxwell G]

Report started at 2024-04-02 16:05:20 UTC

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via the *Take* button in the left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://a.gtmx.me/orphans/orphans.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan

Package  (co)maintainers   Status Change

botan orphan   1 weeks ago  
container-workflow-tool   orphan   1 weeks ago  
emacs-htmlize orphan   1 weeks ago  
kio-upnp-ms   jgrulich, orphan 3 weeks ago  
ktp-contact-runner@kde-sig, orphan, rdieter3 weeks ago  
liquidshell   orphan   5 weeks ago  
loudgain  orphan   3 weeks ago  
mrxvt orphan   3 weeks ago  
nextcloud ichavero, orphan 1 weeks ago  
perl-Git-PurePerl iarnell, orphan  6 weeks ago  
perl-Net-GitHub   jplesnik, lkundrak, orphan,  6 weeks ago  
  ppisar
perl-Spreadsheet-ParseExcel-  jplesnik, orphan, ppisar 6 weeks ago  
Simple  
perl-Spreadsheet-WriteExcel-  jplesnik, orphan, ppisar 6 weeks ago  
Simple  
perl-String-Diff  iarnell, orphan  6 weeks ago  
perl-WWW-Google-Contacts  orphan   3 weeks ago  
php-aws-sdk3  orphan   1 weeks ago  
php-bantu-ini-get-wrapper adamwill, orphan 1 weeks ago  
php-christophwurst-id3parser  orphan   1 weeks ago  
php-deepdiver-zipstreamer orphan   1 weeks ago  
php-doctrine-dbal orphan, remi 1 weeks ago  
php-fgrosse-phpasn1   orphan   1 weeks ago  
php-giggsey-localeorphan   1 weeks ago  
php-guzzlehttp-guzzle6orphan   1 weeks ago  
php-league-uri-interfaces orphan   1 weeks ago  
php-opencloud-openstack   orphan   1 weeks ago  
php-opis-closure  orphan, remi 1 weeks ago  
php-phpSmug   orphan   5 weeks ago  
php-pimpleorphan   1 weeks ago  
php-punic orphan   1 weeks ago  
php-ralouphie-getallheaders   orphan   1 weeks ago  
php-scssphp   orphan   1 weeks ago  
php-stecman-symfony-console-  orphan   1 weeks ago  
completion  
python-aiomqttorphan   4 weeks ago  
python-autoprop   orphan   4 weeks ago  
python-colorcet   orphan   4 weeks ago  
python-extractcode@python-packagers-sig, orphan3 weeks ago  
python-jose   orphan   0 weeks ago  
python-limits orphan   3 weeks ago  
python-param  orphan   4 weeks ago  
python-pyct   orphan   4 weeks ago  
python-signature-dispatch orphan   4 weeks ago  
python-vecrec orphan   4 weeks ago  
telepathy-logger-qt   @kde-sig, jgrulich, orphan   3 

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Steve Cossette]

It is not an april fools joke.

On Wed, Apr 3, 2024 at 04:37 Peter Boy  wrote:

>
>
> > Am 02.04.2024 um 22:06 schrieb Steve Cossette :
> >
> > ... The overall spirit of the CP is that we think KDE, and to some
> extent the other spins too, need a bit more visibility on the website. …
> > ...
> > We've been discussing it in Matrix, and we can't seem to reach a
> consensus as to what is the best way to initiate the discussion procedure.
> Figured a change proposal was probably a decent way to "kick the hornet's
> nest", so to speak.
> >
> > We essentially just want more visibility on the website, if that makes
> sense.
>
> That sounds pretty much like an April Fool's joke (and an abuse of the
> change proposal process).  A pity in a way, but perhaps better this way,
> given the miserable debate about Wayland / X11 recently.
>
>
>
> --
> Peter Boy
> https://fedoraproject.org/wiki/User:Pboy
> p...@fedoraproject.org
>
> Timezone: CET (UTC+1) / CEST (UTC+2)
>
> Fedora Server Edition Working Group member
> Fedora Docs team contributor and board member
> Java developer and enthusiast
>
>
>
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: xz backdoor

[Lennart Poettering]

On Di, 02.04.24 19:44, Petr Menšík (pemen...@redhat.com) wrote:

> Function pid_notify_with_fds_internal from
> ./src/libsystemd/sd-daemon/sd-daemon.c certainly is not just few lines, as
> suggested. Should I ask why, if not necessary?

The version in sd-daemon.c is a bit more complex because it supports a
few things typically not necessary:

- In systemd we support sd_notify() also via AF_VSOCK. i.e. PID 1 will
  send sd_notify() messages itself to a supervisor VMM or similar, to
  inform it when the system is booted up. It uses the very same protocol
  as we usually use via AF_UNIX, but over AF_VSOCK. Support for
  AF_VSOCK should be completely unnecessary for anyone but systemd
  (i.e. PID1) itself, hence we didn't add it to the copy/paste version
  version. The AF_VSOCK thing is awesome btw, because it allows you to
  properly schedule activation of a bunch of VMs in order, with
  correct waiting until they are ready to respond.

- The code allows overriding the sender struct ucred (i.e. the
  SCM_CREDS control message te service manager will see). This exists
  to implement the "systemd-notify" tool, which is always going to the
  be a child process of the shell script it is invoked off, and which
  wants to patch the sender PID hence to its own PPID. Nothing should
  need that except of that tool.

- The code allows sending along fds to the service manager, to make
  use of the "fdstore" concept in systemd (i.e. the service manager
  can keep copies of a service's active fds in escrow, so that the
  service can implement seamless restrats without losing any
  resources).

So yes, most folks won#t need any of these three things, hence the
copy version of the code doesn't mention it.

> I think they preferred having fast fix over having long-term sustainable
> solution. I haven't seen offer to provide libsystemd-notify library with
> minimal dependencies, which they kindly refused. They preferred bundled code
> over systemd bloat in comment #13. I haven't seen bloat-less library
> considered in the bug, but might have missed it?

uff, "bloat", "bloat", "bloat".

I mean, libsystemd in git main doesn't pull in the compression libs
anymore, it doesnt pull in gcrypt either. It pulls in libc and libcap
only. Do you have a problem with these libraries?

Or are you concerned about the extra space in memory? Well, libsystemd
is going to be in memory anyway, you might as well use it. After all,
if Linux is smart enough to load it into memory only once, and just
give each consumer their own immutable memory map. Or in other words,
having yet another shared lib in the mix just makes things worse: more
of the same code, not less...

The way I see it, there are two options from my systemd perspective:

1. Use libsystemd.so, it doesn't pull in any other deps anymore
   (except for libc and libcap), and is installed everywhere anyway.

   Use this when:
   - Your project is in C
   - You don't care about an extra dep
   - You use the other stuff libsystemd offers anyway (i.e. sd-bus,
 sd-event or so)

1. Roll your own sd_notify(). [In case you hack is a C project: you can start
   with the copylib the man pages now include
   (i.e. 
https://www.freedesktop.org/software/systemd/man/devel/sd_notify.html#Notes)
   and adjust it to your framework of choice, coding style and so
   on. i.e. adjust the error handling, logging to your choice.]

   Use this when:
   - Your project is not in C or
   - You really don't want an extra dep

Lennart

--
Lennart Poettering, Berlin
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Peter Boy]

> Am 03.04.2024 um 03:51 schrieb Kevin Kofler via devel 
> :
> 
> Fedora 21 has introduced the Editions vs. Spins distinction, Fedora 2*21=42 
> would be a good time to retire it.


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.




--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast



--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Peter Boy]

> Am 03.04.2024 um 03:18 schrieb Adam Williamson :
> 
> 
> I mean, we really don't need to speculate about this much. We did an
> entire overhaul of the project - Fedora.next - which was explicitly
> based around making it much more focused and less of a choose-your-own-
> adventure, …


And let's not forget that we set special requirements for an edition and an 
edition working group behind it, which should (and does) ensure ongoing 
maintenance and user orientation in the long term (even if the latter 
unfortunately too often takes a back seat). 




--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast



--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Peter Boy]

> Am 02.04.2024 um 22:06 schrieb Steve Cossette :
> 
> ... The overall spirit of the CP is that we think KDE, and to some extent the 
> other spins too, need a bit more visibility on the website. …
> ...
> We've been discussing it in Matrix, and we can't seem to reach a consensus as 
> to what is the best way to initiate the discussion procedure. Figured a 
> change proposal was probably a decent way to "kick the hornet's nest", so to 
> speak. 
> 
> We essentially just want more visibility on the website, if that makes sense.

That sounds pretty much like an April Fool's joke (and an abuse of the change 
proposal process).  A pity in a way, but perhaps better this way, given the 
miserable debate about Wayland / X11 recently. 



--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast



--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Iñaki Ucar]

El mié., 3 abr. 2024 3:22, Adam Williamson 
escribió:

> On Tue, 2024-04-02 at 21:15 -0400, Steve Cossette wrote:
> > I get your point, Kevin. I would argue though that, if a user is looking
> to
> > use Linux, they probably got a decent idea as to what DE they want to
> use.
> > There are SO MANY LINUX DISTROS! Making a choice between two is
> > honestly probably not that jarring imo.
>
> I mean, we really don't need to speculate about this much. We did an
> entire overhaul of the project - Fedora.next - which was explicitly
> based around making it much more focused and less of a choose-your-own-
> adventure, specifically including making the download page much more
> opinionated. AFAIR, the numbers Matthew tracks strongly indicate this
> was associated with a very significant immediate bump in Fedora usage.


How do we measure "usage" and how do we attribute the bump to the change in
the download page? Did we A/B test the new page?

Iñaki
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F41 Change Proposal: OpenSSL Deprecate Engine (system-wide)

[Clemens Lang]

Hi,

> On 2. Apr 2024, at 16:31, Luca Boccassi  wrote:
> 
> The fact that such packages are physically present is not enough - they need 
> to implement all the needed features, and they need to be mature enough to 
> just work out of the box. Neither of these are true today, and providers just 
> do not work for very simple use cases like signing a UKI with a yubikey. At 
> the very least a couple more years of development and testing is needed 
> before they are anywhere near ready to drop support for engines, that 
> actually do work out of the box. Not to mention third party engines that are 
> specific to internal/private build systems - if any such system runs Fedora 
> as the build host, they'd have to migrate to Debian/Ubuntu to keep working.


I did try using the current pkcs11-provider with my Yubikey to create a 
signature using openssl dgst -sign 
'pkcs11:serial=18c9662a9c930e9e;id=%02;type=private'. It worked just fine for 
me, including prompting for the PIN, twice.

I did have to enable the PKCS11 provider in my openssl.cnf, but that could also 
be done programmatically at runtime by applications should they choose to do so.

I was not able to reproduce the problems you faced in the systemd upstream 
ticket you referred to earlier. It is possible that they have been fixed 
upstream in the meantime.

There will always be some effort related to such a transition, but that effort 
will have to happen one way or the other eventually. I suspect if Fedora 
decides to keep ENGINE support, we’ll have the exact same discussion in a few 
years when OpenSSL 4.0 is released, and people will demand that the rebase to 
4.0 that removes engine support should be a system-wide change proposal because 
it breaks engines.


-- 
Clemens Lang
RHEL Crypto Team
Red Hat


--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Luis Correia]

On Wed, 3 Apr 2024 at 03:24, Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:

> 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 have to choose" should
> be
> a concious choice, also considering that the mostly unconfigurable (by
> design) GNOME is very likely to be the wrong option for anybody not in
> that
> category. And besides:
>
> > (Which is pretty much what we have now)
>
> Well, not quite, it is more like:
>
> [LOGO Workstation (Download Now) (Learn More)]
>
> [LOGO Server (Download Now) (Learn More)]
>
> [LOGO IoT (Download Now) (Learn More)]
>
> [LOGO Cloud (Download Now) (Learn More)]
>
> [LOGO CoreOS (Download Now) (Learn More)]
>
> Want more Fedora options?
>
> Atomic Desktops (Learn More) ← no frame nor logo nor mention of "download"
>
> Fedora Spins (Learn More) ← no frame nor logo nor mention of "download"
>
> Fedora Labs (Learn More) ← no frame nor logo nor mention of "download"
>
> Fedora ALT Downloads (Learn More) ← no frame nor logo
>
> So you get offered a lot of (most likely) irrelevant (to you) options
> (Server, IoT, Cloud, CoreOS) before even being told that there are more
> options than those (and Workstation), the "Workstation" link does not tell
> you that (even though those are clearly workstation/desktop-targeted
> options
> too), and you also do not see the full list of options anywhere, but just
> a
> list of lists. You actually have to click on "Learn More" after "Fedora
> Spins" to even see what desktop environments are available.
>
> Kevin Kofler
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue


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.

(sorry for the slight offset in conversation)

Luis
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Call for Action] Testing Alibaba Cloud for Fedora CoreOS 40

[Sumantro Mukherjee]

Hey folks,

As many of you might know, we are currently running the Fedora 40
CoreOS Test Week.[0]
We would like to have anyone with Alibaba account to run this test
case[1] and report [2] under
Alibaba column.

Should you have any questions, please let us know via email or
https://matrix.to/#/#test-day:fedoraproject.org

[0] http://fedoraproject.org/wiki/Test_Day:Fedora_40_CoreOS
[1] https://fedoraproject.org/wiki/QA:Testcase_CoreOS_Alibaba
[2] https://testdays.fedoraproject.org/events/179
-- 
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

[Andreas Schneider]

On Wednesday, 3 April 2024 01:34:00 CEST Gordon Messmer wrote:
> On 2024-03-30 11:52, Dmitry Belyavskiy wrote:
> > We have an upstream-adjusted version of this patch, see
> > https://bugzilla.mindrot.org/show_bug.cgi?id=2641
> > I'm OK to bring the updated version of this script to Fedora as soon
> > as it is finalized.
> 
> I proposed https://src.fedoraproject.org/rpms/openssh/pull-request/72 ,
> which uses the implementation from
> https://www.freedesktop.org/software/systemd/man/devel/sd_notify.html#Notes

Thanks for the contribution, but please use https://bugzilla.mindrot.org/
show_bug.cgi?id=2641#c13 instead.

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

[Gordon Messmer]

On 2024-04-01 23:59, Gordon Messmer wrote:

On 2024-03-30 13:18, Gordon Messmer wrote:
The write up describing the back door indicates that the malicious xz 
library "changes the value of rsa_public_decr...@plt to point to 
its own code."  So the back door has pointed one of the symbols that 
should point to a page mapped to OpenSSL's libcrypto.so.3 to a page 
mapped to liblzma.so.5, instead.


Would it be possible to audit the value of a process's symbols at 
runtime to look for this kind of shenanigans?  Could this type of 
auditing be added to functional tests or rpminspect?


As a proof of concept, I extended GEF a tiny bit: 
https://github.com/gordonmessmer/gef 



I spent a little more time extending GEF further, as a new "got-audit" 
command.  The command will report an error if two or more libraries 
appear to export conflicting symbols.  It will also report an error if a 
symbol in the GOT points to a shared object that doesn't appear to 
export that symbol.  For all symbols in the GOT, it reports a mapping 
between the symbol and the path where that symbol is mapped.


I'll work on a functional test for the openssh package.  I think the 
naive approach is to simply record the known-good output of the audit in 
a file in the test's directory, run the "got-audit" command, and compare 
the two files.  Any difference is an error.


I haven't started on that yet, but the "port-forward" test seems fairly 
small and simple, so I'll try writing something similar, unless anyone 
has suggestions otherwise.


--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue