RE: Introduction Amanda Cavalcante

[Amanda dos Santos Cavalcante]

I want to join the QA team and help.


De: Robbi Nespu 
Enviado: terça-feira, 19 de janeiro de 2021 23:08
Para: test@lists.fedoraproject.org 
Assunto: Re: Introduction Amanda Cavalcante



On 20/1/2021 9:26 am, Amanda dos Santos Cavalcante wrote:
> Hello, Fedora Project people !!!
>
> I am very happy to join the Fedora team !!!
> I'm a beginner in the Linux universe and I'm very excited to help.
> I have only 6 months of experience in Linux, but I want to enjoy it for
> the rest of my life.
>
> My name is Amanda dos Santos Cavalcante, I am 34 years old, I live in
> Recife-PE, Brazil.
> As I started to use a computer, around 2007, I always used Windows.
> Linux here in Brazil is still very wronged.
> It was in 2018 that I started flirting with Linux through YouTuber
> Diolinux. But only in 2020 did I have direct contact with Linux.
>
> My first contact with Linux was EndlessOS when I bought a notebook that
> came with the system by default. But I found it very limited for my
> profile and installed Mint 20 Cinnamon. I was using Mint for 3 months
> and then came to Fedora Mate 33.
>
> I am in love with Fedora Mate 33 because it is teaching me to understand
> much more about Linux !!!
> So I want to be able to help in whatever I can.
> I hope to be useful so that the Fedora Project can be stronger and
> stronger !!!
>
> Fas account: amandacavalcante
> Telegram: @Amandextra
> Emails: amanda_kid...@hotmail.com
> cavalcante...@gmail.com

Welcome to Fedora, this is testing (QA) mailing list so people here
expect you interested to do testing. You can check here[1] for information.

If you want to test new package, you can install testing repo[2] and
give feedback on Bodhi if you encounter bug or nobug by giving karma.

Warning: If it maybe breaking you system and IMO, I think new linux
don't like it..but to me, this is fun. You can learn and contribute at
the same time.

Since you are using Fedora Mate Compiz, you can report bug if you
encounter. I am sorry, I could find Fedora Mate Compiz SIG or it own
mail list. Maybe someone else can show where it hide :)

If you think you are in wrong mail list, then check[4]. It can guide you
which area you like to contribute.

[1] 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FQAdata=04%7C01%7C%7Cd1ba3337455b4129c60908d8bce8498f%7C84df9e7fe9f640afb435%7C1%7C0%7C637467053134746387%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=U17oENAVnvmdslVe2ZVvt%2BD%2B6RVpTBGvDc8KstohJj4%3Dreserved=0
[2] 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FQA%3AUpdates_Testingdata=04%7C01%7C%7Cd1ba3337455b4129c60908d8bce8498f%7C84df9e7fe9f640afb435%7C1%7C0%7C637467053134756341%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=fBVFvJUGIUYZmjBj9SmpuW5j1wjG4feHKM06k9S43mM%3Dreserved=0
[3] 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbodhi.fedoraproject.org%2Fdata=04%7C01%7C%7Cd1ba3337455b4129c60908d8bce8498f%7C84df9e7fe9f640afb435%7C1%7C0%7C637467053134756341%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=65KLkWHSq1vguoAgWSOiJTmaM2c7sutLvJODXp3RSJk%3Dreserved=0
[4] 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatcanidoforfedora.org%2Fendata=04%7C01%7C%7Cd1ba3337455b4129c60908d8bce8498f%7C84df9e7fe9f640afb435%7C1%7C0%7C637467053134756341%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=SQxi%2BwMx9pYNdBeK4IeWl4UyOLzWI2iR9PmZo%2FKjQl8%3Dreserved=0

--
Email: robbinespu[@]fedoraproject[.]org
PGP fingerprint : D311 B5FF EEE6 0BE8 9C91 FA9E 0C81 FA30 3B3A 80BA
PGP key: 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkeybase.io%2Frobbinespu%2Fpgp_keys.ascdata=04%7C01%7C%7Cd1ba3337455b4129c60908d8bce8498f%7C84df9e7fe9f640afb435%7C1%7C0%7C637467053134756341%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=h4sATLUHf5SHnE7PlLmDENaOf3ZTbLr7dIsCtQt4P8U%3Dreserved=0
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: [External] Re: Respins for OEM preloads

[Mark Pearson]

Hi Chris

