Re: changes to nouveau driver in kernel 6.8.2 and higher?

[Frantisek Zatloukal]

I've reported it and proposed as a Final Blocker at:
https://bugzilla.redhat.com/show_bug.cgi?id=2274490

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
>
>
> I have not investigated if nouveau is the cause of these problems
> but it in any case appears to be implicated and there are also
> power management problems. Normally this laptop has a battery
> rate between 9-11W but now shows a rate above 25W in small task
> use.
>
> AV
> --
> ___
> 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
>


-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
--
___
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

[Frantisek Zatloukal]

On Tue, Sep 5, 2023 at 12:31 PM Kamil Paral  wrote:

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

Yes, you're right.


> Does it make sense to also have this approach for Beta?
>

Since the freeze lifts after the beta release, it's not technically
necessary to address these issues 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?
>

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?


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

I don't feel like further complicating our processes and guidelines. And
having another special cases defined somewhere isn't going to work imo.


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

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

-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
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

[Frantisek Zatloukal]

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.

On Wed, Mar 15, 2023 at 1:44 PM Sumantro Mukherjee 
wrote:

>
>
> On Wed, Mar 15, 2023 at 2:09 PM Frantisek Zatloukal 
> wrote:
>
>> But the dnf > dnf5 switch will happen in F39, not F38, so that shouldn't
>> be an issue that it's not supported in DNF 5, no?
>>
>
> I checked and it says F38 as target release
> https://fedoraproject.org/wiki/Changes/MajorUpgradeOfMicrodnf
>
>
>>
>> On Wed, Mar 15, 2023 at 8:32 AM Sumantro Mukherjee 
>> wrote:
>>
>>> DNF5 test day is running and we have figured that dnf modules command
>>> is being worked on.
>>> The functionality can be tracked [0] and this is targeted to be complete
>>> in F39.
>>> If users, have modules enabled in F37 and upgrade to F38, things will be
>>> fine.
>>> However, fresh installs or installations which wanna play with modules
>>> in F38 won't be
>>> able to do that.
>>>
>>> DNF team suggests a workaround how to modify modules without using any
>>> tool - modify files in /etc/dnf/modules.d. if you want to reset nodejs
>>> module you can use rm /etc/dnf/modules.d/nodejs
>>>
>>> If this is a problematic thing, we should communicate this to the users.
>>>
>>> [0] https://github.com/rpm-software-management/dnf5/issues/146
>>>
>>> --
>>> //sumantro
>>> Fedora QE
>>> TRIED AND PERSONALLY TESTED, ERGO TRUSTED
>>> ___
>>> 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
>>>
>>
>>
>> --
>>
>> Best regards / S pozdravem,
>>
>> František Zatloukal
>> Senior Quality Engineer
>> Red Hat
>> ___
>> 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
>>
>
>
> --
> //sumantro
> Fedora QE
> TRIED AND PERSONALLY TESTED, ERGO TRUSTED <https://redhat.com/trusted>
> ___
> 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
>


-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
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

[Frantisek Zatloukal]

But the dnf > dnf5 switch will happen in F39, not F38, so that shouldn't be
an issue that it's not supported in DNF 5, no?

On Wed, Mar 15, 2023 at 8:32 AM Sumantro Mukherjee 
wrote:

> DNF5 test day is running and we have figured that dnf modules command
> is being worked on.
> The functionality can be tracked [0] and this is targeted to be complete
> in F39.
> If users, have modules enabled in F37 and upgrade to F38, things will be
> fine.
> However, fresh installs or installations which wanna play with modules
> in F38 won't be
> able to do that.
>
> DNF team suggests a workaround how to modify modules without using any
> tool - modify files in /etc/dnf/modules.d. if you want to reset nodejs
> module you can use rm /etc/dnf/modules.d/nodejs
>
> If this is a problematic thing, we should communicate this to the users.
>
> [0] https://github.com/rpm-software-management/dnf5/issues/146
>
> --
> //sumantro
> Fedora QE
> TRIED AND PERSONALLY TESTED, ERGO TRUSTED
> ___
> 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
>


-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
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: Proposed change to rendering of release schedule ics file

[Frantisek Zatloukal]

Hey Ben,

we're parsing the ics files for schedule progress at the packager
dashboard. However, I won't have access to my laptop (and the internet most
of the time) before February 15th.

Can you please postpone the change for a week?

Thanks a lot!

On Tue, Jan 31, 2023, 00:12 Ben Cotton  wrote:

> Hi everyone,
>
> I want to get feedback before I make a change to how Fedora Linux
> schedules are generated. As reported in schedule#91[1], the current
> ics files include very long tasks that aren't particularly useful. I
> have a plan for how to address that, but first I want to check that it
> won't impact how people currently use the ics files.
>
> If you're using the Fedora Linux schedule ics files, please see the
> details in the Pagure issue[2]. If this will affect how you or your
> team use those files, comment in the issue before 13 February. Note
> that this will not change how the html or json versions are produced.
>
>
> [1] https://pagure.io/fedora-pgm/schedule/issue/91
> [2] https://pagure.io/fedora-pgm/schedule/issue/91#comment-838492
>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> 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
>
___
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: Last known Good for Rawhide (Server Edition) -- Not Good

[Frantisek Zatloukal]

o/ ,

Please note that "last known good" for rawhide nightlies actually means
that it installs to VM, not via usb.
Thanks for the report though, either myself early next week or somebody
else will try this, it might be an actual bug of something specific about
your configuration.

Just to be sure, did you create the usb media via Fedora Media Writer?

On Sat, Dec 10, 2022 at 11:35 AM Onyeibo Oku 
wrote:

> Good Morning,
>
> I'd like to bring something to attention.  I just downloaded Server
> Boot Media (Netinstall) from:
>
> https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20221209.n.0/compose/Server/x86_64/iso/Fedora-Server-netinst-x86_64-Rawhide-20221209.n.0.iso
>
> I made a USB boot disk out of that and it failed to boot.
>
> Here is what I get after choosing to install at the GRUB Menu:
>
> error: ../../grub-core/fs/fshelp.c:257:file '/images/pxeboot/vmlinuz'
> not found
> error: ../../grub-core/loader/i386/efi/linux.c:258:you need to load the
> kernel first.
>
> Press any key to continue ...
>
>
> The ISO was registered as "last known good". This can't be good.
>
> Which one really works?
>
> ___
> 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
>


-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
___
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: Graphical package managers

[Frantisek Zatloukal]

On Mon, Nov 8, 2021 at 3:05 PM Kamil Paral  wrote:

> "dnf install foo bar"
>

This is a single operation, comparable to having multiple packages
installed via graphical package manager, not scheduling multiple operations
at once. It would be the same If a graphical package manager offered to
select multiple packages/applications and then start the transaction.


> "dnf install foo; dnf install bar"
>

This is equivalent to:

1. Open Graphical package manager
2. Install foo
3. Close Graphical package manager
4. Open Graphical package manager
5. Install bar
6. Close Graphical package manager


> It depends on what your definition of an operation is. But in both cases,
> I don't see a functional difference between these and a user clicking on
> the Install button for foo and bar in the graphical package manager.
>
> Doing a single installation, waiting for it to finish, then doing another
>> is something you can do with dnf and something that I'd block on with
>> graphical package managers.
>>
>
> And yet you voted for a RejectedBlocker just a few weeks back:
> https://pagure.io/fedora-qa/blocker-review/issue/560
>

dnf exits after transaction finish, so it's equivalent to a workaround that
was possible for that blocker proposal. Also, I might've added that I'd
block on this once we agree on proper criterions ;)


>
> If you changed your mind, great :-)
>
>
>> Scheduling multiple tasks without waiting for them to finish one by one
>> is something that I am against blocking on.
>>
>
> What purpose does it make to punish users for something they can't know?
> They don't know that they should wait for the first operation to finish,
> and only then click on the next button. This way they are safer, because
> they are within the path we block on (if we used your definition). So why
> do we even allow them, *tempt them* to be able to click a different button
> in the meantime? Shouldn't we push on developers to prevent simultaneous
> button clicking?
>

Are users doing this? I don't think so, you think they do. We don't have
any data we can use to say which way it is used. Nothing prevents you from
testing this path and reporting bugs and working with the devs on solving
it, even if it isn't a blocking path.


>
> And I'm going to go down the rabbit hole even more. How is scheduling
> another install different from e.g. listing installed packages or available
> updates? If the user starts installation of package A, and then switches to
> the Installed or Updates tab in gnome-software (which executes a
> *concurrent* packagekit operation), and then the whole thing breaks, do we
> also say "you naughty human being, you shouldn't have clicked that, even if
> we allowed you to" and not block on it?
>

I don't do this, I've never seen anyone (with or without a technical
background) do this. All the users I've seen do is to wait until something
finishes and then switch to other tabs/sections, etc. Again, I am not
saying this isn't happening, all I am saying it's not blocker material, in
my opinion.

-- 

Best regards / S pozdravem,

František Zatloukal
Quality Engineer
Red Hat
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: new criterion proposal: Graphical package managers

[Frantisek Zatloukal]

On Thu, Nov 4, 2021, 11:40 Kamil Paral  wrote:

> I'm not sure if you understood it correctly (or if I even expressed it
> correctly). The operations are of course executed sequentially, always
> (that's how our package managers work). But they can be *scheduled*
> concurrently, i.e. you can install GIMP, and before it is downloaded and
> installed, you can also schedule installation of Inkscape. I think this is
> not an unusual use case, to schedule several operations at once. E.g. I
> just installed a new system and want to install my favorite applications.
> Or I decided that I want to play a different game, so I hit Install on
> OpenArena and also click Remove on SuperTuxKart.
>
> Is this really what you are against, or have you understood it
> differently? I can try to phrase it better.
>

Yeah I understood it correctly. I am not saying it's not a valid use case,
just that I don't think that it's a common enough use case to be made
blocking.

>
See my response above. Imagine that we'd ensure only the first dnf
> operation works correctly, but any later one can blow up. Why would we want
> to allow that with a graphical package manager?
>

You can't schedule multiple dnf operations at once. Doing a single
installation, waiting for it to finish, then doing another is something you
can do with dnf and something that I'd block on with graphical package
managers. Scheduling multiple tasks without waiting for them to finish one
by one is something that I am against blocking on.
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: new criterion proposal: Graphical package managers

[Frantisek Zatloukal]

On Wed, Nov 3, 2021 at 12:32 PM Kamil Paral  wrote:

> ~~
> The default graphical package manager for a given software type must
> appropriately:
> * install, remove and update software, even if multiple operations are
> scheduled sequentially or concurrently
>

I am definitely against blocking on "multiple operations concurrently". I
don't see this as a frequently used "blocking material", I'd rather leave
this can of races unopened.

Apart from that, I am slightly against blocking on "sequentially".


> * start the selected installed software
>
If the Graphical package manager exposes such a feature.

Others seem fine, thanks for summarizing this into a more formally defined
criterion.

One more note though, can you post this to the desktop and kde lists (or
tickets) for their opinions? This shouldn't be put into effect unless our
blocking desktop maintainers agree imo. For example, KDE folks might want
to block on a smaller subset of this criterion (I don't know if they do).

Thanks!

-- 

Best regards / S pozdravem,

František Zatloukal
Quality Engineer
Red Hat
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [Proposal] The dual monitor set-up criterion (Final Version)

[Frantisek Zatloukal]

Works for me, nice and simple. Thanks!

On Wed, Apr 21, 2021 at 3:49 PM Geoffrey Marr  wrote:

> LGTM! Good work Lukas.
>
> Geoff Marr
> IRC: coremodule
>
>
> On Wed, Apr 21, 2021 at 2:32 AM Lukas Ruzicka  wrote:
>
>> Hello friends of Fedora,
>>
>> please see the final version of the dual monitor criterion. This is the
>> last chance for you to suggest anything you would like to see inside (or
>> remove from it).
>>
>>
>>
>> *"On computers using two monitors (e.g. two monitors on a desktop, or the
>> built-in and one external monitor on a laptop), the graphical output is
>> correctly shown on both monitors." Note: Due to a wide range of possible
>> hardware configurations, any problem related to this criterion will be
>> regarded as a "conditional blocker" (as described in
>> https://fedoraproject.org/wiki/Blocker_Bug_FAQ#What_about_hardware_and_local_configuration_dependent_issues.3F)
>> ."*
>>
>>
>>
>>
>> --
>>
>> Lukáš Růžička
>>
>> FEDORA QE, RHCE
>>
>> Red Hat
>>
>> 
>>
>> Purkyňova 115
>>
>> 612 45 Brno - Královo Pole
>>
>> lruzi...@redhat.com
>> TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
>> ___
>> 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
>>
> ___
> 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
>


-- 

Best regards / S pozdravem,

František Zatloukal
Quality Engineer
Red Hat
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [Proposal] Test Cases for the Fedora Audio Test Day.

[Frantisek Zatloukal]

On Mon, Feb 22, 2021 at 10:43 AM Lukas Ruzicka  wrote:

> Some of them can be run in a VM for sure, but you might run into unknown
> waters when it comes to using USB external sound cards and some kind of
> application sound routing, because you might not be able to simulate that
> in the VM, where the sound device is just a bridge to the real one on the
> hardware.
> The testcases are therefore practical and bare-metal oriented.
>
>
You can set up usb passthrough through virt-manager or VirtualBox. After
you do that, the guest gains complete control of that usb device and it
should work/behave like it wasn't even in a vm.

You can get there through "Show virtual hardware details", "Add Hardware",
"USB Host Device", then choose a device you wish to hand of to the guest.
Beware that the selected device won't be available on host for use while
the vm is up and running.

-- 

Best regards / S pozdravem,

František Zatloukal
Quality Engineer
Red Hat
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Proposal to modify: Working Sound Beta Release Criterion

[Frantisek Zatloukal]

> On Thu, 2021-01-28 at 14:55 +0100, Lukas Ruzicka wrote:

> > Ok, after an offline part of discussion with @Kamil Paral

> > , we both have agreed that:

> >

> >

> >1. The beta criterion for *Working sound *should remain as is now (no

> >change needed).

> >2. We would like to introduce a *new final criterion *saying*: **"The

> >installed system must be able to record audio using the default web
browser

> >(if applicable) and gstreamer-based applications."*

> >
> What do you think?

+1 from 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

Re: Proposal to Modify: Testcase dualboot with macOS

[Frantisek Zatloukal]

On Tue, Jan 19, 2021 at 8:56 PM Geoffrey Marr  wrote:

> Hi all,
>
> I have spent the last two days experimenting with Fedora 33 on a 2017 12"
> Macbook (Macbook10,1). Unlike some previous Macs I have installed Fedora
> on, out-of-the box peripheral support is fantastic. I didn't have to
> install a single driver myself, everything was included. /praise over
>
> After reviewing our "dualboot with macOS" testcase [0], I noticed that the
> testcase says it's based on a Mac running macOS 10.12 Sierra. At this point
> in time, macOS Sierra is almost 5 years old. I would like to update this
> testcase to reflect that it supports *any* OS from macOS 10.12 Sierra to
> macOS 11 Big Sur. I have tested these myself for compatibility and find
> that they all provide the necessary means for a dualboot install.
>
> On a side note, I would also like to include a small notice within the
> testcase that mentions that Fedora is *not* supported on the new Apple
> Silicon M1 computers and that this testcase only applies to Intel-based
> Macs.
>
> I have made these changes as I see them to my own wiki page [1]. Please
> review the page and propose any suggestions here. Feedback is welcome. If I
> don't hear any major squawks in a week or so, I will merge the changes into
> the official Fedora QA wiki.
>
>
The changes look good to me. Thanks!

On Wed, Jan 20, 2021 at 4:45 AM Chris Murphy 
wrote:

>
> It's a teeny modification but you could make it macOS 10.13 High
> Sierra as the cutoff. There's a chunk of hardware for which 10.13 is
> the latest officially supported version. And also Apple only supports
> two current versions of macOS, which are now 10.15 and 11. The vast
> majority of macOS users upgrade within a year, so the bulk of the user
> base is on 10.15 and 11.
>
> There is a Fedora Media Writer signing issue related to a macOS bug in
> 10.13, so I wouldn't fuss one bit if you want to make the test case,
> or at least for blocking purposes, 10.14 and higher.
>

So you can't get FMW to run on 10.13 without workarounds? If the cutoff was
set to 10.14, we wouldn't be able to utilize our old Mac Mini 2011 that we
have for testing in Brno office. 10.13 is the latest Mac OS X we can get to
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

Re: [Test-Announce] Fedora 33 Candidate Beta-1.3 Available Now!

[Frantisek Zatloukal]

On Wed, Sep 23, 2020, 07:37 Jaap Bosman  wrote:

> You know the page https://fedoraproject.org/wiki/QA:Testcase_USB_fmw
> wants us to upgrade/download sudo dnf --enablerepo=updates-testing
> --refresh --best install mediawriter
>
> that will not  install the required testing version (4.0.95)
>
> but a new version.  mediawriter-4.1.4-4.fc32.x86_64
>
> I trust that is OK?
>
Yes, that's okay. I'll update the wiki page in a moment.

>
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Request for Fedora QA team information

[Frantisek Zatloukal]

LGTM, thanks for putting it together Adam!

On Fri, Sep 4, 2020, 20:54 Sumantro Mukherjee  wrote:

>
>
> On Sat, Sep 5, 2020 at 12:17 AM Adam Williamson <
> adamw...@fedoraproject.org> wrote:
>
>> On Fri, 2020-09-04 at 14:31 -0400, David Cantrell wrote:
>> > Hi,
>> >
>> > The Fedora Council is working to update the Team Directory in the
>> council-docs
>> > project.  Part of that is reviewing the teams we have documented and if
>> the
>> > information is correct.
>> >
>> > The Fedora QA Team is currently listed here:
>> >
>> >  https://docs.fedoraproject.org/en-US/engineering/
>> >
>> > We are asking for teams to fill out this template so we can have a more
>> > consistent listing for team information:
>> >
>> >
>> https://pagure.io/Fedora-Council/council-docs/blob/master/f/engineering/modules/ROOT/partials/TEMPLATE_team_info.adoc
>> >
>> > Can you complete this template and send it to me via email (I am trying
>> to
>> > collect and update the engineering team entries)?  If you no longer
>> wish to
>> > have the team listed in the council-docs, that's fine too.  Here is
>> > information about what we are trying to accomplish with the Fedora Team
>> > Directory:
>> >
>> >
>> https://docs.fedoraproject.org/en-US/council/procedures/team_directory/
>> >
>> > If you have any questions, let me know.
>>
>> Proposed reply:
>>
>> ===
>>
>> // TEMPLATE
>>
>> // This is a data store of information about a Fedora team.
>>
>> // File like this would be stored either in the team's docs
>> // git repository, or if they don't have any (maybe they live on a wiki).
>> // then it can be stored in the council-docs repo next to the template.
>>
>> // Team name:
>> :team_name: Fedora QA
>>
>> // Team summary:
>> :team_summary: We co-ordinate testing and validation of Fedora
>> releases, updates and so on.
>>
>> // Team page URL:
>> :team_url: https://fedoraproject.org/wiki/QA
>>
>> // Team activity status.
>> // Choose from: Active, Inactive
>> :team_status: Active
>>
>> // Preferred Asynch communication channel (mailing list,
>> discussion.fp.o, none, etc)
>> :team_asynch_communication:
>> https://lists.fedoraproject.org/admin/lists/test.lists.fedoraproject.org/
>>
>> // Preferred Synch (IRC channel, telegram, etc, none)
>> :team_synch_communication: IRC #fedora-qa, Telegram
>> https://t.me/fedora_qa
>>
>> // Issue tracker
>> :team_issue_tracker: https://pagure.io/fedora-qa/issues
>>
>> // Meetings
>> :team_meetings: https://fedoraproject.org/wiki/QA/Meetings
>>
>> // Any other information?
>> :team_other: How to join: https://docs.fedoraproject.org/en-US/qa-docs/
>>
>> ===
>>
>> Any comments / suggestions / enhancements? Thanks!
>>
>
> Looks good. Nothing much to add.
>
>
>
>> --
>> Adam Williamson
>> Fedora QA Community Monkey
>> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
>> http://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
>>
>
>
> --
> //sumantro
> Fedora QE
> TRIED AND PERSONALLY TESTED, ERGO TRUSTED 
> ___
> 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
>
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Can dxvk be turned on/off per app?

[Frantisek Zatloukal]

On Fri, Aug 14, 2020 at 10:39 AM Bruno Wolff III  wrote:

> I'm not interested in creating a github account and it looks like one
> is required to report problems.
>

Okay, I (might) be able to test that game/report issues to the dxvk tracker
sometime next week.


> I ended up using alternatives to disable dxvk as I was worried about
> the packages getting pulled in again later. I'm running rawhide and
> I had this get pulled in during a routine update so I wasn't sure if it
> would get pulled in another update later. Sins is the heaviest
> graphics game that I play, so I don't think I'll need it for performance
> reasons for other games at this time. I would have been interested in
> trying
> it out on a couple of more games. If I end up wanting to do that, it looks
> like writing a couple of scripts that use alternatvies to turn it on and
> off wouldn't be hard. And would be faster than installing and uninstalling
> the dxvk packages and simpler than keeping multiple versions of wine
> around.
>
> I'll be keeping an eye on it though, as Sins does slow down in the end
> game. I think this has more to do with tracking objects than rendering
> them,
> but if it does help, I'll want to use it. I expect I'll test 1.7.1 as
> soon as it is convenient, as that is supposed to have a lot of fixes.
>

I pushed the 1.7.1 into F34-F31 just moments ago. You can grab the rpms
from koji or wait till tomorrow (or whenever we get another F33/34 compose).

Btw, you can exclude wine-dxvk through dnf config as per Change Proposal
Page:
https://fedoraproject.org/wiki/Changes/DXVKwined3d#Upgrade.2Fcompatibility_impact
 :

"Users would be able to opt-out from using DXVK by adding
'exclude=wine-dxvk*' into /etc/dnf/dnf.conf and removing wine-dxvk package."

Thanks for getting dxvk into Fedora.
>

You're welcome :)
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Can dxvk be turned on/off per app?

[Frantisek Zatloukal]

On Fri, Aug 14, 2020 at 4:50 AM Bruno Wolff III  wrote:

> The next dxvk enhancement for wine broke Sin of the Solar Empire -
> Rebellion
> (GoG's version) for me, but works for some other games. Right now I've
> turned it off for everything, but I'd like to only turn it off for games
> that have a problem.
>

Can you please go ahead and report the issue to DXVK developers?
https://github.com/doitsujin/dxvk/issues

They are pretty responsive there, thanks!


>
> I looked at the feature page and there doesn't seem to be much help
> there for people who have problems other than uninstalling it.
> Alternatives
> was mentioned without examples, which was enough to help me turn it off
> with that so that it didn't get reinstalled later and break things. But
> I'm hoping there is a way to do overrides using winecfg, but I'm not
> sure how to specify the overrides.
>

Unfortunately, enabling/disabling dxvk from default installation per
application is not possible.
In these cases, the only option would be to uninstall dxvk and then
install/enable it from official sources. Or, if you're having problems with
only few applications/games, you can use lutris to launch them with
different (dxvk-less) versions of wine.
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Proposal refinement of the late blocker exception

[Frantisek Zatloukal]

On Fri, Apr 17, 2020 at 3:56 PM Kamil Paral  wrote:

> I think this:
> "If the release is declared no-go, the bug loses last minute status."
> should be part of our policy. I considered it obvious, but I'm sure some
> people (/me looking at Frantisek) would argue. Let's put it there.
>

I am against prohibiting use of last minute status if a release is no-go.
Kamil, we already have "bugs proposed as blockers 5 days or fewer before
the scheduled" in the last minute definition, I'd that's say that's
specific enough.

Also, we might want to preserve last minute "blocker waive" even if a
release is no-go, consider having slip by one day (which is happening
pretty frequently).
___
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

Fedora Easy Karma - Request for testing

[Frantisek Zatloukal]

Hi,

I've released updated fedora-easy-karma version yesterday with fixes for
Bodhi >= 4 and some cleaning up of the code (dropped python2, old bodhi and
yum support). Bodhi 5.2 fixed the issue server side (thanks!).

You don't need to open updates page and give karma manually through bodhi
webui, *giving karma from the CLI works again*.

The new version is currently in updates-testing:

F30: https://bodhi.fedoraproject.org/updates/FEDORA-2020-a298299fd5
F31: https://bodhi.fedoraproject.org/updates/FEDORA-2020-cf10f95a87
F32: https://bodhi.fedoraproject.org/updates/FEDORA-2020-05f8e750df

I'd appreciate some testing if everything works as it should. Feel free to
report issues either in this thread, on bodhi updates page or in
fedora-easy-karma-repo ( https://pagure.io/fedora-easy-karma ).

Thanks and happy "karming"!
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: criterion proposal: prevent services timing out on system shutdown

[Frantisek Zatloukal]

On Tue, Mar 17, 2020 at 4:49 PM Dulaney  wrote:

> I can't recall, but, is podman included in a release blocking package set?
>
> I ask because it already fails to properly exit and is eventually
> timed out.  Podman fails this criteria for F31 (and presumably F32).
> That said, I'm all for this criteria.
>

This is only about services included in default installation. As far as I
know, podman isn't a service, so this change wouldn't affect it at all.

Also, I don't think podman is included in default package set anywhere, but
I could be wrong 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

Re: criterion proposal: prevent services timing out on system shutdown

[Frantisek Zatloukal]

On Tue, Mar 17, 2020, 15:34 Kamil Paral  wrote:

> On Tue, Mar 17, 2020 at 2:40 PM Frantisek Zatloukal 
> wrote:
>
>>
>> Yeah, I'd prefer something like:
>> *All system services present after installation with one of the
>> release-blocking package sets must not time out every time when they are
>> being stopped during system reboot/shutdown.*
>>
>
> It's possible but I find it too weak. See my reply to Ben, thanks.
>
>
>>
>>
>> I like the general proposal, just different wording seems better. If
>> timeout doesn't happen regularly, I won't block on it.
>>
>
> "Every time" is different from "regularly".
>

Doesn't need to be. "Every time" implies "regularly", "regularly" can mean
"every time".

I get your point, for the record, I am for blocking on this only if it
happens every 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

Re: criterion proposal: prevent services timing out on system shutdown

[Frantisek Zatloukal]

On Tue, Mar 17, 2020 at 2:10 PM Ben Cotton  wrote:

> On Tue, Mar 17, 2020 at 4:48 AM Kamil Paral  wrote:
> >
> > All system services present after installation with one of the
> release-blocking package sets must not time out frequently or regularly
> when they are being stopped during system reboot/shutdown.
> >
> I like it generally, but I worry we'll get hung up on the definition
> of "frequently" or "regularly". For shutdown in particular, I'm less
> concerned with service timeouts (granted, I'm not paying for my
> compute by the minute). I'm leaning toward something like
> "predictably" or "reliably" (which is an awkward use of the word).
> Basically, it's not a blocker unless it does it every time.
>
>
Yeah, I'd prefer something like:
*All system services present after installation with one of the
release-blocking package sets must not time out every time when they are
being stopped during system reboot/shutdown.*

I like the general proposal, just different wording seems better. If
timeout doesn't happen regularly, I won't block on 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

Re: Proposal: Asynchronous blocker review process (using Pagure)

[Frantisek Zatloukal]

On Thu, Nov 28, 2019 at 1:31 PM Kamil Paral  wrote:

>
> 5. Once some kind of understanding of the issue is formed, a privileged
> member (e.g. a member of @fedora-qa FAS group) can start the vote by
> including a command in his comment, e.g. "START VOTE" on a separate line.
> (Note that this is just a proposal. We can easily let anyone start the
> vote, or we can allow voting right from the
> 9. If new important information appear or the vote needs to be repeated
> for any other reason, a privileged member can restart the vote e.g. by
> issuing RESTART VOTE command. (We can have more such administrative
> commands for any purpose we need, same as we have them with IRC bots).
>

It's probably just a small detail, why would we need (RE)START VOTE
commands? It seems we can vote whatever/whenever we want, bot would just
count the last VOTE +/- 1, 0 comment (or rather command) from each
participant.
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Gnome on F31: Qt applications cannot be fullscreened

[Frantisek Zatloukal]

Looks like QT apps using Wayland can't go fullscreen on GNOME Wayland
session. As a workaround, you can set QT_QPA_PLATFORM=xcb .

On Tue, Oct 8, 2019 at 12:25 PM Ankur Sinha  wrote:

> Hello,
>
> Ran into another bug today while trying to watch netflix. Qt
> applications cannot be full screened.
>
> Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=1759490
>
> This is more basic functionality---worth proposing as a blocker?
>
> --
> Thanks,
> Regards,
> Ankur Sinha "FranciscoD" (He / Him / His) |
> https://fedoraproject.org/wiki/User:Ankursinha
> Time zone: Europe/London
> ___
> 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
>
___
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

[F31] Some updates waiting for testing

[Frantisek Zatloukal]

Hi,


as you all probably know, we are currently in F31 Beta Freeze.That means
only updates fixing blocker bugs or those granted Freeze Exception status
might be pushed to the stable repository.


As we'll be deciding next Thursday if F31 Beta is ready to go[0], there are
some updates pending to be tested and pushed. It'd be amazing if those
could get some testing from as many users as possible.


What's needed? Not much, just fire up Fedora 31 (you can grab an ISO from
this page [1]), install and test those updates and give them some karma in
bodhi. All of those packages should be present in F31 updates-testing
repository (which is enabled by default at this point of F31 cycle), so you
should be able to just do dnf update after installing Fedora 31.


In case you don't see those packages (mirror is out of sync for example),
you can download rpms from each update via "*bodhi updates download
--updateid=FEDORA-*" and install them with dnf.


If you find any problems compared to previous Fedora 31 state, give it a
negative karma in bodhi. If you find something terribly broken, give it
negative karma. Otherwise, if anything is broken, file a bug to bugzilla,
as usual :)


Some significant updates worthy of testing:


GNOME Mega Update

https://bodhi.fedoraproject.org/updates/FEDORA-2019-18f7fc4f08

What to test: Entire GNOME desktop (Fedora Workstation default). Testing
this includes interaction with default desktop environment and majority of
it's base applications, eg. Boxes, Nautilus, File Roller, Terminal,
Gedit,...You can find a list at the bodhi page.


rpm 4.15

https://bodhi.fedoraproject.org/updates/FEDORA-2019-e4b6ffd824

What to test: Manipulation with packages, ideally both via dnf and
PackageKit (GNOME Software). Installing, updating, removing packages, doing
some queries directly with rpm (rpm -q package, rpm -ql package).


Thanks a lot and happy bug hunting!


[0]
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/ED3KLLX54KKOFSLTLNFJYILVAULM4XFH/

[1]
https://kojipkgs.fedoraproject.org/compose/branched/latest-Fedora-31/compose/
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Testing Branched F31 drop 0831

[Frantisek Zatloukal]

On Sun, Sep 1, 2019 at 6:04 PM pmkel...@frontier.com 
wrote:

> During the reboot after the install, the sad face saying "Oh no!
> ..." appeared and the boot did not proceed further.
>

Yep, known and proposed as a blocker:
https://bugzilla.redhat.com/show_bug.cgi?id=1746563 , related selinux part:
https://bugzilla.redhat.com/show_bug.cgi?id=1746584 .
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

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

[Frantisek Zatloukal]

On Mon, Aug 26, 2019 at 4:53 PM Kamil Paral  wrote:

> On Mon, Aug 26, 2019 at 2:42 PM Justin Forbes 
> wrote:
>
>> From my standpoint, ext4 and xfs are the primary supported root
>> filesystems. I don't think that anything else should be release
>> blocking.
>
>
> If this is the case, we can explicitly list the supported file systems in
> criteria. The list would need to be extended with at least vfat, which is
> used for ESP, though.
>
> If we go this route, it would be nice to communicate this somehow to the
> end user, directly in anaconda interface. Either by showing a warning when
> a "not officially supported" filesystem is selected, or by hiding those
> filesystems in dialogs when creating a new partition (with a documented
> override).
>

Hmm, I don't see this as necessary. I think changing criterions on what
file systems are blocking doesn't mean we need to hide things or add some
ugly warnings. Anybody who uses advanced partitioning should know what is
doing, we can just update criterions so not everything visible in advanced
partitioning must work and is supported.


> Existing partitions still need to be handled somehow, so the warning bar
> might need to be implemented in any case (warn that the existing partition
> is unsupported by allow to use it, or warn that the existing partition
> can't be used unless the override is activated).
>

I am -1 on this. I just somehow hate the idea of showing warnings and/or
adding some blocks and overrides. We weren't testing on unsupported/other
file systems anyway (correct me if I am mistaken), so what's the difference
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

Re: [Test-Announce] Fedora 30 Candidate Beta-1.8 Available Now!

[Frantisek Zatloukal]

So, today, we went through 1.8 testing. Results of stuff (including
installation tests of all release blocking images) that we retested are
filled to the 1.8 result pages, I don't think it's necessary to copy over
all remaining 1.4 results.

We didn't find anything broken compared to 1.4, Firefox is working just
fine, it's using XWayland as it should per FESCO decision . We didn't test
fix for Korean input, but at least Czech/English inputs are still working
fine.

I went through a lot of GNOME apps testing, nothing seems broken,
Boxes/qemu blocker is fixed.

So, fingers crossed for a Go tomorrow :)

On Tue, Mar 26, 2019 at 9:25 PM Adam Williamson 
wrote:

> On Tue, 2019-03-26 at 15:19 +, rawh...@fedoraproject.org wrote:
> > According to the schedule [1], Fedora 30 Candidate Beta-1.8 is now
> > available for testing. Please help us complete all the validation
> > testing! For more information on release validation testing, see:
> > https://fedoraproject.org/wiki/QA:Release_validation_test_plan
> >
> > Test coverage information for the current release can be seen at:
> > https://www.happyassassin.net/testcase_stats/30
> >
> > You can see all results, find testing instructions and image download
> > locations, and enter results on the Summary page:
> >
> > https://fedoraproject.org/wiki/Test_Results:Fedora_30_Beta_1.8_Summary
> >
> > The individual test result pages are:
> >
> >
> https://fedoraproject.org/wiki/Test_Results:Fedora_30_Beta_1.8_Installation
> > https://fedoraproject.org/wiki/Test_Results:Fedora_30_Beta_1.8_Base
> > https://fedoraproject.org/wiki/Test_Results:Fedora_30_Beta_1.8_Server
> > https://fedoraproject.org/wiki/Test_Results:Fedora_30_Beta_1.8_Cloud
> > https://fedoraproject.org/wiki/Test_Results:Fedora_30_Beta_1.8_Desktop
> >
> https://fedoraproject.org/wiki/Test_Results:Fedora_30_Beta_1.8_Security_Lab
>
> So just to keep everyone up to date on what's going on here...
>
> Last week we had Beta-1.4 then Beta-1.7. The only differences between
> 1.4 and 1.7 were a kickstart fix to pull a browser into the ARM
> graphical images (Firefox isn't working on ARM atm), the inclusion of
> Firefox 66.0.1, some kickstart changes to fix non-blocking image
> creation, and a fedora-logos update to fix missing text on the
> installer 'ad banners'.
>
> The only differences between 1.7 and 1.8 are a mutter update to fix the
> Korean input bug (https://bugzilla.redhat.com/show_bug.cgi?id=1688082
> ), a python-nudatas / mu update to try and fix compose of the Python
> Classroom image, and a qemu update to fix a crasher bug that we decided to
> accept as a blocker at the blocker review meeting yesterday:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1692323
>
> so, bearing in mind those changes, the priorities for Beta-1.8 testing
> should be basic "smoke tests" - especially the 'default boot and
> install' tests, GNOME testing, and checking Firefox to make sure the
> new version didn't break anything critical.
>
> Of course, it would be great to fill out as many validation tests as we
> can, but those are the key areas.
>
> At present no known blockers are outstanding, so 1.8 is on track for
> release as the Beta; of course if you *do* find something that looks
> like a blocker bug, please nominate it!
>
> The Go/No-Go meeting will be on Thursday, when we will decide whether
> to ship Beta or not, so please help to get as much testing done as
> possible before then.
>
> Thanks folks!
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
>


-- 

Best regards / S pozdravem,

František Zatloukal
Quality Engineer
Red Hat
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Fedora Upgrade - release criteria update proposal

[Frantisek Zatloukal]

On Mon, Nov 19, 2018 at 6:43 AM Kevin Kofler  wrote:

> If you follow exactly this procedure, the set of "the multilib packages
> installed before" will be empty and you will not reproduce the issue at
> hand. Multilib cruft has not been installed by default for years now! (And
> that is a good thing! Pure 64-bit just works.)


Yeah, of course, the "Verify that upgrade and update went fine and that the
multilib packages installed before are still present" should have been in
the later paragraph.

>
On Mon, Nov 19, 2018 at 2:06 AM Adam Williamson 
wrote:

> I don't think the bug had anything to do with upgrades, did it? AIUI it
> would also affect a fresh F29 install to which multilib packages had
> been added.


I've got an impression from all the rant around that on the internet that
it happened just on upgraded systems. But it makes sense to also affect
clean installs.
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Fedora Upgrade - release criteria update proposal

[Frantisek Zatloukal]

We have encountered a bug[0] which seemingly “broke” offline updates after
systems were upgraded from an older Fedora to Fedora 29 and had some
multilib packages installed. After the discussion at last week's Release
Retrospective meeting, I am proposing some changes to our blocking
criterions in order to address similar issues in the future:

What we test now

We are currently blocking on upgrading from Fedora n-1 and n-2 releases
only with default package set installed.

What we can test

We can alter our upgrade test cases to also verify that updates after an
upgrade work. The test case might look like this:

   -

   Install Fedora n-1
   -

   Upgrade to Fedora n (updates-testing disabled)
   -

   Enable updates-testing
   -

   Update to latest packages
   -

   Verify that upgrade and update went fine and that the multilib packages
   installed before are still present


Apart from that, we can add (Final Blocking) test case
upgrade_dnf_current_workstation_multilib /
upgrade_dnf_current_minimal_multilib which will test upgrades (and then
updates as described above) with at least one i686 package installed on
x86_64 system. The other (less-generic, but closer to what users probably
do have on their systems) approach would be to test upgrade with steam (or
wine) installed.


What are our opinions about this?

[0] https://bugzilla.redhat.com/show_bug.cgi?id=1642796
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Unusable dnf after dnf system-upgrade to F29

[Frantisek Zatloukal]

>
> Can you try to delete this file?
> /var/lib/dnf/history.sqlite
>

Maybe try to backup that file first, it might be useful for tracking down
and fixing that bug.

On Sun, Sep 30, 2018 at 5:20 PM Alessio Ciregia  wrote:

> On Sun, Sep 30, 2018, 1:55 PM Ankur Sinha  wrote:
>
>> Hiya,
>>
>> I upgraded to F29 via dnf last evening and it went off without a hitch.
>> However, now dnf is unusable. Each time I try to run it, I get this:
>>
>
> Can you try to delete this file?
> /var/lib/dnf/history.sqlite
>
>
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
>


-- 

Best regards / S pozdravem,

František Zatloukal
Associate Quality Engineer
Red Hat
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Slow display manager on Fedora 29 Workstation - am I the only one who's seeing this?

[Frantisek Zatloukal]

What version of selinux-policy do you have? Make sure it's at
least selinux-policy-3.14.2-34.fc29.

Dne pá 14. 9. 2018 8:03 uživatel Aleksandar Kurtakov 
napsal:

>
> On Fri, Sep 14, 2018 at 8:25 AM, M. Edward (Ed) Borasky 
> wrote:
>
>> I've got a workstation that I'm testing with Fedora 29 Workstation. I
>> installed it over the network using the "everything boot" network
>> installer. Relative to other Linux systems, including Silverblue 28,
>> the system takes a long time to display the GDM greeter, and once I
>> log in, it takes a long time to come up with a desktop.
>>
>> This machine has an AMD "Bonaire" GPU and I've had plenty of kernel
>> and Wayland / X issues with it over the years, so my first guess is
>> that this is kernel / GPU related and not something everyone is
>> seeing. But before I go collecting log files I'm curious if other
>> people are seeing this.
>>
>
> I experience this kind of slowness too (Intel).
>
>
>>
>> --
>>
>> Markovs of the world, unite! You have nothing to lose but your chains!
>> ___
>> test mailing list -- test@lists.fedoraproject.org
>> To unsubscribe send an email to test-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
>>
>
>
>
> --
> Alexander Kurtakov
> Red Hat Eclipse Team
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
>
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

GNOME: log in not possible/crash after update/upgrade

[Frantisek Zatloukal]

Hi,
today, I've updated my fedora (from 2018-04-17, with updates-testing).
After reboot, I wasn't able to log in (session just crashed right after
typing my password). The bug is already reported in BZ:
https://bugzilla.redhat.com/show_bug.cgi?id=1573683

The reason of crash and actual fix for it is pretty weird:
may 02 13:34:48 fanys-laptop gnome-session[1246]:
gnome-session-binary[1246]: WARNING: Application
'org.gnome.SettingsDaemon.XSettings.desktop' killed by signal 5
may 02 13:34:48 fanys-laptop gnome-session-binary[1246]: WARNING:
Application 'org.gnome.SettingsDaemon.XSettings.desktop' killed by signal 5
may 02 13:34:48 fanys-laptop gsd-xsettings[1960]: Settings schema
'org.cinnamon.desktop.a11y.applications' is not installed
may 02 13:34:48 fanys-laptop systemd-coredump[1941]: Process 1798
(gsd-xsettings) of user 42 dumped core.
(stack trace [1])


In order to fix this, I had to install cinnamon-desktop. After this, I was
able to log in, both into Wayland an Xorg session. I never had
cinnamon-desktop (or any other cinnamon package) installed on my PC. This
fix worked at least on one another computer. I am currently unable to
reproduce the issue.


[0] https://bugzilla.redhat.com/attachment.cgi?id=1430226 (log from dnf
update)
[1] https://bugzilla.redhat.com/attachment.cgi?id=1430225
-- 

Best regards / S pozdravem,

František Zatloukal
Associate Quality Engineer
Red Hat
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org

Call for testing - auto-suspend on Live Media

[Frantisek Zatloukal]

Hi,
as you probably know, beginning with Fedora Workstation 28, auto-suspend
will be enabled by default. This affects also live media.

In our testing, some configurations were unable to resume after being
suspended from live media[0]. I'd like to ask you to do some more testing,
so we'll have more data from different hardware combinations about how many
desktops are not able to resume properly.

You can change suspend timer value (default is 20 minutes) to something
lower for easier testing:
*dconf write
/org/gnome/settings-daemon/plugins/power/sleep-inactive-ac-timeout 10*

(the number at the end is how many seconds of idling is required to trigger
suspend)

You can use Beta iso for testing, available here:
https://kojipkgs.fedoraproject.org/compose/28/Fedora-28-20180328.1/compose/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-28_Beta-1.3.iso

You can post results here.

Thanks!

[0] https://bugzilla.redhat.com/show_bug.cgi?id=1555292

-- 

Best regards / S pozdravem,

František Zatloukal
Associate Quality Engineer
Red Hat
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org

Re: Not able to install Fed28: Secure Boot Violation

[Frantisek Zatloukal]

Hi,
the issue is already reported (although, I didn't check the clean install,
just an upgrade, but I believe it is the same problem).

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

On Fri, Mar 16, 2018 at 5:46 PM, AV  wrote:

> This applies to an ASUS Zenbook with Fed27 installed using
> UEFI + Secure Boot (working without problems).
>
> I downloaded
> Fedora-Workstation-netinstall-x86_64-28-20180313.n.0.iso
> and wanted to install it on the Zenbook (wiping Fed27) but enountered
> this:
>
> Secure Boot Violation
> Invalid Signature Detected
> Check Secure Boot Policy Setup
>
> Is this a temporary snafu or should I report a bug?
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@lists.fedoraproject.org
>



-- 

Best regards / S pozdravem,

František Zatloukal
Associate Quality Engineer
Red Hat
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org

Introduction: František Zatloukal

[Frantisek Zatloukal]

Hi,
I am new member in Fedora QA. I've been involved in Fedora since ~2013 and
I became Fedora Ambassador in 2015.

Feel free to contact me on IRC (freenode/fedora-qa): frantisekz ; I am in
Brno (CET) time zone.

I am looking forward to make using Fedora better and more pleasant
experience for its users :)

-- 

Best regards / S pozdravem,

František Zatloukal
Associate Quality Engineer
Red Hat
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org