Re: F40 Final test request: NVIDIA RTX 3000 GPUs

[Neal Gompa]

On Thu, Apr 11, 2024, 11:47 AM Adam Williamson 
wrote:

> Hi folks! See also the thread between AV and Frantisek ("changes to
> nouveau driver in kernel 6.8.2 and higher?")
>
> Can anyone else who has a similar NVIDIA GPU please try booting the
> Workstation live image -
>
> https://dl.fedoraproject.org/pub/alt/stage/40_RC-1.13/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-40-1.13.iso
> - and see if it works for you? Please post results here or in the bug
> report. Thanks!
>


Could you post a link to the bug report in this thread?

>
--
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [Test-Announce] Fedora 40 Candidate Beta-1.9 Available Now!

[Neal Gompa]

On Wed, Mar 20, 2024 at 8:45 AM Dan Horák  wrote:
>
> On Tue, 19 Mar 2024 12:41:48 + (UTC)
> rawh...@fedoraproject.org wrote:
>
> > According to [the schedule][1], Fedora 40 Candidate Beta-1.9 is now
> > available for testing. Please help us complete all the validation
> > testing! For more information on release validation testing, see:
> >  https://fedoraproject.org/wiki/QA:Release_validation_test_plan
> >
> > Test coverage information for the current release can be seen at:
> >  https://openqa.fedoraproject.org/testcase_stats/40
> >
> > You can see all results, find testing instructions and image download
> > locations, and enter results on the Summary page:
> >
> >  https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Summary
> >
> > The individual test result pages are:
> >
> > https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Installation
> > https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Base
> > https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Server
> > https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Cloud
> > https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Desktop
> > https://fedoraproject.org/wiki/Test_Results:Fedora_40_Beta_1.9_Security_Lab
> >
> > All Beta priority test cases for each of these [test pages][2] must
> > pass in order to meet the [Beta Release Criteria][3].
> >
> > Help is available on [the Fedora Quality chat channel][4], [the Fedora
> > Quality tag on Discourse][5], or on [the test list][6].
> >
> > Current Blocker and Freeze Exception bugs:
> >  https://qa.fedoraproject.org/blockerbugs/current
> >
> > [1]: https://fedorapeople.org/groups/schedule/f-40/f-40-quality-tasks.html
> > [2]: https://fedoraproject.org/wiki/QA:Release_validation_test_plan
> > [3]: https://fedoraproject.org/wiki/Fedora_40_Beta_Release_Criteria
> > [4]: 
> > https://matrix.to/#/#quality:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org
> > [5]: https://discussion.fedoraproject.org/tags/c/project/7/quality-team
> > [6]: 
> > https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/
>
> the Cloud and Container image filenames miss the "Beta" string in the
> name, not sure, but someone might have mentioned it already ...
>
> for example
> Fedora-Cloud-Base-Generic.ppc64le-40-1.9.qcow2
> should be
> Fedora-Cloud-Base-Generic.ppc64le-40-Beta_1.9.qcow2
> I believe. The checksum filename is correct.
>

This is tracked in https://bugzilla.redhat.com/show_bug.cgi?id=2270197

We have an upstream fix to kiwi for this, but some code will need to
be written for the koji plugin and pungi to resolve it.



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: gnome-session-46-alpha-1 has broken Budgie sessions

[Neal Gompa]

On Sat, Feb 10, 2024 at 7:52 PM Ian Laurie  wrote:
>
> I rolled back to a working backup of Rawhide Budgie and selectively
> upgraded until I could no longer log into a Budgie session, and it's the
> upgrade to gnome-session-46-alpha-1 that did it.  Previous 45.0-6 works.
>
> Further, downgrading gnome-session to 45.0-6 on an already broken system
> has restored it to a working condition.
>

You might want to file this as a report with the Budgie SIG to act on:
https://pagure.io/fedora-budgie/project



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Multimedia group still referencing gimp-heif-plugin

[Neal Gompa]

On Tue, Dec 19, 2023 at 5:29 PM Samuel Sieb  wrote:
>
> On 12/19/23 14:19, Ian Laurie wrote:
> > On 12/20/23 08:44, Neal Gompa wrote:
> >> On Tue, Dec 19, 2023 at 4:37 PM Ian Laurie  wrote:
> >>>
> >>> I notice that:
> >>>
> >>>   sudo dnf group upgrade --with-optional Multimedia
> >>>
> >>> produces the error:
> >>>
> >>>   No match for group package "gimp-heif-plugin"
> >>>
> >>> Seems like "gimp-heif-plugin" no longer exists in the repos.  Is this a
> >>> bug in the spec file for the Multimedia group?
> >>>
> >>
> >> This is not defined in Fedora's multimedia comps group. It's probably
> >> coming from some other repository's comps definition.
> >
> > Well if it's not a Fedora group, it would have to be RPM Fusion.
>
> And that's where it is:
> 
> multimedia
> Multimedia
> Audio/video framework common to desktops
> false
> false
> 
> gstreamer1-plugins-bad-freeworld
> gstreamer1-plugins-ugly
> ffmpeg
> ffmpeg-libs
> ffmpeg-libs
> gimp-heif-plugin
>  requires="libavcodec-free">libavcodec-freeworld
>  requires="libheif">libheif-freeworld
>  requires="pipewire">pipewire-codec-aptx
>  requires="qt5-qtwebengine">qt5-qtwebengine-freeworld
> 
> 
>
> But that's not a Fedora issue.  File a bug with rpmfusion.

There are other issues there too, like the "ffmpeg-libs" stanza there,
as that conflicts with baseline Fedora.


-- 
真実はいつも一つ！/ Always, there's only one truth!
--
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Multimedia group still referencing gimp-heif-plugin

[Neal Gompa]

On Tue, Dec 19, 2023 at 5:20 PM Ian Laurie  wrote:
>
> On 12/20/23 08:44, Neal Gompa wrote:
> > On Tue, Dec 19, 2023 at 4:37 PM Ian Laurie  wrote:
> >>
> >> I notice that:
> >>
> >>   sudo dnf group upgrade --with-optional Multimedia
> >>
> >> produces the error:
> >>
> >>   No match for group package "gimp-heif-plugin"
> >>
> >> Seems like "gimp-heif-plugin" no longer exists in the repos.  Is this a
> >> bug in the spec file for the Multimedia group?
> >>
> >
> > This is not defined in Fedora's multimedia comps group. It's probably
> > coming from some other repository's comps definition.
>
> Well if it's not a Fedora group, it would have to be RPM Fusion.
>
> It's reproducible on multiple machines, in fact, all mine that I have so
> far tested, native and virtual, on Fedora 38, 39 and Rawhide 40.
>

Please file a bug with them about it so they can fix it, then.




--
真実はいつも一つ！/ Always, there's only one truth!
--
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Multimedia group still referencing gimp-heif-plugin

[Neal Gompa]

On Tue, Dec 19, 2023 at 4:37 PM Ian Laurie  wrote:
>
> I notice that:
>
>  sudo dnf group upgrade --with-optional Multimedia
>
> produces the error:
>
>  No match for group package "gimp-heif-plugin"
>
> Seems like "gimp-heif-plugin" no longer exists in the repos.  Is this a
> bug in the spec file for the Multimedia group?
>

This is not defined in Fedora's multimedia comps group. It's probably
coming from some other repository's comps definition.



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Make toolbx a crit-path package

[Neal Gompa]

On Tue, Aug 29, 2023 at 3:00 AM Adam Williamson
 wrote:
>
> On Tue, 2023-08-29 at 10:09 +0530, Sumantro Mukherjee wrote:
> > On Wed, Aug 16, 2023 at 10:40 PM Adam Williamson 
> > 
> > wrote:
> >
> > > On Wed, 2023-08-16 at 19:57 +0530, Sumantro Mukherjee wrote:
> > > > Hey Folks!
> > > >
> > > > Toolbx is very necessary and is becoming very important. It provides
> > > > the basic and core
> > > > functionality for many users who use immutable OS as daily driver for
> > > > installing apps with
> > > > dnf. In many cases, help devs manage deps, libs and envs.
> > > > Functional breakage of Toolbx causes distress and many folks might be
> > > > actually running
> > > > apps inside and if after "dnf update" things fall apart[0], that's great
> > > UX.
> > > >
> > > > I want to mark Toolbx rpm as crit-path.. thoughts?
> > > > Any ideas on how to go about this?
> > >
> > > Well, per my change to the critpath definition recently:
> > >
> > > https://fedoraproject.org/w/index.php?title=Critical_path_package=686714=599546
> > > (this was proposed and agreed in 2022 but I forgot to change it), the
> > > thing to do would be to get one or more editions, spins or labs to
> > > declare that toolbx is critpath for them.
> > > --
> > > Adam Williamson (he/him/his)
> > > Fedora QA
> > > Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
> > > https://www.happyassassin.net
> >
> >
> >  Hey Adam,
> >
> > We have the ack from Workstation Working Group [0]
> > It's still not implemented and I would like to learn how to do it! :)
> > Any guidance will be awesome :D
>
> You send a PR for fedora-comps, adding it to the critical-path-gnome
> group:
>
> https://pagure.io/fedora-comps/blob/main/f/comps-f39.xml.in#_784
>
> make sure to keep it in alphabetical order. Probably do it for both
> comps-f39.xml.in and comps-f40.xml.in.
>
> After that, the critical path definition will be updated within 24
> hours and any updates with the package in created after that will be
> marked as critical path.

With the successful implementation of the toolbx being
release-blocking, KDE SIG will also depend on it for both the KDE Spin
and Kinoite.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: new criterion proposal: toolbox functionality

[Neal Gompa]

On Tue, May 2, 2023 at 12:00 AM Sumantro Mukherjee  wrote:
>
>
>
> On Tue, May 2, 2023 at 9:04 AM Neal Gompa  wrote:
>>
>> On Mon, May 1, 2023 at 10:48 PM Sumantro Mukherjee  
>> wrote:
>> >
>> > Hello
>> >
>> >
>> > This has been silent for a long time now but here's the update.
>> > Debarshi and I decided to re-write the whole thing as a changeset[0].
>> > We DO care about not just the rpm but also the OCI image that we ship
>> > with Toolbx. As a result, we filed a releng ticket[1] where
>> > we justified the following: We need the image ready for branch point,
>> > beta and final and that image be blocked implying we resort to "no-go"
>> > if the expected image is not there at all.
>> >
>> > As the basic functionality of toolbx continues to work as intended, we
>> > would also like to block on any upcoming changeset, if that
>> > has the potential to break toolbx or toolbx OCI image deliverables as
>> > well. Read [2] for more exact things that might break toolbx.
>> >
>> > Finally, GNOME WS, Silverblue, FCOS include Toolbx as part of their
>> > deliverable. RHEL does the same. It's crucial that we block
>> > on this. However, as the changeset process rolls, we will go through
>> > FESCO as well. This is just a good time for us to ensure
>> > we all are on the same page and have the plumbing done beforehand!
>> >
>>
>> I'd also like to preload toolbx on Fedora KDE:
>> https://pagure.io/fedora-kde/SIG/issue/346
>>
>> We already ship it for Fedora Kinoite.
>
>
> y


Note that my desire to preload it depends on a guarantee
that it isn't broken and works on GA.




--
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: new criterion proposal: toolbox functionality

[Neal Gompa]

On Mon, May 1, 2023 at 10:48 PM Sumantro Mukherjee  wrote:
>
> Hello
>
>
> This has been silent for a long time now but here's the update.
> Debarshi and I decided to re-write the whole thing as a changeset[0].
> We DO care about not just the rpm but also the OCI image that we ship
> with Toolbx. As a result, we filed a releng ticket[1] where
> we justified the following: We need the image ready for branch point,
> beta and final and that image be blocked implying we resort to "no-go"
> if the expected image is not there at all.
>
> As the basic functionality of toolbx continues to work as intended, we
> would also like to block on any upcoming changeset, if that
> has the potential to break toolbx or toolbx OCI image deliverables as
> well. Read [2] for more exact things that might break toolbx.
>
> Finally, GNOME WS, Silverblue, FCOS include Toolbx as part of their
> deliverable. RHEL does the same. It's crucial that we block
> on this. However, as the changeset process rolls, we will go through
> FESCO as well. This is just a good time for us to ensure
> we all are on the same page and have the plumbing done beforehand!
>

I'd also like to preload toolbx on Fedora KDE:
https://pagure.io/fedora-kde/SIG/issue/346

We already ship it for Fedora Kinoite.

> The revised criterion I have now stands as:
>
> 
> For any release-blocking deliverable whose default deployment includes
> toolbx, the toolbox CLI must be able to list existing containers,
> create a new container with the latest Fedora and RHEL image, and
> enter it.
> OCI images should get updates in every stage of the release cycle
> (Branched, Beta and Final).
>
> Footnote - "What does this cover?":
> This criterion aims at blocking Toolbx OCI image and Toolbx rpms. In
> cases of a breaking changeset or regression which affects toolbx, we
> will need to test well ahead of time to ensure things are fine.
> The images must be present in registry.fedoraproject.org and must keep
> being updated like for branchpoints, beta and final. Missing images or
> broken images, will be blocking the release.
> Changes in Toolbx stack will warrant for a test day in that particular
> release cycle and regular validation to ensure there are no
> regressions.
>

"will warrant for a" -> "will warrant a"

otherwise lgtm.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Introducing Steam + video game testing criteria

[Neal Gompa]

On Tue, Apr 25, 2023 at 12:18 PM Adam Williamson
 wrote:
>
> On Tue, 2023-04-25 at 13:49 +0200, Kamil Paral wrote:
> > On Thu, Apr 20, 2023 at 11:39 PM Neal Gompa  wrote:
> >
> > > Is there a way we can add regular testing for it without making it a
> > > blocker then?
> > >
> >
> > For popular third-party software, I think this testing occurs quite
> > naturally - people just use it. E.g. Steam, Chrome, VSCode, etc. I've been
> > running Steam on F38 since Beta (and it helped me to discover an issue in
> > mutter, which was later accepted as a blocker - but not because of Steam,
> > but because of general issues). But if you want to have an explicit test
> > case, Adam described how to do it. We could also have a test day for
> > popular third-party software, if it makes sense.
>
> To be fair, we did miss
> https://bugzilla.redhat.com/show_bug.cgi?id=2177287 (I missed it
> because I run Steam via Flatpak, not RPM). So we do have scope to
> improve there. I do think testing commonly used third-party stuff is a
> good idea, to be clear, and I'm all in favor of adding optional test
> cases for it.

And I'm fine with us adding some optional test cases for this. Would
running a test day each cycle also be possible?



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Introducing Steam + video game testing criteria

[Neal Gompa]

On Thu, Apr 20, 2023 at 2:28 PM Adam Williamson
 wrote:
