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

[Naheem Zaffar]

On Thu, 4 Apr 2024, 16:35 Kevin Kofler via devel, <
devel@lists.fedoraproject.org> wrote:

> Neal Gompa wrote:
> > By default, GNOME only presents the close window button. The other
> > buttons are missing, and there isn't really an intuitive way to
> > discover the other window management actions.
>
> In the version I tried, and judging from end user reports, for several
> years, it did not even present that, leading to fun issues such as some
> KDE
> dialogs that could not be closed at all (because they were missing a
> "Close"
> button and relying on the window decoration exclusively).
>
> >> "the shut down options in the mouse menu hidden behind a keyboard dead
> >> key, etc.)" this is also not the case for ages, or at least not in its
> >> completeness.
> >
> > Yes, this did change a few GNOME releases ago.
>
> Of course, having only tried GNOME 3 once, I could not know this.
>

Of course the right thing to do when faced with a topic where you lack
knowledge is to not throw shade and either learn it first or decide others
know better and not comment.

What has been really awkward about this proposal is that instead of
focussing on the benefits of Plasma, it's used as more of an axe to grind
about gnome. Not unexpected considering the lead proposer.

However that is not helpful.

If you need to define gnome in order to promote plasma, you are doing it
wrong.

>
> 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
>
--
___
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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Naheem Zaffar]

On Sun, 4 Feb 2024, 23:16 Sérgio Basto,  wrote:

> On Sun, 2024-02-04 at 03:55 +0100, Kevin Kofler via devel wrote:
> > Neal Gompa wrote:
> > > It's extremely obvious that people want to use it. You replied to
> > > someone who did and denigrated their opinion. Frankly, I'm
> > > disappointed in your response as well as the tone of you and Kevin.
> >
> > I cannot really speak for Sérgio. I do think his choice of words in
> > the
> > particular mail you are referring to could have been better. (In
> > particular,
> > I would not have used the word "crap" there.) But please keep in mind
> > that
> > he (like me) is not a native English speaker.
> >
>
> I haven't time to read all messages on this thread
>
> My conclusion is, we have false arguments , that Xorg is old, that is
> not maintained, that will give more work , even we got some lies on
> some arguments and when we disassemble these arguments, they came up
> with new ones, now is the tone . I know would be very fancy only have
> wayland , modern  etc etc . But the true is they have the work of
> remove X11 and not the opposite.
>
> Other thought it is obvious that KDE 6 will be a disaster, I remember
> Kevin step up from leader of KDE SIG, after move from KDE 3 for 4 or 4
> for 5 because the work was too much and we need have a life.
>
> And the problem here is, we haven't an agreement , since the first day
> of proposal many people said that was not acceptable and there opinions
> were ignored and the proposal haven't changed one bit.
>
> I think, I and Kevin so be added to the KDE SIG , please add me at
> least (here is the request) .


Wouldn't it be better to create a new totally different named SIG?

Since bug reporting and crossover of people assuming it is official fedora
plasma are the concerns, a totally independent named SIG and an
independently named desktop should be considered serious options as that
way the extra work can be avoided for the current KDE SIG.

That way you can even have a desktop with a different name so people will
not think to file bug reports with plasma etc., avoiding problems with
overloading the SIG with work.


>
> I think is stupid and a waste of energy, IMO, do a kwin-x11 and plasma
> -x11 , like I said KDE SIG had the work of remove X11 from the builds,
> to enable kwin-x11 on Fedora Rawhide is just set %bcond to 1 on
> kwin.spec [1] and plasma-workspace.spec [2], so I think that should be
> enable.
> Another way is build the entire package with X11 and conflict with the
> original because will give us less work and we will have less doubts or
> user use packages from KDE SIG or user use packages from KDE-X11 SIG
> and can't use both. Like happens with ffmpeg where also Neal haven't
> reach to an agreement with members of RPMFusion , so now we have ffmpeg
> from  RPMFUSion with one freeworld sub-package and we have fffmpeg-free
> from Fedora and ffmpeg(s) conflicts each other .
>
> It never happened to me such thing , except recently and all cases with
> Neal directly involved, so I see Neal as the problem, was ImageMagick ,
> was ffmpeg, was LSB , now KDE and one honest advice for Neal who
> appears everywhere, try to do fewer things but be more focused
>
>
> [1]
> https://src.fedoraproject.org/rpms/kwin/blob/rawhide/f/kwin.spec#_2
>
> [2]
>
> https://src.fedoraproject.org/rpms/plasma-workspace/blob/rawhide/f/plasma-workspace.spec#_2
>
>
>
>
> > I can, though, speak for myself, and I am frankly surprised that you
> > are
> > offended by the tone of my messages. Are you sure that it is not the
> > content
> > that upsets you rather than the tone? And if it is, try asking you
> > why the
> > content upsets you. Maybe because it points out inconvenient facts?
> >
> > > Neither of you are aligning with the Fedora Foundation of Friends,
> > > and
> > > the personal attacks were unwarranted and unwanted.
> >
> > We (the KDE SIG and me) stopped being Friends when you (the KDE SIG)
> > unilaterally decided to ban me from all your communication channels,
> > a ban
> > that has still not been lifted years after the alleged misconduct (on
> > IRC
> > only, but the ban was extended to the mailing list and even your
> > Pagure
> > issue trackers!) you accused me of.
> >
> > Nevertheless, I am really trying hard to not make this personal. What
> > I
> > disagree with is the technical decision to remove X11 support from
> > the
> > Fedora Plasma packaging. I also objected right when you filed your
> > Change
> > Proposal that the KDE SIG has no authority to declare in the Change
> > that
> > Fedora will NOT ship something because other packagers are free to
> > package
> > it. A belief that at the time was actually shared by the KDE SIG, or
> > at
> > least by the one KDE SIG member who has publicly commented on it:
> >
> https://discussion.fedoraproject.org/t/f40-change-proposal-kde-plasma-6-system-wide/89794/11
> > Though the wording in the Change Proposal was not changed. Possibly
> > because
> > you did not believe at the 

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Naheem Zaffar]

