Hi Fedora users, developers, and friends!
It's time to start thinking about Test Days for Fedora 40.
For anyone who isn't aware, a Test Day is an event usually focused
around IRC for interaction and a Wiki page for instructions and results,
with the aim being to get a bunch of interested users and developers
together to test a specific feature or area of the distribution. You can
run a Test Day on just about anything for which it would be useful to do
some fairly focused testing in 'real time' with a group of testers; it
doesn't have to be code, for instance, we often run Test Days for
l10n/i18n topics. For more information on Test Days, see
https://fedoraproject.org/wiki/QA/Test_Days .
Anyone who wants to can host their own Test Day, or you can request that
the QA group helps you out with organization or any combination of the
two. To propose a Test Day, just file a ticket in fedora-qa pagure - here's
an example https://pagure.io/fedora-qa/issue/624 . For
instructions on hosting a Test Day, see
https://fedoraproject.org/wiki/QA/SOP_Test_Day_management .
You can see the schedule at https://pagure.io/fedora-qa/issues?tags=test+days .
There are many slots open right now. Consider the development
schedule, though, in deciding when you want to run your Test Day - for
some topics you may want to avoid
the time before the Beta release or the time after the feature freeze
or the Final Freeze.
We normally aim to schedule Test Days on Thursdays; however, if you want
to run a series of related Test Days, it's often a good idea to do
something like Tuesday / Wednesday / Thursday of the same week (this is
how we usually run the X Test Week, for instance). If all the Thursday
slots fill up but more people want to run Test Days, we will open up
Tuesday slots as overflows. And finally, if you really want to run a
Test Day in a specific time frame due to the development schedule, but
the Thursday slot for that week is full, we can add a slot on another
day. We're flexible! Just put in your ticket the date or time frame you'd
like, and we'll figure it out from there.
If you don't want to run your own Test Day, but you are willing to
help with another, feel free to join one or more of already accepted
Test Days:
GNOME Test Day*
i18n Test Day*
Kernel Test Week(s)*
Upgrade Test Day*
IoT Test Week*
Cloud Test Day*
Fedora CoreOS Test Week*
And don't be afraid, there are a lot of more slots available for your
own Test Day!
[*] These are the test days we run generally to make sure everything
is working fine, the dates get announced as we move into the release
cycle.
If you have any questions about the Test Day process, please don't
hesitate to contact me or any member of the Fedora QA team on test at
lists.fedoraproject.org or in #fedora-qa on IRC. Thanks!
--
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED
Hi all,
The next meeting of the Fedora Workstation Working Group is planned for
tomorrow, 7 November, at 10:00 AM EDT (14:00 UTC).
Join link: https://meet.opensuse.org/FedoraWorkstationWG
Allan
--
Agenda
#topic f39 status
#topic Evaluate our X11 session offering
#link https://pagure.io/fedora-workstation/issue/395
Summary of last week's discussion:
* Proprietary NVIDIA driver support
* Nouveau is needed for the out of the box experience, but is not viable
as a complete replacement for the proprietary driver at the moment
* Nouveau isn't currently a viable way to support Cuda
* Work on explicit sync support is ongoing
* Concerns we've heard about X11 session removal:
* DRM leasing - there's some kind of obstacle around the portal API
there?
* VRR - https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1154
* Screen tearing
* Remote desktop
* Color management
* Global key bindings - needed by Orca
* Recommendation from the graphics team is to keep the X11 session as a
fallback in the short term. This needn't be automatic or exposed in the UI,
but could be accessed through the CLI.
* Other issues to consider:
* Gaps around proprietary apps
* Certification for OpenJDK in Wayland (project Wakefield -
https://wiki.openjdk.org/display/wakefield/ )
* Remote desktop
* CI
#topic NVIDIA driver and UEFI secure boot
#link https://pagure.io/fedora-workstation/issue/155
Summary of the previous discussion:
* NVIDIA proprietary driver can be installed through GNOME Software.
However, if secure boot is enabled, you will get broken graphics and
nouveau will be blacklisted. It will only work if secure boot is disabled.
* Possible actions:
* Improve the fallback situation
* Have Software detect if secure boot is off and have it adjust
accordingly
* Find someone to look into automatic enrolement. First step would be to
dig into the Ubuntu code. We'd also need to overcome opposition from the
Fedora kernel maintainers.
#topic Include usbguard by default
#link https://pagure.io/fedora-workstation/issue/401
#topic Announcements and status updates
Minutes from last week:
#link
https://meetbot.fedoraproject.org/fedora-meeting-2/2023-11-01/workstation...
On Thu, Nov 2, 2023 at 9:43 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
>
> Hey folks,
>
> As part of the work to upgrade to KDE Plasma 6, appstream is being
> upgraded to a snapshot release as 1.0.0 is arriving soon. There are
> some consequences for this change:
>
> * appstream has gone through an API/ABI breakage, and consumers will
> need to adapt
> * appstream-data needs to move its content from
> /usr/share/app-info/{xmls,icons} to /usr/share/swcatalog/{xml,icons}
> * Direct consumers of the C API will need to make changes to support
> appstream 1.0
> * Consumers of the Qt bindings moving to Qt6 will need to make changes
> to support appstream 1.0
> * Consumers of the Qt5 bindings will need to build against
> appstream0.16-qt-devel
>
> I've built appstream in a side-tag, and I'd appreciate it if folks
> could help by adapting their packages and submitting builds into it.
>
> This can be done with the following command: fedpkg build
> --target=f40-build-side-76936
>
> My simple query of the consumers of the libraries in question resulted in this:
> ngompa@fedora ~> sudo dnf repoquery -q --whatrequires
> "libappstream.so.4()(64bit)" --qf "%{SOURCE_NAME}"
> appstream
> appstream-generator
> flatpak
> gnome-software
> libadwaita
> malcontent
I've handled appstream, appstream-generator, and appstream-data already.
* Flatpak has an upstream change that needs backporting[1] or a new release.
* GNOME Software has a merge request open[2].
* libadwaita has an upstream change that needs backporting[3].
* malcontent needs work done.
Please address these ASAP in some meaningful way and submit the result
into the "f40-build-side-76936" side tag.
[1]: https://github.com/flatpak/flatpak/pull/5563
[2]: https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/1810
[3]: https://gitlab.gnome.org/GNOME/libadwaita/-/merge_requests/1000
--
真実はいつも一つ!/ Always, there's only one truth!