>
> On Thu, 2023-04-20 at 08:20 -0400, Neal Gompa wrote:
> > Hey all,
> >
> > I would like for us to have some testing criteria around gaming and
> > Steam so that we can ensure we're offering a working gaming experience
> > in Fedora Linux releases. This is motivated by the issue we had in the
> > F37 cycle where glibc broke popular multiplayer games[1]. I was
> > reminded of this when I launched Steam today on F38 and zenity
> > crashed[2].
> >
> > I would like to propose the following criterion for Steam itself as a
> > Beta Blocker bug:
> > "Steam MUST be able to be installed and have its basic functionality
> > work with no visible errors. Basic functionality for Steam includes:
> > logging into a Steam account and installing a Windows/Proton game and
> > a Linux/SteamOS native game."
> >
> > For gaming itself, I would like to propose the following criterion as
> > a Final Blocker bug:
> > "Steam games identified as Deck Verified by ProtonDB.com (see
> > https://www.protondb.com/explore?selectedFilters=whitelisted) MUST
> > launch and let the user play the game. This criterion is not intended
> > to judge performance, merely accessibility. At least one
> > Windows/Proton game and one Linux/SteamOS native game MUST be tested
> > in this manner."
> >
> > Now, the tricky issue here is how to wordsmith the check for
> > anti-cheat systems. I don't want to specifically call out just EAC,
> > but I also don't know of a good mix of games with different
> > anti-cheats. The important thing is to catch regressions and see if
> > it's something we can resolve. In the EAC case from F37, it was easy
> > for us to deal with, but if it's genuinely broken in a way we can't
> > deal with it on the Fedora side, I don't know what we're supposed to
> > do, so I'm wary of doing some kind of blocker criterion for that.
> >
> > I'd also like this to be imposed on both release-blocking desktops:
> > GNOME and KDE Plasma.
> >
> > Any ideas welcome and appreciated!
>
> I'm against this. We have never blocked the OS on proprietary third-
> party applications. I don't think it's a path we want to go down.
>
> I'm in favour of testing common third-party stuff before release and
> fixing it if we can, but we have always said we will not block Fedora
> on this, and I don't think we should change that.
>
> (I did actually test Steam, but I used the flatpak version, not RPM...)
>
> I'm fixing the zenity bug, BTW.

Is there a way we can add regular testing for it without making it a
blocker then?


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Introducing Steam + video game testing criteria

[Neal Gompa]

On Thu, Apr 20, 2023 at 5:14 PM Peter Robinson  wrote:
>
> On Thu, Apr 20, 2023 at 1:20 PM Neal Gompa  wrote:
> >
> > Hey all,
> >
> > I would like for us to have some testing criteria around gaming and
> > Steam so that we can ensure we're offering a working gaming experience
> > in Fedora Linux releases. This is motivated by the issue we had in the
> > F37 cycle where glibc broke popular multiplayer games[1]. I was
> > reminded of this when I launched Steam today on F38 and zenity
> > crashed[2].
> >
> > I would like to propose the following criterion for Steam itself as a
> > Beta Blocker bug:
> > "Steam MUST be able to be installed and have its basic functionality
> > work with no visible errors. Basic functionality for Steam includes:
> > logging into a Steam account and installing a Windows/Proton game and
> > a Linux/SteamOS native game."
> >
> > For gaming itself, I would like to propose the following criterion as
> > a Final Blocker bug:
> > "Steam games identified as Deck Verified by ProtonDB.com (see
> > https://www.protondb.com/explore?selectedFilters=whitelisted) MUST
> > launch and let the user play the game. This criterion is not intended
> > to judge performance, merely accessibility. At least one
> > Windows/Proton game and one Linux/SteamOS native game MUST be tested
> > in this manner."
> >
> > Now, the tricky issue here is how to wordsmith the check for
> > anti-cheat systems. I don't want to specifically call out just EAC,
> > but I also don't know of a good mix of games with different
> > anti-cheats. The important thing is to catch regressions and see if
> > it's something we can resolve. In the EAC case from F37, it was easy
> > for us to deal with, but if it's genuinely broken in a way we can't
> > deal with it on the Fedora side, I don't know what we're supposed to
> > do, so I'm wary of doing some kind of blocker criterion for that.
> >
> > I'd also like this to be imposed on both release-blocking desktops:
> > GNOME and KDE Plasma.
> >
> > Any ideas welcome and appreciated!
>
> So this is a proprietary platform, we don't even block on something
> like the binary nvidia drivers, so I'm not sure how we can block on
> something that is mostly out of our control.
>
> If there is a change in an upstream kernel that triggers a crash do we
> have to await a fix from them or roll back to an older kernel?
>
> Also are there free games that can be played for testing or
> reproducing bugs that don't require you to put in a credit card to be
> able to use them on Steam (sorry, I've never used it).

Steam has a toggle in the storefront for "free-to-play" games that you
can add to your Steam library without entering a credit card.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Introducing Steam + video game testing criteria

[Neal Gompa]

Hey all,

I would like for us to have some testing criteria around gaming and
Steam so that we can ensure we're offering a working gaming experience
in Fedora Linux releases. This is motivated by the issue we had in the
F37 cycle where glibc broke popular multiplayer games[1]. I was
reminded of this when I launched Steam today on F38 and zenity
crashed[2].

I would like to propose the following criterion for Steam itself as a
Beta Blocker bug:
"Steam MUST be able to be installed and have its basic functionality
work with no visible errors. Basic functionality for Steam includes:
logging into a Steam account and installing a Windows/Proton game and
a Linux/SteamOS native game."

For gaming itself, I would like to propose the following criterion as
a Final Blocker bug:
"Steam games identified as Deck Verified by ProtonDB.com (see
https://www.protondb.com/explore?selectedFilters=whitelisted) MUST
launch and let the user play the game. This criterion is not intended
to judge performance, merely accessibility. At least one
Windows/Proton game and one Linux/SteamOS native game MUST be tested
in this manner."

Now, the tricky issue here is how to wordsmith the check for
anti-cheat systems. I don't want to specifically call out just EAC,
but I also don't know of a good mix of games with different
anti-cheats. The important thing is to catch regressions and see if
it's something we can resolve. In the EAC case from F37, it was easy
for us to deal with, but if it's genuinely broken in a way we can't
deal with it on the Fedora side, I don't know what we're supposed to
do, so I'm wary of doing some kind of blocker criterion for that.

I'd also like this to be imposed on both release-blocking desktops:
GNOME and KDE Plasma.

Any ideas welcome and appreciated!

[1]: https://pagure.io/fesco/issue/2873
[2]: https://bugzilla.redhat.com/2177287

--
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: new criterion proposal: Window manager functionality

[Neal Gompa]

On Fri, Mar 17, 2023 at 5:48 AM Kamil Paral  wrote:
>
> Related to a recently proposed blocker [1][2], I propose a new release 
> criterion which would cover such cases. Here it is:
>
> 
> The desktop environment must work correctly when displaying common 
> application content - that includes regular application windows, video 
> output, games and possibly other common content. Regular operations like 
> windows close/resize/maximize/minimize/fullscreen (when 
> supported/applicable), windows switching, using windows on virtual 
> workspaces, and similar common operations must behave as expected.
>
> Footnote - "What does this cover?":
> A small number of misbehaving applications is not a violation of this 
> criterion. The goal of this criterion is to ensure general functionality for 
> different types of applications and their operations. An example of a 
> violation would be e.g. if a significant number of QT applications couldn't 
> be resized (but they should be), or if all Java applications failed to 
> display any content.
> ~
>
> I think this criterion could target F38 Beta Release Criteria [3] or Basic 
> Release Criteria [4].
>
> Please tell me your thoughts, thanks!
> Kamil
>
> [1] https://pagure.io/fedora-qa/blocker-review/issue/1102
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=2178167
> [3] https://fedoraproject.org/wiki/Fedora_38_Beta_Release_Criteria
> [4] https://fedoraproject.org/wiki/Basic_Release_Criteria
>

I think this qualifies as Basic Release Criteria, since if the window
management functionality doesn't work, it's basically unusable. We
should also see if it's possible to have some OpenQA tests for this as
well. Maybe some open source game demo loops? Or maybe specially
crafted SDL applications for these use-cases?




--
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: criterion change proposal: macOS dual-boot

[Neal Gompa]

On Wed, Feb 8, 2023 at 1:56 PM Neal Gompa  wrote:
>
> On Wed, Feb 8, 2023 at 1:31 PM Kevin Fenzi  wrote:
> >
> > On Wed, Feb 08, 2023 at 09:55:33AM +0100, Kamil Paral wrote:
> > > Our current macOS (still called OS X) dual boot criterion says:
> > >
> > > "The installer must be able to install into free space alongside an
> > > existing OS X installation, install and configure a bootloader that will
> > > boot Fedora."
> > > https://fedoraproject.org/wiki/Fedora_38_Final_Release_Criteria#OS_X_dual_boot
> > >
> > > I suggest renaming  "OS X" to "macOS" in the section title and in the
> > > criterion text. That reflects the name change that Apple did in the past.
> > >
> > > I also suggest adding this footnote:
> > > "Footnote: Supported hardware
> > > This criterion only covers Mac devices with an Intel x86_64 processor."
> > >
> > > That makes it explicit that we don't support the latest ARM-based 
> > > M
> > > custom processors, nor the older PowerPC-based devices. I originally 
> > > wanted
> > > to link to some official Fedora requirements, but we don't seem to have 
> > > any
> > > (for Macs), so at least a footnote here.
> > >
> > > Thoughts?
> >
> > +1 to those changes, makes sense.
> >
> > I am not sure 100% of intel macs are supported either however.
> > I have a macbook here with the touchbar thing and last I tried it,
> > fedora will boot, but the keyboard doesn't work at all. That was like a
> > year or so ago tho, so I should try again. ;)
> >
>
> There is a patch set for the T2 era of Macs, but I don't know if
> anyone has tried to shepherd them upstream yet:
> https://github.com/t2linux/linux-t2-patches
>
> (I don't have access to one of this era of Macs, so I don't have quite
> the ability to vouch for them.)
>

Well, I spoke too soon, look at that:
https://lore.kernel.org/lkml/e5d8beba-3c5b-460f-bd2c-39470a793...@live.com/



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: criterion change proposal: macOS dual-boot

[Neal Gompa]

On Wed, Feb 8, 2023 at 1:31 PM Kevin Fenzi  wrote:
>
> On Wed, Feb 08, 2023 at 09:55:33AM +0100, Kamil Paral wrote:
> > Our current macOS (still called OS X) dual boot criterion says:
> >
> > "The installer must be able to install into free space alongside an
> > existing OS X installation, install and configure a bootloader that will
> > boot Fedora."
> > https://fedoraproject.org/wiki/Fedora_38_Final_Release_Criteria#OS_X_dual_boot
> >
> > I suggest renaming  "OS X" to "macOS" in the section title and in the
> > criterion text. That reflects the name change that Apple did in the past.
> >
> > I also suggest adding this footnote:
> > "Footnote: Supported hardware
> > This criterion only covers Mac devices with an Intel x86_64 processor."
> >
> > That makes it explicit that we don't support the latest ARM-based M
> > custom processors, nor the older PowerPC-based devices. I originally wanted
> > to link to some official Fedora requirements, but we don't seem to have any
> > (for Macs), so at least a footnote here.
> >
> > Thoughts?
>
> +1 to those changes, makes sense.
>
> I am not sure 100% of intel macs are supported either however.
> I have a macbook here with the touchbar thing and last I tried it,
> fedora will boot, but the keyboard doesn't work at all. That was like a
> year or so ago tho, so I should try again. ;)
>

There is a patch set for the T2 era of Macs, but I don't know if
anyone has tried to shepherd them upstream yet:
https://github.com/t2linux/linux-t2-patches

(I don't have access to one of this era of Macs, so I don't have quite
the ability to vouch for them.)




--
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: 6.1 kernel in F36/F37?

[Neal Gompa]

On Sun, Jan 1, 2023 at 2:48 PM Andre Robatino
 wrote:
>
> What's going on with the 6.1 kernel for stable releases? Normally, there are 
> Koji builds even if it's not intended for stable releases yet, but the only 
> Koji build for the 6.1 kernel was for Rawhide. Is there an issue causing it 
> to be skipped?

It was released late and the holidays came upon us. We'll probably see
builds after people are back from vacation.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Video issue

[Neal Gompa]

On Sat, Oct 15, 2022 at 11:23 AM pmkel...@frontier.com
 wrote:
>
>
> This is something I first saw at first branch and I have continued
> monitoring it since. There has been no change.
>
> The problem is that MP4, and AVI videos will not play on Totem. This is
> probably not a blocker based on the current criteria. I doubt that a bug
> report is even a proper thing to do.  However this seems likely to cause
> some discontent and commentary.
>
> My current clean install is from Fedora-WS-Live-37-20221013-n-0. It is
> fully updated. I have also loaded the Free video codecs from
> RPMFusion.org. In Software --> Codecs when I try to install the the
> gstreamer-libav Software says it's not available. So it can't be
> installed. I've looked for it on RPMFusion.org with no luck. I found
> gstreamer1-plugin-libav in the fedora repo then installed in and did a
> reboot. This solved the problem. MP4, and AVI videos now play in totem.
> Software --> Codecs still says that gstreamer-libav is not available.
>
> I think this either needs to be installed by default and remove it from
> Software --> Codecs or put it back in RPMFusion.org where it can be
> installed the way users are used to. For now I'll just add it to my
> install script.
>

gstreamer1-plugin-libav has no AppStream data for GNOME Software to
recognize it. If someone wants to write a metainfo file for it, pull
requests are welcome.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Heads up: GNOME 43.0 megaupdate is in testing

[Neal Gompa]

On Wed, Sep 21, 2022 at 4:30 AM Kalev Lember  wrote:
>
>
> Hi all,
>
> Just a quick heads up that the GNOME 43.0 final release megaupdate is
> now in F37 updates-testing:
> https://bodhi.fedoraproject.org/updates/FEDORA-2022-0bd68bbb43
>
> This is the GNOME version that's we'll be shipping F37 Final with, so
> please make sure to test it and file issues for things that would need
> fixing before F37 GA. I'd suggest starting upstream at gitlab.gnome.org
> for most issues, and then letting me (and other people) know in
> #fedora-workstation if anything needs backporting to Fedora (since there
> won't be any more upstream releases before F37 Final). If anything looks
> to be release blockery, then please also file issues downstream at
> bugzilla.redhat.com as soon as possible and mark them as blockers using
> the blockerbugs page,
> https://qa.fedoraproject.org/blockerbugs/milestone/37/final/buglist
>

FYI, the Fedora workstation chat is also accessible via Matrix:
https://matrix.to/#/#workstation:fedoraproject.org





--
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Release criteria proposal: require GNOME Shell extension install/remove to work

[Neal Gompa]

On Mon, Sep 12, 2022 at 3:35 PM Adam Williamson
 wrote:
>
> Hey folks!
>
> So a bug came up at today's blocker review meeting:
> https://bugzilla.redhat.com/show_bug.cgi?id=2106868
>
> it takes a minute to parse, but the tl;dr is that right now in Fedora
> 37, you can't go to https://extensions.gnome.org and install
> extensions.
>
> We agreed that it doesn't violate any existing release criteria, but to
> me, this is actually kind of a significant problem. Anecdotally, I get
> the impression that a lot of our Workstation users do use extensions,
> and not being able to easily install them on a fresh install would be a
> big problem for them, and make us look pretty bad.
>
> We have a handful of extensions packaged, though I'm not sure how well
> they're kept up to date. Aside from those, I don't know of any other
> really practical way for regular users to install extensions besides
> https://extensions.gnome.org . Is there one?
>
> Assuming for now that there isn't, I'm gonna propose this as a Final
> release criterion to see how people feel about it, to come after
> "Default panel functionality":
>
> #
>
> === GNOME extensions ===
>
> On Fedora Workstation, it must be possible to install and remove
> extensions by visiting https://extensions.gnome.org in the default web
> browser, after installing the required browser extension.
>
> #
>
> Do folks think this is important enough to block Final release on?
> Desktop folks, do you consider it "supportable"?
>

I think it's important to block the final release on. And as a user, I
can't use GNOME without working extensions, so it *must* be
supportable by us. So if we can't do it, we should block the release.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Proposal: changes to "default application functionality" release criteria

[Neal Gompa]