Another option is to allow the x11-compatible packages but as a clearly
forked desktop with a clearly different name

On Thu, 1 Feb 2024, 12:10 Steve Cossette,  wrote:

> So, if you all don't mind, I'd like to steer this discussion in a slightly
> different way:
>
> What *is* the definition of a Fedora Change Proposal?
>
> I was under the impression it was an announcement of intent by the
> maintainers of a specific subset of the fedora project to "change"
> something. Once said announcement has been discussed publicly, Fesco (Sorry
> if the capitals are incorrect) discusses it internally (albeit, publicly)
> and either blocks or approves the change, making it official.
>
> *(Please note: The following paragraphs will use "we" as a pronoun which
> is intended to be the Fedora project as a whole)*
>
> Once approved, we announced our intent to drop X11 from the KDE spin of
> Fedora. That announcement has gained traction everywhere, got publicized
> and everything. As Neal Gompa also stated, it has already caused some
> substantial development effort upstream to effectively iron out the rough
> edges of many of the problems, with what I assume is more to come.
>
> My fear is that, while those x11 libraries/runtimes/... *would* indeed no
> longer be maintained by the KDE sig, we would basically just be partially
> rolling back that initial proposal. And the quality of said packages would
> also maybe suffer from them being updated separately, which might also
> reflect poorly on us (*again, in this context, "us" = the Fedora Project)*
> .
>
> It would also introduce a precedent: What if later a proposal is made to
> remove some old drivers from, let's say, the kernel, and someone decides to
> package it, undermining the general efforts of that proposal?
>
> Hopefully I'm making sense. Writing this 30mins after waking up might not
> have helped. What I'm trying to say basically is, I get that for some
> legacy nvidia users the Wayland experience may not be optimal. But will it
> *ever* be? Does that mean we can never drop x11? Will anyone ever update
> those legacy nvidia drivers? *Could they be?*
>
> Le mar. 30 janv. 2024, à 07 h 48, Sérgio Basto  a
> écrit :
>
>> Link to the FESCo ticket: https://pagure.io/fesco/issue/3165
>>
>> and I'm very upset
>>
>> --
>> Sérgio M. B.
>> --
>> ___
>> 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

Re: KDE and GNOME Join Hands To Add Payments To Turn Flathub Into a Store for the Linux Desktop

[Naheem Zaffar]

On Fri, 1 Sep 2023, 13:37 JT,  wrote:

> That looks like it's just a proposal by some random people that KDE and
> GNOME should to work together.  I've not seen a statement by either
> desktop. the file referenced is literally under a directory called
> "proposals". and I've never heard of this "Plaintext Group" before.
> It does not look like KDE and GNOME have agreed to anything.
>
>
> On Wed, Aug 30, 2023 at 6:19 PM Ryan Bach via devel <
> devel@lists.fedoraproject.org> wrote:
>
>> It would be nice for Redhat to monetize the Desktop. What do you guys
>> think?
>>
>>
>> https://www.reddit.com/r/linux_gaming/comments/11accyi/kde_and_gnome_join_hands_to_add_payments_to_turn/
>> 6 mo. ago
>>
>
That proposal was rejected as the plaintext group were not accepting any
more funding proposals.

There are other avenues being explored, but it is a distro agnostic
approach via creating a legal entity for flathub to cover it all.

For Red Hat, it may be beneficial if they had an LTS flatpak store
(freedesktop runtime is inky supported for 3 years whilst the RHEL runtime
is for 10 years) if they can convince major companies like Adobe to use it.
Otherwise it wont have much benefit to end users.


___
>> 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

Re: Update on DNF05 in Fedora

[Naheem Zaffar]

On Thu, 27 Jul 2023, 21:23 Kevin Fenzi,  wrote:

> On Thu, Jul 27, 2023 at 02:54:13PM -0400, DJ Delorie wrote:
> > Samantha Bueno  writes:
> > > We've gone ahead and decided not to replace DNF with DNF05 in Fedora
> > > 39 and, perhaps notably, Fedora 40 as well.
> >
> > For those of us who upgraded to DNF05 in rawhide to test it, is there a
> > quick reference for our paths forward?  Er, backward?  I upgraded at the
> > wrong time and spent half a day recovering my system, I'd rather avoid
> > that if I have to go back to DNF04...
>
> I would expect a revert back to where /usr/bin/dnf is dnf4 (but
> hopefully dnf5 is still available/seperate).



