Re: ABRT - Server says: 400 Bad Request

[Kamil Paral]

On Fri, Sep 27, 2024 at 8:14 AM lejeczek via test <
test@lists.fedoraproject.org> wrote:

> Hi guys.
>
> I've submitted a bug and it's been a while with no comments, so I hope -
> perhaps devel checks herel - here I'll get more luck/feedback.
>

Please give us a link to the reported bugzilla. Also, if not stated there,
please state your abrt packages versions.

Hasn't your bugzilla apikey simply expired? Please check the bugzilla
interface.
-- 
___
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: Self-introduction thephatle

[Kamil Paral]

On Tue, Sep 24, 2024 at 5:37 AM Marko Jokinen via test <
test@lists.fedoraproject.org> wrote:

> hello
>
> i am thephatle real name Marko Jokinen Retired Head Chef currently
> co-founder and CTO on International Tourism company. Originally From
> scandinavia living in Asia but soon Moving back to Scandinavia for longer
> residence and still will be living in 2 countries. Timezones Asia UTC+7
> Scandinavia UTC+3.
>
> i have been wanting to join Fedora contributing for year now, but i guess
> i am still sufferring imposter syndrome and not feeling i am ready or my
> skills are good enough to be art of the Contributing part.
>
> Alwas been testing new tech or Softwares started long time ago on Windows
> when insider came i joined on it and started to run Windows insider builds
> and man others IOS beta, Android Beta builds. Passion has always been on QA
> side and testing things since i like test and try to fix when i brake them
> and i just like build system from start.
>
> What i can do well i like learning alot and i am Creative Developer/3D
> developer ( Three.js/WebGL/blender ) still learning when i have time. Have
> studied IT support and got nice little Certification From Google for IT
> support Specialist.
>
> Second i really like security and immutable systems with cyber security
> and ethical hacking so now i am Doing my First C|EH certificate on ethical
> hacking and Google Cyber Security Specialist. On side still learning C# and
> Python and sometimes refreshing html,css,sass, react and javascript when i
> start some website project or updating someting
>
> sorry for long mail, but i want to join QA team and start on small scale
> to slowly get to more knowledge to go more demanding stuff
>
> Bugzilla account : thepha...@proton.me
> Fedora User name : thephatle
> Matrix : thepahtle
>

Hi Marko,
welcome! We're happy to have you onboard. Please look at
https://fedoraproject.org/wiki/QA
for some basic info.

To start slow, you can enable updates-testing repository on your current
stable version of Fedora and provide feedback on packages that you know how
to test:
https://fedoraproject.org/wiki/QA:Updates_Testing

Or you can follow test-announce list for announcements of new Fedora 41
composes, and help us test those:
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org/
Issues found can be discussed here or at:
https://discussion.fedoraproject.org/tags/c/project/7/quality-team
Bugs should be directed to Bugzilla. You can also try to fill out some
release validation matrices on wiki by following test cases (see the links
in test-announce compose announcements).

Thanks,
Kamil
-- 
___
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: 2024-07-22 - Fedora Quality Meeting - minutes

[Kamil Paral]

On Mon, Jul 22, 2024 at 6:00 PM Kamil Paral  wrote:
> Action items
> 
> * kparal to update Desktop test matrix template to mark KDE as
> blocking on aarch64

It was not just the Desktop matrix. Here are the changes I made:
https://fedoraproject.org/w/index.php?title=Template%3ADesktop_test_matrix&diff=715278&oldid=703933
https://fedoraproject.org/w/index.php?title=Template%3AInstallation_test_matrix&diff=715279&oldid=702590
https://fedoraproject.org/w/index.php?title=Template%3ABase_test_matrix&diff=715280&oldid=701675

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

2024-07-22 - Fedora Quality Meeting - minutes

[Kamil Paral]

Text Log: 
https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-07-22/quality.2024-07-22-15.00.log.txt
HTML Log: 
https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-07-22/quality.2024-07-22-15.00.log.html
Text Minutes: 
https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-07-22/quality.2024-07-22-15.00.txt
HTML Minutes: 
https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-07-22/quality.2024-07-22-15.00.html

=
# #meeting:fedoraproject.org: Quality
=

Meeting started by @kparal:matrix.org at 2024-07-22 15:00:37

Meeting summary
---
* TOPIC: Roll Call (@kparal:matrix.org, 15:00:55)
* TOPIC: Previous meeting follow-up (@kparal:matrix.org, 15:05:41)
* TOPIC: Fedora 41 status (@kparal:matrix.org, 15:06:47)
* INFO: KDE AArch64 image will be release blocking from F41
(@kparal:matrix.org, 15:09:40)
* LINK: 
https://fedoraproject.org/wiki/Changes/Fedora_KDE_AArch64_ReleaseBlocker
(@kparal:matrix.org, 15:09:45)
* ACTION: kparal to update Desktop test matrix template to mark
KDE as blocking on aarch64 (@kparal:matrix.org, 15:16:43)
* TOPIC: Test Day / community event status (@kparal:matrix.org, 15:20:39)
* INFO: Podman and Kernel test days are upcoming
(@kparal:matrix.org, 15:24:36)
* ACTION: sumantrom to publish F39 and F40 community stats on
commblog (@kparal:matrix.org, 15:28:31)
* TOPIC: Git forge replacement (@kparal:matrix.org, 15:29:20)
* INFO: distigt replacement investigation is ongoing and we should
collect and describe our requirements and submit them to CPE
(@kparal:matrix.org, 15:43:39)
* ACTION: kparal to create a document for describing
distgit-related QA processes and our requirements/feedback for the
replacement (@kparal:matrix.org, 15:45:29)
* INFO: bugzilla replacement process will come later, we don't
need to focus on it atm, unless it's related to the distgit
replacement within our processes (@kparal:matrix.org, 15:46:55)
* ACTION: everyone to collect our distgit-related processes,
stories and requirements, once the document is live (see previous
action item) (@kparal:matrix.org, 15:48:13)
* TOPIC: Open floor (@kparal:matrix.org, 15:49:47)

Meeting ended at 2024-07-22 15:52:32

Action items

* kparal to update Desktop test matrix template to mark KDE as
blocking on aarch64
* sumantrom to publish F39 and F40 community stats on commblog
* kparal to create a document for describing distgit-related QA
processes and our requirements/feedback for the replacement
* everyone to collect our distgit-related processes, stories and
requirements, once the document is live (see previous action item)

People Present (lines said)
---
* @kparal:matrix.org (81)
* @sumantrom:fedora.im (40)
* @humaton:fedora.im (26)
* @amoloney:fedora.im (8)
* @derekenz:fedora.im (2)
* @meetbot:fedora.im (2)

-- 
___
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] TestDays Category TestCase Tags

[Kamil Paral]

On Tue, May 28, 2024 at 7:24 AM Sumantro Mukherjee 
wrote:

> Hello Testers,
>

Hi Sumantro. Just a note, I'd send proposals to the test list only. (And
even after it is decided, I don't think wiki categories are something that
most subscribers are that interested in ;-)).


> Fedora QA has been hosting loads of test days for sometime (ie 15 test
> days/release) which is why we author test cases. These test cases are
> sometimes for features which may never see the light of day (at least
> not in that particular release).
> Sometimes, these test cases are integration test cases and are very
> hard to categorize in package-specific test cases. Many times, due to
> their non-blocking nature, they are not associated with "Release
> Criterion". This makes test cases authored for a particular test day,
> extremely hard to find and check for bitrot.
>
> I propose the following:
>
> a) Add a new category Category:CoreOS Test Cases
>

That exists already:
https://fedoraproject.org/wiki/Category:CoreOS_Test_Cases


> b) Add new Category TestDay:NAME
>

Do you mean e.g. "TestDay:I18N" and "TestDay:Kernel", or do you mean "Test
Day:2024-03-05 I18N Test Day" and "Test Day:2023-11-12 Kernel 6.6 Test
Week", i.e. specific to a particular date?

Please note that we already have this:
https://fedoraproject.org/wiki/Category:Test_Days_Test_Cases

But it's not seeing much use. My idea was that we assign all test
days-specific test cases into it, so that we have one place to find them
all. But we could have subcategories in there.


> c)  We already track the release cycle, Category:Fedora 41 Test Days
>

Yes, that exists already:
https://fedoraproject.org/wiki/Category:Fedora_41_Test_Days

Benefits:
>
> a) In the long run add more filtering functions to testday-stats on
> test cases added
> b) Easier navigation of test cases, written just for a test day and
> updation of the same
> c) Establishing scope for blocking criteria for upcoming features that
> get tested in Rawhide Test Days
>

I guess my choice would be to have "Category:Test day kernel test cases"
[1], and "Category:Test day podman test cases", which follows the naming
convention of "Category:Package kernel test cases" for Bodhi-related test
cases. It also enables us to have generic "Category:Kernel test cases" (or
CoreOS, see above) if we want to have test cases categorized for a certain
package/theme, but not belonging to neither Bodhi nor Test days use case.

These new "Category:Test day XXX test cases" would be subcategories of
"Category:Test_Days_Test_Cases", so that it's easy to find them all.

WDYT?
--
___
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: changes to nouveau driver in kernel 6.8.2 and higher?

[Kamil Paral]

On Wed, Apr 10, 2024 at 5:59 PM AV via test 
wrote:

> I have been trying out fedora 40 beta on a Dell XPS 15 9500 with
> integrated Intel UHD graphics and discrete Nvidia graphics.
> Everything worked perfectly with the 6.8.1 kernel and using nouveau
> but things started to happen after the upgrade to kernel 6.8.2 and
> later 6.8.4 kernel.
> First thing was an extremely slow boot, more than 3 minutes:
>
> systemd-analyze blame
> 3min 18.876s sys-module-fuse.device
> 3min 18.817s dev-ttyS11.device
> etc, etc.
>
> Looking with journalctl -k -b shows a very long list of entries for
> nouveau regularly containing the lines:
>
> kernel: nouveau :01:00.0: disp: one-time init failed, -110
> kernel: nouveau :01:00.0: DRM: [DRM/:drmDevice] [NEW
> dispc570] (ret:-110)
> kernel: WARNING: CPU: 11 PID: 452 at
> drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:112
> r535_gsp_msgq_wait+0x1a9/0x1d0 [nouveau]es:
> 
> kernel: nouveau :01:00.0r -110: gsp: fini failed, -110
> kernel: nouveau: probe of :01:00.0 failed with error -110
>

Which card do you have? Ampere seems to be broken right now in GSP (and I
see "gsp: fini failed" in your log):
https://www.phoronix.com/news/Nouveau-GSP-Fix-Ampere-Support
--
___
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: Bash terminal: intermittently, significant lag up to 20 seconds for characters to be rendered on the screen

[Kamil Paral]

On Sun, Apr 7, 2024 at 12:06 AM John Lynch 
wrote:

> Since upgrading from 39 to 40, when I issue a command in the Terminal,
> sometimes I have to wait for the character to be displayed.   If I press
> another key, then the previous character shows up, but it continues thus.
>  I am running an Asus laptop with 16GB RAM and quad-core CPU.   Has anyone
> else encountered such behaviour with Fedora 40?
>

Works fine here.

Does it happen in Terminal only, or other apps as well? What gpu and driver
are you using? Does the problem go away if you boot with nomodeset?
--
___
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: System JDK update from JDK 17 to JDK 21 ready to be pushed to stable

[Kamil Paral]

On Wed, Mar 6, 2024 at 12:39 PM Petra Mikova  wrote:
> Can you please tell us how to proceed to get this change pushed to
> stable? There was a deadline set for our changes to be pushed today
> (Wednesday), so please let us know if we have to do some additional
> steps to ensure the update makes it to Beta.

Thanks, Petra. All of the updates need at least 2 karma, I believe, so
that they can be pushed stable.

If anyone is able to test these Java-related updates, please do, and
provide karma, thanks!
--
___
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 Branched 20240216.n.0 nightly compose nominated for testing

[Kamil Paral]

On Fri, Feb 16, 2024 at 1:30 PM  wrote:
>
> Announcing the creation of a new nightly release validation test event
> for Fedora 40 Branched 20240216.n.0.

HEADS UP
cockpit-311-1.fc40 landed yesterday, but anaconda-webui-6-1.fc40
landed only today, which means the F40 Workstation image
(Fedora-Workstation-Live-x86_64-40-20240216.n.0.iso) is quite broken
for anaconda webui. No need to spend time on testing it and reporting
bugs (as I just did... sigh).

Of course please test all the other images and bits. It's just the
Workstation installer which is known to be broken in this compose.

Thanks.
--
___
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: Kernel 6.7 Test Week Invitation

[Kamil Paral]

On Mon, Jan 15, 2024 at 2:29 PM Sumantro Mukherjee 
wrote:

> As usual, the Fedora QA team will hangout at #fedora-test-...@libera.chat
> for questions and discussion.
>

Will we? The wiki page says "Matrix: #test-day:fedoraproject.org". At the
same time, it says "You can chat with us on IRC" [1]. My assumption is that
IRC is now completely dropped and we're on Matrix only. At least I am.

[1] It looks like the updated description from our template page was not
used: https://fedoraproject.org/wiki/QA/Test_Days/Template
--
___
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 Digest, Vol 238, Issue 1

[Kamil Paral]

On Wed, Dec 13, 2023 at 12:00 AM Rick Marshall  wrote:

> Hi All
>
> Since the F39 update pppd is broken (perhaps not in all cases but the
> config needs to be changed and it's not obvious).
>

Please file a bug in RH Bugzilla and post the link here, thanks.
--
___
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] 2023-12-11 @ 16:00 UTC - Fedora QA Meeting

[Kamil Paral]

On Tue, Dec 12, 2023 at 7:26 PM Kevin Fenzi  wrote:

> I suppose also you could make a new account and try with it to confirm
> you get the agreement and things work with it?
>

Also make sure to disable any extensions like adblockers etc, which might
interfere with it.
--
___
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] 2023-12-11 @ 16:00 UTC - Fedora QA Meeting

[Kamil Paral]

On Sun, Dec 10, 2023 at 10:03 PM pmkellly  wrote:

> What is the recommended client?
>
>
I can recommend the browser-based Element [1], it works well. And I think
it's also the client recommended by default.

[1] https://app.element.io
--
___
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: removed installer help release criterion and archived test case

[Kamil Paral]

On Wed, Nov 29, 2023 at 9:19 PM Adam Williamson 
wrote:

> Hey folks! I just wanted to give a heads up - I've removed the
> installer help criterion from the Final release criteria:
>
>
> https://fedoraproject.org/w/index.php?title=Fedora_40_Final_Release_Criteria&diff=695349&oldid=695347
>
> why? well, the installer removed help:
>
> https://github.com/rhinstaller/anaconda/pull/5335
>
> so, the criterion becomes useless. I decided to just go ahead and do
> this rather than proposing it, as it seems like a pretty clear-cut
> situation, but I did want to explain why it had happened.
>
> I will also mark the test case as obsolete, since...it is.
>

In that case I also removed it from the installation matrix:
https://fedoraproject.org/w/index.php?title=Template%3AInstallation_test_matrix&type=revision&diff=695372&oldid=689565
--
___
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] 2023-11-27 @ ** 16:00 ** UTC - Fedora QA Meeting

[Kamil Paral]

On Sat, Nov 25, 2023 at 3:11 AM Adam Williamson 
wrote:

> Greetings testers! It's time for another QA meeting.
>

Sorry, can't attend today.


> == Proposed Agenda Topics ==
>
> 1. Previous meeting follow-up
> 2. Fedora 40 check-in and Change review
> 3. Communications overhaul: Discourse and Matrix?
>

Yes to both.


> 4. Test Day / community event status
> 5. Open floor
>
--
___
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: Self-Presentation Niccolo' to QA Team

[Kamil Paral]

On Mon, Oct 23, 2023 at 7:25 PM Niccolò Zuccolo  wrote:

> Hello Fedora QA Team Members,
>
> My name is Niccolo' and it is my pleasure to introduce myself as a new
> member interested in contributing to your Quality Assurance team. Fedora is
> a community and project that I have long admired, and I am eager to put my
> skills and passion at your service.
>
> In the past, I have worked in the supercomputing field as an IT supporter
> and have had several experiences with linux and server/clients operating
> systems.
>
> I have always enjoyed the operating system and the Fedora Philosophy.
> Although I do not have much direct experience in the field of Quality
> Assurance, I am eager to learn and apply my skills.
>
> Kind regards,
> Niccolo' Zuccolo
>

Welcome, Niccolò! Thanks for joining us.

At this moment, we're working hard on releasing Fedora 39, so please
subscribe to the test-announce list, and help us run test cases on latest
composes (announced there), to find any issues that might still be present.

Thanks!
___
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: F39-beta Live OS: Mouse stops working after changing Display Orientation in Settings.

[Kamil Paral]

On Mon, Oct 23, 2023 at 5:31 AM Rob Lahaye  wrote:

> Hi,
>
> I start the Live OS of F39
> (Fedora-Workstation-Live-x86_64-39_Beta-1.1.iso) on a system that requires
> a display orientation of "Portrait Right".
> As soon as I change the display orientation, the mouse stops working.
>

It works fine for me on my fully updated F39. Can you try again with the
latest nightly image?
https://download.fedoraproject.org/pub/fedora/linux/development/39/Workstation/x86_64/iso/
___
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: Failed to start udisks2.service

[Kamil Paral]

On Thu, Oct 19, 2023 at 6:55 PM camiro pan  wrote:

> Hello everybody,
>
> i run fedora 38 on my dell xps 9300 and want to install Fedora 39
> beta/nightly.
> When i boot from a Fedora 39 (nightly) boot device i get the error
> message:
> "[Failed] Failed to start udisks2.service - Disk Manager".
>

Hi Camiro, which exact image did you use? You can find the latest nightly
here:
https://download.fedoraproject.org/pub/fedora/linux/development/39/Workstation/x86_64/iso/

When booting the Live image, make sure to select "Test this media". Does
the test pass OK?

Does the installer fail to start every time? It would be great if you could
open ABRT and make it generate the backtrace for the crash. If you can even
report it to Bugzilla, even better, or at least post the full backtrace
here.
___
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: [Fedora Rawhide][x86 MacBook] Can’t boot after dnf system-upgrade 39 to Rawhide

[Kamil Paral]

On Wed, Oct 18, 2023 at 7:37 PM Osama Albahrani via test <
test@lists.fedoraproject.org> wrote:

> Hi!
>
> I wanted to test Fedora Rawhide so I ran `dnf system-upgrade download
> --releasever rawhide --exclude=sdubby` (as per
> https://bugzilla.redhat.com/show_bug.cgi?id=2243872#c12) to upgrade from
> Fedora 39 and it finished successfully. However after I ran `dnf
> system-upgrade reboot` and got a black screen after the system upgrade
> progress bar. And I can no longer boot into the Fedora partition and only
> get a black screen. Before that, I was able to use Fedora 39 alongside
> macOS just fine.
>
> Has anyone been able to run Rawhide on an x86 MacBook Pro (2016) or a
> similar x86 Mac* device? And what can I do to further investigate the boot
> issue?
>

Can you display the GRUB menu (listing all the installed kernels), when you
repeatedly press F8 after starting the laptop? (A question is whether Mac
keyboard actually sends F8 by default, perhaps connect an external one). If
you can see GRUB, try older kernels. On the latest kernel, you can edit the
command line and remove "rhgb quit" to see some boot debug messages.


>
> Note: I noticed that after the upgrade, the name in the mac boot menu
> changed from “Fedora” to “UEFI Boot” and the symbol is still the Fedora
> logo, not sure what this means. So could it be the efibootmgr-related bug
> that was recently fixed in the Fedora 39 nightly ISO (
> https://bugzilla.redhat.com/show_bug.cgi?id=2239316)?
>
> Note 2: I also couldn't go past the initial menu when I used the Fedora
> Rawhide ISO a few days ago (around Oct 10 iirc), not sure if this is
> related.
>

If you decide to reinstall F39 on that laptop, I'd recommend just
continuing testing with Rawhide ISOs, so that you don't break your system
again needlessly. The ISO needs to boot, that's a prerequisite. If it
doesn't, please file a bug and link it here, we'll make it a blocker bug
for Fedora 40.

Thanks for testing.
___
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: anyone available to test x86_64 macOS dual boot?

[Kamil Paral]

On Tue, Oct 17, 2023 at 1:23 PM Osama Albahrani via test <
test@lists.fedoraproject.org> wrote:

> Hi Kamil,
>
> I have an intel-based MacBook Pro (2017). I tried the iso the other day
> and submitted the following bugzilla for it:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2243144
>

I see that the problem is already resolved and the fix verified. Thanks a
lot for testing, Osama!
___
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

anyone available to test x86_64 macOS dual boot?

[Kamil Paral]

It would be great if somebody could test Fedora 39 dual boot on a macOS
device, because our internal team currently doesn't have hardware to do so.
It needs to be an older x86_64 Mac (Macbook, Mac Mini, etc), the newer
M-based Macs are not yet supported by Fedora.

Is here anyone who has access to such a device and willing to test it?

The testcase is here:
https://fedoraproject.org/wiki/QA:Testcase_dualboot_with_macOS

The install media (preferably Workstation or KDE Live) can be downloaded
from here:
https://fedoraproject.org/wiki/Test_Results:Fedora_39_Branched_20231014.n.0_Installation#How_to_test

And the test result can be reported here (next to
"QA:Testcase_dualboot_with_macOS"):
https://fedoraproject.org/wiki/Test_Results:Fedora_39_Branched_20231014.n.0_Installation#Miscellaneous
(or here to the list, of course)

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

Fwd: [Test-Announce] Please help complete validation testing for current Fedora 39 candidate nightly!

[Kamil Paral]

-- Forwarded message -
From: Adam Williamson 
Date: Wed, Oct 11, 2023 at 1:50 AM
Subject: [Test-Announce] Please help complete validation testing for
current Fedora 39 candidate nightly!
To: 


Hey folks! You probably saw the mail "Fedora 39 Branched 20231010.n.0
nightly compose nominated for testing" today. Although we still don't
have an RC for the Fedora 39 Final release, I want to ask folks to
please help us fill out the matrices for this candidate as much as
possible. It's best if we find any remaining blocker bugs *now*, not
wait for an RC before doing the full testing.

You can use testcase_stats to see what test cases probably need running
- https://openqa.fedoraproject.org/testcase_stats/39/ . The pages there
shows the execution history and last run date for each test on the
corresponding matrix page, so you can see at a glance which tests
haven't been run recently or at all. Please focus on tests marked
Basic, Beta or Final that have not yet been run, or not been run for
some time. And of course, if you find a significant bug, mark the test
as a failure, file a bug, and nominate it as a release blocker.

Thanks a lot folks!
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-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-annou...@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
___
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: The desktop of Fedora Robotics top left corner no display “Activity”， is a white cube

[Kamil Paral]

> When install Fedora Robotics in virtualbox 7.0.10， after start Fedora 
> Robotics， top left corner is a white cube， then install into disk，chinese 
> version， reboot again，top left corner is a white cube as before。

Yes, GNOME changed it. It no longer says Activities, it shows
workspaces. The active one is a white bar, the inactive ones are grey
dots. You can see it e.g. in this video:
https://www.youtube.com/watch?v=47aZgF6xmS0

I also thought it was a bug, initially :-)
___
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: Fedora-Workstation-Live-x86_64-39_Beta-1.1.iso wont boot in VMWare Player

[Kamil Paral]

Does it work for you if you boot it using libvirt (e.g. virt-manager /
gnome-boxes / cockpit)?
___
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: Text is blurry in apps like edge, spotify etc. But not blur in system apps , firefox.

[Kamil Paral]

You shouldn't run this with sudo, just as a regular user. What do you get
if you run
$ gsettings get org.gnome.mutter experimental-features
?

Here's how it should work:
$ gsettings get org.gnome.mutter experimental-features
['scale-monitor-framebuffer']
$ gsettings set org.gnome.mutter experimental-features "[]"
$ gsettings get org.gnome.mutter experimental-features
@as []
$ gsettings reset org.gnome.mutter experimental-features
$ gsettings get org.gnome.mutter experimental-features
['scale-monitor-framebuffer']

So far, I've only tested in a VM, but the fractional scaling factors
disappear from gnome-control-center once I disable
"scale-monitor-framebuffer". But I'd think relogin is required for app
scaling to actually change.
___
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: Text is blurry in apps like edge, spotify etc. But not blur in system apps , firefox.

[Kamil Paral]

On Wed, Sep 20, 2023 at 1:30 PM Neil Chetty 
wrote:

> I recelty upgraded from F38 to F39. In F38 i was using default settings
> for display which is 2880x1800(16:10), 90hz,200% scaling. AFter upgrading
> to F39 when scaling is set to 200 percent texts are blurry in apps except
> system apps and firefox.


This is caused by fractional scaling, which kicks in even for integer
multiples now:
https://pagure.io/fedora-workstation/issue/357

The workaround is to disable fractional scaling. There should be a toggle
in GNOME Settings, but it's not there yet at this moment. You can see how
to disable it manually at the end of this article:
https://www.omglinux.com/how-to-enable-fractional-scaling-fedora/

We probably need to create a Common Issue description for this.
___
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: freeze exceptions for FTI bugs

[Kamil Paral]

On Tue, Sep 5, 2023 at 5:22 PM Adam Williamson 
wrote:

> updates-testing is not enabled by default for the upgrade.
>
> The upgrade process uses whatever repos are enabled *in the current
> configuration*. So in the "typical" case, you are upgrading from a
> stable Fedora release with default repo configuration, in which
> updates-testing is not enabled. Thus updates-testing is not used for
> the upgrade.
>

This didn't occur to me, you're right. We could update our instructions to
tell people to use "--enablerepo=updates-testing" when upgrading to a
development release, or at least add it if they see broken dependencies and
the upgrade fails to start, but only limited people would find those
instructions. It's definitely better in general to fix those packages in
the main repo.


> I'd like to propose an alternative change: we should make clean FTI
> cases "automatic freeze exceptions". By "clean" I mean cases where the
> package was, practically speaking, useless before the fix. Cases where
> it's just one subpackage of a larger package that was FTI should still
> be manually checked, especially if the changes are larger than just a
> straight targeted fix to that subpackage (e.g. a version bump).
>

That sounds reasonable. But would we trust packagers to include this
important information ("this is not a simple case...") in their FE
proposal, or would we still manually check case-by-case?
___
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: freeze exceptions for FTI bugs

[Kamil Paral]

On Tue, Sep 5, 2023 at 2:05 PM Frantisek Zatloukal 
wrote:

> The added work for a FE seems pretty minimal to me (3 people write +1, I
> push it to the accepted FE in about a minute), not sure if the releng
> perspective is different here though?
>

I see it a bit differently. Even when just considering myself, it amounts
to frequent email distractions and non-trivial time spent on it (when
summed up). I usually don't just blindly type "BetaFE +1", but try to open
the Bugzilla ticket (that's slow) and at least skim through it, whether it
is really what it claims to be, whether it is FTBFS or also FTI (sometimes
I check myself in a VM or in a container), whether it is a non-important
package or could possibly impact the release somehow. This total time is
multiplied by people involved in the FE process (not just three), although
I understand not everyone spends that much time with it. Then there's
someone managing the agreement, it can be included in the blocker meeting
(if we don't do it async in time), it lowers the readability of the
blockerbugs app page because FTI bugs are high in their number, and of
course somebody needs to double-check everything when creating a releng
request.

It's not terrible, not at all, but especially this cycle I'm starting to
think that we need some adjustments (thus this email).


> I don't feel like further complicating our processes and guidelines.
>

Well the process is not presently super simple either. FE SOP [1] says:
"FTI bugs may still be rejected in complex cases - e.g. if only one
subpackage of an important package fails to install, and the fix might
potentially cause problems for more important workflows using other
subpackages"

This requires at least opening that Bugzilla ticket and reading through it,
to figure out whether this is the case or not. If we swapped the approach -
reject FTI FEs at Beta, unless they provide a direct justification during
proposal - it might actually simplify things - for our team, at least. And
the volume of proposed FTIs would go down. Not sure whether it's an
improvement for Fedora in general, though. I'm not looking at simplifying
my work at the expense of others, I'm looking for ways to optimize the
process.

[1] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

Yeah, Instead of starting to reject the Beta FTI FEs, I'd say we probably
> should just automatically approve all of them? Adding something like this
> to the blockerbugs sounds very easy and straightforward, and would save us
> some time in the final cycle:
> *Does bug depend on the FE tracker? Is the reporter "Fedora Fails To
> Install"? Does it have an update marked as fixing the bug? Fine, approved,
> next.*
>

I wouldn't need automation, at least in the first iteration. "Image
oversized" is not automated either, but we know we can just tag it
"accepted" and go on. A similar approach would be fine. But, as cited above
from the FE SOP, this might actually bring us some troubles. So I'm not
sure whether we can do this generally, without manual inspection.
___
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

freeze exceptions for FTI bugs

[Kamil Paral]

Lately we've seen a surge of FTI (fails to install) bugs being proposed as
freeze exceptions [1] [2]. We generally grant them, because we want the
base repo to be in a consistent and buildable state. However, I wonder,
isn't this approach mostly relevant for the Final release? Does it make
sense to also have this approach for Beta?

The reason why I'm thinking about this is because of course there's some
work connected with granting and processing these freeze exceptions (FEs).
But at the same time, updates-testing is enabled by default, so users can
get the fixed versions immediately, and the fixes can be pushed stable
right after the Beta freeze is over. Is the extra FE-related work justified?

One reason I can think of is when the package A in question needs to be
used for rebuilding/installing another package B. In that case, if package
A is not pushed stable, you can't prepare an update for package B into
updates-testing (or can you? Can you build several inter-connected packages
together and make a Bodhi update for them? What if you have access rights
to just package B but not A?). I do understand that in this case waiting
until the freeze lifts might be inconvenient.
What if we granted FEs for Beta just in these justified cases but not in
general, in order to decrease the processing-work? Is that a good/bad idea?

Or perhaps we can grant FTI FEs automatically? Either always, or in some
cases?

What are your thoughts on this?

Thanks,
Kamil


[1] https://qa.fedoraproject.org/blockerbugs/milestone/39/beta/buglist
[2]
https://pagure.io/fedora-qa/blocker-review/issues?status=all&search_pattern=F39FailsToInstall&close_status=
___
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: Add toolbx to Basic release matrix and tag toolbx test case

[Kamil Paral]

On Tue, Aug 29, 2023 at 6:37 AM Sumantro Mukherjee 
wrote:

> [2]
> https://fedoraproject.org/w/index.php?title=Template:Base_test_matrix&oldid=687376
> [3]
> https://fedoraproject.org/w/index.php?title=Template:Base_test_matrix&oldid=687377


I tweaked the ordering a bit to make sure Basic test cases are before Final
;-)
___
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: 2023-08-21 @ 15:00 UTC - Fedora QA Meeting

[Kamil Paral]

On Sun, Aug 20, 2023 at 8:09 AM Adam Williamson
 wrote:
>
> # Fedora Quality Assurance Meeting
> # Date: 2023-08-21
> # Time: 15:00 UTC
> (https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
> # Location: #fedora-meeting on irc.libera.chat
>
> Greetings testers! Once again it's been a bit of time since we last
> met, sorry for that. Let's meet up on Monday!

Sorry, I won't be around this time.
___
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: Join now GNOME 45 Test Week

[Kamil Paral]

On Mon, Aug 14, 2023 at 5:39 AM Sumantro Mukherjee 
wrote:

> Hello,
>
> As most of you might know, with each new release of Fedora, we get a
> new GNOME and that means this is the time to test GNOME 45's new
> features. GNOME 45 test week begins today. During the course of next
> week, we will have 14-17 reserved for testing the Desktop and the Core
> Apps [0] and the rest for testing GNOME Apps that need extensive
> testing[1]
>
> As always, you can submit results for respective test days in [2] and
> [3]. The development folks and QE folks come from different time zones
> and will be available on Martix/element chatrooms as much as possible.
>
> [0]
> http://fedoraproject.org/wiki/Test_Day:2023-08-14_Fedora_39_GNOME_45_Desktop_and_Core_Apps
> [1]
> http://fedoraproject.org/wiki/Test_Day:2023-08-18_Fedora_39_GNOME_45_Apps
> [2]https://testdays.fedoraproject.org/events/1642


This is supposed to be: https://testdays.fedoraproject.org/events/162


>
> [3]https://testdays.fedoraproject.org/events/164
> --
> //sumantro
> Fedora QE
> TRIED AND PERSONALLY TESTED, ERGO TRUSTED
> ___
> desktop mailing list -- desk...@lists.fedoraproject.org
> To unsubscribe send an email to desktop-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/desk...@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
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 to remove Modularity tests from openQA

[Kamil Paral]

On Mon, Jul 17, 2023 at 10:20 AM Lukas Ruzicka  wrote:

> Hello,
>
> based on this (
> https://pagure.io/fedora-comps/c/38890fd54281a3dc2dd64439de8955637ca6f2a7?branch=main),
> I am proposing to put the Modularity tests on hold for some time (modular
> features are currently not supported in DNF5 anyway) and potentially remove
> them from openQA.
>

That certainly makes sense. I assume you mean from F39 forward, right? Or
would it apply to current stable releases as well?
___
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

[Kamil Paral]

On Mon, Jun 26, 2023 at 10:21 AM Sumantro Mukherjee 
wrote:

> Thanks a lot Kamil and Adamw!!
> Can I go and publish this under the Beta criteria? :)
> @Kamil Paral   it will be awesome, if you can point me
> to the correct criteria template , please?
>

Thumbs up from me. Here's the criterion page [1]. It will probably fit
under "Post-install requirements". Please make sure to add a References
footnote with a hyperlink to this email thread. When saving the wiki page,
provide a reasonable summary so that the page history is easy to read.
Please link to the page diff here afterwards.

The next action would be to figure out how to test the nightly/RC toolbox
image (it will require uploading to some testing branch/tag [2]), write a
test case, add it to one of the release validation matrices, and link it
from the release criterion ;-)

Thanks,
Kamil

[1] https://fedoraproject.org/wiki/Fedora_39_Beta_Release_Criteria
[2] https://pagure.io/fesco/issue/3002#comment-862116
___
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: Rawhide update gating on openQA tests will be enabled Wednesday

[Kamil Paral]

On Thu, Jun 22, 2023 at 12:27 PM Adam Williamson 
wrote:

> On Mon, 2023-06-19 at 18:28 +0200, Adam Williamson wrote:
> > Hey folks! So, as per https://pagure.io/fesco/issue/3011 , we plan to
> > enable gating of Rawhide updates on openQA test results on Wednesday.
>
> This is now enabled! Please let me and/or releng know if it causes any
> terrible consequences, and in the worst case, we'll turn it off again.
>

🎉🎉🎉

Thanks a lot for your work on this, Adam.
___
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

[Kamil Paral]

On Tue, Jun 20, 2023 at 12:07 PM Adam Williamson 
wrote:

> ~
> For any release-blocking deliverable whose default deployment includes
> Toolbx, the {{command|toolbox}} CLI must be able to list existing
> containers.


One nitpick, it's not clear whether "list" means listing local containers
or remote containers (all in the registry). So perhaps say "list existing
local containers", or something similar?
___
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: DNF5 testing ~ Unknown argument "--skip-broken"

[Kamil Paral]

On Thu, Jun 15, 2023 at 12:10 AM Ian Laurie via test <
test@lists.fedoraproject.org> wrote:

> On 6/15/23 00:15, Sérgio Basto wrote:
> >> Is this option being added or is this a bug?
> >>
> >
> > seems related with https://bugzilla.redhat.com/show_bug.cgi?id=1501804


No, that bug is only related to dnf4 and the distrosync command.


>
> >
> > --skip-broken is not helpful anymore
>
> Ok thanks. It's an error in the man page then.
>

Please file a bug. It's either a man page issue or a dnf5 issue, both
options are possible.
___
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

[Kamil Paral]

On Thu, Jun 8, 2023 at 7:07 AM Sumantro Mukherjee 
wrote:

> FESCo has approved[0] this changeset and now the criterion needs to be in
> place. I will gather all the knowledge and the corrections that have been
> talked about in this thread and start a fresh one for voting?
>
> [0] https://pagure.io/fesco/issue/3002
>

Either continue this one or start a fresh one, as you wish. If you start a
fresh one, please include a link to this conversation as a reference.
Thanks.
___
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: DNF5 is in f38 updates-testing ?????

[Kamil Paral]

On Wed, May 31, 2023 at 10:32 AM Ian Laurie  wrote:

> I was under the impression DNF5 was being held of until F39?
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2023-b3c645d401


"dnf5" is a separate package from "dnf" (version 4 in F38). It's already in
stable repos, and you can install it and experiment with it, if you wish.
"dnf" is going to stay at version 4 in F38, don't worry.
___
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

[Kamil Paral]

On Fri, May 5, 2023 at 6:39 AM Sumantro Mukherjee 
wrote:

> Adam & Kamil, since my criteria starts with"for each release-blocking
> artifact", do you folks think its a good idea to site the criterion? or at
> least have it? I am not able to find it as well.
>

You mean "cite", right? :-) Cite which one? Sorry I don't understand. Are
you talking about the following sentence?
> Honestly, I thought we have some criterion saying "all release-blocking
artifacts must exist" or something along those lines, but I haven't found
it :-)

