devel August 2024

devel@lists.fedoraproject.org

137 participants
194 discussions

F41 Change Proposal: Anaconda as native Wayland application (System Wide)
by Aoife Moloney 16 Sep '24

16 Sep '24

Wiki - https://fedoraproject.org/wiki/Changes/Anaconda_As_Native_Wayland_Applicati… Discussion Thread - https://discussion.fedoraproject.org/t/f41-change-proposal-anaconda-as-nati… This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Currently, Anaconda is still an X11 application, which we would like to fix and make Anaconda Wayland native application to allow us drop of the X11 dependencies from installation ISO images. However, this change is not just a simple switch and we need to do some adjustments during the path which will impact user experience. == Owner == * Name: Anaconda team ([[User:jkonecny| Jiří Konečný]]) * Email: jkonecny(a)redhat.com == Detailed Description == Anaconda is required to migrate to Wayland native application to drop dependencies from the installation ISO images which are deprecated. Package owners want to drop libXklavier from Fedora (see https://bugzilla.redhat.com/show_bug.cgi?id=1955025 ) but also Xorg server from CentOS Stream and RHEL. However, this change won’t be just simple switching from X11 to Wayland, we also need to change a few things in Anaconda to be able to remove the X11 dependencies. This will have two main visible impacts listed below. === VNC switch to RDP for remote GUI installations === Anaconda has to remove ‘TigerVNC' which is used for VNC connection to be able to install your machine remotely with graphical UI. Reason is that TigerVNC is built from the Xorg server sources, so we would still depend on the Xorg server with this project. As replacement, we follow the recommendation of the Fedora Workstation to switch to Gnome Remote Desktop (grd) with a better protocol Remote Desktop Protocol (RDP) which gives users better performance and security. This will have an impact on current vnc kickstart commands and kernel boot options of Anaconda. This will impact only the Anaconda installation environment (boot.iso). === Consistent keyboard control === Currently, Anaconda experiences difficulties in handling keyboard layouts in the installation environment, particularly on Wayland. Formerly, libXklavier was utilized by Anaconda to manage keyboard layout configuration, however, it proved unstable on Wayland. As a result, Anaconda has disabled keyboard handling during Wayland Live media installations due to unexpected behavior (refer to https://bugzilla.redhat.com/show_bug.cgi?id=2016613 ). This approach may lead to situations when users encountering issues while unlocking LUKS devices or using user passwords in the installed system because installation was done with a different keyboard layout. To exacerbate the situation, there is no universally applicable solution for keyboard handling on Wayland systems, as Wayland lacks a unified API for keyboard management. It means that each Fedora Desktop Environment developed their own API. Unfortunately, the Anaconda team is not able to maintain a custom solution for each Fedora spin. Some Desktop environments started to use '''systemd-localed''' DBus API to address this issue and similar issues. The systemd-localed API seems to be the best approach currently, so we want to promote it as a shared solution for all Fedora spins. The plan is: * All Fedora spins and Anaconda listen on '''org.freedesktop.locale1''' and reflect configuration on the currently running system (might be only for Live media if desired) * All Fedora spins and Anaconda reflect their configuration to org.freedesktop.locale1 * In case Fedora spin will not support '''org.freedesktop.locale1''', the keyboard configuration of Anaconda won’t be reflected in the current system and the situation will be similar to the current Live Wayland experience All the spin owners were notified about this request: * https://pagure.io/fedora-workstation/issue/430 * https://pagure.io/fedora-kde/SIG/issue/504 * https://gitlab.com/fedora/sigs/sway/SIG/-/issues/36 * https://bugzilla.redhat.com/show_bug.cgi?id=2278655 * https://bugzilla.redhat.com/show_bug.cgi?id=2278658 * https://bugzilla.redhat.com/show_bug.cgi?id=2278656 * https://bugzilla.redhat.com/show_bug.cgi?id=2278864 * https://bugzilla.redhat.com/show_bug.cgi?id=2278866 * https://bugzilla.redhat.com/show_bug.cgi?id=2278869 * https://bugzilla.redhat.com/show_bug.cgi?id=2278874 * https://pagure.io/fedora-cosmic/SIG/issue/1 * https://pagure.io/fedora-budgie/project/issue/4 * https://pagure.io/fedora-lxqt/SIG/issue/4 * https://pagure.io/i3-sig/Fedora-i3-Spin/issue/70 == Feedback == We have some feedback from the SIG owners for the keyboard handling (see the links above). We don’t have feedback for the VNC to RDP switch yet. == Benefit to Fedora == * This change will enable removal of X11 dependencies from the Anaconda which may result in reduction of installed software to the system when installing from Live ISO where ISO content is copied to the installed system (depends on the spin dependencies). * Switching from VNC to RDP allow users to use remote graphical installations which are more secure and have better performance . == Scope == * Proposal owners: The Anaconda team will implement changes required in the Anaconda project. More specifically: ** Switch Anaconda code to start Wayland environment on boot.iso instead of X11 ** Change keyboard switching logic to use systemd-localed DBus instead of libXklavier ** Switch remote graphical installations from VNC (TigerVNC) to RDP (GRD) * Other developers: Fedora SIG owners needs to add support for their environment to listen and use systemd-localed DBus API to reflect current state of the DE/WM or they won’t have support of keyboard layout switching in Anaconda. * Release engineering: [https://pagure.io/releng/issue/12138 #12138] * Policies and guidelines: Yes should be done after the implementation (https://docs.fedoraproject.org/en-US/fedora-server/installation/interactive… should switch to RDP) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: == Upgrade/compatibility impact == This will impact only Fedora installations so no compatibility or upgrade issues. == Early Testing (Optional) == We will reach Fedora QE to coordinate testing approach. == How To Test == # Download any installation media # Run the installation # Look for breakages during the installation Testing should be especially focused on: * Changing resolution with ''inst.resolution'' kernel boot option * Test new RDP solution (API will be clarified) ** Password can be set to the RDP ** Username can be set to the RDP * Test keyboard layout switching works correctly ** On Live media, Anaconda should react on keyboard layout change in the DE and set that to the installed system ** On Live media, Anaconda should be able to set the keyboard layout changes to the live environment ** In the network installation (boot.iso) Anaconda should correctly reflect keyboard layouts changes so text in the Anaconda is written by the correct layout ** Check if specific keyboard layouts are configured and installed as expected == User Experience == The only visible change to a user should be: * Remote graphical installations will use RDP instead of VNC. * Anaconda will be able to control keyboard layouts in the Wayland environment on Live ISOs. This will improve user experience when installing Fedora Workstation, Fedora KDE, Fedora Sway and other Wayland based environments. == Dependencies == No dependencies of this package related to this change. == Contingency Plan == * Contingency mechanism: Postpone this change to the next Fedora release. Revert landed changes in Anaconda if required. * Contingency deadline: 100% code completion deadline * Blocks release? No == Documentation == No documentation yet. However, there are a few PRs ready for merge for CentOS Stream 10: * https://github.com/rhinstaller/anaconda/pull/5463 * https://github.com/rhinstaller/anaconda/pull/5470 * https://github.com/rhinstaller/anaconda/pull/5485 * https://github.com/rhinstaller/anaconda/pull/5498 == Release Notes == TBD -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-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/devel-announce@lists.fedorapr… Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