On 20/01/2021 17:06, Chris Murphy wrote:
> On Tue, Jan 19, 2021 at 10:43 AM Mark Pearson  wrote:
>>
>>
>> Some background: We need the latest kernel/alsa/pulse/libfprint and
>> their dependencies for supporting the new 2021 HW - and as we'll be
>> (hopefully) releasing before F34 is available we're looking for
>> F33+updates and the best way to provide that in a way that works for the
>> community and our preload process.
> 
> We need to coordinate a shim update, one that's signed with new world
> keys (post-BootHole) which doesn't yet exist.
> 
> Specifically, if the new hardware will come with UEFI Secure Boot
> enabled, it will need a preloaded image containing either pre-BootHole
> revocation database. Shim needs to be updated before the revocation
> database or the system will not boot.
> 
> If this preload image is also going to form the basis for a recovery
> partition, this is a bigger concern because it'd be rendered
> unbootable once the revocation database is pushed. Fedora hasn't
> decided to push the revocation database automatically, but other
> distros do so aggressively. Microsoft has thus far delayed pushing the
> post-BootHole revocation db, but eventually they will sometime this
> year.
> 
> 
We still have secure boot disabled by default for Linux systems - it's
something I want to turn on but every time we look at it there are a few
headaches and there's some process in manufacturing too to resolve and
it just never quite makes it high enough in the list to become a priority.

I'm not going to get that solved for this round so I don't think it has
to block this effort. Something I'm happy to look at for platforms later
in the year with F34/F35?

Let me know if I'm missing something important.

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

Re: Respins for OEM preloads

[Chris Murphy]

On Tue, Jan 19, 2021 at 10:43 AM Mark Pearson  wrote:
>
>
> Some background: We need the latest kernel/alsa/pulse/libfprint and
> their dependencies for supporting the new 2021 HW - and as we'll be
> (hopefully) releasing before F34 is available we're looking for
> F33+updates and the best way to provide that in a way that works for the
> community and our preload process.

We need to coordinate a shim update, one that's signed with new world
keys (post-BootHole) which doesn't yet exist.

Specifically, if the new hardware will come with UEFI Secure Boot
enabled, it will need a preloaded image containing either pre-BootHole
revocation database. Shim needs to be updated before the revocation
database or the system will not boot.

If this preload image is also going to form the basis for a recovery
partition, this is a bigger concern because it'd be rendered
unbootable once the revocation database is pushed. Fedora hasn't
decided to push the revocation database automatically, but other
distros do so aggressively. Microsoft has thus far delayed pushing the
post-BootHole revocation db, but eventually they will sometime this
year.


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

Re: [fedora-arm] Enabled some openQA desktop tests on aarch64

[Adam Williamson]

On Tue, 2021-01-19 at 23:30 +, Peter Robinson wrote:
> Hey Adam,
> 
> Sorry for the delayed reply here. I wanted to reply properly, then it
> got lost in my inbox.
> 
> > Hey folks! Just a heads up that I merged a branch I've had lying around
> > for weeks that enables *some* of the openQA desktop tests on the
> > aarch64 Workstation image.
> 
> Thanks for this, it's really awesome!
> 
> > I left out some with known issues. desktop_notifications_postinstall
> > needs to boot to runlevel 3, which is actually a bit tricky because of
> > UEFI - we don't get the boot menu with a usable timeout and the trick
> > we use to work around that on x86_64 (where we run the tests on BIOS)
> > doesn't work on UEFI because the setting is in the UEFI vars which are
> > not part of the main disk image.
> 
> Can you use "efibootmgr --timeout XX" to set a usable timeout at some
> point during the process?

Well...

> > To fix this I think I need to have the 'image deploy' test upload its
> > UEFI vars disk image and have the desktop_notifications_postinstall
> > test attach that as well as the main disk image, but I need to look
> > into the ins and outs of that a bit and this is my last work day of the
> > year, so I'll do it next year.