Let's wait for Adam to reply. (Ping him if he doesn't, thanks).
___
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

[Kamil Paral]

On Tue, May 2, 2023 at 4:48 AM Sumantro Mukherjee 
wrote:

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

toolbx -> Toolbx
to denote you're talking about the project/software

and we can also do
toolbox CLI -> toolbox CLI
to distinguish the command name


> OCI images should get updates in every stage of the release cycle
> (Branched, Beta and Final).
>

"get updates" is probably a bit confusing. You want to say that the Toolbx
OCI image must be composed from the same software versions as other compose
artifacts, right? This is actually a bit tricky, because sometimes some
artifacts might have slightly different versions (IoT, respinning some
Spins when they fail to compose, a hotfix in just one Spin, etc, it has
happened before). Perhaps we can neglect that. But I wonder if this
sentence is actually needed. Once Toolbox OCI is release-blocking, it will
have to be built with every compose, just as Kevin said. So this will have
to be true each time. And we have the same assumption basically for each
release-blocking artifact.


>
> Footnote - "What does this cover?":
> This criterion aims at blocking Toolbx OCI image and Toolbx rpms.


I think this is already covered in the criterion above.


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

This sentence doesn't fit into the release criteria. Just leave it out.


> The images must be present in registry.fedoraproject.org


This is fine. It adds extra detail to the main requirement specified above
(it could be merged there or kept inside the footnote).


> and must keep
> being updated like for branchpoints, beta and final. Missing images or
> broken images, will be blocking the release.
>

I think this is just assumed, as described above, for each release-blocking
artifact. Honestly, I thought we have some criterion saying "all
release-blocking artifacts must exist" or something along those lines, but
I haven't found it :-)

Adam, am I looking wrong?


> Changes in Toolbx stack will warrant for a test day in that particular
> release cycle and regular validation to ensure there are no
> regressions.
>

This sentence doesn't fit into the release criteria. Just leave it out.
___
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

[Kamil Paral]

On Tue, May 2, 2023 at 4:48 AM Sumantro Mukherjee 
wrote:

> Debarshi and I decided to re-write the whole thing as a changeset[0].
>

Great, I think this is the best approach.


> The revised criterion I have now stands as:
>

Does it make sense to wait for the FESCo approval before we finalize the
exact criterion wording? I don't want to spend too much time on it in
advance, when we're not sure about the outcome :-)
___
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: [Testdays] Call for Fedora Linux 39 testing events

[Kamil Paral]

On Mon, May 1, 2023 at 8:10 AM Sumantro Mukherjee 
wrote:

> Hi Fedora users, developers, and friends!
>
> It's time to start thinking about Test Days for Fedora 39.
>

Neal Gompa asked for a popular third-party apps test day recently:
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/NKE52N6DRJ5GNBMKC52UDTQ3KAQKC3AG/

I assume no-one will really want to prepare/maintain this test day, so it
would probably fall to us, if we want it to happen.
___
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

[Kamil Paral]

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.

Note that we had proprietary software-related blockers in the past. We
accepted the EAC glibc issue as a blocker in one of the recent releases. We
also accepted the RPM signatures change as a blocker for F38. But in these
cases, it was always accepted as an exceptional blocker confirmed by FESCo.
I guess it makes sense to use this exceptional process for these cases
(blocking on issues with third-party software, which can affect our user
base badly). We could talk about some general rule related to popular
third-party software, but that would again need to go through FESCo. At the
moment, we only block on our own code in our own workflows, with a few very
specific exceptions (boot usb creation, dual boot configuration, cloud
images deployment).
___
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

[Kamil Paral]

>
> ~
> For any release-blocking deliverable whose default deployment includes
> toolbox, it must be
> possible to list existing containers, enter them, and create a new one.
>
>
> Footnote - "What does this cover?":
> Toolbox CLI should offer commands to be executed by the user which
> includes listing existing container images created by the toolbox,
> creating container images with the latest Fedora and RHEL and entering
> these containers.
> This criterion aims at blocking only the toolbox rpm functionality and not
> the OCI image which is supposed to be downloaded by user's choice.
> https://fedoraproject.org/wiki/QA:Testcase_toolbox
> ~~~
>

The criterion and the footnote seem a bit duplicated, perhaps we can
shorten it. I'd also specify that entering is related just to those
containers which we're blocking on creating. What about this?


For any release-blocking deliverable whose default deployment includes
toolbox, the toolbox CLI must be able to list existing containers, create a
new container with the latest Fedora and RHEL image, and enter it.

Footnote - "What does this cover?":
This criterion aims at blocking only on the toolbox CLI functionality. It
does not require that the specified image is present in the registry or
functional.


It would be also good to have a Workstation WG member (since this is driven
by them) comment here that this is indeed what they want.
___
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

[Kamil Paral]

On Wed, Apr 12, 2023 at 5:57 AM Sumantro Mukherjee 
wrote:

> There is a push from the
> Dekstop team to have toolbox as a default app in the installer iso as
> well.


The 'toolbox' package is already installed by default. Or do you mean some
related GUI app?


> 
> Toolbox aka Toolbx should be usable. Toolbox should be able to list,
> create and provide the desired containerized environment to the user
> without root privileges. Toolbox images should be generally
> functional.
>
> Footnote - "What does this cover?":
> Toolbox's general functionality as covered by this test cases
> https://fedoraproject.org/wiki/QA:Testcase_toolbox
> ~
>