Dont they have different/incompatible  database formats/locations where
dnf4 does not track updates via dnf5 and vice versa?

>
>
> Hopefully that can happen before branching in a few weeks.
>
> 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: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)

[Naheem Zaffar]

On Sat, 8 Jul 2023, 01:08 Randy Barlow via devel, <
devel@lists.fedoraproject.org> wrote:

> On 7/7/23 19:59, Demi Marie Obenour wrote:
> > That is not consent.  The GDPR explicitly states that consent must
> > be opt-IN.
>
> I agree.
>
> I think it is important to make it possible for a user to ask for the
> data collected from their machine to be deleted in the event they
> mistakenly submitted data, or changed their mind.
>

Wouldnt that require the data to be individually identifiable?

___
> 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: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

[Naheem Zaffar]

On Fri, 23 Dec 2022 at 08:26, Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:

> On 23/12/2022 09:20, Mattia Verga via devel wrote:
> > I know this is way harder, but the right approach would be having a way
> > to tell systemd what processes can be killed and what other processes
> > must not be forced off in any case, then display a user friendly message
> > which inform the user that the system cannot be forced off ATM "because
> > I'm doing this or that". In the worst case, the user can choose to pull
> > the plug themselves.
>
> I agree. Terminating the PackageKit service while updates are being
> installed can result in a broken system.
>

Is there a way to be smarter about all this?

1. Set default at 15s or something short.
2. For services known to require longer (older pinephone modem firmware,
libvirtd), allow a larger timeout for that specific service only
3. For services that should NOT be terminated have a mechanism for them to
not be cut off

-- 
> Sincerely,
>Vitaly Zaitsev (vit...@easycoding.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
>
___
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: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Naheem Zaffar]

> > what is the impact of the proposed change on non-x86 platforms? I
> > assume the proposal focuses on x86, but the distro wide flags are shared
> > across all platforms in Fedora, it means aarch64, ppc64le and s390x.
> > With RISC-V waiting behind the door ...
>
> None, because this proposal is not going to be implemented.
>

AFAIK none, but not for that reason: it seems to already be implemented and
part of the aarch64 abi. It would be helpfulmfornthe change request to
confirm this.

For the python code, also none because it will also be implemented as
default via upstream in python 3.12 and thus coming to fedora even without
this change request.

So the situation will be that the slowest mainstream arch and the slowest
mainstream code on all arches will have frame pointers enabled, but not on
the fastest arch for the fastest code.

>
___
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: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Naheem Zaffar]

On Tue, 8 Nov 2022, 19:22 Vitaly Zaitsev via devel, <
devel@lists.fedoraproject.org> wrote:

> On 08/11/2022 19:53, Naheem Zaffar wrote:
> > Has there been any consideration to turn on frame pointers for atleast
> > dev releases?
>
>
> Fedora has no dev releases. Mass rebuild is a huge pain for maintainers
> due to FTBFS issues, and doing it multiple times is unacceptable.
>
I think I explained the idea poorly.

Not all builds in rawhide are release builds. You will get for instance the
whole gnome stack beta releases and rc releases during development.

This isnt limited to gnome, most software will go into rawhide first to
stabilise.

It is almost never intended for these builds to end up in the final
release  ll, but they are useful and necessary parts of the development
cycle. Theywill be replaced before general availability, all without a mass
rebuild.

It's not a silver bullet solution but atleast it starts things off on a
path where profiling can be done in a limited manner compared to the other
proposed alternatives where the tooling doesnt exist and will likely not
ever be written.

>
>
___
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: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Naheem Zaffar]

Has there been any consideration to turn on frame pointers for atleast dev
releases?

AFAIK the kernel already has a separate configuration during the
development phase of the distro-cycle

Can this be extended for rebuilds of alpha and beta releases in rawhide to
turn on frame pointers as an interim solution until everything else is
figured out?
___
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: libbautilus-extension 3 no longer available?

[Naheem Zaffar]

With its move to gtk4, the  nautilus extensions api has been changed:
https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/927 (plus another
merge request moving the extension location to the correct place).

Brasero (and others) require more than just bumping to higher API version
number.
___
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: F37 proposal: Officially Support Raspberry Pi 4 (Self-Contained Change proposal)

[Naheem Zaffar]

On Sat, 9 Jul 2022, 03:37 Allan via devel, 
wrote:

> On Tue, 5 Jul 2022 23:21:36 +0200
> Miro Hrončok  wrote:
>
> > On 05. 07. 22 23:16, Ben Cotton wrote:
> > > The work around Raspberry Pi 4 has been on going for a number of
> > > years, but we've never officially supported it due to lack of
> > > accelerated graphics and other key features. A few of us have led
> > > the push to get the accelerated graphics work over the line
> > > upstream so it now makes sense to enable this in Fedora and make
> > > support for the Raspberry Pi 4 more official.
> >
> > I don't understand what is actually proposed by this change proposal.
>
> I can't see any change here in any polices of Fedora too.
>
> Please explain what really IS the CHANGE