...IIRC (I didn't refresh my memory on this since the shutdown) we can
set it "at some point in the process", but that point is during the
"image deploy" test...but it gets written *to the efi vars storage*, I
believe, and we don't currently hand that off from the "image deploy"
test to the other tests that follow it. We hand off the *main 'system
disk' image*, which for BIOS boot includes the boot manager config, but
we've just never set things up so the EFI var storage gets stashed by
the "image deploy" test and reused by subsequent tests. So we can set
it, sure, but the setting effectively gets "lost" between being set and
the point where we'd actually need it.

Now I've been reminded of this, I'll try and get back to it soon...I've
said that about five things already this week...sigh.

> > The desktop_login test is generally fragile (things tending to get
> > stuck or time out), but if it gets that far, it *always* fails when it
> > tests locking the screen; on aarch64 this seems to cause the VM to
> > permanently stop updating the display, or something. Again I haven't
> > had time to look into this, and I want to enable the other tests
> > without waiting for it.
> 
> Huh, weird, I would have thought given it's basically the same driver
> stack it would have been closest here.

Yeah, it's odd for sure. Again haven't found the roundtuits to look
into it further yet.

> > The desktop_browser test is also failing, but I left that in because
> > it's not a test bug, it's a distro bug. Firefox builds have just been
> > disabled on aarch64 since 2020-11-20, so current composes don't have
> > Firefox in them on aarch64 at all. There's a bug related to this:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1897675
> > which I just gave a bit of a bump, because it shouldn't really be
> > acceptable to just turn off our default browser's build on one of our
> > primary arches for weeks at a time :(
> 
> That's been an ongoing issue with the firefox maintenance for years sadly :(

Yeah, we'll just have to keep asking mstransky not to turn off aarch64
:(

> > This also breaks several of the other tests which use Firefox, like the
> > Cockpit and FreeIPA browser tests.
> > 
> > The tests should run on openQA prod from the next compose. The branch
> > has been deployed on openQA lab (staging) for weeks (including the
> > broken tests), so you can see how it's been behaving there.
> 
> How are they generally after a few weeks running?

Good question! Rawhide's a bit flaky in general ATM, but the answer
seems to be..."a bit flaky" :) I'm seeing quite a few failures that are
likely performance-related; here are the ones from yesterday for
instance:

https://openqa.fedoraproject.org/tests/758486 - desktop_terminal,
failed because root auth failed, likely a dropped keystroke
https://openqa.fedoraproject.org/tests/758487 -
desktop_update_graphical , system seems to have crashed after updates
were installed and system rebooted, not sure about that one; i'm
rerunning it
https://openqa.fedoraproject.org/tests/758485 - desktop_browser , seems
like when openQA "saw" the "addon_add" needle the browser was actually
kinda lagging a bit, and so openQA's click probably got eaten

I'll try and throw in some mitigations, but all we can really do is
slow the tests down - make them wait after matching needles, make them
type slower and slower - and you know how that can snowball. One thing
I'll be interested to see is whether the tests get less flaky after we
switch away from debug kernels for F34; IIRC Justin was thinking about
getting away from debug kernels entirely, so if that happens and they
are an issue here, it might help in future.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha

Re: [External] Re: Respins for OEM preloads

[Mark Pearson]

On 20/01/2021 15:30, Adam Williamson wrote:
> On Wed, 2021-01-20 at 17:11 +0100, Kamil Paral wrote:
>> On Tue, Jan 19, 2021 at 6:44 PM Mark Pearson  wrote:
>>
>>> Release cadence is once. We just can't update our preload images that
>>> often - there's a long test cycle, and energy certification that goes
>>> with that image. It's one of the reasons the X1C8 is still shipping with
>>> Fedora32, and P1G3 and P15 (soon!) will be with F33 for a long time. The
>>> only reason to update would be a critical bug that couldn't be fixed
>>> with an update once the platform was received.
>>>
>>
>> If the cadence is once in a long time (related to new hardware
>> introductions, so possibly once a year or similar), I think the best
>> approach here is to have releng manually trigger an F33 Workstation Live
>> image compose using the current updates repo. Assuming it's not a problem
>> for them. We (the QA) can then trigger an OpenQA test run on it, create the
>> release validation test matrices for it, and even ask the community in
>> large to perform some manual tests if they have time. I believe some of us
>> would devote some time to make sure at least the basics work correctly. I'm
>> not sure if all the plumbing for this one-off compose is ready (in fedfind,
>> relval, openqa and wherever else needed), but Adam will know more.
> 
> Yeah, I don't think that should be really tricky for anyone. I'd
> suggest we just run it as a post-release nightly compose rather than a
> candidate and don't give it any kind of label. I don't think it should
> be hard for releng to run that, and I should be able to run openQA
> tests and even create a validation event if necessary, I might need to
> metaphorically whang a few things with a hammer because it won't quite
> fit the normal flows but it shouldn't be a big deal.
> 
That would be awesome and very much appreciated :) Let me know anything
we can do to help

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

Re: Respins for OEM preloads

[Adam Williamson]

On Wed, 2021-01-20 at 17:11 +0100, Kamil Paral wrote:
> On Tue, Jan 19, 2021 at 6:44 PM Mark Pearson  wrote:
> 
> > Release cadence is once. We just can't update our preload images that
> > often - there's a long test cycle, and energy certification that goes
> > with that image. It's one of the reasons the X1C8 is still shipping with
> > Fedora32, and P1G3 and P15 (soon!) will be with F33 for a long time. The
> > only reason to update would be a critical bug that couldn't be fixed
> > with an update once the platform was received.
> > 
> 
> If the cadence is once in a long time (related to new hardware
> introductions, so possibly once a year or similar), I think the best
> approach here is to have releng manually trigger an F33 Workstation Live
> image compose using the current updates repo. Assuming it's not a problem
> for them. We (the QA) can then trigger an OpenQA test run on it, create the
> release validation test matrices for it, and even ask the community in
> large to perform some manual tests if they have time. I believe some of us
> would devote some time to make sure at least the basics work correctly. I'm
> not sure if all the plumbing for this one-off compose is ready (in fedfind,
> relval, openqa and wherever else needed), but Adam will know more.

Yeah, I don't think that should be really tricky for anyone. I'd
suggest we just run it as a post-release nightly compose rather than a
candidate and don't give it any kind of label. I don't think it should
be hard for releng to run that, and I should be able to run openQA
tests and even create a validation event if necessary, I might need to
metaphorically whang a few things with a hammer because it won't quite
fit the normal flows but it shouldn't be a big deal.

Also, I forgot to mention it'll obviously be completely impossible for
this to work without Lenovo shipping me some hardware for,
uh...testing. Yup. That's definitely non-negotiable. Two of everything.
:D
-- 
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

Re: Proposal to Modify: Testcase dualboot with macOS

[Chris Murphy]

On Wed, Jan 20, 2021 at 1:45 AM Frantisek Zatloukal  wrote:
>
> 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.

Correct
https://pagure.io/fedora-infrastructure/issue/7902#comment-606878

Therefore I create USB sticks via other means.

I think there is a workaround Fedora could employ in the FMW signing
process, but my recollection is it's a PITA and not really worth the
effort, despite a bunch of hardware being abandoned to 10.13. I have a
2011 MacBook Pro that's also stuck on 10.13.



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

Re: Fedora Audio Test Cases for Test Day (a proposal)

[Garry T. Williams]

On Wednesday, January 20, 2021 11:01:59 AM EST Brandon Nielsen wrote:
> Would some kind of device switching test case be feasible? In my 
> experience that's where a lot of weird behavior creeps in. For example, 
> plugging in a USB interface, using it, and unplugging it.

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

-- 
Garry T. Williams


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

Re: [External] Re: Respins for OEM preloads

[Mark Pearson]

On 20/01/2021 13:05, Neal Gompa wrote:
> On Wed, Jan 20, 2021 at 1:04 PM Mark Pearson 
> wrote:
>> 
>> 
>> 
>> As Matthew mentioned - 5.10.8 is coming out soon and whether that
>> ties into this too? Any recommendations from the community as to
>> which fixes are important etc happy to take on board. The HW
>> testing we've done so far looks good - but that's not the whole
>> story.
>> 
> 
> While there are hardware fixes, the main reason for 5.10.8 being 
> important is that the Btrfs performance regression introduced in 
> 5.10.0 was fixed in that release. With this release, Btrfs I/O 
> performance is at least 50% higher than 5.9 across virtually all 
> workloads.
> 
Nice! Looks like it's already landed in stable (and it's now running on
my P15...)