Already covered by Ben and Adam, so just a few additional notes:
* We can't block on toolbox *images*, unless they are marked as
release-blocking artifacts. If the Desktop team wants that, Ben will know
the right process to take.
* We can block on the toolbox cli command. We can say that it must list
existing containers, enter them, create a new one, etc. But since the
toolbox images are not release-blocking at the moment, they might be
broken, and then we won't be able to verify toolbox cli functionality
(that's probably not a showstopper to creating this criterion). It would
certainly make more sense to have both parts blocking, though :-)
* The criterion can't refer to the testcase for definitions. The criterion
must contain definitions, and the testcase is then written to test them,
that's the correct relation.
___
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: rc.local fails

[Kamil Paral]

On Fri, Apr 14, 2023 at 1:54 AM George R Goffe via test <
test@lists.fedoraproject.org> wrote:

> Howdy,
>
> To get rc.local running you used to be able to put the file in /etc/rc.d
> and then reboot.
>
> This has worked for quite some time but does not any more. This situation
> has been happening now for several months. Am I missing something?
>

See the output of "systemctl status rc-local.service", you'll see whether
the service is enabled and a possible error if there was some.
___
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: Copy as HTML in Gnome Terminal (f38beta)

[Kamil Paral]

On Sun, Apr 9, 2023 at 8:11 AM Robin A. Meade 
wrote:

> I'm having trouble with the *Copy as HTML* menu item in GnomeTerminal in
> Fedora 38 beta.
>
> When I paste the result into a Google doc, the result is HTML code.
>
> When I paste the result into a Libre Office Writer doc, the result is an
> error dialog saying "Requested clipboard format is not available."
>
> A workaround I found is to execute the following after selecting the *Copy
> as HTML* menu item:
>
> xclip -sel c -t 'text/plain' -o | xclip -sel c -t 'text/html'
>
> Anybody else have this problem? I'm wondering if it is a problem with my
> particular installation.
>

I can confirm this. When I play with `wl-paste -l` and `wl-paste -t
mimetype`, it seems that gnome-terminal offers 'text/html' mimetype, but
it's empty. The html tags are actually present in the 'text/plain' content.
When I copy something into the clipboard in Firefox, it correctly populates
both 'text/html' and 'text/plain' with appropriate content. So I think the
problem is in gnome-terminal. Can you please report a problem here?
https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues
___
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

[Kamil Paral]

On Tue, Apr 4, 2023 at 6:05 PM Adam Williamson 
wrote:

> On Tue, 2023-04-04 at 15:21 +0200, Kamil Paral wrote:
> > On Mon, Apr 3, 2023 at 5:34 PM Kamil Paral  wrote:
> >
> > > At today's QA meeting, nobody had any further objections. If there's no
> > > additional feedback, I'll push it live tomorrow.
> > >
> >
> > This is now live:
> >
> https://fedoraproject.org/w/index.php?title=Basic_Release_Criteria&type=revision&diff=673055&oldid=650015
> >
> https://fedoraproject.org/w/index.php?title=Fedora_38_Final_Release_Criteria&type=revision&diff=673056&oldid=668039
>
> Thanks!
>
> Do you plan to write a test case?
>

Never propose a criterion, kids, you'll get even more work :-)

There:
https://fedoraproject.org/wiki/QA:Testcase_window_manager
https://fedoraproject.org/w/index.php?title=Template%3ADesktop_test_matrix&type=revision&diff=673086&oldid=636274
___
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

[Kamil Paral]

On Mon, Apr 3, 2023 at 5:34 PM Kamil Paral  wrote:

> At today's QA meeting, nobody had any further objections. If there's no
> additional feedback, I'll push it live tomorrow.
>

This is now live:
https://fedoraproject.org/w/index.php?title=Basic_Release_Criteria&type=revision&diff=673055&oldid=650015
https://fedoraproject.org/w/index.php?title=Fedora_38_Final_Release_Criteria&type=revision&diff=673056&oldid=668039

Thanks everyone for your feedback.
___
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

[Kamil Paral]

On Wed, Mar 22, 2023 at 8:57 AM Kamil Paral  wrote:

> Here's a second draft. I took feedback here and also from the QA meeting
> [1]. The split between the milestones makes this harder to read and
> compare. If you have better ideas on how to do it, please tell me :-)
>
> 
> == Basic milestone ==
> For each release-blocking desktop, the desktop environment must perform
> regular operations like windows close/resize/maximize/minimize/fullscreen
> (when supported/applicable), windows switching, and similar common
> operations as expected. Common application content such as regular
> application windows, video output, and games must be displayed correctly.
> In this milestone, only pre-installed applications are considered.
>
> Footnote - "What does this cover?":
> The goal of this criterion is to ensure general desktop-related
> functionality for different types of applications. A small number of
> non-working applications (caused by applications themselves or the desktop
> environment) is not a violation of this criterion.
>
> == Final milestone ==
> For each release-blocking desktop, the desktop environment must perform
> regular operations like windows close/resize/maximize/minimize/fullscreen
> (when supported/applicable), windows switching, using windows on virtual
> workspaces, and similar common operations as expected. Common application
> content such as regular application windows, video output, and games must
> be displayed correctly.
>
> Footnote - "What does this cover?":
> The goal of this criterion is to ensure general desktop-related
> functionality for different types of applications. A small number of
> non-working applications (caused by applications themselves or the desktop
> environment) is not a violation of this criterion. 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.
>
> Footnote - "Difference from the Basic criterion?":
> Compared to the similar [Basic criterion](link), this covers all
> applications (including third-party ones), not just pre-installed ones.
> More window operations are required to work, e.g. the explicitly-stated
> virtual workspaces workflows.
> 
>
> [1]
> https://meetbot.fedoraproject.org/fedora-meeting/2023-03-20/fedora-qa.2023-03-20-15.00.log.html
>
>
At today's QA meeting, nobody had any further objections. If there's no
additional feedback, I'll push it live tomorrow.
___
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: Feedback F38 Beta

[Kamil Paral]

On Sun, Apr 2, 2023 at 1:50 AM old sixpack13  wrote:

> dnf remove kernel-core
>
> doesn't remove the directory for that kernel under /lib/modules/
>

Please report a bug against kernel here:
https://bugzilla.redhat.com/

The kernel maintainers are not watching this list. Thanks.
___
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: crypto-policies

[Kamil Paral]

On Sat, Mar 25, 2023 at 8:20 AM Neal H. Walfield  wrote:

> Panu wrote https://bugzilla.redhat.com/show_bug.cgi?id=2170878#c126 :
>
> > To me the key points here are
> > 1) there's a lot of obsolete/broken crypto out there
> > 2) we need better error messages
> >
> > Properly dealing with 2) needs an API redesign, but we'll try to work
> out some sort of bandaid solution.
>
> Are better diagnostics sufficient from your point of view, or are you
> looking for a different solution?
>

I think my question in
https://bugzilla.redhat.com/show_bug.cgi?id=2170878#c125 wasn't really
answered, or at least I don't understand the implications.
___
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: 2023-03-27 @ **16:00** UTC - Fedora 38 Blocker Review Meeting

[Kamil Paral]

On Sun, Mar 26, 2023 at 6:23 PM Adam Williamson 
wrote:

> # F37 Blocker Review meeting
> # Date: 2023-03-27
> # Time: **16:00** UTC
> # Location: #fedora-blocker-review on irc.libera.chat
>

I added this to Fedocal and it shows up at https://qa.fedoraproject.org/
now :-)
___
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

[Kamil Paral]

On Wed, Mar 22, 2023 at 1:17 PM pmkel...@frontier.com 
wrote:

>
>
> On 3/22/23 03:57, Kamil Paral wrote:
> > Here's a second draft. I took feedback here and also from the QA meeting
> > [1]. The split between the milestones makes this harder to read and
> > compare. If you have better ideas on how to do it, please tell me :-)
> >
>
> The only suggestion I have is for the foot notes under Final. Combine
> the second note into the first.


I could do that, but it's helpful to see the information that there's a
Basic criterion as well, right in the footnote title, without expanding it.
But approaches work, though. Thanks for your suggestion.
___
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

[Kamil Paral]

Here's a second draft. I took feedback here and also from the QA meeting
[1]. The split between the milestones makes this harder to read and
compare. If you have better ideas on how to do it, please tell me :-)


== Basic milestone ==
For each release-blocking desktop, the desktop environment must perform
regular operations like windows close/resize/maximize/minimize/fullscreen
(when supported/applicable), windows switching, and similar common
operations as expected. Common application content such as regular
application windows, video output, and games must be displayed correctly.
In this milestone, only pre-installed applications are considered.

Footnote - "What does this cover?":
The goal of this criterion is to ensure general desktop-related
functionality for different types of applications. A small number of
non-working applications (caused by applications themselves or the desktop
environment) is not a violation of this criterion.

== Final milestone ==
For each release-blocking desktop, the desktop environment must perform
regular operations like windows close/resize/maximize/minimize/fullscreen
(when supported/applicable), windows switching, using windows on virtual
workspaces, and similar common operations as expected. Common application
content such as regular application windows, video output, and games must
be displayed correctly.

Footnote - "What does this cover?":
The goal of this criterion is to ensure general desktop-related
functionality for different types of applications. A small number of
non-working applications (caused by applications themselves or the desktop
environment) is not a violation of this criterion. 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.

Footnote - "Difference from the Basic criterion?":
Compared to the similar [Basic criterion](link), this covers all
applications (including third-party ones), not just pre-installed ones.
More window operations are required to work, e.g. the explicitly-stated
virtual workspaces workflows.


[1]
https://meetbot.fedoraproject.org/fedora-meeting/2023-03-20/fedora-qa.2023-03-20-15.00.log.html
___
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

[Kamil Paral]

On Fri, Mar 17, 2023 at 1:59 PM Ben Cotton  wrote:

> On Fri, Mar 17, 2023 at 5:48 AM Kamil Paral  wrote:
> >
> > 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.
>
> Thinking like an editor for a moment, this feels a little redundant in
> places. I agree with the general concept, so this is entirely a
> presentation issue and I will not push back if you disagree. :But how
> about something more like:
>
> The desktop environment must perform regular operations like windows
> close/resize/maximize/minimize/fullscreen (when supported/applicable),
> windows switching, using windows on virtual workspaces, and similar
> common operations as expected. Common application content such as
> regular application windows, video output, and games must be displayed
> correctly.
>

Thanks, sounds better. I'll propose an updated version with a few more
tweaks mentioned yesterday in the QA meeting.


>
> > 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'd also add something that makes it clear if it's the application not
> displaying the content correctly, that's out of scope for this
> criterion. I can't think of a good way to phrase that. But I wouldn't
> want someone to think Joe's Fancy Pew Pew Pew Game having a glitchy
> display would violate this.
>