On Fri, May 6, 2022 at 7:29 AM Matthias Clasen  wrote:
>
> On Thu, May 5, 2022 at 1:23 PM Matthew Miller  
> wrote:
>
> Wading into this discussion pretty late... there's far too much "GNOME does 
> this" or "GNOME wants that" in this discussion.
>
> That is really not how it works, neither for GNOME nor for Fedora - its down 
> to small teams and individual maintainers to
> make changes and decisions. For improving the QA situation between upstream 
> GNOME and downstream Fedora, a good
> team to talk to is the GNOME release team of which both Michael and I happen 
> to be members.
>
>>
>> > Testing that is much more useful to upstream than testing Rawhide,
>> > because we certainly aren't updating all the bits of GNOME in Rawhide
>> > nightly. But if it's not built on Fedora (I don't think it is), it may
>> > well have differences in theme and font configuration that might make
>> > Fedora's openQA needles not match, which is the problem I'm concerned
>> > about with sharing the tests.
>>
>> Could we (GNOME and Fedora in collaboration) set up something where they
>> _are_ updating everything on top of Rawhide nightly? If not instead of GNOME
>> OS, at least alongside it?
>>
>
> This would be a useful discussion to have, Having it in a bof at guadec 
> sounds great.
>

One of the things we're working on in the KDE SIG is eventually
auto-building all our KDE software in a COPR on a regular schedule,
with the goal of eventually producing something that we could wire up
to run through OpenQA tests using that COPR repo for precisely this
purpose. I think it would absolutely make sense if the folks
maintaining GNOME did the same thing, since they're both release
blocking desktops.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Please help us test: Fedora Media Writer 5.0

[Neal Gompa]