Picking that up sounds good to me

Mark
___
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: Strange performance on Rawhide this morning (UTC+1)

[Samuel Sieb]

On 1/20/21 3:00 AM, Onyeibo Oku wrote:


After powering down my box to change power source, I attempted to boot
again.  I noticed that the process hangs after selecting Kernel.  For a
moment, I couldn't boot.


If you run into this again, try removing "quiet rhgb" from the kernel 
boot command line to maybe see what's happening.  Also, try pressing 
some keys, there was a mention recently about the random generator 
having some difficulty at boot.



Then I chose the test kernel (5.10.5-200.fc33.x86_64) and it went well.
  I figured the kernel was the culprit so I ran an update.  I got the
  following:

Cleanup : btrfs-progs-5.9-1.fc34.x86_64 265/266
Cleanup : SDL2-2.0.12-4.fc33.x86_64 266/266
Running scriptlet: kernel-core-5.11.0-0.rc4.129.fc34.x86_64 266/266

sort: fflush failed: 'standard output': Broken pipe sort: write error
gzip: stdout: Broken pipe
gzip: stdout: Broken pipe
sort: write failed: 'standard output': Broken pipe
sort: write error


This is a known issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1911038

It looks bad, but doesn't cause any harm.
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: [External] Re: Respins for OEM preloads

[Neal Gompa]

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

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



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

Re: [External] Re: Respins for OEM preloads

[Mark Pearson]