Good idea, I'll try to include it.
___
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

new criterion proposal: Window manager functionality

[Kamil Paral]

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
___
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: F38 dnf modules isn't going to be functional

[Kamil Paral]

On Thu, Mar 16, 2023 at 10:14 AM Peter Robinson 
wrote:

>
> On Wed, Mar 15, 2023 at 2:20 PM Frantisek Zatloukal 
> wrote:
>
>> But that's microdnf, not the current default dnf. I don't think microdnf
>> was used by default in any of our blocking spins/images.
>>
>
> We ship microdnf in the arm minimal image due to issues with dnf and
> memory usage[1] and it's used quite widely on devices like the Raspberry Pi
> Zero2W. The Minimal image is blocking.
>

So if I understand it correctly, microdnf will get a major upgrade, now
based on the dnf5 library. Dnf5 doesn't support modularity in its CLI yet,
and neither will microdnf. But that shouldn't really matter, because the
older microdnf also haven't supported modules, right? So there should be no
loss of functionality... ? Even on the arm minimal image, which is blocking.
___
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: Install java-latest-openjdk-headless failed in Fedora-Rawhide

[Kamil Paral]

On Thu, Mar 9, 2023 at 2:19 AM wang_chen 
wrote:

> dnf install -y java-latest-openjdk.x86_64 java-latest-openjdk-devel.x86_64
> java-latest-openjdk-headless.x86_64
>
> 错误：事务测试失败：
>   file /usr/lib/.build-id/4e/d857f31670d36b42e0e4e7cc60da99c9e598da from
> install of java-latest-openjdk-headless-1:19.0.2.0.7-4.rolling.fc38.x86_64
> conflicts with file from package
> java-17-openjdk-headless-1:17.0.6.0.10-4.fc39.x86_64
>

Please file a bug here, thanks:
https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=java-latest-openjdk
___
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] Dropping YYYY-MM-DD from Test Day Page Title

[Kamil Paral]

On Fri, Mar 3, 2023 at 2:28 AM Sumantro Mukherjee 
wrote:

> So, I am thinking when the
> test day/week are over. How about then we add the date and pass it through
> the testdays CLI tool.
>

This would be a solution if we don't want to adjust our tooling. The wiki
pages can be created like "TestDay:Fedora 38 I18N Test Day" and only once
the date is fully fixed, they can be moved to "TestDay:2023-04-05 I18N Test
Day". It's a bit more work, but you can create it right away, and our
tooling will work. You just mustn't forget about the title change, or the
tools will fail to work.
___
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] Dropping YYYY-MM-DD from Test Day Page Title

[Kamil Paral]

For the record, it was me who nudged Sumantro to send this proposal. It's
my understanding that having the date in the title discourages Sumantro (or
anyone handling it) from creating the wiki page too soon, before the page
is really settled. It makes sense, because any date change (and sometimes
the dates change quite a lot when shuffling test days around) adds extra
work - not just changing the contents, but also renaming the page (which
creates an automatic redirect), and then also updating the hyperlinks, if
you already have them prepared in some announcement template or something.
The effect is that wiki pages are done later than ideal, and some proactive
developers need to ping us and request that we finally create it, which is
not a good service from us (this was my trigger for all this). So I was
thinking - why are we really doing this? Is there a good reason, or can we
simplify?

Having a distinguisher like "F38" or "Fedora 38" in the title seems good
enough (we have that there even already [1][2]), and the date is in the
infobox, and seem to be processed, because the template [3] includes:

| date = '''FIXME'''


[1] https://fedoraproject.org/wiki/Category:Fedora_37_Test_Days
[2] https://fedoraproject.org/wiki/Category:Fedora_38_Test_Days
[3] https://fedoraproject.org/wiki/QA/Test_Days/Template

(see more inline comments below)

On Thu, Mar 2, 2023 at 6:00 PM Adam Williamson 
wrote:

> The wikitcms parser relies on the -MM-DD part of the title,
> so if we change this I would have to rewrite the parser to handle two
> different types of test day page, which is a pain.


OK, that's unfortunate. Why two types? Couldn't all test days be handled
through infobox parsing? Perhaps the code could be copied from testdays.


> I do kinda like the date in the title personally, honestly. It's one of
> the most important pieces of information about a test day, and having
> it in the title means any time you share or see a link to the test day,
> the information about when it's happening is baked in.
>

Yes. But it can go stale, it adds some complications (see above), and in
the last cycles we've tried to move away from single day events and make
them multi-day or a whole week. Then the date in the title can have an
opposite effect, someone might not even click on it because it's already
"too late".
___
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: Please vote on blocker tickets!

[Kamil Paral]

On Mon, Feb 27, 2023 at 5:20 PM Luna Jernberg  wrote:

> Hey!
>
> Did vote some today, was not the Blockers meetings supposed to start
> today? or did i got that wrong and they are starting up later this
> cycle?
>

Adam wasn't available today and nobody else decided to run it. It'll happen
next week ;-)
___
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: Fedora 38: GDM not recognizing Wayland, only X11

[Kamil Paral]

On Tue, Feb 21, 2023 at 10:27 PM Scott Beamer 
wrote:

> I filed a bug report today.
>
> https://bugzilla.redhat.com//show_bug.cgi?id=2172291


But you haven't replied to my question, nor did you provide necessary
details in the bug report. At least "journalctl -b" and "lspci -nn" output
should be attached.
___
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: Fedora 38: GDM not recognizing Wayland, only X11

[Kamil Paral]

On Mon, Feb 20, 2023 at 4:09 PM Scott Beamer 
wrote:

> Greetings,
>
> I did a fresh install of Fedora 38 on 19 February from the latest Live
> images  (both Workstation and KDE Spin).
>
> Workstation install lists no option for either X11 or Wayland.   Default
> GNOME selection lands you in a GNOME session under X11.
>

What's your GPU? This should be the expected behavior with Nvidia (using
the proprietary driver, at least).
___
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

[Kamil Paral]

On Wed, Feb 8, 2023 at 9:55 AM 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?
>
>
Thanks everyone for feedback, the change is now live:
https://fedoraproject.org/w/index.php?title=Fedora_38_Final_Release_Criteria&type=revision&diff=668039&oldid=665509
___
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

[Kamil Paral]

On Wed, Feb 8, 2023 at 7:31 PM Kevin Fenzi  wrote:

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

We have exactly the same experience with a Macbook Pro (with the touch bar)
and F37, tested this week. It seems to be related to the T2 Security Chip,
as mentioned in the lkml post linked by Neal.

I believe we'd use the hardware provision [1] if somebody argued the broken
keyboard/touchpad should be a blocker, as long as at least some Macs work.
This proposed change is just to clarify that only Intel-based Macs are
covered by it, and nothing else.

[1]
https://fedoraproject.org/wiki/Blocker_Bug_FAQ#What_about_hardware_and_local_configuration_dependent_issues
?
___
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

criterion change proposal: macOS dual-boot

[Kamil Paral]

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

Fwd: [Test-Announce] Heads up: testing requested for significant PackageKit update

[Kamil Paral]

-- Forwarded message -
From: Adam Williamson 
Date: Tue, Jan 24, 2023 at 1:29 AM
Subject: [Test-Announce] Heads up: testing requested for significant
PackageKit update
To: 


Hey folks!

The desktop team kindly let us know that there's a fairly significant
PackageKit update coming. It's been built for Rawhide today (so will be
in tomorrow's compose) and is now in updates-testing for F37:

https://bodhi.fedoraproject.org/updates/FEDORA-2023-6c1c40d160

what it does is re-enable a feature where the PackageKit daemon doesn't
run forever as it does now, but shuts down after an inactivity timeout.
This should save a decent amount of RAM, as the daemon tends often to
consume 400M+ of the stuff.

This feature has been turned on and off and on and off again a few
times before because it was found to cause problems. This time, a few
folks have done some diligent work trying to ensure all the previously-
encountered problems were solved, but of course it's *possible* they
missed something, or there are some other problems that folks weren't
aware of.

So it'd be great if as many folks as possible can install this update
and check how it goes. In the past, problems have tended to arise when
you mix operations between dnf and PackageKit-based apps like GNOME
Software, so please pay attention to those kinds of cases - if you
habitually do some stuff with dnf at the command line and some stuff in
Software, keep an eye out for new problems or oddities. Also look out
for incorrect or non-functional update notifications from GNOME,
especially if you e.g. update via DNF but then get a notification from
GNOME for the same updates.

There's some more background reading here:
https://github.com/PackageKit/PackageKit/pull/578

for folks who are interested.

The update for F37 has karma auto-push disabled and time-based auto-
push set to 21 days, so we have plenty of time to find any major
problems with it - don't worry about it being rushed into stable before
we're sure it's OK.

Thanks everyone!
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
___
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: info to verify checksum files not correct

[Kamil Paral]

On Mon, Nov 21, 2022 at 6:34 PM Adam Williamson 
wrote:

> Well, the point of the asterisk is to make it so you can just copy-and-
> paste and run the command and it will find whatever (assumed single)
> CHECKSUM file is present - it saves the user having to manually modify
> the command.
>

That's a good point, but I think it's the wrong thing to do there. The
important goal as I see it is that people can verify their images (in all
cases, even if they download multiple), and saving a few seconds for a
command which is likely to work mostly but not always is not a good
tradeoff, in my view. Man pages are also written clearly.
___
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: info to verify checksum files not correct

[Kamil Paral]

On Mon, Nov 21, 2022 at 12:18 AM AV via test 
wrote:

> On Sat, 2022-11-19 at 19:33 -0800, Samuel Sieb wrote:
> > On 11/18/22 16:11, AV via test wrote:
> > > Following info on https://getfedora.org/en/security/
> > >
> > > gpgv --keyring ./fedora.gpg *-CHECKSUM
> > > gpgv: not a detached signature
> > >
> > > I think a little correction is warranted.
> >
> > You need to give more specific information about what exactly you
> > tried.
> > I followed the instructions there and it worked as expected.
>
> I discovered today what happened. I had downloaded both
> Fedora-Workstation and Fedora-Everything together with
> their CHECKSUMS into the same folder.
> If you then try "gpgv --keyring ./fedora.gpg *-CHECKSUM"
> it results in this error message.
> Remove one of the two from the folder and it works as
> expected.
> But as yet it is not clear to me why this error message
> meant for another situation.
>

Can you file a bug or a pull request at
https://pagure.io/fedora-web/websites/ ? I think the command should be
modified to:
$ gpgv --keyring ./fedora.gpg CHECKSUM_FILE
and the description should state to replace CHECKSUM_FILE with an actual
checksum file name. I agree that currently it's confusing because it looks
like it can handle processing multiple checksum files together (which is
the case for sha256sum, but not for gpgv).
Thanks!
___
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

Help test backlight control changes on old laptops in the upcoming kernel

[Kamil Paral]

Hello,

kernel 6.1 or 6.2 will change how laptop backlight is handled and it might
negatively affect some laptops, especially older ones. Hans De Goede, the
developer of that change, asks for wider community testing. Here are his
blog posts containing all necessary instructions:

* Part 1: https://hansdegoede.livejournal.com/26427.html
* Part 2: https://hansdegoede.livejournal.com/27130.html

If you can, please help him identify affected laptops, so that this change
can be prepared with a minimum negative impact. All results are to be
submitted directly to Hans (not to this list), as described in the blog
posts.

Thank you!
Kamil Páral
Fedora QA
___
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: 2022-11-07 @ **15:00** UTC - Fedora 37 Blocker Review Meeting

[Kamil Paral]

On Mon, Nov 7, 2022 at 6:54 AM Adam Williamson 
wrote:

> # F37 Blocker Review meeting
> # Date: 2022-11-07
> # Time: **15:00** UTC
>

I think this should be 17:00 UTC. That's what Fedocal shows for the
meeting, and what looks like the appropriate time in my own calendar.
___
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: make meetings officially every other week

[Kamil Paral]

On Sat, Oct 29, 2022 at 2:49 AM Adam Williamson 
wrote:

> Anyway, it seems a bit silly that we still notionally schedule a
> meeting every week but I almost always cancel half of them. So I'm
> proposing we make it official that we only meet every *other* week.
> This would save sending out cancellation notices and manually canceling
> the event in the calendar every other week.
>

+1, every other week is fine
___
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: Install matrix update - more coverage for the Basic Video Driver testcase

[Kamil Paral]

On Wed, Oct 26, 2022 at 10:38 PM Adam Williamson 
wrote:

> Ack, I was going to propose the same change. I've tweaked it slightly
> to use brackets instead of dashes, though, as that's what we use
> elsewhere in the page.
>

Fine by me. But I don't think we have a consistent style 😀 :
https://fedoraproject.org/wiki/Template:Desktop_test_matrix
___
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

Install matrix update - more coverage for the Basic Video Driver testcase

[Kamil Paral]

Just a heads up that I updated the Install matrix and extended the Basic
Video Driver testcase coverage. This is because the basic video driver is a
frequent cause of problems, and the limited coverage could often overlook
issues, like our latest proposed blocker:
https://bugzilla.redhat.com/show_bug.cgi?id=2137600

Before (2 test runs were enough to completely fill it out):
https://fedoraproject.org/wiki/Test_Results:Fedora_37_RC_1.4_Installation#User_interface

After (4 test runs are necessary to completely fill it out):
https://fedoraproject.org/wiki/Template:Installation_test_matrix#User_interface

Diff:
https://fedoraproject.org/w/index.php?title=Template%3AInstallation_test_matrix&type=revision&diff=659352&oldid=655215

Any new release validation matrices (new RC, new nightly) should get the
updated table.
___
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

KDE Live can be installed without creating a regular user - correct/wrong?

[Kamil Paral]

KDE Live can be installed without creating a regular user, only root. All
you need to do is to not create a regular user in anaconda (only root), and
then not create a regular user in the first boot utility (just click
Finish). In SSDM, it is then possible to log in using the root account (not
a good idea in general, to be sure).

Is this intentional, or a bug? Should KDE require creating a regular user,
similarly to Workstation?
___
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: [Fedocal] Reminder meeting : Prioritized bugs and issues

[Kamil Paral]

On Tue, Oct 4, 2022 at 9:29 PM Ben Cotton  wrote:

> We will evaluate the following nominated bugs:
>
> * [abrt] gnome-shell: clutter_actor_destroy_all_children():
> gnome-shell killed by SIGABRT
> - https://bugzilla.redhat.com/show_bug.cgi?id=2127826


I just closed this one.


>
> * Systemd causes PC Speaker to emit a loud beep during
> reboot/poweroff, after suspend&resume
> - https://bugzilla.redhat.com/show_bug.cgi?id=2129387


On the other hand, I would very appreciate pulling the right strings to get
this one resolved before F37 Final :-)
___
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: Chromium doesn't respond to clicks or typing in 1 external monitor

[Kamil Paral]

On Mon, Oct 3, 2022 at 2:19 PM Frederic Muller  wrote:

> Hi!
>
> This one is really weird and probably too specific:
>
> I start chromium and move it to my lower left monitor (I have 4
> screens). I can do nothing with it.
>
> I move it back to either center (the primary display) or even the upper
> left monitor and can type or click. I then move it to the lower left
> monitor back and then it's working.
>
> As I said this really is weird. But if anyone is interested I can file a
> bug and do further testing.
>

You should definitely file a bug. This is probably the best place for it:
https://gitlab.gnome.org/GNOME/mutter

This time, try to post the link to the reported bug ;-) Thanks.
___
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: Fractional scaling

[Kamil Paral]

On Mon, Oct 3, 2022 at 12:29 PM Frederic Muller  wrote:

> Thank you very much, just did!
>

It's good to post the link to the bug, in case somebody else is also
affected and reading this.
___
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: Fractional scaling

[Kamil Paral]

On Sun, Oct 2, 2022 at 10:29 AM Frederic Muller  wrote:

> The same feature was working fine under F36.
>

This is the important part.


> What should I look at now to resolve this?
>

Please report a bug: https://gitlab.gnome.org/GNOME/mutter
___
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: Loud PC speaker beep during reboot, sometimes

[Kamil Paral]

On Fri, Sep 23, 2022 at 9:51 PM John Morris  wrote:

> About the only fix Linux could make is to ensure all audio channels are
> muted as the system goes into shutdown, reboot, sleep or suspend.  That
> still won't stop a directly connected beeper though.
>

You're making it sound as if I wanted to prevent firmware-caused beeps. I
don't. I'm pretty sure that the beep I'm complaining about is OS-caused,
and most likely systemd-caused. The links to other people's complaints
confirm my experience.
___
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: Loud PC speaker beep during reboot, sometimes

[Kamil Paral]

On Fri, Sep 23, 2022 at 5:13 PM stan via test 
wrote:

> I forgot to reply to this part of the message.  I have been running F37
> since it was rawhide, and have never heard this beep.  But, I'm running
> a desktop, so that might make a difference.  And a question.  Are you
> sure this is the PC speaker, and not something sending sound to the
> sound device during startup?


It's during shutdown, not startup. Yes, I'm sure. It's the same sound as
when I want to go to UEFI config during startup or show a one-time boot
menu. The sound is unmistakable.


>
> I run a custom kernel, and I have the config options for the speaker
> set as follows:
>
> CONFIG_HAVE_PCSPKR_PLATFORM=y
> CONFIG_PCSPKR_PLATFORM=y
> # CONFIG_INPUT_PCSPKR is not set
>

I have the stock Fedora kernel:

# grep -i pcspkr /boot/config-5.19.9-300.fc37.x86_64
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_INPUT_PCSPKR=m

I'm aware I could blacklist the pcspkr module, but I don't want to fix this
just for myself.
___
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: Loud PC speaker beep during reboot, sometimes

[Kamil Paral]

On Thu, Sep 22, 2022 at 12:13 PM Alexander Ploumistos <
alex.ploumis...@gmail.com> wrote:

> A few months ago I noticed some reports about such an issue, I think
> it's related to systemd v251. Here are some links and a proposed
> workaround:
>
> https://bbs.archlinux.org/viewtopic.php?id=276754
> https://forum.endeavouros.com/t/solved-loud-beep-at-shutdown/27389/5
> https://github.com/systemd/systemd/issues/23520
>

Thank you, this was very helpful!
I reported a systemd bug here:
https://bugzilla.redhat.com/show_bug.cgi?id=2129387
___
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: Upgrade blocker /usr/bin/WebKitWebDriver

[Kamil Paral]

On Fri, Sep 23, 2022 at 12:12 PM RS  wrote:

> When trying to upgrade to Fedora 37 Beta with the system-upgrade Plugin
> like so:
>
> sudo dnf system-upgrade download --releasever=37
>
> I get the following error:
>
> Error: Transaction test error:
>   file /usr/bin/WebKitWebDriver from install of
> webkit2gtk4.1-2.37.91-1.fc37.x86_64 conflicts with file from package
> webkit2gtk3-2.38.0-2.fc36.x86_64
>   file /usr/bin/WebKitWebDriver from install of
> webkit2gtk5.0-2.37.91-1.fc37.x86_64 conflicts with file from package
> webkit2gtk3-2.38.0-2.fc36.x86_64
>

The problem is that you have a package from updates-testing installed, but
you don't have the repo enabled (I simulated the problem above exactly in
this case). So when upgrading to F37, it doesn't include that repo, and
then dependencies fail. Either enable updates-testing, so that the upgrade
process uses it even for F37, or distrosync all your F36 packages back to
their stable versions and only then upgrade.
___
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

Loud PC speaker beep during reboot, sometimes

[Kamil Paral]

Completely randomly, my laptop sometimes emits a loud PC speaker beep while
rebooting/powering off Fedora 37. The beep is very strong, and as a PC
speaker sound, it of course ignores any configured volume level, mute
status, and even headphones plugged in. I fortunately am in a different
room than the rest of my family sleeps in, but if I were in the same room,
and were I just a regular user, this would probably be the last day of
Fedora on that laptop. The beep is that loud and uncomfortable, especially
at night.

I wonder if somebody else running F37 noticed it as well? Any hints what
might cause it and how we can fix it? It never happened on F36 on the same
laptop.

Thanks,
Kamil
___
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

[Kamil Paral]

On Wed, Sep 21, 2022 at 6:02 PM Kamil Paral  wrote:

> On Wed, Sep 21, 2022 at 10:30 AM Kalev Lember 
> wrote:
>
>> 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).
>
>
> Hi Kalev,
> while it's not essential, I find it unfortunate that Night Light controls
> are now broken, I think many people use it:
> https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2056
> It should be fixed by this commit (I haven't tested it), but it seems it's
> not present in mutter-43.0-1:
> https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2623
>
>
And another important mutter fix seems to be this one:
https://bugzilla.redhat.com/show_bug.cgi?id=2128660
https://gitlab.gnome.org/GNOME/mutter/-/issues/2387
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2624
___
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

[Kamil Paral]

On Wed, Sep 21, 2022 at 10:30 AM Kalev Lember  wrote:

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


Hi Kalev,
while it's not essential, I find it unfortunate that Night Light controls
are now broken, I think many people use it:
https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2056
It should be fixed by this commit (I haven't tested it), but it seems it's
not present in mutter-43.0-1:
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2623
___
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

gnome-shell crash when resuming/waking up from idle

[Kamil Paral]

Hi folks,
I wonder if I'm the only one who sees an occasional gnome-shell crash on
Fedora 37 when the system is resumed from suspend, or possibly even woken
up from idle (screen turned off)? It happens to me a few times per week,
completely randomly, I can't reproduce it intentionally.

I reported the crash here:
https://bugzilla.redhat.com/show_bug.cgi?id=2127826
And this might be the upstream issue:
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5832

It might be caused by gnome-shell-extension-appindicator-42-3.fc37.noarch,
but given how seldomly it happens, it's hard for me to verify that.
___
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: except BitLocker-enabled installs from Windows dual-boot criterion bootloader requirement

[Kamil Paral]

On Mon, Sep 19, 2022 at 9:17 PM Adam Williamson 
wrote:

> "The installer must be able to install into free space alongside an
> existing clean Windows installation. As long as the Windows
> installation does not have BitLocker enabled, the installer must also
> install a bootloader which can boot into both Windows and Fedora."
>

The updated criterion sounds OK to me.
___
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: F37 seems to require a reboot after updates of firmware packages in order for firefox to run.

[Kamil Paral]

On Thu, Aug 18, 2022 at 5:32 PM stan via test 
wrote:

> I'm running an actual install of F37.  I have had this experience twice
> now. I run the updates in a virtual console using dnf, they
> complete successfully, they have a firmware package among the updates.
> I then start X to run LXDE, and it starts without complaint.  But when
> I try to run either nightly from /usr/local or firefox from /usr/bin in
> a terminal, they start and just hang.  There are no messages in the
> journal or in the terminal, and when I look at them using ps they are
> in interruptable sleep.
>
> In both cases, I killed them, and exited X, restarted X, and tried to
> run them again.  No change.  But, when I reboot the computer,
> everything starts working again the way I would expect; firefox starts.
>
> Is this a change in F37 that requires a reboot after the install of
> firmware packages?  I know that Gnome, and I think KDE, now require a
> reboot after every update.  Has it moved to other desktops?  Can I
> turn it off, if it has?  Is there a command I can run from the command
> line to do the equivalent of a reboot?  Or is it all just coincidence,
> and there is another reason?
>

I can't speak to your particular experience, but updating the system
without restarting is unreliable by design (no matter the desktop). If you
really want to avoid restarting (I don't recommend it), you can install
python3-tracer and then run "sudo tracer -ea". It will try to list all
processes which need to be restarted, because their corresponding files
changed on disk due to the update. If you see anything listed in the
output, you're in a potentially unsafe state. It is just a heuristic,
though, it can't detect everything.
___
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: Call for testing: UEFI boot of current Rawhide images written to USB with dd

[Kamil Paral]

On Wed, Aug 3, 2022 at 1:45 AM Adam Williamson 
wrote:

> Can anyone else try writing a recent Rawhide image - I used Fedora-
> Everything-netinst-x86_64-Rawhide-20220704.n.0.iso at the time, so a
> current equivalent would be
>
> https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20220802.n.0/compose/Everything/x86_64/iso/Fedora-Everything-netinst-x86_64-Rawhide-20220802.n.0.iso
> - to USB with dd then booting it in native UEFI mode on some system,
> and see if it works? It'd be good to know if there's a general issue or
> I just have some cranky hardware. Thanks!
>

Wrote the linked ISO to a thumb drive using Fedora Media Writer. Tested
UEFI-only boot on three different computers, works fine. Tested BIOS-only
boot on two different computers, and IT'S BROKEN. Well, it actually works
fine on my Intel 4th gen-based desktop PC, but it doesn't boot on my
Thinkpad T480s (in "Legacy only, CSM enabled" mode). When I select the
flash drive in the one-time boot menu, it just immediately returns back to
the menu. On the same T480s, Fedora 36 images boot just fine in BIOS-only
mode. Not good. Worth reporting it somewhere? (I'm not sure if I can add
any more valuable data, though).
___
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: Future of Test Cases and their Management in Fedora QA

[Kamil Paral]

I have played with https://kiwidemo.fedorainfracloud.org for a few days and
I have to say I'm quite disappointed by it :-( I thought it would be closer
to what we need, with some tweaking. But currently I'm hitting serious
obstacles and the user experience for a regular tester is not great either.
It seems that Kiwi is designed in a very rigid way where each person gets
some area of responsibility and they work just there, or there's a smaller
team of educated testers which can easily collaborate on a shared area.
Other approaches feel cumbersome.

First, you need to create a test run, in order to test something. When
creating the test run, you have to define which test cases will be
included. You can populate it from a test plan, which we can prepare, but
either we'll have many many smaller test plans with a couple of test cases,
or a couple of large test plans with tens of test cases. It feels either
constraining or overwhelming to work this way. You can't just simply pick
one random test case which hasn't been tested yet, like with our wiki
matrices. Moreover, searching for those test plans is tedious, always
filling out Product, Version, etc. You're provided with a database list of
test plans, without any logical layout, milestone priorities etc, as on our
wiki. When creating a test run, you have to fill out some fields, like
Build. Perhaps we can provide pre-created hyperlinks which would forward
testers into a fully filled out page and they'd just click a button. After
you create a test run, you have to start it, and after you're done, you
have to end it. You don't actually need to, because you can populate
results even if it hasn't started/has already ended, but certain views will
display in-progress test runs and some won't (unless you display only
in-progress test runs). This feels like bookkeeping feature more than
anything else, and it's a nuisance for us. People will forget to end their
test runs.

Instead of everyone creating their own test run (actually many test runs),
it seems possible to create one single "shared" test run and distribute the
link to it. Other people can fill out the results, even if they haven't
created it. However, there are serious disadvantages:
1. Only a single result can be provided for a test case. So no longer we'd
be able to see results from multiple people, or openqa and an additional
manual tester, for one particular test case. As described above, this feels
very "corporate style of work", but very different from what we need.
2. It is extremely easy to overwrite somebody else's result by accident.
The test run page doesn't update automatically, you need to manually
refresh it. So if you simply submit a result for a test case which looks
untested, somebody else might have submitted the result already (a few
hours earlier, possibly) and your result will simply overwrite it. There's
no warning, nothing. On wiki, we at least get a warning if people edit the
same page/section simultaneously and there's an edit collision. This is a
complete no-go for us. I even wonder how corporate teams can avoid this
situation if multiple people work on the same test run, unless they're
sitting in the same office space talking to each other.

Because sharing test runs is a no-go, individual test runs is the way to
go. But there's another big hurdle. How do you figure out what should you
test, i.e. it hasn't been tested yet by somebody else? I only found a
single solution to this, which is by looking into the "Status matrix".
Unfortunately that page is probably the worst one I encountered in Kiwi.
There's no dedicated Search button, it performs a search on any field
change (and initially shows the whole database, if you wait long enough -
ooof). There's no progress indication, so you never know if a search was
initiated, if it is complete, if empty results page is actually what you
should see or not. The search params are not placed into URL, so every time
you want to refresh the page to see updated results, you have to fill out
all search fields again. The page readability is decent if only a low
number of test runs is displayed. But if people create multiple test runs
(for each smaller test plan/test section, because of submitting results
before lunch/after lunch, etc), the readability gets much worse and it's an
exercise in horizontal scrolling. Our testcase_stats (e.g. [1]) do much
better job in clearly showing what was run and what wasn't, what was the
last tested build and where were some issues. Especially if you want to
show the history, not just the current build. And of course the page again
provides just a database list of test cases, but doesn't structure them in
any way, so we can't e.g. display milestone priorities etc in that list. In
essence, the more test runs are performed, the harder it is to figure out
what wasn't run yet, any test case structuring is not possible, and you
can't refresh the page to see the current state.

The Product/Version/Build organization is 

Re: Plan / proposal: enable openQA update testing and potentially gating on Rawhide updates

[Kamil Paral]

On Thu, Jun 9, 2022 at 9:48 PM Adam Williamson 
wrote:

> So, I'd like to propose that we enable Rawhide update testing on the
> production openQA instance also. This would cause results to appear on
> the Automated Tests tab in Bodhi, but they would be only informational
> (and unless the update was gated by a CI test, or somehow otherwise
> configured not to be pushed automatically, updates would continue to be
> pushed 'stable' almost immediately on creation, regardless of the
> openQA results).
>
> More significantly, I'd also propose that we turn on gating on openQA
> results for Rawhide updates. This would mean Rawhide updates would be
> held from going 'stable' (and included in the next compose) until the
> gating openQA tests had run and passed. We may want to do this a bit
> after turning on the tests; perhaps Fedora 37 branch point would be a
> natural time to do it.
>

+1 from me, thanks for working on this. Crossing fingers for a smooth ride.
___
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: Updated criteria proposal: networking requirements

[Kamil Paral]

On Sat, Jun 4, 2022 at 1:36 AM Adam Williamson 
wrote:

> Any more thoughts, comments, adjustments etc? Thanks!
>

Which milestone is this supposed to block? It sounds fine (to my networking
layman ears).
___
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

[Kamil Paral]

On Thu, May 5, 2022 at 7:05 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.
>

Thanks everyone for testing! I believe this has been super-helpful and we
uncovered (and Jan fixed) lots of issues. FMW 5.0 should be available
officially today together with Fedora 36 (if stars align, otherwise a few
days later). Testing the latest builds (from the project page or from
updates-testing) is of course still very useful. If you find any more
bugs/issues, please report them at
https://github.com/FedoraQt/MediaWriter/issues (instead of this mailing
list). Thank you!
___
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

[Kamil Paral]

On Tue, May 10, 2022 at 4:15 AM Geraldo Simião Kutz <
geraldo.simiao.k...@gmail.com> wrote:

> allright, with 5.0 PT-br is almost done (Rafael tod me he finished by now).
>
> I saw strange alignment of progress numbers at this window. attached
>

I'm not sure if Jan still follows this thread, can you please create a
ticket at https://github.com/FedoraQt/MediaWriter/issues and attach that
screenshot? Thanks!
___
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

[Kamil Paral]

On Fri, May 6, 2022 at 3:49 PM Jan Grulich  wrote:

> New scratch build:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=86726403
>
> 


A fixed link:
https://koji.fedoraproject.org/koji/taskinfo?taskID=86726403
___
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

[Kamil Paral]

On Fri, May 6, 2022 at 1:56 PM Lukas Ruzicka  wrote:

> Hello,
> when I want to download a Server image, it does not show anything, just a
> 0.
>
> https://imgur.com/a/ZoOE1Y1
>

Ouch, that's a bummer. Can you please create a report at
https://github.com/FedoraQt/MediaWriter/issues ? This is the first serious
regression compared to FMW 4.2 and a current showstopper, I believe.
___
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

[Kamil Paral]

I tested the Windows version on Windows 10, and found FMW to be working
well, except perhaps one minor issue:

Restoring a flash drive on Windows creates a FAT16 partition, which is
unusable on larger drives
https://github.com/FedoraQt/MediaWriter/issues/464
___
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