20 54

gdk-pixbuf removing several icon loaders
by Michael Catanzaro 15 Sep '24

15 Sep '24

Hi, gdk-pixbuf 2.42.11 has dropped support for several uncommon image formats. This is causing several applications to crash in Fedora rawhide [1][2]. (The change also got backported to F40 and F39, but I've reverted it there.) Benjamin Gilbert has proposed reenabling the removed loaders [3], but this is not likely to be accepted upstream. So he's currently planning to package the removed loaders for Fedora in a separate package. You'll be able to depend on these if needed to avoid crashing, but please do so only if you really need to, since the goal of removing the extra loaders is to reduce attack surface. (Unfortunately gdk-pixbuf is a fairly risky dependency: many applications require it, but it's not very safe.) Most applications should use modern image formats instead. Michael [1] https://bugzilla.redhat.com/show_bug.cgi?id=2276464 [2] https://bugzilla.redhat.com/show_bug.cgi?id=2276661 [3] https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/merge_requests/169 [4] https://src.fedoraproject.org/rpms/gdk-pixbuf2/pull-request/4#comment-198909

4 6

Orphaned: egl-wayland, egl-gbm and eglexternalplatform
by Leigh Scott 11 Sep '24

11 Sep '24

I have decided to orphan these packages as they are useless replacements for the nvidia driver provided libs. The rpmfusion 560+ driver will use the bundled libs. I believe it's time fedora dropped eglstream support. https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1386 Affected packages $ dnf5 -q repoquery --enablerepo=fedora-source --arch src --whatrequires egl-wayland-devel gstreamer1-plugins-base-0:1.22.9-1.fc40.src kf6-kwindowsystem-0:6.0.0-1.fc40.src mir-0:2.16.3-1.fc40.src mutter-0:46.0-1.fc40.src xorg-x11-server-Xwayland-0:23.2.4-3.fc40.src