On 20/01/2021 11:11, Kamil Paral wrote:
> On Tue, Jan 19, 2021 at 6:44 PM Mark Pearson  > wrote:
> 
> Release cadence is once. We just can't update our preload images that
> often - there's a long test cycle, and energy certification that goes
> with that image. It's one of the reasons the X1C8 is still shipping with
> Fedora32, and P1G3 and P15 (soon!) will be with F33 for a long time. The
> only reason to update would be a critical bug that couldn't be fixed
> with an update once the platform was received.
> 
> 
> If the cadence is once in a long time (related to new hardware
> introductions, so possibly once a year or similar), I think the best
> approach here is to have releng manually trigger an F33 Workstation Live
> image compose using the current updates repo. Assuming it's not a
> problem for them. We (the QA) can then trigger an OpenQA test run on it,
> create the release validation test matrices for it, and even ask the
> community in large to perform some manual tests if they have time. I
> believe some of us would devote some time to make sure at least the
> basics work correctly. I'm not sure if all the plumbing for this one-off
> compose is ready (in fedfind, relval, openqa and wherever else needed),
> but Adam will know more.
> 
> I don't want to just repeat Adam's words, but I'd like to stress out
> that from the security perspective, such a compose should really be
> created using the proper Fedora Infra tooling (or Lenovo itself using
> official Fedora bits). I don't want to belittle the people standing
> behind the unofficial Live respins, they are doing a great and useful
> work, but if this is going to be shipped preinstalled to thousands of
> customers, the whole process should be as verifiable as with our
> official releases.
> 

Thanks Kamil,

My preference would be to have a build that comes from Fedora with
Fedora's blessing rather than something we put together :) Partly so we
don't screw it up but also as part of the "we don't mess with the Fedora
image" thing - if we get the image from you then it reinforces that.

I know our timelines right now are quite tight - I'd like to get the
image into test before Chinese New Year happens - though I'm looking at
the calendar and wondering how optimistic I'm being How big a deal
is creating an official compose? Is it days/weeks/months? At the moment
I'd like it by start of Feb (with a bit of wriggle room)

As Matthew mentioned - 5.10.8 is coming out soon and whether that ties
into this too? Any recommendations from the community as to which fixes
are important etc happy to take on board. The HW testing we've done so
far looks good - but that's not the whole story.

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

Re: Fedora Audio Test Cases for Test Day (a proposal)

[Kamil Paral]

On Wed, Jan 20, 2021 at 5:02 PM Brandon Nielsen 
wrote:

> Would some kind of device switching test case be feasible? In my
> experience that's where a lot of weird behavior creeps in. For example,
> plugging in a USB interface, using it, and unplugging it. Or switching back
> and forth between Bluetooth and wired hardware (or even changing Bluetooth
> headset mode back and forth between A2DP / HFP).
>

This is a great idea, I love it! Most of us now have at least two output
devices - the usual jack output and a display connected over DP/HDMI. Not
all monitors have integrated speakers, but some have a jack connector you
can connect your headphones in. And that's exactly how I use it - speakers
connected to my desktop's output jack, and headphones connected to my
monitor, which allows me to switch between speakers and headphones in a
pure software way, without replugging connectors all the time. Sometimes it
causes some issues. This would be a great test case with Pipewire.

And as suggested by Brandon, other devices like USB headphones or Bluetooth
headphones are probably even more common than my own use case. Let's cover
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

Re: Respins for OEM preloads

[Kamil Paral]

On Tue, Jan 19, 2021 at 6:44 PM Mark Pearson  wrote:

> Release cadence is once. We just can't update our preload images that
> often - there's a long test cycle, and energy certification that goes
> with that image. It's one of the reasons the X1C8 is still shipping with
> Fedora32, and P1G3 and P15 (soon!) will be with F33 for a long time. The
> only reason to update would be a critical bug that couldn't be fixed
> with an update once the platform was received.
>

If the cadence is once in a long time (related to new hardware
introductions, so possibly once a year or similar), I think the best
approach here is to have releng manually trigger an F33 Workstation Live
image compose using the current updates repo. Assuming it's not a problem
for them. We (the QA) can then trigger an OpenQA test run on it, create the
release validation test matrices for it, and even ask the community in
large to perform some manual tests if they have time. I believe some of us
would devote some time to make sure at least the basics work correctly. I'm
not sure if all the plumbing for this one-off compose is ready (in fedfind,
relval, openqa and wherever else needed), but Adam will know more.

I don't want to just repeat Adam's words, but I'd like to stress out that
from the security perspective, such a compose should really be created
using the proper Fedora Infra tooling (or Lenovo itself using official
Fedora bits). I don't want to belittle the people standing behind the
unofficial Live respins, they are doing a great and useful work, but if
this is going to be shipped preinstalled to thousands of customers, the
whole process should be as verifiable as with our official releases.
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Fedora Audio Test Cases for Test Day (a proposal)

[Brandon Nielsen]

On 1/20/21 6:56 AM, Kamil Paral wrote:
On Tue, Jan 19, 2021 at 2:26 PM Lukas Ruzicka > wrote:


Hello friends of Fedora,

the following is a proposal for the test scope of PipeWire audio
in Fedora, which could be tested as part of Fedora Audio Test
Days. Please let me know what you think about it.
Particular test cases have not been developed yet, but as soon as
I have the idea what is actually desired for testing, I will
develop them and prepare them as a material for test days.