On Thu, May 5, 2022 at 1:06 PM Kamil Paral  wrote:
>
> Hi there. We just learned that there's an opportunity to have a brand new 
> Fedora Media Writer 5.0 (with a completely redone UI, but using the same 
> background code) together with the Fedora 36 release. The timing is tight, 
> but we agreed that we'd like to give it a try.
>
> We'd like to gather test feedback today and tomorrow, so that we can decide 
> whether it's a good idea to make it public next week on Tuesday for F36 GA 
> (assuming we're GO today). If it doesn't work well, we'll ask Jan Grulich, 
> the developer, to keep to the old FMW 4.2 for now.
>
> The latest 5.0 builds are here:
> https://github.com/FedoraQt/MediaWriter/releases
> and here:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=86685593
>
> Can you please help us test FMW 5.0 on all possible platforms and system 
> configurations as possible, and report here?
>
> There's a guide here for making FMW see the latest F36 RCs, instead of 
> feeding it the ISO manually:
> https://fedoraproject.org/wiki/QA:Testcase_USB_fmw
> (of course the Setup phase doesn't apply, use the links above instead)
>
> Please tell us which version you tested (rpm/flatpak/windows/mac), on which 
> OS, with which hardware (especially the GPU could be relevant for rendering 
> the UI, and if you used closed/open drivers in case of Nvidia), and how it 
> went. Thanks!
>

I tested the RPM and the Flatpak on Fedora Workstation 36 on an Intel
GPU. I flashed Fedora Kinoite 36 Beta to a USB stick using it
successfully.

With both the RPM and the Flatpak, I noticed that it doesn't follow
the light/dark preference from GNOME, but that's probably
QGnomePlatform there.

With the RPM, the panels don't seem to have any imagery? The picture
of the main window in the readme has a graphic that doesn't show up on
my installed version. No graphic on the downloading and writing panels
either. At the end when it's finished, the main window still says writing to
disk, even though the notification was pushed that it finished, so it
didn't switch to the "finished" window pane. Closing it in this
scenario seems harmless, but confusing. Otherwise, it seems to work fine.

When testing the Flatpak, it seems to work the same, except the
imagery shows up and the finished writing panel shows up. The Flatpak
downloads ISOs much more slowly than the RPM (like several orders
slower!).

Are the RPM and the Flatpak built from the same commit? If so, there
might be a packaging bug in the RPM one.




--
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: dnf system-upgrade conflict

[Neal Gompa]

On Fri, Mar 4, 2022 at 6:46 AM Alessio  wrote:
>
> It is not the first time that performing a system-upgrade from 35 to
> 36, I get:
>
> Error:
>  Problem: problem with installed package mlocate-0.26-31.fc35.x86_64
>   - package plocate-1.1.15-2.fc36.x86_64 conflicts with mlocate
> provided by mlocate-0.26-46.fc36.x86_64
>   - mlocate-0.26-31.fc35.x86_64 does not belong to a distupgrade
> repository
>   - conflicting requests
> (try to add '--allowerasing' to command line to replace conflicting
> packages or '--skip-broken' to skip uninstallable packages)
>
> Is this a good candidate for common bugs?

It is planned to fix it: https://pagure.io/fesco/issue/2765



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [Anaconda-devel] deprecate bootloader selection criterion

[Neal Gompa]

On Sun, Jan 23, 2022 at 6:54 AM Peter Robinson  wrote:
>
> On Sun, Jan 23, 2022 at 2:37 AM Neal Gompa  wrote:
> >
> > On Sat, Jan 22, 2022 at 5:21 PM Chris Murphy  
> > wrote:
> > >
> > > https://fedoraproject.org/wiki/Fedora_35_Final_Release_Criteria#Bootloader_disk_selection
> > >
> > > "The installer must allow the user to choose which disk the system
> > > bootloader will be installed to, and to choose not to install one at
> > > all. "
> > >
> > > The "choose not to install one at all" doesn't really apply to UEFI. I
> > > wonder if we can just drop the whole criterion? (I'm still hopeful
> > > that one day the entirety of bootloader UI in the installer goes
> > > away.)
> > >
> > > So what you get is a system without an EFI system partition (or an
> > > existing ESP that isn't used), but all the bootloader stuff is put on
> > > the /boot volume. So it's not going to boot, which makes the
> > > installer's warnings true. The one thing *not* copied for some reason
> > > is the stub grub.cfg. But shim, grub, the real grub.cfg, and BLS
> > > snippets are all there - just on ext4 /boot which the firmware can't
> > > read so the system doesn't boot. It's harmless because the user signed
> > > up for this after all, but it's also kinda pointless.
> > >
> > >
> > > Reproduce steps:
> > > 1. Any that use Anaconda, from any release, but I just used this:
> > > Fedora-Workstation-Live-x86_64-Rawhide-20220119.n.0.iso
> > > 2. Boot it, launch installer
> > > 3. Installation destination keep all defaults
> > > 4. Click blue text at the bottom "Full disk summary and boot loader..."
> > > 5. Select the (in my case single) drive, click the "Do not install
> > > bootloader" button
> > > 6. Close and install
> > >
> >
> > The ability to not install the bootloader is used for creating some of
> > the images. And it's also useful in advanced installations where
> > people are using custom boot managers.
>
> Which images?

Hmm, now that I look, I guess we're not doing it anymore for the ARM
ones. But I think we'll be using that for the RISC-V ones once that
gets brought into Fedora.




--
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [Anaconda-devel] deprecate bootloader selection criterion

[Neal Gompa]

On Sat, Jan 22, 2022 at 5:21 PM Chris Murphy  wrote:
>
> https://fedoraproject.org/wiki/Fedora_35_Final_Release_Criteria#Bootloader_disk_selection
>
> "The installer must allow the user to choose which disk the system
> bootloader will be installed to, and to choose not to install one at
> all. "
>
> The "choose not to install one at all" doesn't really apply to UEFI. I
> wonder if we can just drop the whole criterion? (I'm still hopeful
> that one day the entirety of bootloader UI in the installer goes
> away.)
>
> So what you get is a system without an EFI system partition (or an
> existing ESP that isn't used), but all the bootloader stuff is put on
> the /boot volume. So it's not going to boot, which makes the
> installer's warnings true. The one thing *not* copied for some reason
> is the stub grub.cfg. But shim, grub, the real grub.cfg, and BLS
> snippets are all there - just on ext4 /boot which the firmware can't
> read so the system doesn't boot. It's harmless because the user signed
> up for this after all, but it's also kinda pointless.
>
>
> Reproduce steps:
> 1. Any that use Anaconda, from any release, but I just used this:
> Fedora-Workstation-Live-x86_64-Rawhide-20220119.n.0.iso
> 2. Boot it, launch installer
> 3. Installation destination keep all defaults
> 4. Click blue text at the bottom "Full disk summary and boot loader..."
> 5. Select the (in my case single) drive, click the "Do not install
> bootloader" button
> 6. Close and install
>

The ability to not install the bootloader is used for creating some of
the images. And it's also useful in advanced installations where
people are using custom boot managers.




--
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: new criterion proposal: Graphical package managers

[Neal Gompa]

On Mon, Nov 8, 2021 at 10:50 AM John Mellor  wrote:
>
> On 2021-11-08 9:31 a.m., Neal Gompa wrote:
> > On Mon, Nov 8, 2021 at 9:25 AM Frantisek Zatloukal  
> > wrote:
> >> On Mon, Nov 8, 2021 at 3:05 PM Kamil Paral  wrote:
> >>> "dnf install foo bar"
> >> This is a single operation, comparable to having multiple packages 
> >> installed via graphical package manager, not scheduling multiple 
> >> operations at once. It would be the same If a graphical package manager 
> >> offered to select multiple packages/applications and then start the 
> >> transaction.
> >>
> >> "dnf install foo; dnf install bar"
> >> This is equivalent to:
> >> 1. Open Graphical package manager
> >> 2. Install foo
> >> 3. Close Graphical package manager
> >> 4. Open Graphical package manager
> >> 5. Install bar
> >> 6. Close Graphical package manager
> >>
> >> dnfdragora supports doing install + upgrade + removal in the same
> >> transaction. This is equivalent to using "dnf shell" to construct a
> >> transaction in the CLI.
> >>
> >> It is technically possible to do this with PackageKit too, but neither
> >> Discover nor Software expose this as far as I know.
>
> Did I miss something in this thread?  Given that the current Gnome
> graphical package manager requires a full and expensive reboot in
> between every install for virtually every package for mostly-defective
> reasons, how would you actually install two packages sequentially like
> that?  Are you suggesting that the current and IMHO
> poorly-thought-through package manager be finally replaced?  If so,
> hoorah!!!
>

No. We are not suggesting it. I am merely explaining what's possible.

Note that Discover *does* let you turn off offline updates if you
wish, though we default to offline updates.

Even with online updates, Discover and Software do not let you select
multiple actions before executing it.

> I'm all for stealing the code from tracer or the Ubuntu installer to
> identify what needs restarting, and maybe putting out a flag to prevent
> bug submissions while the running packages are not up-to-date.  I
> believe that would completely eliminate the mandatory reboots, and allow
> the package manager to move forward properly.

We will *not* change the default back to online updates for Discover
or Software.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: new criterion proposal: Graphical package managers

[Neal Gompa]

On Mon, Nov 8, 2021 at 9:25 AM Frantisek Zatloukal  wrote:
>
>
>
> On Mon, Nov 8, 2021 at 3:05 PM Kamil Paral  wrote:
>>
>> "dnf install foo bar"
>
>
> This is a single operation, comparable to having multiple packages installed 
> via graphical package manager, not scheduling multiple operations at once. It 
> would be the same If a graphical package manager offered to select multiple 
> packages/applications and then start the transaction.
>
>>
>> "dnf install foo; dnf install bar"
>
>
> This is equivalent to:
>
> 1. Open Graphical package manager
> 2. Install foo
> 3. Close Graphical package manager
> 4. Open Graphical package manager
> 5. Install bar
> 6. Close Graphical package manager
>

dnfdragora supports doing install + upgrade + removal in the same
transaction. This is equivalent to using "dnf shell" to construct a
transaction in the CLI.

It is technically possible to do this with PackageKit too, but neither
Discover nor Software expose this as far as I know.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Proposal: Migrate “Common Bugs” from the wiki to Ask Fedora

[Neal Gompa]

On Fri, Nov 5, 2021 at 8:36 PM Adam Williamson
 wrote:
>
> On Thu, 2021-11-04 at 11:43 -0400, Matthew Miller wrote:
> > Background
> > --
> >
> > Every release since possibly the dawn of time (or, at least, [Fedora
> > Core 5][1]), we make a [Common Bugs page][2] on the wiki. This is where
> > we document things that we judge not to be blockers but are concerned
> > many people might run into on upgrade or first install of a new Fedora
> > Linux release — or, would-be blockers we decide we have to waive
> > because we don’t have time or resources to fix. Or, just common issues
> > that crop after the release.
> >
> >
> > Problem
> > ---
> >
> > This time around, based on my anecdotal impression from social media,
> > Ask Fedora questions, and even comments on the release announcement,
> > [No sound after upgrade][3] appears to be the … winner. Lots of people
> > are hitting this.
> >

To be blunt, I try my hardest to avoid the Discourse system. I would
rather us just make the CommonBugs page linked from Ask in a prominent
way for people to see it. People using the Ask system should be made
aware of CommonBugs before posting, so you could add an overlay on the
"new topic" post page so people are notified of it before creating a
topic.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 Wayland and Darktable hard lock

[Neal Gompa]

On Fri, Oct 22, 2021 at 12:39 PM Leander Hutton via test
 wrote:
>
> Hello, I recently upgraded to FL35 and noticed that Darktable under a Wayland 
> session causes a hard lock of the whole session. Both the package that ships 
> with the distro and the release version compiled from source. I did a fresh 
> install from the FL35 beta ISO on this machine to test but before on FL34 the 
> application worked fine.
>
> Upon opening the program it will lock up and then the whole compositor and I 
> have to force a hard reset. It is fine on an X11 session. This is a Dell XPS 
> 9310 with Intel integrated Xe graphics so nothing terribly exotic in terms of 
> hardware.
>
> Unfortunately as the whole machine becomes hosed obtaining logs is proving 
> difficult. But I can attempt again and see if I can capture some output from 
> Darktable if that would be help.
>

Which desktop environment?



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Wayland and basic graphics mode

[Neal Gompa]

Hey all,

During the final days of Fedora Linux 34 development, it was
discovered that Plasma Wayland hangs when kernel modesetting isn't
available[1]. It was resolved for F34 with a downstream change to sddm
that checks if "nomodeset" is set and disables Wayland sessions
accordingly.

However, this is not a sustainable solution. Technically, Plasma
Wayland supports fbdev, but it is not very good relative to the
standard drm backend (and requires extra configuration to work).
Additionally, GNOME Wayland *only* supports the drm backend and it
fails entirely when "nomodeset" is set, thus GDM forces back to X11 in
this scenario. As we move forward with adopting Wayland across the
board, variations of this problem will happen over and over again.

So my questions are:

Do we want to support a "basic graphics mode"? If so (which I think we
do), are there any alternatives to disabling KMS entirely that we
could use? Perhaps vkms[2] is an option? If not, what do we do about
it?


[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1952431
[2]: https://dri.freedesktop.org/docs/drm/gpu/vkms.html

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gdm / gnome-shell segfaults on Raspberry Pi 3B+

[Neal Gompa]

On Fri, Apr 23, 2021 at 3:29 PM Adam Williamson
 wrote:
>
> On Fri, 2021-04-23 at 09:07 -0500, Brandon Nielsen wrote:
> > Thanks for following up. I was mostly trying to gauge if this was common
> > enough it should be a proposed blocker.
> >
> > Now, not to be a stick in the mud, but what other common armhfp hardware
> > is out there? If the Pi 3B+ isn't "up to the task", perhaps desktop
> > images that aren't expected work should just be dropped? I'm not sure a
> > desktop environment running on armhfp in a VM is that common of a use case.
> >
> > We're now looking at publicly releasing a version of Fedora that
> > apparently just doesn't work when all immediately obvious documentation
> > implies it should.
>
> I can't speak to "immediately obvious documentation", but it's worth
> remembering that Workstation on 32-bit ARM is not release blocking by
> policy. See:
> https://fedoraproject.org/wiki/Releases/34/ReleaseBlocking
> the only release-blocking 32-bit ARM image left is minimal, and the
> release criteria preamble state:
> "The current set of release-blocking desktops for x86_64 is GNOME and
> KDE, and for aarch64 is GNOME. No desktop is release-blocking for 32-
> bit ARM."
> https://fedoraproject.org/wiki/Basic_Release_Criteria#Basic_Release_Requirements
>
> If there is documentation or marketing that gives the impression that
> Workstation on 32-bit ARM is some sort of
> priority/"supported"/recommended/blocking/whatever environment, it
> should be changed.

The whole arm.fedoraproject.org website makes it seem like that. We
actually *don't* have a site for AArch64 stuff at all, as far as I can
tell.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [Suggestion] Add `noatime` mount option

[Neal Gompa]

On Wed, Apr 14, 2021 at 11:37 PM TheEvilSkeleton
 wrote:
>
> I'd like to suggest to use noatime mount option for btrfs.
>
> I've come across two posts about combining atime with btrfs. Unfortunately 
> those two should not be combined, as explained here: 
> https://lwn.net/Articles/499293/; and here: Why I experience poor performance 
> during file access on filesystem?
>
> TL;DR: btrfs and atime should not be combined because it causes more problems 
> than it fixes due to the nature of CoW. CoW already does what atime should 
> do, so we are essentially losing a lot more performance than we should, just 
> because we have atime. Another thing, reading files after a snapshot can 
> cause files to grow considerably.
>
> I would suggest to use noatime mount option by default for increased 
> performance and to prevent high space consumption.

This had been actively discussed in the Fedora Btrfs project a while
back: https://pagure.io/fedora-btrfs/project/issue/9

The current consensus is that relatime mitigates most of the issues
while preserving atime-centric workflows. We do disable atime for SBCs
because regardless of filesystem, noatime drastically improves
performance for all the crappy ARM boards in existence.



--
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Self-introduction: TheEvilSkeleton

[Neal Gompa]

On Sun, Mar 28, 2021 at 12:50 PM Matthew Miller
 wrote:
>
> On Sun, Mar 28, 2021 at 03:24:38PM +0200, Michael Schwendt wrote:
> > Where does this come from that people introduce themselves with
> > pseudonyms, aliases, usernames but no real name?
>
> If anything, I think it's a lot less common than it used to be.
>

When I started getting involved in Fedora in 2005, I didn't use my
real name either. I started using my real name a couple of years
afterward when I got comfortable with it. I've seen trends go back and
forth on this over the past 15 years.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Upgrade on F34 -> F34 on x11 utils split

[Neal Gompa]

Hey all,

I attempted to do a distro-sync to upgrade my system to latest F34
pre-release packages, but I got the following error:

Error: Transaction test error:
  file /usr/bin/iceauth conflicts between attempted installs of
xorg-x11-server-utils-7.7-39.fc34.x86_64 and
iceauth-1.0.8-1.fc34.x86_64
  file /usr/bin/sessreg conflicts between attempted installs of
xorg-x11-server-utils-7.7-39.fc34.x86_64 and
sessreg-1.1.2-1.fc34.x86_64
  file /usr/bin/xgamma conflicts between attempted installs of
xorg-x11-server-utils-7.7-39.fc34.x86_64 and
xgamma-1.0.6-1.fc34.x86_64
  file /usr/bin/xhost conflicts between attempted installs of
xorg-x11-server-utils-7.7-39.fc34.x86_64 and xhost-1.0.7-1.fc34.x86_64
  file /usr/bin/xinput conflicts between attempted installs of
xorg-x11-server-utils-7.7-39.fc34.x86_64 and
xinput-1.6.3-1.fc34.x86_64
  file /usr/bin/xkill conflicts between attempted installs of
xorg-x11-server-utils-7.7-39.fc34.x86_64 and xkill-1.0.5-1.fc34.x86_64
  file /usr/bin/xmodmap conflicts between attempted installs of
xorg-x11-server-utils-7.7-39.fc34.x86_64 and
xmodmap-1.0.9-1.fc34.x86_64
  file /usr/bin/xrandr conflicts between attempted installs of
xorg-x11-server-utils-7.7-39.fc34.x86_64 and
xrandr-1.5.1-1.fc34.x86_64
  file /usr/bin/xrdb conflicts between attempted installs of
xorg-x11-server-utils-7.7-39.fc34.x86_64 and xrdb-1.1.1-1.fc34.x86_64
  file /usr/bin/xrefresh conflicts between attempted installs of
xorg-x11-server-utils-7.7-39.fc34.x86_64 and
xrefresh-1.0.6-1.fc34.x86_64
  file /usr/bin/xset conflicts between attempted installs of
xorg-x11-server-utils-7.7-39.fc34.x86_64 and xset-1.2.4-1.fc34.x86_64
  file /usr/bin/xsetroot conflicts between attempted installs of
xorg-x11-server-utils-7.7-39.fc34.x86_64 and
xsetroot-1.1.2-1.fc34.x86_64
  file /usr/bin/xstdcmap conflicts between attempted installs of
xorg-x11-server-utils-7.7-39.fc34.x86_64 and
xstdcmap-1.0.4-1.fc34.x86_64
  file /usr/share/man/man1/sessreg.1.gz conflicts between attempted
installs of xorg-x11-server-utils-7.7-39.fc34.x86_64 and
sessreg-1.1.2-1.fc34.x86_64
  file /usr/share/man/man1/xrandr.1.gz conflicts between attempted
installs of xorg-x11-server-utils-7.7-39.fc34.x86_64 and
xrandr-1.5.1-1.fc34.x86_64
  file /usr/share/man/man1/xstdcmap.1.gz conflicts between attempted
installs of xorg-x11-server-utils-7.7-39.fc34.x86_64 and
xstdcmap-1.0.4-1.fc34.x86_64

Seems we're not properly handling the package split in F34?

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Need help with btrfs.

[Neal Gompa]

On Thu, Mar 4, 2021 at 9:50 AM Matthew Miller  wrote:
>
> On Wed, Mar 03, 2021 at 05:40:19PM -0800, Samuel Sieb wrote:
> > There are a few different types of full-disk backup, but if it's
> > file-based and the atimes are modified, that's the intent of the
> > backup process.  The atimes are used to determine which files to
> > backup.  A scrub is not a backup and shouldn't modify the atimes.
>
> I can't imagine why you would use atime instead of ctime for backups.
>

Also, this seems really easy to game. Why not maintain a checksum
record instead? That makes it possible to maintain more efficient
deltas. Using atimes/mtimes is just asking for trouble.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Need help with btrfs.

[Neal Gompa]

On Tue, Feb 23, 2021 at 10:03 AM Matthew Miller
 wrote:
>
> On Mon, Feb 22, 2021 at 02:58:00PM -0700, Chris Murphy wrote:
> > We should find out if there's more widespread corruption. The basic
> > command to scrub that particular Btrfs file system is:
> >
> > sudo btrfs scrub start /mnt
>
> It's kind of unfortunate that we also have a command (in the distro since
> 2007) called just "scrub" which will destroy al of your data. :-/
>

Not going to lie, it took three tries to read this to understand what
was being said here. :)

> Anyway... do we have a timer which does this automatically on Fedora Linux
> systems, or are there plans to add one? Upstream wiki
> https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs-scrub says "The user
> is supposed to run it manually or via a periodic system service. The
> recommended period is a month but could be less."
>

We *do* have btrfsmaintenance[1] which provides what you're asking
for. However, we don't install it by default or have presets set up
for the timers. There were arguments for and against shipping and
enabling them by default[2].

If we want to ship these, we can easily do so.

[1]: https://src.fedoraproject.org/rpms/btrfsmaintenance
[2]: https://pagure.io/fedora-btrfs/project/issue/16

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: How To Test pipewire On F33?

[Neal Gompa]

On Sun, Jan 24, 2021 at 12:28 PM Qiyu Yan  wrote:
>
> My procedure:
>
> 1. sudo swap pulseaudio pipewire-pulseaudio --allowerasing 
> --enablerepo=updates-testing
>
> If you lost sound:
>
> 2. sudo systemctl enable --global pipewire-pulse.socket
>
> The second step should be done automatically, but it's not the case for me...
>

It's supposed to be started as a user unit, rather than a system unit.

If it's not working, then "systemctl enable --user
pipewire-pulse.socket" should fix it.





-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org

Re: Testcase Audio Recording Basic (new test case proposal)

[Neal Gompa]

On Fri, Jan 22, 2021 at 9:19 AM Kamil Paral  wrote:
>
> On Fri, Jan 22, 2021 at 3:01 PM Neal Gompa  wrote:
>>
>> On Fri, Jan 22, 2021 at 2:01 AM Kamil Paral  wrote:
>> >
>> > On Thu, Jan 21, 2021 at 12:30 PM Neal Gompa  wrote:
>> >>
>> >> GNOME applications pull in most of the GNOME desktop as dependencies.
>> >> Properly developed KDE applications will pull in the KF5 libraries and
>> >> occasionally some Plasma libraries. That's just how it goes. It is
>> >> also unrealistic to expect GNOME applications to work fully "to spec"
>> >> on KDE because KDE does not provide all the D-Bus interfaces and
>> >> services that GNOME does. We can and do have quirks when applications
>> >> are transplanted from one desktop environment to another, if the
>> >> underlying frameworks don't handle this well. While most of the KDE
>> >> frameworks adapt well to a non-KDE environment, it's rare that GNOME
>> >> applications fully do, especially ones that depend on things like
>> >> gnome-settings-daemon, gnome-shell, or gnome-control-center. In the
>> >> case of gnome-sound-recorder, it'll be fine as it's quite simple. But
>> >> if you were using something like the GNOME screencast app, that would
>> >> fail in KDE. Note that I'm specifically saying "GNOME applications".
>> >> Plain GTK applications are generally fine on Plasma.
>> >
>> >
>> > Neal, you're doing a great job in Fedora, but this made me somewhat angry. 
>> > Because I *did* spend the time yesterday, installed KDE in a VM from 
>> > scratch, and tested gnome-sound-recorder, audacity and kwave in it. And 
>> > sounds like you haven't. Gnome-sound-recorder only pulls in gjs and 
>> > libhand1, and that's *all*. It's the most minimal application I could 
>> > find. I also tested its functionality, it worked without issues. I stand 
>> > by my opinion that this is the best sound recorder to recommend. Your 
>> > reaction is the tribalism I was talking about, negatively reacting to 
>> > anything that has "GNOME" or "K" in the name.
>> >
>>
>> I specifically said that GNOME Sound Recorder is fine because it's
>> simple,
>
>
> I must admit I missed that particular sentence in the middle, sorry.
>
>>
>> but the majority of GNOME applications are *not*. But I was
>> responding *specifically* to your comment about tribalism, because you
>> suggested that all desktop applications for each desktop work fine on
>> other desktops.
>
>
> Ugh... I didn't say that. And I re-read my emails again, just to be sure.
>
> I do feel that the common advice of "install app X if you're on GNOME, or app 
> Y if you're on KDE" (just because X uses GTK and Y uses QT, or a similar 
> reason) harms the whole ecosystem. That's why I said I want to avoid this 
> style of instructions, find a tool that works best everywhere, and recommend 
> it universally (and then we don't even need to name the desktops, which might 
> feel like we're looking down on the other ones). Quote:
> "If one tool works well on all desktops, recommend that one, regardless of 
> its name or library toolkit used. Of course ideally such a tool shouldn't 
> pull half of some desktop with it as dependencies (as KWave does), and should 
> have a reasonably newcomer friendly UI. It would also make the instructions 
> sound better, currently it seems like we only care about GNOME and KDE."
>

Hmm, that's more fair than I read it as originally. I'm mostly annoyed
because I've had people complain to me why X GNOME app doesn't work on
KDE (e.g. GNOME screen recording app on Plasma Wayland). It's
frustrating how we've regressed on inter-desktop interoperability over
the past few years...



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org

Re: Testcase Audio Recording Basic (new test case proposal)

[Neal Gompa]

On Fri, Jan 22, 2021 at 2:01 AM Kamil Paral  wrote:
>
> On Thu, Jan 21, 2021 at 12:30 PM Neal Gompa  wrote:
>>
>> GNOME applications pull in most of the GNOME desktop as dependencies.
>> Properly developed KDE applications will pull in the KF5 libraries and
>> occasionally some Plasma libraries. That's just how it goes. It is
>> also unrealistic to expect GNOME applications to work fully "to spec"
>> on KDE because KDE does not provide all the D-Bus interfaces and
>> services that GNOME does. We can and do have quirks when applications
>> are transplanted from one desktop environment to another, if the
>> underlying frameworks don't handle this well. While most of the KDE
>> frameworks adapt well to a non-KDE environment, it's rare that GNOME
>> applications fully do, especially ones that depend on things like
>> gnome-settings-daemon, gnome-shell, or gnome-control-center. In the
>> case of gnome-sound-recorder, it'll be fine as it's quite simple. But
>> if you were using something like the GNOME screencast app, that would
>> fail in KDE. Note that I'm specifically saying "GNOME applications".
>> Plain GTK applications are generally fine on Plasma.
>
>
> Neal, you're doing a great job in Fedora, but this made me somewhat angry. 
> Because I *did* spend the time yesterday, installed KDE in a VM from scratch, 
> and tested gnome-sound-recorder, audacity and kwave in it. And sounds like 
> you haven't. Gnome-sound-recorder only pulls in gjs and libhand1, and that's 
> *all*. It's the most minimal application I could find. I also tested its 
> functionality, it worked without issues. I stand by my opinion that this is 
> the best sound recorder to recommend. Your reaction is the tribalism I was 
> talking about, negatively reacting to anything that has "GNOME" or "K" in the 
> name.
>

I specifically said that GNOME Sound Recorder is fine because it's
simple, but the majority of GNOME applications are *not*. But I was
responding *specifically* to your comment about tribalism, because you
suggested that all desktop applications for each desktop work fine on
other desktops. That's not true, especially for highly integrated
applications (which a lot of GNOME ones *are*).

> Audacity is OK, but it's UI is quite old, it crashes every time I close it, 
> and it pulls more dependencies (11 more packages in KDE). It's a decent 
> fallback option, but I wouldn't recommend it as the first one.
>

I'm surprised that it crashes so much. That's unfortunate...

> KWave pulls a zillion packages on GNOME systems (over 50 packages) and it's 
> UI is the worst of the three, at least from a beginner perspective.

KDE applications have larger dependency webs because of the KF5
libraries, I'm not surprised. As for the UI, yeah, I don't disagree
there. It's closer to Audacity than a simple sound recorder.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org

Re: Testcase Audio Recording Basic (new test case proposal)

[Neal Gompa]

On Thu, Jan 21, 2021 at 6:59 AM Lukas Ruzicka  wrote:

>
>
> On Thu, Jan 21, 2021 at 12:30 PM Neal Gompa  wrote:
>
>> On Thu, Jan 21, 2021 at 6:15 AM Kamil Paral  wrote:
>> >
>> > On Thu, Jan 21, 2021 at 11:24 AM Lukas Ruzicka 
>> wrote:
>> >>
>> >>
>> >> On Thu, Jan 21, 2021 at 10:04 AM Lukas Ruzicka 
>> wrote:
>> >>>>
>> >>>> Have you tested whether gnome-sound-recorder works well in KDE and
>> optionally also other desktops? If not (or if it pulls too many
>> dependencies), it would be good to suggest an alternative tool as well.
>> >>
>> >>
>> >
>>
>> If you want to endorse a cross-desktop tool for testing, I would
>> suggest Audacity. It's simple, powerful, and known to work on all
>> desktops. It also standardizes the test and minimizes the variables
>> for validation.
>>
>>
>>
> Ok, let's make it Audacity.
>
> The corrected text now looks:
>
> Install any sound recording application you're familiar with. If you've
> never worked with any, *Audacity* (the audacity package) is a popular
> full-featured audio editor which can also easily capture sound from your
> microphone.
>
>
Works for me!


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org

Re: Testcase Audio Recording Basic (new test case proposal)

[Neal Gompa]

On Thu, Jan 21, 2021 at 6:15 AM Kamil Paral  wrote:
>
> On Thu, Jan 21, 2021 at 11:24 AM Lukas Ruzicka  wrote:
>>
>>
>> On Thu, Jan 21, 2021 at 10:04 AM Lukas Ruzicka  wrote:

 Have you tested whether gnome-sound-recorder works well in KDE and 
 optionally also other desktops? If not (or if it pulls too many 
 dependencies), it would be good to suggest an alternative tool as well.
>>
>>
>> So, now I have found the KDE recording tool - KWave. I have tested it and 
>> works ok for the purposes of the test. I am updating the steps in the 
>> proposal to:
>>
>> If you do not have any sound recording application installed, install Gnome 
>> Sound Recorder (the gnome-sound-recorder package) on GNOME or KWave (the 
>> kwave package) on KDE.
>
>
> I believe we should move away from desktop tribalism, if possible. If one 
> tool works well on all desktops, recommend that one, regardless of its name 
> or library toolkit used. Of course ideally such a tool shouldn't pull half of 
> some desktop with it as dependencies (as KWave does), and should have a 
> reasonably newcomer friendly UI. It would also make the instructions sound 
> better, currently it seems like we only care about GNOME and KDE.
>

GNOME applications pull in most of the GNOME desktop as dependencies.
Properly developed KDE applications will pull in the KF5 libraries and
occasionally some Plasma libraries. That's just how it goes. It is
also unrealistic to expect GNOME applications to work fully "to spec"
on KDE because KDE does not provide all the D-Bus interfaces and
services that GNOME does. We can and do have quirks when applications
are transplanted from one desktop environment to another, if the
underlying frameworks don't handle this well. While most of the KDE
frameworks adapt well to a non-KDE environment, it's rare that GNOME
applications fully do, especially ones that depend on things like
gnome-settings-daemon, gnome-shell, or gnome-control-center. In the
case of gnome-sound-recorder, it'll be fine as it's quite simple. But
if you were using something like the GNOME screencast app, that would
fail in KDE. Note that I'm specifically saying "GNOME applications".
Plain GTK applications are generally fine on Plasma.

If you want to endorse a cross-desktop tool for testing, I would
suggest Audacity. It's simple, powerful, and known to work on all
desktops. It also standardizes the test and minimizes the variables
for validation.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org

Re: [External] Re: Respins for OEM preloads

[Neal Gompa]

On Wed, Jan 20, 2021 at 1:04 PM Mark Pearson  wrote:
>
>
> On 20/01/2021 11:11, Kamil Paral wrote:
> > On Tue, Jan 19, 2021 at 6:44 PM Mark Pearson  > > wrote:
> >
> > Release cadence is once. We just can't update our preload images that
> > often - there's a long test cycle, and energy certification that goes
> > with that image. It's one of the reasons the X1C8 is still shipping with
> > Fedora32, and P1G3 and P15 (soon!) will be with F33 for a long time. The
> > only reason to update would be a critical bug that couldn't be fixed
> > with an update once the platform was received.
> >
> >
> > If the cadence is once in a long time (related to new hardware
> > introductions, so possibly once a year or similar), I think the best
> > approach here is to have releng manually trigger an F33 Workstation Live
> > image compose using the current updates repo. Assuming it's not a
> > problem for them. We (the QA) can then trigger an OpenQA test run on it,
> > create the release validation test matrices for it, and even ask the
> > community in large to perform some manual tests if they have time. I
> > believe some of us would devote some time to make sure at least the
> > basics work correctly. I'm not sure if all the plumbing for this one-off
> > compose is ready (in fedfind, relval, openqa and wherever else needed),
> > but Adam will know more.
> >
> > I don't want to just repeat Adam's words, but I'd like to stress out
> > that from the security perspective, such a compose should really be
> > created using the proper Fedora Infra tooling (or Lenovo itself using
> > official Fedora bits). I don't want to belittle the people standing
> > behind the unofficial Live respins, they are doing a great and useful
> > work, but if this is going to be shipped preinstalled to thousands of
> > customers, the whole process should be as verifiable as with our
> > official releases.
> >
>
> Thanks Kamil,
>
> My preference would be to have a build that comes from Fedora with
> Fedora's blessing rather than something we put together :) Partly so we
> don't screw it up but also as part of the "we don't mess with the Fedora
> image" thing - if we get the image from you then it reinforces that.
>
> I know our timelines right now are quite tight - I'd like to get the
> image into test before Chinese New Year happens - though I'm looking at
> the calendar and wondering how optimistic I'm being How big a deal
> is creating an official compose? Is it days/weeks/months? At the moment
> I'd like it by start of Feb (with a bit of wriggle room)
>
> As Matthew mentioned - 5.10.8 is coming out soon and whether that ties
> into this too? Any recommendations from the community as to which fixes
> are important etc happy to take on board. The HW testing we've done so
> far looks good - but that's not the whole story.
>

While there are hardware fixes, the main reason for 5.10.8 being
important is that the Btrfs performance regression introduced in
5.10.0 was fixed in that release. With this release, Btrfs I/O
performance is at least 50% higher than 5.9 across virtually all
workloads.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org

Re: Respins for OEM preloads

[Neal Gompa]

On Tue, Jan 19, 2021 at 10:50 AM Matthew Miller
 wrote:
>
> A large computer vendor with whom we have a friendly relationship would like
> to update the image they're shipping on their systems so that 1) new users
> don't have quite so many updates immediately and 2) auiu newer kernel helps
> with some upcoming things *vague vague handwavy vague*.
>
> I can think of four possibilities:
>
> 1. Sure, use the live-respins!
>
> 2. The live-respins are unofficial, but we have run [this specific
>workstation iso] through our standard validation tests and we
>recommend it for your use.
>
> 3. Use the netinstall and choose "apply updates" (or whatever that option is
>called) when making your distribution image.
>
> 4. Uh, sorry, we got nothin'.
>

Is there a reason we can't make option 4 to be: officially create OEM
images and create an OEM preload guide? I don't personally know how
preloads work, even though I'm trying to figure out how to improve
"preloaded Fedora" experience over the next couple of cycles for
Fedora KDE.

It might also make sense to make either monthly or quarterly
full recomposes with updates for downstreams with all the artifacts,
similar to how Microsoft used to do "rollup images" to support OEM
preloads.




--
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org

Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)

[Neal Gompa]

On Wed, Dec 2, 2020 at 12:19 PM Adam Williamson
 wrote:
>
> On Wed, 2020-12-02 at 09:23 -0500, Ben Cotton wrote:
> >
> > == How To Test ==
> > See QA test cases : 
> > https://fedoraproject.org/wiki/Category:CoreOS_Test_Cases
> >
> > We also have regular tests days, for example
> > https://fedoramagazine.org/fedora-coreos-test-day/
>
> So...yeah, that's not really enough to call something a Fedora Edition
> :)
>
> I think this has a lot of the issues we had with IoT, but turned up to
> 11.
>
> We have an entire process for releasing a thing called "Fedora" which
> is based around the idea that all the bits that make up a "Fedora
> release" get built, tested, and signed off together.
>
> IoT stretched this process a bit, because it's not actually built as
> part of the same composes as all the other "Fedora" bits. So we had to
> implement an entire parallel validation process just for IoT composes.
> But at least it's built *the same way* as Fedora, so we could more or
> less just split existing things into two paths and use them, which is
> what we did. We now have both mainline and IoT composes and validation
> events. Even there, the process wasn't perfect for Fedora 33; if you
> look at the log of the Fedora 33 Go/No-Go meeting[1], which is supposed
> to be where we go over the status of the bits-to-be-released in great
> detail and decide whether to sign them off, there is precisely one line
> about IoT:
>
> 17:58:36  IoT is also covered - 
> https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_33_RC_20201020.0_General#ISO_Install
>
> ...no-one else said a word about it. So yeah, we clearly don't have
> this whole "releasing from multiple streams" entirely down yet.
>
> CoreOS is going to be the same only worse, because it's not even built
> the same way as the rest of Fedora. It's not built by Pungi, we don't
> get the same messages published when CoreOS builds happen (we don't get
> messages published at all, IIRC), the metadata for CoreOS builds is not
> in productmd[2] form like the metadata for Pungi builds, the whole
> process is entirely different.
>
> So to boil this down into a representative question: when we are doing
> the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide
> whether to release "Fedora CoreOS 34"?
>
> What does the question "is Fedora CoreOS 34 ready to go" even mean, in
> the context of how CoreOS is built and released? What set of bits will
> we be deciding to ship or not ship, and how will that have been decided
> and communicated? Where will we look to find the test results and
> criteria on which we would base that decision?
>
> Are any of these silly questions, which would indicate that our release
> process is based on assumptions which need to be fundamentally re-
> examined as part of this Change?
>
> All of this is stuff we could kind of handwave so long as CoreOS wasn't
> an official Edition; we could *more or less* leave the CoreOS team to
> decide what a CoreOS release looked like and when it would happen and
> when it was good enough to ship, and so on.
>
> But if we're going to call it an Edition, which is one of the primary
> things that defines what Fedora *is*, I don't think we can do that any
> more. We need more groups to think about and decide on the answers to
> questions like the above.
>
> [1]: 
> https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2020-10-22/f33-final-go_no_go-meeting.2020-10-22-17.00.log.html
> [2]: https://github.com/release-engineering/productmd

This is a fair point. I've personally been very annoyed about how
little Fedora CoreOS integrates with the rest of the Fedora Project.
One very broken consequence of Fedora CoreOS working this way is that
they basically *don't* participate in Changes discussions and just do
things differently without warning or documentation. This has led to
problems when Fedora CoreOS differs from the rest of Fedora in core,
fundamental ways. This has even happened unintentionally, where Fedora
CoreOS accidentally deviated from Fedora (and RHEL CoreOS!) by using
the wrong variant of iptables:
https://github.com/coreos/fedora-coreos-tracker/issues/676

Additionally, to the point about their tooling: there's been a bunch
of effort to plug OSBuild based image builds into our normal
infrastructure, and given that even Fedora IoT Edition can
successfully be produced through that pipeline, I would think that we
should have Fedora CoreOS transition to it. There's a lot more effort
going around OSBuild within the project as a whole, and it's much more
likely that we'll be able to incorporate that into the general
infrastructure in a way that makes it traceable and actionable within
and outside the project.

I would personally rather see Fedora CoreOS pulled *back* into the
fold more as an Edtion.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to 

Re: Blockerbugs discussion tickets feedback 

[Neal Gompa]

On Thu, Nov 12, 2020 at 11:57 AM Adam Williamson 
wrote:

>
> * Using Magic Text for voting and admin is awkward and error-prone.
> Better UI for this would be really helpful. In addition, the state
> isn't automatically updated when you vote or mark a decision, so I
> always find myself manually refreshing the page after doing it just to
> make sure I did it right and the change took effect.
>
> * It'd be really nice if the web UI showed the current vote counts from
> the ticket. I frequently find myself opening every proposal ticket in a
> tab and going through them all just to see if any have enough votes for
> a decision yet; it'd be much more efficient if I could just see the
> totals at a glance on the blockerbugs web UI overview.
>
> So Pagure actually supports scoring with  and  emoji, at least with
pull requests. It might be possible to extend this to issues and add a
simple way to see the score from the UI.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org

Re: fedora 34 Rawhide testing in Virtualbox

[Neal Gompa]

On Sat, Oct 31, 2020 at 1:20 PM Stephen Snow  wrote:
>
> Judging from the image at the link provided I would say you need to select 
> your installation destination.
>

Actually, it looks like MirrorManager wasn't responding quickly enough
for getting it to setup properly. It's supposed to autoconfigure with
the netinstall ISO based on the metalink provided by the mirror
service.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org

Re: snap question

[Neal Gompa]

On Tue, Oct 20, 2020 at 4:59 PM David  wrote:
>
> I wanted to try to learn something about snaps, so I installed what
> is written below:
>
>sudo snap install mate-wayland --edge --classic
>
> But in the log-in screen, I switched to the MATE desktop environment,
> and just got a bunch of gibberish on the screen.
>
> I tried to do the same with LXQt snap version, but it does not have
> a x86_64 version to install.
>
> Do any snap versions of Desktop Environments work in Fedora ?
>
> I have not yet researched if there are other ways to install a desktop 
> environment,
> like Flatpak or Appimage.
>
> I am in Rawhide, if that matters.
>
> And on a not-so-related note, in order to get
> to gdm, I have to first go to Gnome environment, and then log out.I 
> haven't been
> able to get gdm during the boot-up process for about two weeks.
>

Snaps *should* work, but if they don't, you'll need to reach out to
the developers of those snaps to figure out why they don't work. As
the snap isn't produced by Fedora, we're not going to know how to do
anything with them.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org

Re: desktop spins, btrfs copy test request

[Neal Gompa]

On Tue, Oct 13, 2020 at 9:38 PM Chris Murphy  wrote:
>
> Hi,
>
> I'm looking for testers:
> - Fedora 33
> - User home is on Btrfs (clean installed or converted, in a subvolume
> or not, these details won't matter)
> - using any spin other than Workstation (kde, lxqt, xfce, etc are all
> requested). I'd like to know which desktops do/don't automagically
> support reflink copies. What are reflinks? See Note 1 below.
>
>
> 1. Use the file manager to duplicate a file anywhere within user home,
> by all available means. i.e. using control-c then control-v, or
> contextual menu copy/paste, or copy to...  if available. (Any file?
> Yes, although I'm most interested in files 4KiB and larger. The
> handling for smaller files might be different.)
>
> 2.  Copy it from/to anywhere in your user home directory.
>
> 3. Check all copies of the file with 'filefrag -v /path/to/file'
>
> Check: The main thing you're looking for is that flags is "shared" for
> the original and each copy. An extra check is verify all the column
> values are the same for the original and each of its copies.
>
>  ext: logical_offset:physical_offset: length:   expected: flags:
>0:0..7429:   16640282..  16647711:   7430:
> last,shared,eof
>

Fedora 33 KDE Plasma Edition seems to confirm the KIO reflink support
is working.

I copied a file with Dolphin and the result in the terminal indicates
the file is reflinked:

> ngompa@f33-ryo-ohki-winvm ~/abf-scm> /sbin/filefrag -v rpm.spec
> Filesystem type is: 9123683e
> File size of rpm.spec is 27515 (7 blocks of 4096 bytes)
> ext: logical_offset:physical_offset: length:   expected: flags:
>   0:0..   6: 589306..589312:  7: 
> last,shared,eof
> rpm.spec: 1 extent found
> ngompa@f33-ryo-ohki-winvm ~/abf-scm> /sbin/filefrag -v rpm/rpm.spec
> Filesystem type is: 9123683e
> File size of rpm/rpm.spec is 27515 (7 blocks of 4096 bytes)
> ext: logical_offset:physical_offset: length:   expected: flags:
>   0:0..   6: 589306..589312:  7: 
> last,shared,eof
> rpm/rpm.spec: 1 extent found


Reflinks are supposed to work in KDE Plasma (or any desktop using KIO
built on KDE Frameworks 5.72 or higher):
https://kde.org/announcements/kde-frameworks-5.72.0




--
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org

Re: btrfs testing

[Neal Gompa]

On Mon, Jul 6, 2020 at 7:43 PM pmkel...@frontier.com
 wrote:
>
>
> After the QA meeting today, I spent a few hours trying the get  Rawhide
> 0703 WS Live installed with btrfs.
>
> I have Rawhide 0703 WS Live on a thumb drive. I know this works fine
> when taking the default for the disk. I was trying to do a bare metal
> install to my test machine (Lenovo M53 with a i5-4570 CPU). the boot and
> Anaconda start were normal. For the disk drive I selected "Custom" and
> that's when the problems started. Granted, this was the first time I
> ever attempted using the custom option. It displayed the existing mount
> points from the prior default install (ext4). I selected btrfs, but I
> could not find a way the delete the existing mount points or change
> them. I tried lots of things including the Advanced Custom. I was not
> successful in getting the disk configuration set in a configuration that
> Anaconda would accept for installation. Is this the sort of problem with
> Anaconda that was mentioned in the meeting? Or... I suppose these tools
> are not supposed to be very intuitive to use and I need some reading
> material.
>
> The test day instruction were of no aid. and I found nothing in the wiki
> that was helpful.
>

Yeah, custom installation is a little bit of a mind-screw. :(

So, what you should try here is go to the Custom view, then select the
existing partition on the left side, then click the "-" button. It
should prompt you about deleting the partition, and provide a checkbox
for deleting all related partitions. Check that, then click "OK". It
should clear them out. If there's any more you want to delete, rinse
and repeat.

Then you can use the drop down menu to select Btrfs and have it create
the layout as you attempted before.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org

Re: Blocking on user switching: redux

[Neal Gompa]

On Tue, Apr 28, 2020 at 3:05 PM Adam Williamson
 wrote:
>
> On Tue, 2020-04-28 at 12:04 -0400, Neal Gompa wrote:
> > On Tue, Apr 28, 2020 at 12:01 PM Adam Williamson
> >  wrote:
> > > On Tue, 2020-04-28 at 09:26 -0500, Michael Catanzaro wrote:
> > > > On Tue, Apr 14, 2020 at 11:13 am, Adam Williamson
> > > >  wrote:
> > > > > So, once again: do we think it makes sense to consider desktop user
> > > > > switching - that is, switching between multiple active desktop
> > > > > sessions
> > > > > for different users, without logging out and in - as release-blocking?
> > > >
> > > > Workstation WG agrees that user switching should be release blocking.
> > > > We trust QA will write the specific release criterion.
> > >
> > > Obvious thing to do would be to resurrect kparal's old draft. So, KDE
> > > team, since we'll be blocking on this for GNOME, do you want us to
> > > include KDE too or make it Workstation-only? Thanks!
> >
> > I believe Rex mentioned earlier in the thread[1] that it should
> > include KDE. As a member of both Workstation WG and KDE SIG,
>
> *record scratch*
>
> wait, is that even legal?!

Well, I hope so! I replaced Rex as the KDE guy on the Workstation WG
last year... :)

It's been a fun experience so far, we'll see how far I can take it. :D



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org

Re: Blocking on user switching: redux

[Neal Gompa]

On Tue, Apr 28, 2020 at 12:01 PM Adam Williamson
 wrote:
>
> On Tue, 2020-04-28 at 09:26 -0500, Michael Catanzaro wrote:
> > On Tue, Apr 14, 2020 at 11:13 am, Adam Williamson
> >  wrote:
> > > So, once again: do we think it makes sense to consider desktop user
> > > switching - that is, switching between multiple active desktop
> > > sessions
> > > for different users, without logging out and in - as release-blocking?
> >
> > Workstation WG agrees that user switching should be release blocking.
> > We trust QA will write the specific release criterion.
>
> Obvious thing to do would be to resurrect kparal's old draft. So, KDE
> team, since we'll be blocking on this for GNOME, do you want us to
> include KDE too or make it Workstation-only? Thanks!

I believe Rex mentioned earlier in the thread[1] that it should
include KDE. As a member of both Workstation WG and KDE SIG, I support
this.

[1]: 
https://lists.fedoraproject.org/archives/list/k...@lists.fedoraproject.org/message/6HEJM5VPIAQOZ4YYWUOXNBLD3OR27B3Y/


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org

Re: Proposal to adjust final criterion for backgrounds

[Neal Gompa]

On Thu, Apr 16, 2020 at 12:41 PM Matthew Miller
 wrote:
>
> On Thu, Apr 16, 2020 at 12:30:07PM -0400, Neal Gompa wrote:
> > Well, you could check based on EVR of fedora-release. Stable release
> > is always has Release field bumped to 1, and unstable is below 1.
>
> True -- as long as people don't get the idea that this means that release
> candidates are final.
>

Considering that we just upload a given RC as "Final" if the Go/No-Go
decision goes in that RC's favor, I think that's fine.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org

Re: Proposal to adjust final criterion for backgrounds

[Neal Gompa]

On Thu, Apr 16, 2020 at 12:25 PM Matthew Miller
 wrote:
>
> On Thu, Apr 16, 2020 at 08:18:27AM -0700, Adam Williamson wrote:
> > It kinda harks back to a time where we had more custom artwork, I think
> > - like boot splashes and stuff? I don't totally remember, but that was
> > basically it, at the time artwork was more than 'just' the desktop
> > background. These days it's really pretty much that...
>
> Yeah, boot splashes, and custom login theme.
>

I miss all those things...

> I don't know if this has been mentioned (thread parachute drop wheee!) but
> the plan going forward for the wallpaper is to land the next release's
> background in Rawhide right after the branch -- so, a Fedora 34 wallpaper
> should land mid-August.
>
> I love the idea of updating the logo extension to indicate Rawhide. It'd be
> nice for it also to indicate beta but I don't know how it could magically do
> that without without problematic gymnastics (or having it check something
> online, which has its own problems).
>

Well, you could check based on EVR of fedora-release. Stable release
is always has Release field bumped to 1, and unstable is below 1.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org

Re: Blocking on user switching: redux

[Neal Gompa]

On Tue, Apr 14, 2020 at 2:14 PM Adam Williamson
 wrote:
>
> Hi folks!
>
> So, during Fedora 32 Final blocker review, a bug relating to "user
> switching" came up for review:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1817708
>
> I dug into the question of whether we have tended to consider the "log
> in / log out / shut down / reboot" criterion as covering user
> switching, and found that this issue is actually kinda outstanding and
> unresolved for a long time.
>
> Back in January 2015, we kinda provisionally decided that we *did* want
> to block on user switching bugs, by accepting this one as a blocker
> during a review meeting:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1184933
>
> kparal was detailed to propose clearly adding it to the criteria, and
> he duly drafted up a change and mailed it to the relevant lists -
> test@, kde@ and desktop@:
>
> https://lists.fedoraproject.org/pipermail/test/2015-January/124811.html
> https://lists.fedoraproject.org/pipermail/kde/2015-January/014175.html
> https://lists.fedoraproject.org/pipermail/desktop/2015-January/011558.html
>
> However, here things foundered a bit because there was some opposition
> to the idea. The discussion is spread across the three lists, but my
> reading is broadly that there were distinct camps in favour of and
> against blocking on user switching bugs. Prominent "pro-blocking" folks
> were Michael Catanzaro and Kevin Kofler. Prominent "anti-blocking"
> folks were Matthias Clasen, Rex Dieter and Josh Boyer. Obviously that's
> a particularly awkward split because we have pro- and anti- folks on
> both the desktop and KDE teams.
>
> The discussion was pretty active, but in the end it sort of petered out
> without any definite conclusion being reached. The draft changes Kamil
> proposed were never made, and the criterion remained as it was before.
>
> For the purposes of our specific F32 blocker proposal we decided to
> adopt the principle that, since there was a discussion that clearly did
> not reach a consensus that user switching *should* be release-blocking,
> we could not really treat it as such, and thus we rejected the bug as a
> blocker. But I figured it would probably be a good idea to bring the
> topic up again and try to come to a definite conclusion this time.
>
> So, once again: do we think it makes sense to consider desktop user
> switching - that is, switching between multiple active desktop sessions
> for different users, without logging out and in - as release-blocking?
> Has anyone who was active in the previous discussion changed their mind
> on this?
>
> I suppose one question that could potentially arise is whether we could
> treat it as release-blocking for GNOME but not for KDE, or vice versa.
> In general I think it's a good goal to try and keep our standards
> similar across our release-blocking desktops, but I do think we could
> at least consider that, if the discussion seemed to be going in that
> direction.

Unfortunately I missed the discussion because of $DAYJOB stuff...

From my perspective in Workstation WG and member of KDE SIG, I would
say that we should consider this release blocking. This is a somewhat
common use-case on family/shared computers that we should have
working.

(I am a tiny bit biased, I've set up several Fedora systems where this
feature has been used heavily...)




--
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org

Re: Automatic blocker addition proposal: desktop background criterion

[Neal Gompa]

On Thu, Sep 5, 2019 at 2:59 PM Adam Williamson
 wrote:
>
> Hey folks! So, it was suggested at the blocker review meeting on Monday
> that violations of the Basic desktop background criterion:
>
> "The default desktop background must be different from that of the last
> two stable releases."
>
> should be added to the 'automatic blocker' list:
>
> https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Automatic_blockers
>
> this is basically a list of cases where blocker status is so clear-cut
> and obvious that there's no need for us to vote on it, and any
> stakeholder can just invoke the 'automatic blocker' policy and mark a
> bug as 'AcceptedBlocker' if it matches one of the cases in the list.
>
> Does anyone have any objection to adding this? If not, I'll go ahead
> and do it next week. Thanks!

I'm a bit surprised this wasn't _already_ a blocker, but sounds good to me!

Did we just usually have it ready before the beta Go/No-Go event?

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org

Re: Discussion: what would not blocking on btrfs look like?

[Neal Gompa]

On Thu, Aug 29, 2019 at 4:23 AM  wrote:
>
> On Tue, 2019-08-27 at 14:59 -0700, Adam Williamson wrote:
> > On Tue, 2019-08-27 at 13:25 -0400, David Cantrell wrote:
> > > > Josh, to be fair, I can see Neal's point here. In a way you seem
> > > > to be
> > > > kinda sending him in circles here: "anaconda team doesn't have
> > > > the
> > > > time/resources to invest in btrfs development, but you can help
> > > > by
> > > > sending them pull requests. Oh, you sent them a pull request and
> > > > they
> > > > rejected it? Well, it's because they don't have time/resources
> > > > for
> > > > btrfs development..." You're right that one rejected PR doesn't
> > > > necessarily indicate a contribution model problem, but putting
> > > > the
> > > > wider issue aside, a very simple one-liner with a major impact on
> > > > btrfs
> > > > functionality being rejected *does* seem to say a lot about the
> > > > prospects of any btrfs-related work being accepted.
> > > >
> > > > Putting myself in Neal's shoes, given my experience with that PR
> > > > and
> > > > other attempts to help out with btrfs in anaconda, why would I
> > > > invest
> > > > my time and effort to write another one when it seems extremely
> > > > likely
> > > > it would be rejected?
> > >
> > > There's an assumption here that when someone is asked to send a PR,
> > > it
> > > will always be accepted.
> >
> > No, that's not what I'm assuming, but if we (Red Hat) tell people
> > that
> > it would be a good idea to send PRs, we should at least be
> > *potentially* willing to accept them. We should not be saying 'send
> > PRs' if there is no chance of them being accepted. And it would be
> > nicest if we gave people a roadmap: here are the specific things you
> > can do that would be acceptable to us as a way to continue including
> > btrfs handling in the installer.
>
> Sorry but I have to react on this. It's killing me how many of you
> people here are telling Anaconda does not accept patches. That is
> really not true. We have smaller amount of contributions from community
> that is partially our fault because of a lack of documentation but
> mainly it's really hard to develop & test Anaconda and most users see
> it just once in a few years so it's not bothering them so much. I guess
> most of the installers are in the same situation.
>

I sat on this for a few days, as I wanted to cool down and think about
how to reply to this. As of this moment, I have directly and
indirectly contributed to both the Red Hat and SUSE installers, and
yes it's definitely true that both installers have some of the worst
interaction models for contributors I've ever seen.

YaST's contribution model and process seems to be somewhat better,
because their team has components being used by other people. Their
libyui components are used by Fedora and Mageia for dnfdragora, and
the rest of ManaTools in Mageia uses it too. The YaST control center
is a cornerstone in the user experience in SUSE distributions, so
there are contributors from their community who do work on the main
YaST components.

The Calamares installer stack has a pretty healthy community, but our
community has an interesting aversion to all things Qt/KDE even though
the installer works fine on Fedora...

But the point I'm trying to make is there is no reason for Anaconda to
be so difficult. Unfortunately, it is.

> Please before any of you will tell again that Anaconda team is not
> accepting patches, please look on the last few years history. How many
> patches were "rejected" and how many were accepted. There are just a
> few patches which weren't accepted and basically only a few PR (I would
> even say the only one) for BTRFS. That is unfortunate but it's not all
> our contributions.
>

I also took the opportunity look back at over the last 400 merged pull
requests by paging through GitHub. Now I don't exactly have firm
numbers, but in the past 400 pull requests, I saw less than a dozen
pull requests merged from non-RHers. Half of them were from Pat from
the Scientific Linux team. One of them was a documentation fix from
some person I don't recognize with no clear affiliation. If I page
back *slightly more* then the next PR from a non Red Hatter that was
merged was *mine* fixing Anaconda's package exclusion feature for
kickstarts (which was nearly two years old when it was merged).

Of the 42 currently open pull requests, 4 are from people I could
clearly identify as not from Red Hatters. Of the ones that are from
Red Hatters, 7 appear to not be from members of the Red Hat Installer
team or the Red Hat Bootloader team as I know of them.

The lag time to response *is* improving. It's gone down from years to
months, with the most recent pull request getting a comment within a
week, and then stalling out after that. So it may even improve to
weeks!

As Adam pointed out, there's literally no reason for me to attempt
more sophisticated changes to Anaconda if a simple one-liner can't get
merged. And I didn't even 

Re: Discussion: what would not blocking on btrfs look like?

[Neal Gompa]

On Tue, Aug 27, 2019 at 1:30 PM Laura Abbott  wrote:
>
>
> > I also think there are other perspectives that might at least
> > potentially be useful here. Right now we've mainly heard from a couple
> > of community folks who are very passionate about btrfs, and Red Hat
> > folks from anaconda/kernel development and RHEL management who
> > essentially see it as a burden that is not aligned with their
> > priorities. Is that all the perspectives we have to make a decision
> > with? I think we should at least talk to the Facebook team that
> > apparently uses btrfs on Fedora extensively about whether they'd be sad
> > to see installer btrfs support die and, if so, whether they'd perhaps
> > be interested in helping support it. And more broadly, community folks
> > on all the lists this is going to: are there more people who actually
> > are interested in this functionality and would be sad to see it go? If
> > btrfs isn't a part of Red Hat's product roadmaps but is important to
> > lots of folks in the wider Fedora community, maybe that's another
> > indicator we can useor indeed, if it turns out not many folks
> > actually care.
>
> As an on the record btrfs skeptic, I think it would help to have an 
> end-to-end picture of what's missing or needs to be added across all 
> packages. If someone comes to me today and says "I want to help btrfs be 
> successful in Fedora", I'd like to know where to point them besides just 
> suggesting they get added on the btrfs kernel alias.

Forgive me, but I had missed this in the sea of other messages (this
thread is long and crazy now!).

The Fedora Btrfs folks over the past few years have implemented the following:
* Developed a DNF plugin to invoke snapper correctly for full system snapshots
* Ported over the change set from SUSE to the Fedora grub2 package to
support btrfs boot to snapshot
* Fixed grubby to handle snapshot menu items for grub (this is kind of
deprecated with BLS, though)

The things that I'm looking to do:
* Develop a libdnf plugin to replace the existing DNF snapper plugin
(so that PackageKit is also covered)
* Adapt the boot to snapshot stuff to use BLS (with boom, presumably?)

The things I've been pushing off (for obvious reasons):
* Enable Anaconda to allow /boot to be a btrfs subvolume (PR is in limbo...)
* Ensure Anaconda configures snapper automatically when btrfs rootfs is selected
* Design a sensible default btrfs layout (perhaps based on the current
openSUSE one?)

The mid-/long-term things I'm thinking of:
* Consideration of moving the rpmdb to /usr/lib/sysimage/rpm (unifying
standard Fedora and OSTree Fedora...)
* A libdnf plugin to implement atomic package management using btrfs
snapshots (like transactional-update, except done properly...)

That's basically the full scope of the Btrfs enablement work I've
planned right now.



--
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org

Re: Discussion: what would not blocking on btrfs look like?

[Neal Gompa]

On Tue, Aug 27, 2019 at 8:57 AM Josh Boyer  wrote:
>
> On Tue, Aug 27, 2019 at 8:48 AM Neal Gompa  wrote:
> >
> > On Tue, Aug 27, 2019 at 8:30 AM Josh Boyer  
> > wrote:
> > >
> > > On Tue, Aug 27, 2019 at 8:10 AM Neal Gompa  wrote:
> > > >
> > > > On Tue, Aug 27, 2019 at 7:41 AM Josh Boyer  
> > > > wrote:
> > > > >
> > > > > On Tue, Aug 27, 2019 at 7:19 AM Neal Gompa  wrote:
> > > > > >
> > > > > > On Tue, Aug 27, 2019 at 5:55 AM  wrote:
> > > > > > >
> > > > > > > On Mon, 2019-08-26 at 23:54 -0400, Neal Gompa wrote:
> > > > > > > > On Mon, Aug 26, 2019 at 7:16 AM  wrote:
> > > > > > > > >
> > > > > > > > > I understand them. The point is, for them and even us (the
> > > > > > > > > installer)
> > > > > > > > > is work on BTRFS not a priority. It's something we can't 
> > > > > > > > > benefit on
> > > > > > > > > RHEL and it could be almost completely replaced by LVM + xfs
> > > > > > > > > solution.
> > > > > > > > > However, it still giving us bugs and making our test surface
> > > > > > > > > bigger.
> > > > > > > > >
> > > > > > > > > > From the Anaconda team PoV it would make our lives easier 
> > > > > > > > > > to not
> > > > > > > > > support BTRFS at all. I'm not saying that we should drop 
> > > > > > > > > BTRFS in
> > > > > > > > > Fedora, only that it would be easier for Anaconda team to be
> > > > > > > > > without
> > > > > > > > > that on Fedora.
> > > > > > > >
> > > > > > > > This is flat-out a trap. This is what makes Anaconda such a 
> > > > > > > > failure
> > > > > > > > as
> > > > > > > > a community project. Why does the past (RHEL) affect the 
> > > > > > > > present and
> > > > > > > > future (Fedora)? There's basically no way whatsoever to make 
> > > > > > > > anything
> > > > > > > > better with this logic. The Anaconda releases that any 
> > > > > > > > improvements
> > > > > > > > would be going into aren't even landing into the RHEL 8 branch 
> > > > > > > > that
> > > > > > > > governs the latest iteration of Fedora's past. From any 
> > > > > > > > reasonable
> > > > > > > > person's perspective, this answer makes no sense unless you're 
> > > > > > > > using
> > > > > > > > RHEL as an excuse to not support Fedora.
> > > > > > > >
> > > > > > >
> > > > > > > RHEL is not the past. Everything we do we have to think that it 
> > > > > > > will go
> > > > > > > to RHEL and if it is Fedora specific we have to create a way to 
> > > > > > > disable
> > > > > > > the functionality for another RHEL branching. And yes, we have a 
> > > > > > > few
> > > > > > > things (not only a BTRFS) specific to Fedora the same way as a few
> > > > > > > things specific to RHEL which are disabled on Fedora.
> > > > > > >
> > > > > > > And as I wrote before, I'm not saying that we will remove the 
> > > > > > > BTRFS
> > > > > > > support from Fedora. The point is that making the list specific to
> > > > > > > releases smaller will make our live easier.
> > > > > > >
> > > > > >
> > > > > > By definition, RHEL *is* the past from a Fedora context. It's forked
> > > > > > from an old version of Fedora that's not supported anymore. It is 
> > > > > > the
> > > > > > result of decisions that aren't supposed to apply to Fedora. And it 
> > > > > > is
> > > > > > the result of a different bias that should never apply to Fedora if
> > > > > > the RH ecosystem is supposed to be able to evolve.
> > > > >
> > > > > There is always th

Re: Discussion: what would not blocking on btrfs look like?

[Neal Gompa]

On Tue, Aug 27, 2019 at 8:30 AM Josh Boyer  wrote:
>
> On Tue, Aug 27, 2019 at 8:10 AM Neal Gompa  wrote:
> >
> > On Tue, Aug 27, 2019 at 7:41 AM Josh Boyer  
> > wrote:
> > >
> > > On Tue, Aug 27, 2019 at 7:19 AM Neal Gompa  wrote:
> > > >
> > > > On Tue, Aug 27, 2019 at 5:55 AM  wrote:
> > > > >
> > > > > On Mon, 2019-08-26 at 23:54 -0400, Neal Gompa wrote:
> > > > > > On Mon, Aug 26, 2019 at 7:16 AM  wrote:
> > > > > > >
> > > > > > > I understand them. The point is, for them and even us (the
> > > > > > > installer)
> > > > > > > is work on BTRFS not a priority. It's something we can't benefit 
> > > > > > > on
> > > > > > > RHEL and it could be almost completely replaced by LVM + xfs
> > > > > > > solution.
> > > > > > > However, it still giving us bugs and making our test surface
> > > > > > > bigger.
> > > > > > >
> > > > > > > > From the Anaconda team PoV it would make our lives easier to not
> > > > > > > support BTRFS at all. I'm not saying that we should drop BTRFS in
> > > > > > > Fedora, only that it would be easier for Anaconda team to be
> > > > > > > without
> > > > > > > that on Fedora.
> > > > > >
> > > > > > This is flat-out a trap. This is what makes Anaconda such a failure
> > > > > > as
> > > > > > a community project. Why does the past (RHEL) affect the present and
> > > > > > future (Fedora)? There's basically no way whatsoever to make 
> > > > > > anything
> > > > > > better with this logic. The Anaconda releases that any improvements
> > > > > > would be going into aren't even landing into the RHEL 8 branch that
> > > > > > governs the latest iteration of Fedora's past. From any reasonable
> > > > > > person's perspective, this answer makes no sense unless you're using
> > > > > > RHEL as an excuse to not support Fedora.
> > > > > >
> > > > >
> > > > > RHEL is not the past. Everything we do we have to think that it will 
> > > > > go
> > > > > to RHEL and if it is Fedora specific we have to create a way to 
> > > > > disable
> > > > > the functionality for another RHEL branching. And yes, we have a few
> > > > > things (not only a BTRFS) specific to Fedora the same way as a few
> > > > > things specific to RHEL which are disabled on Fedora.
> > > > >
> > > > > And as I wrote before, I'm not saying that we will remove the BTRFS
> > > > > support from Fedora. The point is that making the list specific to
> > > > > releases smaller will make our live easier.
> > > > >
> > > >
> > > > By definition, RHEL *is* the past from a Fedora context. It's forked
> > > > from an old version of Fedora that's not supported anymore. It is the
> > > > result of decisions that aren't supposed to apply to Fedora. And it is
> > > > the result of a different bias that should never apply to Fedora if
> > > > the RH ecosystem is supposed to be able to evolve.
> > >
> > > There is always the *next* RHEL.  Or, if you want to remove a product
> > > context, the next enterprise operating system derived from Fedora.
> > > RHEL/enterprise is both past and future and Fedora focuses on the
> > > future.  You cannot dismiss enterprise as a target by waiving it away
> > > as "past".
> > >
> >
> > Until there's a branch in Anaconda's git for the next version of RHEL,
> > it doesn't exist yet. I'm sure people are *thinking* about it, but
> > it's obviously on the back burner for a little while. I would expect
> > to start to see a rhel-9 branch in Anaconda in 1.5 years, but for now
> > it doesn't exist.
>
> In 1.5 years is entirely too late.  Massively so.  I know people think
> we're paying lip-service to upstream when discussing Fedora and RHEL,
> but even with a terrible "import once" model the code being developed
> in Fedora right now will materially land in RHEL 9.  Your presumption
> on a branch needing to exist is simply incorrect.
>

For us non RH people, there's nothing for us to do about RHEL 9 right
now. Your planning is done in secret, and there's little to no
com

Re: Discussion: what would not blocking on btrfs look like?

[Neal Gompa]

On Tue, Aug 27, 2019 at 7:41 AM Josh Boyer  wrote:
>
> On Tue, Aug 27, 2019 at 7:19 AM Neal Gompa  wrote:
> >
> > On Tue, Aug 27, 2019 at 5:55 AM  wrote:
> > >
> > > On Mon, 2019-08-26 at 23:54 -0400, Neal Gompa wrote:
> > > > On Mon, Aug 26, 2019 at 7:16 AM  wrote:
> > > > >
> > > > > I understand them. The point is, for them and even us (the
> > > > > installer)
> > > > > is work on BTRFS not a priority. It's something we can't benefit on
> > > > > RHEL and it could be almost completely replaced by LVM + xfs
> > > > > solution.
> > > > > However, it still giving us bugs and making our test surface
> > > > > bigger.
> > > > >
> > > > > > From the Anaconda team PoV it would make our lives easier to not
> > > > > support BTRFS at all. I'm not saying that we should drop BTRFS in
> > > > > Fedora, only that it would be easier for Anaconda team to be
> > > > > without
> > > > > that on Fedora.
> > > >
> > > > This is flat-out a trap. This is what makes Anaconda such a failure
> > > > as
> > > > a community project. Why does the past (RHEL) affect the present and
> > > > future (Fedora)? There's basically no way whatsoever to make anything
> > > > better with this logic. The Anaconda releases that any improvements
> > > > would be going into aren't even landing into the RHEL 8 branch that
> > > > governs the latest iteration of Fedora's past. From any reasonable
> > > > person's perspective, this answer makes no sense unless you're using
> > > > RHEL as an excuse to not support Fedora.
> > > >
> > >
> > > RHEL is not the past. Everything we do we have to think that it will go
> > > to RHEL and if it is Fedora specific we have to create a way to disable
> > > the functionality for another RHEL branching. And yes, we have a few
> > > things (not only a BTRFS) specific to Fedora the same way as a few
> > > things specific to RHEL which are disabled on Fedora.
> > >
> > > And as I wrote before, I'm not saying that we will remove the BTRFS
> > > support from Fedora. The point is that making the list specific to
> > > releases smaller will make our live easier.
> > >
> >
> > By definition, RHEL *is* the past from a Fedora context. It's forked
> > from an old version of Fedora that's not supported anymore. It is the
> > result of decisions that aren't supposed to apply to Fedora. And it is
> > the result of a different bias that should never apply to Fedora if
> > the RH ecosystem is supposed to be able to evolve.
>
> There is always the *next* RHEL.  Or, if you want to remove a product
> context, the next enterprise operating system derived from Fedora.
> RHEL/enterprise is both past and future and Fedora focuses on the
> future.  You cannot dismiss enterprise as a target by waiving it away
> as "past".
>

Until there's a branch in Anaconda's git for the next version of RHEL,
it doesn't exist yet. I'm sure people are *thinking* about it, but
it's obviously on the back burner for a little while. I would expect
to start to see a rhel-9 branch in Anaconda in 1.5 years, but for now
it doesn't exist.

> > From the way you describe it, Fedora is just something occasionally
> > give lip service to while your main focus is RHEL. That's fine, but
> > that is a problem for the Fedora context.
>
> Neal, I don't understand.  The source code to anaconda is available.
> What is preventing you from taking it and making a micro-fork that
> does better btrfs enablement, and packaging that in Fedora and using
> it in a spin?
>

I have seriously contemplated it. It isn't the first time I've done a
fork because I had to[1].

But the main reason I don't do it is because it will cause more damage
in the Fedora community by doing so. Two sets of packages for Anaconda
that all the things that depend on Anaconda could cause a huge level
of breakage because the two versions must *always* be drop-in
replacements for each other. If they're not, it makes it impossible to
leverage the Fedora tooling to do things like making spins and such. I
don't even *know* what kind of work it would entail if I wanted it to
be an official spin composed through pungi. I'm pretty sure the releng
folks would kill me for doing that, as now pungi would have be aware
and switch anaconda packages for lorax...

Additionally, it would require a fork of pykickstart so that further
enhancements to the Btrfs partitioning can be defined. However, *that*
causes bigger problems because

Re: Discussion: what would not blocking on btrfs look like?

[Neal Gompa]

On Tue, Aug 27, 2019 at 5:55 AM  wrote:
>
> On Mon, 2019-08-26 at 23:54 -0400, Neal Gompa wrote:
> > On Mon, Aug 26, 2019 at 7:16 AM  wrote:
> > >
> > > I understand them. The point is, for them and even us (the
> > > installer)
> > > is work on BTRFS not a priority. It's something we can't benefit on
> > > RHEL and it could be almost completely replaced by LVM + xfs
> > > solution.
> > > However, it still giving us bugs and making our test surface
> > > bigger.
> > >
> > > > From the Anaconda team PoV it would make our lives easier to not
> > > support BTRFS at all. I'm not saying that we should drop BTRFS in
> > > Fedora, only that it would be easier for Anaconda team to be
> > > without
> > > that on Fedora.
> >
> > This is flat-out a trap. This is what makes Anaconda such a failure
> > as
> > a community project. Why does the past (RHEL) affect the present and
> > future (Fedora)? There's basically no way whatsoever to make anything
> > better with this logic. The Anaconda releases that any improvements
> > would be going into aren't even landing into the RHEL 8 branch that
> > governs the latest iteration of Fedora's past. From any reasonable
> > person's perspective, this answer makes no sense unless you're using
> > RHEL as an excuse to not support Fedora.
> >
>
> RHEL is not the past. Everything we do we have to think that it will go
> to RHEL and if it is Fedora specific we have to create a way to disable
> the functionality for another RHEL branching. And yes, we have a few
> things (not only a BTRFS) specific to Fedora the same way as a few
> things specific to RHEL which are disabled on Fedora.
>
> And as I wrote before, I'm not saying that we will remove the BTRFS
> support from Fedora. The point is that making the list specific to
> releases smaller will make our live easier.
>

By definition, RHEL *is* the past from a Fedora context. It's forked
from an old version of Fedora that's not supported anymore. It is the
result of decisions that aren't supposed to apply to Fedora. And it is
the result of a different bias that should never apply to Fedora if
the RH ecosystem is supposed to be able to evolve.

From the way you describe it, Fedora is just something occasionally
give lip service to while your main focus is RHEL. That's fine, but
that is a problem for the Fedora context.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org

Re: Discussion: what would not blocking on btrfs look like?

[Neal Gompa]

On Mon, Aug 26, 2019 at 7:16 AM  wrote:
>
> On Sat, 2019-08-24 at 07:31 -0700, Adam Williamson wrote:
> > On Fri, 2019-08-23 at 19:00 -0600, Chris Murphy wrote:
> > > On Fri, Aug 23, 2019 at 1:17 PM Adam Williamson
> > >  wrote:
> > >
> > > > So, there was recently a Thing where btrfs installs were broken,
> > > > and
> > > > this got accepted as a release blocker:
> > > >
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=1733388
> > >
> > > Summary: This bug was introduced and discovered in linux-next, it
> > > started to affect Fedora 5.3.0-rc0 kernels in openqa tests, patch
> > > appeared during rc1, and the patch was merged into 5.3.0-rc2. The
> > > bug
> > > resulted in a somewhat transient deadlock which caused installs to
> > > hang, but no corruption. The fix, 2 files changed, 12 insertions, 8
> > > deletions (1/2 the insertions are comments).
> > >
> > > How remarkable or interesting is this bug? And in particular,
> > > exactly
> > > how much faster should it have been fixed in order to avoid
> > > worrying
> > > about it being a blocker bug?
> > >
> > > 7/25 14:27 utc bug patch was submitted to linux-btrfs@
> > > 7/25 22:33 utc bug was first reported in Fedora bugzilla
> > > 7/26 19:20 utc I confirmed upstream's patch related to this bug
> > > with
> > > upstream and updated the Fedora bug
> > > 7/26 22:50 utc I confirmed it was merged into rc2, and updated the
> > > Fedora bug
> > >
> > > So in the context of status quo, where Btrfs is presented as an
> > > option
> > > in the installer and if there are bugs they Beta blocking, how
> > > could
> > > or should this have been fixed sooner? What about the handling
> > > should
> > > have been different?
> >
> > Nothing. The kernel team's concern is not related to this bug or the
> > handling of this bug in any way. The only relevance of the bug is
> > that
> > it alerted the kernel team to the fact that we currently block on
> > btrfs, which they think we should not.
>
> I understand them. The point is, for them and even us (the installer)
> is work on BTRFS not a priority. It's something we can't benefit on
> RHEL and it could be almost completely replaced by LVM + xfs solution.
> However, it still giving us bugs and making our test surface bigger.
>
> >From the Anaconda team PoV it would make our lives easier to not
> support BTRFS at all. I'm not saying that we should drop BTRFS in
> Fedora, only that it would be easier for Anaconda team to be without
> that on Fedora.

This is flat-out a trap. This is what makes Anaconda such a failure as
a community project. Why does the past (RHEL) affect the present and
future (Fedora)? There's basically no way whatsoever to make anything
better with this logic. The Anaconda releases that any improvements
would be going into aren't even landing into the RHEL 8 branch that
governs the latest iteration of Fedora's past. From any reasonable
person's perspective, this answer makes no sense unless you're using
RHEL as an excuse to not support Fedora.

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org

Re: Discussion: what would not blocking on btrfs look like?

[Neal Gompa]

On Mon, Aug 26, 2019 at 11:16 AM Laura Abbott  wrote:
>
> On 8/23/19 9:00 PM, Chris Murphy wrote:
> > On Fri, Aug 23, 2019 at 1:17 PM Adam Williamson
> >  wrote:
> >
> >> So, there was recently a Thing where btrfs installs were broken, and
> >> this got accepted as a release blocker:
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1733388
> >
> > Summary: This bug was introduced and discovered in linux-next, it
> > started to affect Fedora 5.3.0-rc0 kernels in openqa tests, patch
> > appeared during rc1, and the patch was merged into 5.3.0-rc2. The bug
> > resulted in a somewhat transient deadlock which caused installs to
> > hang, but no corruption. The fix, 2 files changed, 12 insertions, 8
> > deletions (1/2 the insertions are comments).
> >
> > How remarkable or interesting is this bug? And in particular, exactly
> > how much faster should it have been fixed in order to avoid worrying
> > about it being a blocker bug?
> >
> > 7/25 14:27 utc bug patch was submitted to linux-btrfs@
> > 7/25 22:33 utc bug was first reported in Fedora bugzilla
> > 7/26 19:20 utc I confirmed upstream's patch related to this bug with
> > upstream and updated the Fedora bug
> > 7/26 22:50 utc I confirmed it was merged into rc2, and updated the Fedora 
> > bug
> >
> > So in the context of status quo, where Btrfs is presented as an option
> > in the installer and if there are bugs they Beta blocking, how could
> > or should this have been fixed sooner? What about the handling should
> > have been different?
> >
>
> That's a fair question. This bug actually represents how this _should_
> work. The concern is that in the past we haven't seen a lot engagement
> in the past. Maybe today that has changed as demonstrated by this thread.
> I'm still concerned about having this be a blocker vs. just keeping it
> as an option, simply because a blocker stops the entire release and it
> can be a last minute scramble to get things fixed. This was the ideal
> case for a blocker bugs and I'm skeptical about all bugs going this well.
> If we had a few more people who were willing to be on the btrfs alias and
> do the work for blocker bugs it would be a much stronger case.
>

Out of curiosity, how many such issues have we had in the past 2
years? I personally can't recall any monumental occasions where people
were scrambling over *Btrfs* in Fedora. If anything, we continue to
inherit the work that SUSE and Facebook are doing upstream as part of
us continually updating our kernels, which I'm grateful for.

And in the instances where we've had such issues, has anyone reached
out to btrfs folks in Fedora? Chris and myself are the current ones,
but there have been others in the past. Both of us are subscribed to
the linux-btrfs mailing list, and Chris has a decent rapport with most
of the btrfs developers.

What more do you want? Actual btrfs developers in Fedora? We don't
have any for the majority of filesystems Fedora supports, only XFS. Is
there some kind of problem with communicating with the upstream kernel
developers about Fedora bugs that I'm not aware of?

> > I note here that ext2 and ext3 are offered as file systems in
> > Custom/Advanced partitioning and in this sense have parity with Btrfs.
> > If this same bug occurred in ext2 or ext3 would or should that cause
> > discussion to drop them from the installer, even if the bug were fixed
> > within 24 hours of discovery and patch? What about vfat? That's
> > literally the only truly required filesystem that must work, for the
> > most commonly supported hardware so it can't be dropped, we'd just be
> > stuck until it got fixed. That work would have to be done upstream,
> > yes?
> >
>
> I don't think that's really a fair comparison. Just because options
> are presented doesn't mean all of them are equal. ext2/ext3 and vfat
> have been in development for much longer than btrfs and length of development
> is something that's particularly important for file system stability
> from talking with file system developers. It's not impossible for there
> to be bugs in ext4 for example (we've certainly seen them before) but
> btrfs is only now gaining overall stability and we're still more likely to see
> bugs, especially with custom setups where people are likely to find
> edge cases.
>

Nope. We can totally use this because LVM has not existed as long (we
use LVM + filesystem by default, not plain partitions), and we still
encounter quirks with things like thinp LVM combined with these
filesystems. OverlayFS is mostly hot garbage (kernel people know it,
container people know it, filesystem people know it, etc.), and yet we
continue to try to use it in more places. Stratis is in an odd state
of limbo now, since its main developer and advocate left Red Hat.

There are plenty of examples of Red Hat doing crazy/experimental
things... I'd like to think Red Hat isn't supposed to be special here,
but in this realm, it seems like it is...


-- 
真実はいつも一つ！/ Always, there's only one truth!

Re: Discussion: what would not blocking on btrfs look like?

[Neal Gompa]

On Mon, Aug 26, 2019 at 10:48 PM Chris Murphy  wrote:
>
> On Fri, Aug 23, 2019 at 1:44 PM Justin Forbes  wrote:
> >
> > All of this, the criteria, and the UI support for btrfs are from the
> > many years old proposal to make btrfs the default filesystem.  In the
> > beginning, it was not ready, but did show promise. This proposal came
> > up for several releases in a row, and at the end of it, even the
> > upstream developers recommended against it.
>
> Josef Bacik alone pushed for it. And it was Fedora that wasn't ready
> for Btrfs, not the other way around. In Josef's last couple emails to
> devel@ he stated the decision would need to be made by others, not
> him. He pretty much gave up once SUSE got there first.
>

Indeed. In fact, I more or less took over the reigns of trying to
improve Fedora's Btrfs support after Josef gave up.

> I'm not aware of any upstream developers recommending Fedora not use
> it. A significant chunk of upstream are at SUSE and by this time had
> moved to Btrfs by default, so it'd be a little weird if they're
> recommending against the thing.
>

If anything, the Btrfs stack developers at SUSE have been nothing but
helpful whenever I've talked to them about working on bringing this to
Fedora. I've literally *never* heard them say that Btrfs isn't ready.
However, they have told me in the past to be cautious with some
features for "enterprise supportability". But they've never said
anything about Btrfs not being ready as a whole.

>
> > At this point, it is safe
> > to say that btrfs will not be the default.  Since that time, things
> > have not gotten better.
>
> This is ambiguous. One possible way to read this is: no matter what
> resources are put into supporting it in Fedora, it's safe to say it
> won't be the default. Another possibility: the support resources
> necessary haven't materialized, therefore it won't be the default.
>
> I would like to better understand why it is "safe to say" it won't be
> the default.
>

I really didn't want this to come up, and I ignored this the first
time, but I can't anymore...

I'm pretty sure this is another variation of the "shutdowns" I keep
getting when trying to work on Btrfs support in Fedora. It's
surprisingly annoying that Fedora as a community distribution has
touch points where community members have basically zero chance at
being successful at anything.

Honestly, I'm surprised we've kept Anaconda as the installer for
Fedora, given the attitude I and other community members get from the
Anaconda developers and sheer amount of pain and agony we have to deal
with to even attempt simple contributions, much less complex ones.
Amazingly, I do have a single commit in Anaconda[0], but the amount of
effort and time it took to get it in was ridiculous.

And while I like the Anaconda installer, I don't like that there can
never be a community around it. It's one of those projects that has a
stranglehold around it that is designed to discourage you.

And that's not even with things like Btrfs. There's been a request
(with code even!) from the Qubes OS folks to add GPG key support to
kickstart[1] and Anaconda[2] for literally years. I've wanted to
accept the changes for livecd-tools[3] for years, but I can't until
pykickstart and anaconda support it. I'm not even going to get into
the repo --priority option from the FedBerry guys.

By any meaningful measure, Anaconda has less community than Btrfs, and
it remains the "blessed" installer. Moreover, it gets to
singlehandedly dictate what the distribution supports. And its
developers basically get to shut down any discussion of anything
related to Btrfs, in any form or fashion[4]. And you wonder why Btrfs
support is so weak in Fedora? Because of all this, I was discouraged
from finishing and submitting my change proposal to fully enable Btrfs
with full system snapshots[5].

I'm honestly not surprised that Josef gave up. I'm surprised that I'm
still stubborn enough to try to make it happen, but perhaps there's a
part of me that hates giving up...

[0]: 
https://github.com/rhinstaller/anaconda/commit/c8c5589e4a4c5451d91ae8c47bf2fe0270d2af5f
[1]: https://github.com/bcl/pykickstart/pull/32
[2]: https://github.com/rhinstaller/anaconda/pull/375
[3]: https://github.com/livecd-tools/livecd-tools/pull/14
[4]: https://bugzilla.redhat.com/show_bug.cgi?id=1717728#c9
[5]: https://fedoraproject.org/wiki/Changes/BtrfsWithFullSystemSnapshots

>
> >
> >  Yes, there is active btrfs development
> > upstream.  It is fairly narrowly focused, and not something we can
> > rely upon for a supported default among the Fedora use cases.
>
> The thread is ostensibly about whether it's appropriate to block
> release on Btrfs related bugs, not whether it should be the default
> file system. But as it's been brought up, I'd like to know if there's
> any difference in the expected support resources between it remaining
> "blocker worthy" versus becoming "a default file system" somewhere in
> the Fedora ecosystem in a release 

Re: Discussion: what would not blocking on btrfs look like?

[Neal Gompa]

On Fri, Aug 23, 2019 at 3:48 PM Justin Forbes  wrote:
>
> On Fri, Aug 23, 2019 at 2:17 PM Adam Williamson
>  wrote:
> >
> > Hey folks!
> >
> > So, there was recently a Thing where btrfs installs were broken, and
> > this got accepted as a release blocker:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1733388
> >
> > The bug was fixed, so that's fine, but along the way, Laura said this:
> >
> > "I'm strongly against anything with btrfs being a blocker. If that's in
> > the criteria I think we should see about removing btrfs simply because
> > we don't have the resources to actually deal with btrfs besides
> > reporting bugs upstream."
> >
> > and Justin followed up with:
> >
> > "Agreed, btrfs has been a gamble pretty much always. See previous
> > discussion around proposals to make btrfs default. Ext4 and xfs should
> > be the only release blocking."
> >
> > So, that's the whole kernel team 'strongly against' blocking on btrfs.
> > Which means we should talk about not doing that any more!
> >
> > This is a bit complicated, though, because of how the Final criteria
> > are phrased. Basic does not include btrfs at all, and Beta includes a
> > laundry list we can just remove btrfs from:
> >
> > "When using both the installer-native and the blivet-gui-based custom
> > partitioning flow, the installer must be able to:
> >
> > * Correctly interpret, and modify as described below, any disk with a
> > valid ms-dos or gpt disk label and partition table containing ext4
> > partitions, LVM and/or btrfs volumes, and/or software RAID arrays at
> > RAID levels 0, 1 and 5 containing ext4 partitions
> > * Create mount points backed by ext4 partitions, LVM volumes or btrfs
> > volumes, or software RAID arrays at RAID levels 0, 1 and 5 containing
> > ext4 partitions
> > ..."
> >
> > so those two are easy. However, the Final criterion is not laundry
> > list-style. The relevant Final criterion is this:
> >
> > "The installer must be able to create and install to any workable
> > partition layout using any file system and/or container format
> > combination offered in a default installer configuration."
> >
> > with a somewhat apologetic explanatory footnote:
> >
> > "Wait, what?
> > Yeah, we know. This is a huge catch-all criterion and it's subject to a
> > lot of on-the-fly interpretation. Broadly what it's 'meant to mean' is
> > that you should be able to do anything sane that the Installation
> > Destination spoke attempts to let you do, without the installer
> > exploding or failing. We are trying to write more specific criteria
> > covering this area, but it's not easy. Patches welcome, as the kids
> > say..."
> >
> > so as the footnote says, the rule is basically "if the installer lets
> > you do it, it ought to work". It seems a bit awkward to craft an
> > exception for btrfs from that. I mean, technically it's easy:
> >
> > "The installer must be able to create and install to any workable
> > partition layout using any file system and/or container format
> > combination offered in a default installer configuration, except
> > btrfs."
> >
> > but that's odd. Why is btrfs, alone, an exception? It kinda goes
> > against the fundamental idea of the criterion: that we stand behind
> > everything the UI offers.
>
> All of this, the criteria, and the UI support for btrfs are from the
> many years old proposal to make btrfs the default filesystem.  In the
> beginning, it was not ready, but did show promise. This proposal came
> up for several releases in a row, and at the end of it, even the
> upstream developers recommended against it.  At this point, it is safe
> to say that btrfs will not be the default.  Since that time, things
> have not gotten better.   Yes, there is active btrfs development
> upstream.  It is fairly narrowly focused, and not something we can
> rely upon for a supported default among the Fedora use cases.

Getting btrfs in Fedora to be in a state where it *could* be the
default is something I am working towards. However, it is *very* hard
when people keep shutting down discussions that I try to have about
enablement related to it. The situation with btrfs today is many
orders of magnitude better than before, and yet I've mostly been
improving Btrfs support in Fedora in tiny ways because the bigger
things to do (improving kickstart, Anaconda, etc.) are impossible due
to how difficult it is to contribute to those projects.

The *only* remaining "major" issue in Btrfs itself is the RAID 5/6
feature, which does not provide write hole protection without
additional work (similar to mdraid). There was some work last year by
David Sterba to rework the the RAID code for the SUSE Hackweek 17, but
it has not been completed yet. Some work was done again to try to land
this for the 5.3 cycle, but some last minute issues got that
postponed. It's definitely on the radar to fix, though.

I've been watching and using Btrfs since May of 2015, and the
development has drastically improved. I know for a fact no one