4 9

Execute RPM dependency generators on the .spec file which ships them
by Vít Ondruch 09 Sep '24

09 Sep '24

I am still playing with idea of executing RPM dependency generators on the .spec file which ships them. I have created RPM RFE ticket quite a while ago here: https://github.com/rpm-software-management/rpm/issues/782 So for no luck with having this implemented. However, I think there is reasonable way. It would be enough to have some generic attr file around. I have create small test package exploring this idea and you can find it in my Copr repo: https://copr.fedorainfracloud.org/coprs/vondruch/rpm-local-generator/ https://copr-dist-git.fedorainfracloud.org/cgit/vondruch/rpm-local-generato… On the same place, you can also find package leveraging this concept: https://copr-dist-git.fedorainfracloud.org/cgit/vondruch/rpm-local-generato… Would somebody else benefit from this idea/package or can somebody spot some issue with it? Thx for feedback. Vít

5 12

RPM dependency generator sanity check
by Dridi Boukelmoune 06 Sep '24

06 Sep '24

Greetings, I recently implemented generators for Hare modules (provides and requires so far) and my current work in progress does what it says on the tin. However, trying to answer the question "what if the package installs garbage" I was not able to fail a package build with the dependency generators. I made the scripts end with something written to stderr followed by an explicit "exit 1", and I can see the error message, but then it just succeeds. So my question is how to make RPM register that a dependency generator failed and in turn fail the build? Bear with me, this is only work in progress and I already started to iron out a few kinks, and I have more to address, but I haven't touched my COPR repositories after reaching the first "it works" milestone, so don't look at the kinks. You can grab the sources from here: https://copr-dist-git.fedorainfracloud.org/cgit/dridi/harelang/hare.git/tre… And on my system I use the following command to build packages with automatic dependencies: rm -rf results_hare/ && fedpkg mockbuild --with bootstrap && mock --install results_hare/*/*/hare-rpm-macros-*.rpm && rm -rf results_hare/ && fedpkg mockbuild --no-clean (I broke it down line by line for legibility. If there is a handy all-in-one command for a bootstrapped build followed by a regular build in fedpkg, I didn't find it and I'm interested.) My default mock root points to rawhide. It takes a couple minutes to complete, at which point I can observe virtual provides for Hare modules: $ rpm -qpP results_hare/*/*/hare-stdlib-*.rpm | tail hare(unix) = 0.24.2-1.fc42 hare(unix::hosts) = 0.24.2-1.fc42 hare(unix::passwd) = 0.24.2-1.fc42 hare(unix::poll) = 0.24.2-1.fc42 hare(unix::resolvconf) = 0.24.2-1.fc42 hare(unix::signal) = 0.24.2-1.fc42 hare(unix::tty) = 0.24.2-1.fc42 hare(uuid) = 0.24.2-1.fc42 hare(wordexp) = 0.24.2-1.fc42 hare-stdlib = 0.24.2-1.fc42 Like I said, if the hare.prov and hare.req script fail, the build happily completes. I thought of using a burp script but those look pretty arcane and I couldn't easily find a doc reference explaining how to work with them (they look essentially ad-hoc). How do I get rpmdeps to propagate the exit status of the scripts? Thanks, Dridi

3 6

[SPDX] Mass license change - batch #3 of all remaining packages
by Miroslav Suchý 06 Sep '24

06 Sep '24

Here is the third and last batch of changes for 972 packages (perl-JSON-Create to 0ad-data) https://miroslav.suchy.cz/fedora/rest-of-callaway-batch3.diff Shorten version without the context is here: https://miroslav.suchy.cz/fedora/rest-of-callaway-batch3-short-diff.txt I will appreciate a review. If there will be no issue I will commit and push this to dist-git in a week. -- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys

4 7

GRUB2 rebase (from 2.06 to 2.12) landing soon on rawhide
by Leo Sandoval 04 Sep '24

04 Sep '24

Hi team, We (the Red Hat bootloader team) are completing the work of rebasing/reviewing/testing current rawhide patches, from GRUB2 2.06 to 2.12, so at some point in the near future these would land finally into rawhide. Once everything is in place, we would like your help to start testing the package and report any boot issue found. If there is any concern on this work, please let me know. Regards, Leo

6 16

libsvm soname bump
by Jerry James 04 Sep '24

04 Sep '24

Version 3.34 of libsvm has been released, and bumps the soname of the library. I would like to update libsvm and rebuild the consuming packages: - clisp - openms - perl-Algorithm-SVM I maintain clisp. The other maintainers are BCCed on this message. I will do these builds in Rawhide sometime next week, unless any maintainer has a reason why I should wait. I am open to opinions on whether builds should also be done for F41 or not. -- Jerry James http://www.jamezone.org/

1 1

pyliblo3 - %python3 setup.py test fails
by Martin Gansser 03 Sep '24

03 Sep '24

Hi, i want to use %python3 setup.py test [1] with pyliblo3, but this fails. + /usr/bin/python3 setup.py test running test WARNING: Testing via this command is deprecated and will be removed in a future version. Users looking for a generic test entry point independent of test runner are encouraged to use tox. /usr/lib/python3.12/site-packages/setuptools/command/test.py:193: _DeprecatedInstaller: setuptools.installer and fetch_build_eggs are deprecated. !! ******************************************************************************** Requirements should be satisfied by a PEP 517 installer. If you are using pip, you can try `pip install --use-pep517`. ******************************************************************************** !! ir_d = dist.fetch_build_eggs(dist.install_requires) /usr/lib/python3.12/site-packages/setuptools/command/test.py:194: _DeprecatedInstaller: setuptools.installer and fetch_build_eggs are deprecated. !! ******************************************************************************** Requirements should be satisfied by a PEP 517 installer. If you are using pip, you can try `pip install --use-pep517`. ******************************************************************************** !! tr_d = dist.fetch_build_eggs(dist.tests_require or []) /usr/lib/python3.12/site-packages/setuptools/command/test.py:195: _DeprecatedInstaller: setuptools.installer and fetch_build_eggs are deprecated. !! ******************************************************************************** Requirements should be satisfied by a PEP 517 installer. If you are using pip, you can try `pip install --use-pep517`. ******************************************************************************** !! er_d = dist.fetch_build_eggs( running egg_info writing pyliblo3.egg-info/PKG-INFO writing dependency_links to pyliblo3.egg-info/dependency_links.txt writing top-level names to pyliblo3.egg-info/top_level.txt reading manifest file 'pyliblo3.egg-info/SOURCES.txt' reading manifest template 'MANIFEST.in' adding license file 'COPYING' writing manifest file 'pyliblo3.egg-info/SOURCES.txt' running build_ext copying build/lib.linux-x86_64-cpython-312/pyliblo3/_liblo.cpython-312-x86_64-linux-gnu.so -> pyliblo3 ---------------------------------------------------------------------- Ran 0 tests in 0.000s NO TESTS RAN + RPM_EC=0 ++ jobs -p + exit 0 [1] https://martinkg.fedorapeople.org/Review/SPECS/pyliblo3.spec [2] https://martinkg.fedorapeople.org/Review/SRPMS/pyliblo3-0.16.2-0.3.fc40.src… How can i solve this ? Regards Martin

3 14

[SPDX] Mass license change - batch #2 of all remaining packages
by Miroslav Suchý 02 Sep '24

02 Sep '24

Here is the second batch of changes for 1000 packages (golang-github-danwakefield-fnmatch to perl-Image-Xbm) https://miroslav.suchy.cz/fedora/rest-of-callaway-batch2-normal-diff.txt Shorten version without the context is here: https://miroslav.suchy.cz/fedora/rest-of-callaway-batch2-small-diff.txt I will appreciate a review. If there will be no issue I will commit and push this to dist-git in a week. And then I will post another (larger) batch for a review. -- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys

4 8

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel August 2024