Thanks for cooperation,
Lukas





  Test Cases for Test Days (proposal)


Description

The following is a proposal for test cases that could be tested as
a part of a Fedora Audio Test Day.


Possible test cases

1.

*PipeWire is used by default.* This test case should test that
audio is controlled by PipeWire by default.

2.

*There are GUI and CLI tools to control sound available to the
user*. This test case tests that sound production can be
controlled using different tools.

3.

*Sound can be played back from all applications* – this test
case tests that any audio application installable from Fedora
repositories with a proper setup must produce audible sounds
of expected quality using the selected hardware. This will
cover the majority of JACK or ALSA based applications.

4.

*Sound can be recorded in all applications* – this test case
tests that any audio application installable from Fedora
repositories is able to record sound from the external sources
in expected quality. This will also affect default
applications, such as Firefox, that is used for conferencing
and the ability to receive sound is crucial for this use case.

5.

*Dedicated hardware can be used to produce or record audio* –
any dedicated audio hardware, especially soundcards, must play
audible sounds of expected quality, as well as record them, if
they have been successfully recognized by the operating system.

6.

*MIDI capable hardware communicates with the MIDI capable
applications* – if the MIDI capable hardware is properly
recognized by the system, it must be able to communicate with
an application. However, it should not ever be required that
the application understands that communication fully and
without issues.



I'm not a sound expert, but the list looks reasonable.


Would some kind of device switching test case be feasible? In my 
experience that's where a lot of weird behavior creeps in. For example, 
plugging in a USB interface, using it, and unplugging it. Or switching 
back and forth between Bluetooth and wired hardware (or even changing 
Bluetooth headset mode back and forth between A2DP / HFP).
___
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

[Kamil Paral]

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

> On Tue, Jan 19, 2021 at 12:55 PM Geoffrey Marr  wrote:
> >
> > 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.
>
> 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.
>

Note that we're not talking about adjusting blocking decisions, this is
just a testcase. The current release criterion is here and doesn't specify
any exact versions:
https://fedoraproject.org/wiki/Fedora_34_Final_Release_Criteria#OS_X_dual_boot


>
> > 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.
>
> Yep. I expect there's some bootloader and kernel work before
> Workstation aarch64 is ready and reliable on M1 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.
>
> No objections.
>
> Lurking around, I think kparal knows where it is, there's a write up I
> did about 4 years ago on how to get an "out of the box" setup on macOS
> without having to do a clean install.


I guess it's available as a document on our team's external hard-drive
which we use(d) for macOS re-provisioning. And that hard-drive is probably
in a locker in our currently inaccessible RH office. Or perhaps Lukas
Brabec or Frantisek Zatloukal have it in their home.


> That is obsolete. It's based on
> Core Storage (Apple's logical volume manager), whereas since then
> Apple has abandoned that entire scheme in favor of a new file system,
> APFS, that integrates a volume manager. That write up is probably
> easily adapted for APFS - the use case is to get an exact
> out-of-the-box setup for back to back test installs without having to
> clean install macOS. If it's useful, I can help with a refresh.
>

I don't currently need those updated instructions, neither does Lukas
Brabec (who usually run dual-boot tests on our Mac Mini), I believe,
because our Mac Mini is old and still has the old macOS. If Geoff or anyone
else wants to see the updated instructions, we can try to retrieve that
document (perhaps I have it stored also elsewhere, I'd have to look),
update it, and store it online somewhere on our wiki.
___
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

[Kamil Paral]

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

I have no objections to that testcase change. Listing macOS versions which
the testcase has been validated to work with is a good thing. Thanks for
your work.


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

Sure, good idea.


>
> I have made these changes as I see them to my own wiki page [1]. Please
> review the page and propose any suggestions here.
>

To make the review more comfortable next time,  please first copy the
existing testcase contents to your personal space and save it *intact*, and
only *then* start making changes in followup edits. That way it's easy to
use the wiki history function to see a diff of what exactly changed.
(Currently I have to compare two web pages side by side just with my eyes,
and that's a nuisance;) ). 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

Re: Fedora Audio Test Cases for Test Day (a proposal)

[Kamil Paral]

On Tue, Jan 19, 2021 at 2:26 PM Lukas Ruzicka  wrote:

> Hello friends of Fedora,
>
> the following is a proposal for the test scope of PipeWire audio in
> Fedora, which could be tested as part of Fedora Audio Test Days. Please let
> me know what you think about it.
> Particular test cases have not been developed yet, but as soon as I have
> the idea what is actually desired for testing, I will develop them and
> prepare them as a material for test days.
>
> Thanks for cooperation,
> Lukas
>
>
> 
> Test Cases for Test Days (proposal) Description
>
> The following is a proposal for test cases that could be tested as a part
> of a Fedora Audio Test Day.
> Possible test cases
>
>1.
>
>*PipeWire is used by default.* This test case should test that audio
>is controlled by PipeWire by default.
>2.
>
>*There are GUI and CLI tools to control sound available to the user*.
>This test case tests that sound production can be controlled using
>different tools.
>3.
>
>*Sound can be played back from all applications* – this test case
>tests that any audio application installable from Fedora repositories with
>a proper setup must produce audible sounds of expected quality using the
>selected hardware. This will cover the majority of JACK or ALSA based
>applications.
>4.
>
>*Sound can be recorded in all applications* – this test case tests
>that any audio application installable from Fedora repositories is able to
>record sound from the external sources in expected quality. This will also
>affect default applications, such as Firefox, that is used for conferencing
>and the ability to receive sound is crucial for this use case.
>5.
>
>*Dedicated hardware can be used to produce or record audio* – any
>dedicated audio hardware, especially soundcards, must play audible sounds
>of expected quality, as well as record them, if they have been successfully
>recognized by the operating system.
>6.
>
>*MIDI capable hardware communicates with the MIDI capable applications*
>– if the MIDI capable hardware is properly recognized by the system, it
>must be able to communicate with an application. However, it should not
>ever be required that the application understands that communication fully
>and without issues.
>
>
>
I'm not a sound expert, but the list looks reasonable.
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Testcase Audio Basic - a change proposal

[Kamil Paral]

On Tue, Jan 19, 2021 at 12:50 PM Lukas Ruzicka  wrote:

> Testcase Audio Basic (change proposal) Description
>
> This test case tests whether sound can be played on Fedora.
> Prerequisites
>
>- Make sure your sound device (hardware) is correctly connected to
>your computer, so that you can expect that sound will be played, i.e. you
>have speakers (or headphones) connected to the sound output of your sound
>adapter, or a receiver connected to a *S/PDIF* output.
>- Run *Settings* (or your desktop's alternative) and navigate to the
>*Sound* tab. Check that your sound device is correctly recognized by
>the system. In case you have more sound devices, make sure all of these
>devices are listed.
>- Select a preferred device for output. If you want to use an *S/PDIF*
>connection, set the device's profile to the appropriate choice (the output
>should be *Digital Stereo (IEC958)*).
>- Shut your system down entirely, then start it up again and log in to
>the desktop.
>
> How to test
>
>- Start one of the default desktop media applications, for example
>GNOME's *Videos* or *Rhythmbox*. Alternatively, you can use any audio
>application of your choice.
>
>
I just realized the last sentence could probably go hand in hand with a
proposal to adjust the currently existing "Working sound" criterion [1]. I
think we should get rid of the "gstreamer-based" part and cover all
applications installed by default for that particular Edition. That would
make it possible to mention that e.g. testing playing a sound through your
web browser is also acceptable. Alternatively, we could get rid of that
criterion completely, and just say that playing sound correctly is a part
of "Default application functionality" criterion [2] (for multimedia apps
and browsers, at least). But we'd still have to figure out how we want to
handle Server, Cloud, etc.

[1]
https://fedoraproject.org/wiki/Fedora_34_Beta_Release_Criteria#Working_sound
[2]
https://fedoraproject.org/wiki/Fedora_34_Final_Release_Criteria#Default_application_functionality
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

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

[Kamil Paral]

On Tue, Jan 19, 2021 at 1:07 PM Lukas Ruzicka  wrote:

> Hello friends of Fedora,
>
> this is the follow up for my previous email which proposes a new test
> Desktop test case to cover basic sound recording, because we feel that we
> also should test some basic recording, especially in times when many people
> need to communicate via online tools.
> So far, recording has not been required to be tested.
>
> Please, let me know what you think about this new test.
>
>
> 
> Testcase Audio Recording Basic (test case proposal) Description
>
> This test case tests whether sound can be recorded on Fedora.
> Prerequisites
>
>- If you do not have any sound recording application installed,
>install *Gnome Sound Recorder* (the gnome-sound-recorder package).
>
>
Have you tested whether gnome-sound-recorder works well in KDE and
optionally also other desktops? If not (or if it pulls too many
dependencies), it would be good to suggest an alternative tool as well.


>
>- Make sure the input sound device is correctly connected to your
>computer, so that you can expect that sound will be recorded, i.e. you have
>a microphone (or any sound producing device) connected to the input of your
>sound adapter.
>- Run *Settings* and navigate to the *Sound* tab. Check that your
>sound device is correctly recognized by the system. In case you have more
>input sound devices, make sure all of these devices are listed.
>- Select a preferred device for input and set the input level using
>the slider and the indicator below to avoid over-excitation of the signal
>and sound distortion.
>
> How to test
>
>- Start a sound recording application.
>- Record a sound clip of about 10 seconds using the microphone (or
>another sound producing device).
>- Play back the recorded sound.
>
> Expected Results
>
>- The recorded sound clip is *correctly* recorded and can be played
>back. Note that the quality of the recording depends on many factors, such
>as the quality of the sound adapter, the microphone, the wires used, etc.
>Therefore the sound quality should not be considered a test failing
>criterion unless the quality is much worse than expected.
>
>
Except for the note above, LGTM.

Do you intend to propose a new audio recording criterion? I think it has a
reasonable chance of getting accepted.
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org

Re: Testcase Audio Basic - a change proposal

[Kamil Paral]

On Tue, Jan 19, 2021 at 12:50 PM Lukas Ruzicka  wrote:

> Hello friends of Fedora,
>
> with Fedora 34, the current audio server Pulseaudio will be (probably)
> replaced by PipeWire which will handle all system audio. Therefore we, at
> Fedora QA, believe that some adjustments should be made to how we test the
> basic audio.
> The following is a proposal to change the Testcase_audio_basic (
> https://fedoraproject.org/wiki/QA:Testcase_audio_basic) to cover the
> basic Fedora audio listening.
>
> Please, let me know what you think about it.
>
> Thanks,
> Lukas
>
>
>
> 
> Testcase Audio Basic (change proposal) Description
>
> This test case tests whether sound can be played on Fedora.
> Prerequisites
>
>- Make sure your sound device (hardware) is correctly connected to
>your computer, so that you can expect that sound will be played, i.e. you
>have speakers (or headphones) connected to the sound output of your sound
>adapter, or a receiver connected to a *S/PDIF* output.
>- Run *Settings* (or your desktop's alternative) and navigate to the
>*Sound* tab. Check that your sound device is correctly recognized by
>the system. In case you have more sound devices, make sure all of these
>devices are listed.
>- Select a preferred device for output. If you want to use an *S/PDIF*
>connection, set the device's profile to the appropriate choice (the output
>should be *Digital Stereo (IEC958)*).
>- Shut your system down entirely, then start it up again and log in to
>the desktop.
>
> How to test
>
>- Start one of the default desktop media applications, for example
>GNOME's *Videos* or *Rhythmbox*. Alternatively, you can use any audio
>application of your choice.
>- Use the selected application to play a sound file located on your
>computer. If you do not have any suitable sound files, you can download an
>example from this location (http://bit.ly/ugVihP). Make sure the sound
>file uses a supported format. The *Ogg Vorbis* is a safe choice.
>- Try to change the sound level using dedicated tools, such as panel
>applets.
>- Start another audio application and make it play a sound
>simultaneously with the first audio application.
>
> Expected Results
>
>- You can hear the sound playing over the selected sound device. You
>should not have to adjust any default volume settings in order to hear the
>sound after the computer has started.
>- When two audio applications play simultaneously, both sounds can be
>heard.
>- When you try to adjust the sound volume, it changes accordingly.
>
>
>
LGTM
___
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

Strange performance on Rawhide this morning (UTC+1)

[Onyeibo Oku]

Good morning,

After powering down my box to change power source, I attempted to boot
again.  I noticed that the process hangs after selecting Kernel.  For a
moment, I couldn't boot.

Then I chose the test kernel (5.10.5-200.fc33.x86_64) and it went well.
 I figured the kernel was the culprit so I ran an update.  I got the
 following:

Cleanup : btrfs-progs-5.9-1.fc34.x86_64 265/266
Cleanup : SDL2-2.0.12-4.fc33.x86_64 266/266
Running scriptlet: kernel-core-5.11.0-0.rc4.129.fc34.x86_64 266/266

sort: fflush failed: 'standard output': Broken pipe sort: write error
gzip: stdout: Broken pipe
gzip: stdout: Broken pipe
sort: write failed: 'standard output': Broken pipe
sort: write error

.

Huh?

Should I be worried?
Previous kernel was kernel-5.11.0-0.rc3.122.fc34.x86_64

Regards
Onyeibo
___
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: Proposal to Modify: Testcase dualboot with macOS

[Lukas Ruzicka]

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

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

Yeah, seems reasonable to me, but I also see the point in Chris's remark to
limit the scope to the two last versions of MacOS.


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

+1


>
> 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 testcase looks good to me. Thanks.



> Geoff Marr
> IRC: coremodule
>
> [0] https://fedoraproject.org/wiki/QA:Testcase_dualboot_with_macOS
> [1]
> https://fedoraproject.org/wiki/Coremodule/QA:Testcase_dualboot_with_macOS
> ___
> 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
>


-- 

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