Release criteria proposal: networking requirements
by Adam Williamson
Hi folks!
So at this week's blocker review meeting, the fact that we don't have
explicit networking requirements in the release criteria really started
to bite us. In the past we have squeezed networking-related issues in
under other criteria, but for some issues that's really difficult,
notably VPN issues. So, we agreed we should draft some explicit
networking criteria.
This turns out to be a big area and quite hard to cover (who'd've
thought!), but here is at least a first draft for us to start from. My
proposal would be to add this to the Basic criteria. I have left out
some wikitext stuff from the proposal for clarity; I'd add it back in
on actually applying the proposed changes. It's just formatting stuff,
nothing that'd change the meaning. Anyone have thoughts, complaints,
alternative approaches, supplements? Thanks!
=== Network requirements ===
Each of these requirements apply to both installer and installed system
environments. For any given installer environment, the 'default network
configuration tools' are considered to be those the installer documents
as supported ways to configure networking (e.g. for anaconda-based
environments, configuration via kernel command line options, a
kickstart, or interactively in anaconda itself are included).
==== Basic networking ====
It must be possible to establish both IPv4 and IPv6 network connections
using DHCP and static addressing. The default network configuration
tools for the console and for release-blocking desktops must work well
enough to allow typical network connection configuration operations
without major workarounds. Standard network functions such as address
resolution and connections with common protocols such as ping, HTTP and
ssh must work as expected.
Footnote titled "Supported hardware": Supported network hardware is
hardware for which the Fedora kernel includes drivers and, where
necessary, for which a firmware package is available. If support for a
commonly-used piece or type of network hardware that would usually be
present is omitted, that may constitute a violation of this criterion,
after consideration of the [[Blocker_Bug_FAQ|hardware-dependent-
issues|normal factors for hardware-dependent issues]]. Similarly,
violations of this criteria that are hardware or configuration
dependent are, as usual, subject to consideration of those factors when
determining whether they are release-blocking
==== VPN connections ====
Using the default network configuration tools for the console and for
release-blocking desktops, it must be possible to establish a working
connection to common OpenVPN, openconnect-supported and vpnc-supported
VNC servers with typical configurations.
Footnote title "Supported servers and configurations": As there are
many different VPN server applications and configurations, blocker
reviewers must use their best judgment in determining whether
violations of this criterion are likely to be encountered commonly
enough to block a release, and if so, at which milestone. As a general
principle, the more people are likely to use affected servers and the
less complicated the configuration required to hit the bug, the more
likely it is to be a blocker.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
1 year, 3 months
[SOLVED] No audio after upgrade from F34 to F35 Beta
by Alex Gurenko
Well, it's a nice title for the BZ when you know what the problem is :)
Thanks, yes, I've already set it to enable and it's working fine now.
---
Best regards, Alex
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, October 31st, 2021 at 13:31, Geraldo Simião Kutz <geraldo.simiao.kutz(a)gmail.com> wrote:
> Have you see this bz ticket?
> https://bugzilla.redhat.com/show_bug.cgi?id=2016253
>
> Try to run this command:
> systemctl --user
> enable --now wireplumber
>
> Em sáb, 30 de out de 2021 08:53, Alex Gurenko <agurenko(a)protonmail.com> escreveu:
>
>> Hello everyone, I did a late night upgrade yesterday from F34 KDE to F35 KDE and found myself with no sound devices available on my system. I've opened a BZ for that (https://bugzilla.redhat.com/show_bug.cgi?id=2018681), however it's quite difficult to use system with no sound and it may be a known issue already.
>>
>> As mentioned in the BZ, when I load system with Live USB (RC1.2) the system eventually get all devices listed, so I would presume it's some leftovers from the F34 installation or some config or state file that blocks the F35, but no clear indication which one is a culprit.
>>
>> Any ideas what to try?
>> ---
>> Best regards, Alex
>>
>> _______________________________________________
>> kde mailing list -- kde(a)lists.fedoraproject.org
>> To unsubscribe send an email to kde-leave(a)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/kde@lists.fedoraproject.org
>> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
1 year, 7 months
No audio after upgrade from F34 to F35 Beta
by Alex Gurenko
Hello everyone, I did a late night upgrade yesterday from F34 KDE to F35 KDE and found myself with no sound devices available on my system. I've opened a BZ for that (https://bugzilla.redhat.com/show_bug.cgi?id=2018681), however it's quite difficult to use system with no sound and it may be a known issue already.
As mentioned in the BZ, when I load system with Live USB (RC1.2) the system eventually get all devices listed, so I would presume it's some leftovers from the F34 installation or some config or state file that blocks the F35, but no clear indication which one is a culprit.
Any ideas what to try?
---
Best regards, Alex
1 year, 7 months
SDDM no longer shows entry for Plasma Wayland
by Peter G.
I think it was yesterday morning that sddm-0.19.0-17 appeared. It could be from fedora testing, since I have it enabled. I rebooted the computer a while later. When I wanted to log back in, I saw that the Plasma Wayland entry is missing, only Plasma X11 is available. What happened? How can I get Plasma Wayland back?
1 year, 7 months
Fedora 35 status and testing needed
by Adam Williamson
Hi folks! Just wanted to give an update on Fedora 35 status and beg for
testing :D
We are now down to either one or two blocker bugs. They are in quite
specific areas so the fixes will not be hugely impactful to anything
else. I'm hoping to be able to run an RC compose later today (Tuesday).
However, we're also only 2 days from go/no-go.
Given this, it'd be super helpful if people could help get the
validation tests run on the current nominated nightly compose. We don't
need to wait for an RC to run most tests; for the more complicated or
trickier tests, we can run them now against a nightly and the results
can be counted so long as nothing relevant changes in the RC.
I've just manually nominated the most recent compose (20211018.n.0) for
testing; it won't have the fixes currently in updates-testing (mainly
for plasma-discover), so take that into account. You can see the
summary page (which shows results from all individual pages) here:
https://fedoraproject.org/wiki/Test_Results:Current_Summary
you can enter results by editing individual sections from that page
(the wiki will automagically edit the correct individual page), or by
using the relval tool - just 'dnf install relval' then 'relval report-
results'.
You can look for tests that really need to be run here:
https://openqa.fedoraproject.org/testcase_stats/35/
each of the pages there shows a sort of 'over time view' of the test
cases of that type, showing when it was most recently run and a little
chart view that illustrates which composes the test has been run on and
what the results were (green for pass, orange for warn, red for
failed). Look out for tests that have release level 'Basic', 'Beta' or
'Final' and which have not been run recently or at all; these are the
ones to focus on. For instance, at
https://openqa.fedoraproject.org/testcase_stats/35/Desktop.html we can
see that several of the desktop tests have not yet been run on aarch64;
it'd be great if anyone with an aarch64 system capable of running
Workstation could run those tests and add the results.
Thanks everyone!
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
1 year, 7 months
Re: Fedora Linux 35 Final blocker review summary
by Adam Williamson
On Fri, 2021-10-15 at 14:04 -0400, Ben Cotton wrote:
> Many fewer blockers than last week. Hooray! Go/No-Go for target date
> #1 is Thursday.
>
>
> Action summary
> ====================
>
> Accepted blockers
> -----------------
>
> 3. plasma-discover — Discover shows a misleading state of Flatpak
> repos, can't delete disabled repos — NEW
> ACTION: Maintainers to fix issue
>
> 4. plasma-discover — Discover doesn't seem to find any RPM packages,
> neither locally installed nor in RPM repos — NEW
> ACTION: Maintainers to fix issue
>
> 5. plasma-discover — Toggling repo in Discover doesn't redraw the
> checkbox, confusing users — NEW
> ACTION: Maintainers to fix issue
So I'm pretty worried about these. I've spent the last two days trying
to fix 3 and 5 myself, but I'm just not a Qt C++ developer so it's
pretty tough sledding. I basically understand the problems in both
cases, but fixing them is more work. I have put detailed notes in the
upstream bug reports, and I'm happy to compare notes with anyone who
wants to try and help:
https://bugs.kde.org/show_bug.cgi?id=443455
https://bugs.kde.org/show_bug.cgi?id=406295
#4 is odd as it seems to behave differently for different people at
different times; we haven't figured out the condition that causes the
'bad' state yet.
Nobody else appears to be trying to help. I'm not confident we are
going to have these fixed in time.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
1 year, 7 months