Fedora will be able to support being installed on and having accelerated
graphics on  raspberry pi 4.

It's a milestone, an announcement. Almost like a change notice announcing
that next Fedora will come with next gnome/kde/kernel/samba.

There may be (some times a lot of) work to integrate it and there may be
fedora contributors making it happen and doing upstream development, but it
doesnt require changes in policy or focus.

>
>
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Support for Realtek RTL8811CU (WiFi)

[Naheem Zaffar]

On Thu, 30 Jun 2022, 23:50 Christopher Klooz,  wrote:

> It seems that Fedora does not support the Realtek RTL8811CU for WiFi. A
> user at ask.Fedora just had the issue. `lsusb` classifies it just as
> "Bus 001 Device 010: ID 0bda:c811 Realtek Semiconductor Corp. 802.11ac
> NIC"; correspondingly, `nmcli` does not recognize it at all.
>
> A bug report with some improvised interim-solutions seems to already
> exist https://bugzilla.redhat.com/show_bug.cgi?id=1957828 , the most
> widespread solution seems to be https://github.com/brektrou/rtl8821CU
> (but unknown maintenance).
>
> Is it known why the 8811CU remains unsupported? Or have I missed something?
>
> Regards,
> Chris
>

Fedora does not include out of tree kernel modules. To get it into fedora,
the module will need to be included in the upstream kernel.

>
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Naheem Zaffar]

and the proprietary one could have a blacklist for very bad packages.

The ability remains to filter if there is a package that is considered bad
or malicous. The default is just changed to an allow list. Secondly if
there is a malicious package, it will probably be faster to contact flathub
and have them take action that make a downstream update to block it.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Donate 1 minute of your time to test upgrades from F34 to F35

[Naheem Zaffar]

 I didnt log the error messages but when rebasing Fedora Silverblue, there
was an issue that I encountered:

In Silverblue 34 I had at some point clicked "enable workstation
repositories" in Gnome Software and forgotten about it. This added a layer
with the relevant rpms.

As this rpm is now in the main compose, rebasing streams caused problems. I
had to reset the Fedora 34 install to not include the layered packages
before rebasing.

As the prompt was from the GUI, I suspect a lot of Silverblue users will
hit this.

other than that it was a smooth upgrade.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)

[Naheem Zaffar]

On Fri, 20 Nov 2020 at 16:27, Ben Cotton  wrote:

> https://fedoraproject.org/wiki/Changes/DefaultPipeWire
>
>
>
> == Scope ==
> * Proposal owners:
> We would make a pipewire-pulse package that provides the same features
> as the pulseaudio (daemon) package.
> We would only provide a drop-in replacement daemon, the pulseaudio
> client libraries will remain unchanged.
>
> The idea is that when installing pipewire-pulse, only the pulseaudio
> package is removed and replaced by the
> pipewire-pulse implementation.
>

Is it required to make the packages conflict?

The implementation that is used needs to have its service activated.

I understand the need for replacing pulseaudio package when upgrading, but
it should be possible to have both installed and have the service from only
one activated? Atleast for current fedora that will make it easier to test
and switch between implementations.
___
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

Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)

[Naheem Zaffar]

On Fri, 20 Nov 2020 at 19:47, Brandon Nielsen  wrote:

> On 11/20/20 1:28 PM, Dominique Martinet wrote:
> > Ben Cotton wrote on Fri, Nov 20, 2020:
> l the pipewire-pulse library (which
> >> removes the pulseaudio package).
> >
> > Took me some time to figure out how to test:
>
> [Snip]
>
> Me too.
>
> I think for current F33 / Rawhide you're expected to create some
> symlinks manually:
> https://gitlab.freedesktop.org/pipewire/pipewire/-/snippets/1165


I don't think this is the the correct way any longer. Lib-Pulse was AFAIK
the initially planned drop-in replacement for pulseaudio. This has since
been deprecated. Pipewire-Pulse AFAIK provides a separate pulseaudio
server. I dont think it needs any linking, other than software activation.

It would be great however if the change request clarified what needs to be
done - especially taking into account that very recent online instructions
now may be wrong.
___
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

Re: RHEL 9 and modularity

[Naheem Zaffar]

On Mon, 22 Jun 2020, 02:57 clime,  wrote:

> On Fri, 19 Jun 2020 at 01:59, Josh Boyer  wrote:
> >
> > On Thu, Jun 18, 2020 at 5:51 PM clime  wrote:
> > >
> > > On Thu, 18 Jun 2020 at 15:25, Josh Boyer  wrote:
> > > >
> > > > On Thu, Jun 18, 2020 at 9:05 AM Igor Raits
> > > >  wrote:
> > > > >
> > > > > -BEGIN PGP SIGNED MESSAGE-
> > > > > Hash: SHA512
> > > > >
> > > > > On Thu, 2020-06-18 at 08:44 -0400, Josh Boyer wrote:
> >
> > 
> >
> > > > > > Hopefully that provides some context and helps FESCo and the
> wider
> > > > > > community understand where Red Hat is headed with modularity on
> the
> > > > > > Enterprise side.
> > > > >
> > > > > Sadly no. It helps to understand your plans, however it does not
> help
> > > > > to understand the reasons behind, whether you can't change UX in
> the
> > > > > RHEL 9, or you think that technology is good enough for your
> use-cases
> > > > > or any other reasons.
> > > >
> > > > The base requirement is that the UX remain largely the same.  As I
> > > > said, from a RHEL perspective, we need RHEL 8 and RHEL 9 to have
> > > > commonality so that our customers are not forced to learn something
> > > > entirely different to adopt RHEL 9.  Improvements in the underlying
> > > > functionality are of course welcome and planned, but we are not going
> > > > to do something like replace modules with a different artifact type,
> > >
> > > Hello Josh,
> > >
> > > you can change the artifact type while keeping interface the same and
> > > it would be a _HUGE_ win because it would make modularity finally
> > > understandable for mere humans and better maintainable.
> > >
> > > Namely, modules should become rpms and therefore obey standard rpm
> rules.
> >
> > I'm not sure I entirely understand what you mean, but it sounds like
> > you have some interesting ideas.
> >
> > I'm looking forward to seeing what you and the community can build
> > from them, and how they could be brought into RHEL 10+!  That kind of
> > collaboration is what makes Fedora great.
>
> I know this probably won't change anything because this was mentioned
> many times (by me at least) and nothing has changed but still...
>
> Currently, modules are essentially yum sub-repos, they are not really
> "modules", instead they are collections of rpms that reinvent rpm-like
> relations (obsoletes, requires, build-requires, etc.).
>
> There is no reason for this wheel-reintervention. Modules (the
> collections) can be simply squashed into an rpm by automation and this
> resulting rpm can go to the modular repo together with other modules.
>
> That way we don't have two types of objects we complex inter-relations
> but only one we well-known behavior.
>
> I wonder if this is clear to everyone but nobody really cares or
> doesn't really want to say it or I don't know.
>
> Is this clear to everyone? I mean either I am stating an obvious stuff
> that nobody really considers worth typing or idk.
>

How would this work when there are optional rpms in the module?

You do not need to install every rpm in  eg the php module (different
graphics/database backends) for that module to be useful, but every version
of the module will have the rpm as an option which wont work outside a
module of multiple rpms.

>
___
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

Re: Does the installer detects when a distro have already created BLS?

[Naheem Zaffar]

The change record for this states that we are not following the BLS at
https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ but the
proposed update at
https://www.freedesktop.org/wiki/MatthewGarrett/BootLoaderSpec/ .

It is not clear however if everyone has moved to the new spec or whether
they are now competing specs.

On Mon, 25 May 2020 at 00:27, James Cassell 
wrote:

>
> On Sun, May 24, 2020, at 7:06 PM, Paul Dufresne via devel wrote:
> > Well... I will try to repeat more clearly my claim:
> >
> > If Fedora want to pretend to implement the Boot Loader Specification,
> > it must, on a new disk formatted in GPT, end up with an entry in fstab
> > for an ESP partition mounted on /boot:
> >
> > "These directories are defined below the placeholder file system $BOOT.
> > This placeholder file system shall be determined during installation
> > time, and an fstab entry for it shall be created mounting it to /boot."
> >
> > ...
> >
> > "if the OS is installed on a disk with GPT disk label, and no ESP
> > partition exists yet, a new suitably sized (let's say 500MB) ESP should
> > be created and should be used as $BOOT"
> >
> > This is the rule you are supposed end up to follow for an empty GPT
> partition.
> >
> > And for now, the installer seems to make you define a specific
> > /boot/efi that it make ESP. To follow BLS, it should be /boot that is
> > the ESP partition... and I see no point to define an other /boot/efi
> > partition to be mounted on /boot.
> >
>
> I agree with your assessment and am also confused about the discrepancy
> between BLS documentation and Fedora's implementation.
>
>
> V/r,
> James Cassell
>
> > ...
> >
> > "`$BOOT` must be a VFAT (16 or 32) file system. Other file system types
> > should not be used. Applications accessing `$BOOT` should hence not
> > assume that fancier file system features such as symlinks, hardlinks,
> > access control or case sensitivity are supported."
> >
> >
> >
> ___
> 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
>
___
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

Re: Fedora Lifecycles: imagine longer-term possibilities

[Naheem Zaffar]

The major OS competitor has moved to a 6 month release cadence, so that
needs to be taken into account.

I suspect the easiest way to have a longer supported system is by NOT
having a longer supported system. For the case of desktop hardware vendors
something like a constantly updating silverblue might fit better.

It could be a continuously updating system "automatically" moving to the
next release shortly after the next fedora version is released. As it is
image based breakage should be harder to occur.

It will be no more or less faster updated than competitor operating systems
that manufacturers use.

On Thu, 15 Nov 2018, 00:15 Ben Rosser  On Wed, Nov 14, 2018 at 6:04 PM Stephen John Smoogen 
> wrote:
> >
> > On Wed, 14 Nov 2018 at 16:03, Ben Rosser  wrote:
> > >
> > > On Wed, Nov 14, 2018 at 2:55 PM Stephen John Smoogen 
> wrote:
> > > > From what I have talked with in the past.. 3 years is their bare
> > > > minimum and 7 is their what we really want. It usually takes the
> > > > vendor about 3-6 months of work to make sure the OS works on their
> > > > hardware without major problems and then they want people to buy
> > > > support contracts for 3-5 years where the number of problems needed
> in
> > > > year 3-5 are none. [This means that they want to have Fedora N for
> 3-6
> > > > months before their laptops ship with it. So you ship them a frozen
> > > > preload before you release to public. They also want any shipped to
> > > > 'last' for the warranty cycle because trying to deal with update
> > > > questions when N eol's in the middle costs them a lot.]
> > >
> > > If 7 years is what manufacturers really want, then it sounds like
> >
> > Well they also want a Ferrari and all support to be done upstream for
> > free. 7 is usually their counter to 13 months. You start going down
> > there to find that what they really settle for will be 3-4 years as
> > most people don't extend warranties that long.
>
> Well, even so, 3-4 years would be a pretty long time.
>
> My point about EPEL was that, Fedora currently does produce a
> long-term-support type product (admittedly for another distro). It's
> EPEL.
>
> Except we don't really push it. EPEL is an opt-in thing, which means
> lots of packages don't have EPEL branches-- possibly because the
> maintainers didn't want to commit to maintaining a package in a
> long-term-support type environment, or possibly because the
> maintainers never thought or bothered to create an EPEL branch, or
> possibly because there are too many dependencies that don't exist in
> EPEL and tracking down those maintainers isn't worth the time and
> effort. I know that I would package more things for EPEL if I could
> reuse Fedora specs with a minimum of fuss and I didn't have to spend
> time getting a bunch of dependent packages built.
>
> It is not clear to me that Fedora having two long-term-support type
> products would be a good idea, as I am not sure that we have the
> resources to maintain *one* at the moment. That makes me think we'd
> want to tie a hypothetical "Fedora LTS" directly to RHEL/CentOS/EPEL
> somehow, and find a way to reuse the work for both efforts.
>
> Ben Rosser
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Status of OwnCloud/NextCloud

[Naheem Zaffar]

Looking at Nextcloud releases, it seems that they do a major release once a
year.

It should be possible to catch up with the upstream even if there is a
single update per Fedora release.

Update to Nextcloud 11 in Fedora 27, 12 in current Fedora 28 and then in
Fedora 29 cath up with upstream.

Admittedly that will be a lot of work, but it keeps instances upgradeable.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Why is Fx 57 in Updates Testing?

[Naheem Zaffar]

Another option could be to ship Fedora 27 with a Firefox 57 prerelease
version. This will stop breakage of extensions 2 weeks after Fedora 27
ships (and shipped extensions can be moved to web extension version).

On 13 Oct 2017 12:31 pm, "Peter Oliver" <
lists.fedoraproject@mavit.org.uk> wrote:

> On Thu, 12 Oct 2017, Adam Williamson wrote:
>
> it sounds like downgrading from 56 to 52
>> (the most recent ESR), aside from the epoch bump it'd require on our
>> side, is not straightforward (it seems there were profile changes
>> between 56 and 52).
>>
>
> Ouch.
>
> Is now a good time to think about how we could try to avoid getting into a
> similar situation again in the future?
>
> I see that Firefox ESR releases are supported for one year plus twelve
> weeks (https://www.mozilla.org/en-US/firefox/organizations/faq/).  For
> Fedora 27, would it be safer to include Firefox 57 and 58, but then stick
> with Firefox 59 ESR from March onwards?
>
> --
> Peter Oliver
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Spam

[Naheem Zaffar]

I have received a few on the development mailing list.

On 17 Jul 2017 6:48 pm,  wrote:

> On Mon, Jul 17, 2017 at 12:41 PM, Samuel Sieb  wrote:
>
>> I haven't seen any spam on the devel list.  I even checked my spam
>> folder.  Maybe the messages are being sent directly to you, not the list?
>>
>
> They're being sent to 389-de...@lists.fedoraproject.org (whatever that
> is). I can see in the mail headers that they're passing through Fedora's
> SMPT servers and failing spam checks. I assume the spam checks lose out to
> Kevin being subscribed to the list.
>
> Michael
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What's the current status of mp3-licensing issues?

[Naheem Zaffar]

People have moved past vorbis and into the world of Opus. Even MP3 is more
for the vast amounts of legacy content - most current content will be AACL.

Saying that, as a no-lawyer, it did seem last time that I looked that many
remaining patents after September 2015 were for encoding processes, but as
always the actual lawyers who have had a chance to research this would know
better and for the rest of us, it isnt too too much of an encumberance.

On 15 November 2015 at 16:54, Gerald B. Cox  wrote:

>
> On Sun, Nov 15, 2015 at 8:38 AM, Haïkel  wrote:
>
>> Besides, determining when a patent expires is not that easy and Fedora
>> Legal is backed by skilled lawyers that said the contrary. Unless Fedora
>> Legal confirms your theory (which I doubt), it's useless to discuss this on
>> this list.
>
>
> Yeah, this is an issue for Fedora-Legal list, but is interesting
> nonetheless.  Looked like from the previous email that there were still a
> few patents that don't expire until 2017.  The first thing that actually
> popped into my mind was the argument that was always used about Vorbis,
> i.e. "businesses are afraid to use it because of potential infringement
> issues" - which I always thought was just a bunch of FUD.  That said, if
> MP3 patents are expiring what is now the excuse for people not using
> Vorbis?  It's obviously a better solution and uses less bandwidth for the
> same or better quality.
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: DNF replacing yum: fedup?

[Naheem Zaffar]

On 26 January 2015 at 22:52, Will Woods wwo...@redhat.com wrote:


 (As an aside, PackageKit should also support these operations, so we can
 use PackageKit to make a Upgrade GUI Thing.)


Gnome Software has had some interesting work done in the 3.16 cycle to
handle upgrades.

For atleast the workstation product that may be useful
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Why isn't F2FS support in the Kernel?

[Naheem Zaffar]

Trying to turn this discussion into something more productive and
deliberately ignoring the negativity:

What is the present position/plan for f2fs in Fedora?

Is there any hardware out there that uses it?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: fedora 21 lets me install packages without root

[Naheem Zaffar]

When creating an account, I am pretty sure there is a toggle box of
whether the account is for an administrator or not.

I suspect toggling that has the effect that some on this thread desire.

For a normal single user system, I am glad that such a toggle exists
and gives me some power that is much needed in many cases.

On 20 October 2014 17:10, Stephen John Smoogen smo...@gmail.com wrote:


 On 20 October 2014 07:45, Matthew Miller mat...@fedoraproject.org wrote:

 On Mon, Oct 20, 2014 at 06:21:54AM -0700, James Patterson wrote:
  I'd like consistent behavior please.

 When possible, that is ideal. But yum doesn't have a built-in privilege
 escalation mechanism to do this.

  Typing yum install requires a password, so should be the behaviour for
  running a command that doesn't exist causing a package to be installed.

 Only signed packages from system repositories can be installed.


 So if I mistype 'rm' as rn or rb will lrzsz or rn be installed so that it
 does the wrong thing next time? Or is this only some commands? And beyond
 removing someone from the wheel group what is the way to turn this off?

 --
 Stephen J Smoogen.


 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: the tragedy of Fedora Live USB conversion and what we can do about it

[Naheem Zaffar]

Longer term, would turning this stateless via new systemd features
be helpful?.

On 31 July 2014 18:13, Brian C. Lane b...@redhat.com wrote:
 On Thu, Jul 31, 2014 at 05:04:16AM -0400, Kamil Paral wrote:

 Some ideas:
 1. First and foremost, we should obviously consider whether we can make some 
 compose changes that would make the image more compatible with third-party 
 USB installers. That's very technical, but I hope relevant people could 
 provide some comments here.


 I suppose we could install a dracut module for the live initrd that
 assumes live by default instead of depending on the rd.live.image
 argument. But that won't help much when they totally mangle the cmdline
 or the iso label.

 2. Second, we could make USB conversion instructions more visible on our 
 pages. If you look at http://fedoraproject.org/, there's a big Download Now! 
 button, which gives you the ISO, but you'll never encounter any suggestions 
 what to do with it. That's only available at 
 http://fedoraproject.org/en/get-fedora#desktops in the right column (which 
 is nice and quite visible, I think). Could we provide the same information 
 on the front page?

 I think this is the one that has the best chance for success. We need to
 clearly direct people to the usb creation instructions, encourage use of
 dd on linux/osx systems and liveusb-creator on Windows.


 3. Third, if everything goes wrong and you end up in a dracut shell, could 
 we at least advise our users what went wrong and what to do with it? Because 
 the current output is very scary and very hard to decipher by a general user:
 http://www.zive.cz/uploadedfiles/38598240.png
 So what if we detected that we failed to find a partition having 
 Fedora-Live in its name (thus most probably an incorrectly created 
 LiveUSB), and in that case printed out something like this?

 ***
 * It seems Fedora Live image could not have been accessed. This often 
 happens *
 * when Live USB media is incorrectly created by a third-party USB installer. 
  *
 * Please refer to official documentation on fedoraproject.org for proper 
  *
 * instructions.  
  *
 ***
 (native speakers will surely make it sound better)

 We might be able to do this along with a module that assumes live instead of
 normal boot.

 --
 Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA 
 (PST8PDT)
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf even allows to uninstall RPM and systemd without warnings

[Naheem Zaffar]

While dnf itself might want to stay pure and do as commanded, maybe
for fedora there should be a default plugin that adds some protection
for the regular users?

On 21 June 2014 18:02, Gerald B. Cox gb...@bzb.us wrote:

 On Sat, Jun 21, 2014 at 9:23 AM, Tim Lauridsen tim.laurid...@gmail.com
 wrote:

 many people stops reading fdl, because of all the flaming and people trash
 talking each other and that is sad for Fedora :-(


 Thank you.  No one likes trolling.

 It should be obvious that if you start removing packages you should
 understand what you are doing.  To run DNF, you first have to have root
 authority - which should be the first red flag. Second, when you enter a
 command to remove a package and it comes back and lists hundreds of
 dependencies it is also going to remove, that should be enough of a nudge
 for the prudent person to reply N.

 You can't stop people from being careless by asking them again if they are
 really, really sure.  If they go ahead and destroy their system and have to
 re-install, maybe that will be a sufficient deterrent to keep them from
 doing it again.  Just like telling a child not to touch a hot surface...
 some listen and the ones that don't get burned.

 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf versus yum

[Naheem Zaffar]

A solution may be for someone to write a plugin that restores the
protected packages feature.

Fedora users are clearly used to such a feature and expect it while
upstream doesnt want to add hand holding features, but provide a
method to do the same.

On 5 January 2014 18:32, Lars E. Pettersson l...@homer.se wrote:
 On 01/05/2014 07:24 PM, Lars E. Pettersson wrote:

 As I mentioned before I only auto completed yum, remove is not party of
 the auto completed commands. If remove should be there, then this is a
 bug. I will file one.


 Pressed send a bit too early. Should of course be 'erase' here, not
 'remove'... :)


 Lars
 --
 Lars E. Pettersson l...@homer.se
 http://www.sm6rpz.se/
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: OpenH264 in Fedora

[Naheem Zaffar]

From my understanding, they can be used in any context.

It would probably be interesting if cisco can be convinced to make a
gstreamer plugin that is than automatically downloaded - that will
have a wide benefit.

(they have stated that they are willing to support as many platforms
as possible. Maybe because tey have a vested interest in it.)

On 2 November 2013 17:01, Jon jdisn...@gmail.com wrote:
 Do the codes only apply to WebRTC consumers, or can these be used in
 other context?
 For example Gnome has ctrl+alt+shift+R to screen-cast, which saves in
 webM format.
 Could that switch to whatever h.264 format with Cisco bits?

 Maybe get the lawyers to look at this?



 -Jon Disnard
 irc: masta
 fas: parasense


 On Sat, Nov 2, 2013 at 11:23 AM, Bruno Wolff III br...@wolff.to wrote:
 On Sat, Nov 02, 2013 at 08:11:48 -0700,
   Gregory Maxwell gmaxw...@gmail.com wrote:

 I personally believe it would probably be helpful to the discussion if
 Fedora is able to reach a (preliminary?) decision on if OpenH264 (as
 described) will be able to be used by Fedora systems (e.g. by having
 something analogous to codec buddy go install the codec to give all
 Fedora systems H.264 support) in order to provide feedback to the
 working group. If a decision to mandate H.264 in WebRTC means that
 Fedora systems would be unable to comply with the specification, that
 would be unfortunate.


 I don't see mandating H.264 in WebRTC as a good thing. So I'd rather not see
 Fedora people spend time supporting it, as opposed to doing other Fedora
 related work. And for people that don't need to worry about software patents
 or who don't worry about practising them without proper licensing, they can
 use x264 from RPMFusion.

 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct



 --

 -Jon
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposed F19 Feature: Replace MySQL with MariaDB

[Naheem Zaffar]

On 30 January 2013 04:24, James Hogarth james.hoga...@gmail.com wrote:

  Second, if mariadb differs more in the future and stops to be drop-in
 replacement, then we'll need an alternative for applications, where mariadb
 won't be suitable enough. Nevertheless, this is not a current issue right
 now.
 

 Indeed this is a straw man effectively.

 Is it?

http://blog.mariadb.org/explanation-on-mariadb-10-0/ and
http://blog.mariadb.org/mariadb-10-0-and-mysql-5-6/ seem to suggest that
MariaDB will no longer be following Mysql as religiously as the feature
suggests
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Replacing grubby with grub2-mkconfig in kernel install process

[Naheem Zaffar]

would fixing this also fix the bug where installing a new kernel changes
the default boot OS even when the default is non Linux?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: NetworkManager doesn't start on boot

[Naheem Zaffar]

There seems to be an SElinux denial for me which stops it from starting (I
upgraded from Fedora 14 and its NOT a live machine).

I would assume its the same error?

On 31 January 2011 07:22, Braden McDaniel bra...@endoframe.com wrote:

 I've recently set up a virtual machine running rawhide and I've noticed
 that NetworkManager never seems to start on boot; I must always start it
 manually.  As far as I can tell, it is configured to start on boot.  Is
 there something about the virtual machine context that would trigger
 this?

 --
 Braden McDaniel bra...@endoframe.com

 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: FESCo wants a more sane updates policy (feedback requested)

[Naheem Zaffar]

Thankyou for starting all this hard work with the certainty that it *will*
be blamed by some people.

As an end User I extremely like that Fedora does not ban newer packages from
Stable releases.

At the same time I can see how direct pushes can sometimes create unforseen
bugs.

I however do not see both scenarios as mutually exclusive - even a tool
issue may fix things - have an option to set have a default push to stable
(offset) date and then packagers can fire away their packages, do their
testing and forget about taking any other actions unless there is a need to
fix some more bugs (or a security issue to force the date closer).

Good luck.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel