devel February 2021

devel@lists.stg.fedoraproject.org

226 participants
377 discussions

Fedora's GPG key in DNS(SEC)
by Miroslav Suchý 08 Apr '21

08 Apr '21

All Fedora's GPG key - starting with Fedora 27 - are now stored in fedoraproject.org DNS record and can be verified using DNSSEC. Why? How it can be used? That is long story and you can read about it in my blog entry: http://miroslav.suchy.cz/blog/archives/2021/02/11/verify_package_gpg_signat… Few last minutes notes here: - there are still some gotchas which should be fixed. But enough code is already in production - you can play with it now. Relevant issues are linked in the blog post. - the DNF team is migrating their code to libdnf, I do not have any guarantee when this piece of code will be migrating - so we are far from enabling this by default. Comments are welcomed. -- Miroslav Suchy, RHCA Red Hat, Associate Manager, Community Packaging Tools, #brno, #fedora-buildsys

10 22

thinking journal retention timelimits
by Matthew Miller 07 Apr '21

07 Apr '21

As we start a new year, I'm thinking about data retention in general. :) In my experience, it's pretty rare on an end-user laptop or desktop system for logs from much more than the previous boot to be interesting. Maybe I occasionally want to look back a little while to see if a problem just started. It's exceedingly rare that I need (or want) to look back more than a month. Right now, we don't set MaxRetentionSec, so journal expiry on Workstation is entirely based on disk usage. Logs can accidentally contain sensitive data, and it's just plain faster to work with them when there's less. I propose we set this to something like six months by default. -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

9 13

Donate 1 minute of your time to test upgrades from F33 to F34
by Miroslav Suchý 07 Apr '21

07 Apr '21

Do you want to make Fedora 34 better? Please spend 1 minute of your time and try to run: # Run this only if you use default Fedora modules # next time you run any DNF command default modules will be enabled again sudo dnf module reset '*' sudo dnf --releasever=34 --setopt=module_platform_id=platform:f34 \ --enablerepo=updates-testing --enablerepo=updates-testing-modular \ distro-sync This command does not replace `dnf system-upgrade`, but it will reveal potential problems. You may also run `dnf upgrade` before running this command. If you have have rdma-core.i686 installed you have to pass `--allowerasing`. https://bugzilla.redhat.com/show_bug.cgi?id=1919864 If you get this prompt: ... Total download size: XXX M Is this ok [y/N]: you can answer N and nothing happens, no need to test the actual upgrade. But very likely you get some dependency problem now. In that case, please report it against the appropriate package. Or against fedora-obsolete-packages if that package should be removed in Fedora 34. Please check existing reports against fedora-obsolete-packages first: https://red.ht/2kuBDPu and also there is already bunch of "Fails to install" reports: https://bugzilla.redhat.com/show_bug.cgi?id=F34FailsToInstall Thank you P.S. sent from workstation successfully upgraded to F34 :) -- Miroslav Suchy, RHCA Red Hat, Associate Manager, Community Packaging Tools, #brno, #fedora-buildsys

25 40

Please clarify master vs main vs rawhide branches
by Steven A. Falco 02 Apr '21

02 Apr '21

I see that the master to main conversion has happened. I'd like to know the recommended way to deal with that. Currently, I'm doing: git fetch --all git remote prune origin git remote set-head origin -a git checkout main The above sets origin/HEAD to rawhide Question 1: Is that the right set of steps, or is there a better way to update my local repos? Question 2: For the packages I maintain, should I put changes in main or rawhide? Should I keep main and rawhide in sync? Steve

5 5

Fedora 35 Change proposal: POWER 4k page size (System-Wide Change proposal)
by Ben Cotton 30 Mar '21

30 Mar '21

https://fedoraproject.org/wiki/Changes/Power4kPageSize == Summary == On ppc64le, the kernel is currently compiled for 64k page size. This change proposes using the more common 4k page size. Some HPC workloads may be disadvantaged slightly. Workstation users are likely to encounter fewer bugs. Some things, like the AMD Radeon GPU drivers, firmware or related code, appear to be completely non-functional on the 64k page size. Insufficient upstream developers are testing such issues on this architecture. == Owner == * Name: [[User:pocock|Daniel Pocock]] * Email: daniel(a)pocock.pro == Detailed Description == == Feedback == Discussed several times on devel, [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… latest here] [https://forums.raptorcs.com/index.php/topic,248.msg1852.html discussed upstream in the Raptor forum] == Benefit to Fedora == Better first impression for users of ppc64le workstations. Users can focus on reporting ppc64le bugs without being sidetracked by page size bugs. == Scope == * Proposal owners: [[DanielPocock]] * Other developers: please volunteer by adding your name here * Release engineering: [https://pagure.io/releng/issue/9939 #9939] ** wait for 5.12 kernel, verify that it includes the Btrfs patches for arbitrary 4k / 64k sector size, independent of the page size ** create a kernel with 4k page size to run on the ppc64le build servers ** ensure the default kernel RPM in the distribution has 4k page size ** perform the mass rebuild running on the 4k page size ** create an installer ISO based on the revised kernel with 4k page size * Policies and guidelines: no, as it is an arch-specific issues, most other architectures already have a 4k page size * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: none of the current objectives relate to this change == Upgrade/compatibility impact == If the user has already formatted their root filesystem with Btrfs and a 64k sector size, they need to be using a Fedora kernel that supports both 4k and 64k. This is anticipated in a future kernel release, 5.12 and will hopefully be ready for F34 or F35[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject…. == User Experience == New GPUs are more likely to just work on this non-x86 architecture, as long as the latest firmware, mesa, llvm are also used. Btrfs, the default filesystem, will use the sector size identical to the running kernel's page size. As the 4k page size is more common, this will ensure Btrfs filesystems created on ppc64le hosts can be used on x86 and other hosts without hassle. == Dependencies == All RPMs must be rebuilt on a server running the final page size (4k) == Contingency Plan == * Contingency mechanism: Prepare a kernel with the original 64k config, install it on the build server, rebuild all the packages for this architecture * Contingency deadline: whenever the last time for a full rebuild or kernel change is possible * Blocks release? Yes, full rebuild of all packages must be completed before release -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

13 30

Upstream tip wanted: CI service for Big Endian acrhes
by Miro Hrončok 28 Mar '21

28 Mar '21

Recently I've reported some Big Endian related test failures to an upstream project [0]. I was asked by an upstream project maintainer, whether I know some free Continuous Integration services where they can easily run their testsuite on Big Endian. Any tips? * Upstream uses Travis CI to test on x86_64 Linux (Ubuntu) * Upstream uses AppVeyor to test on Microsoft Windows * It's a pure Python project, noarch, but some changes need to be done when loading/saving binary data (LE) with NumPy on BE system. What I've considered: * COPR (but there is no big endian arch) * (Ab)using Koji (I guess that would be considered a bad practice?) * using QUEMU on Travis CI [1] Any better tips? Thanks [0] https://github.com/mikedh/trimesh/issues/249 [1] https://developer.ibm.com/linuxonpower/2017/07/28/travis-multi-architecture… -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

8 10

Meaning of Size Directories
by Sergio Belkin 16 Mar '21

16 Mar '21

Hi, Tools such as ls or stat report the size of a directory. Of course it is not the content size. stat -c %s /home/sergio/.config 6550 What does 6550 mean in btrfs context? Thanks in advance! -- -- Sergio Belkin LPIC-2 Certified - http://www.lpi.org

10 14

What to do about EPEL package branch with no active maintainer?
by Henrik Nordström 16 Mar '21

16 Mar '21

I recently took over Radare2 maintenance for Fedora after it was orphaned, and now noticed it is also packaged in EPEL-8. I am not in a good position to actively maintain the EPEL-8 release. I am not an EPEL user, no interest in EPEL, and and not very comfortable with doing "blind" maintenance by simply merging changes from fedora and and hope for the best. The question is then what should be done with the stale and known broken EPEL branch of the package? Just let it bitrot further? Anyone who wants to maintain the EPEL-8 branch of Radare2? Or co-maintain the Fedora version? Regards Henrik

2 1

Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
by Ben Cotton 09 Mar '21

09 Mar '21

https://fedoraproject.org/wiki/Changes/DefaultPipeWire == Summary == This change proposal is to route all audio from PulseAudio and JACK to the PipeWire Audio daemon by default. == Owner == * Name: [[User:Wtaymans| Wim Taymans]] * Email: wim.taymans(a)gmail.com == Detailed Description == Currently, all desktop audio is handled by the PulseAudio daemon. Applications make use of the PulseAudio client library to communicate with the PulseAudio daemon that mixes and manages the audio streams from the clients. The desktop shell (gnome-shell) and the control panel (gnome-control-panel) both use the Pulseaudio client libraries to manage the volume and configuration of the PulseAudio daemon. This proposal is to replace the PulseAudio daemon with a functionally compatible implementation based on PipeWire. This means that all existing clients using the PulseAudio client library will continue to work as before, as well as applications shipped as Flatpak. All PRO audio is handled with the JACK client library, which talks to the JACK server. This proposal will install a JACK client library replacement that talks directly to PipeWire. All existing PRO audio jack applications will then work on top of PipeWire. For legacy ALSA clients, we will install an ALSA plugin that routes the audio directly to PipeWire. With these 3 changes, all audio will be routed to PipeWire. There will then be no more need to install the PulseAudio and JACK daemons. == Feedback == The owner of this proposal has been in context with both the PulseAudio and JACK maintainers and community. PipeWire is considered to be the successor of both projects. == Benefit to Fedora == The end goal is to end up with one audio infrastructure for both Desktop and Pro audio use cases. This will end the fragmentation of the audio landscape. Some of the benefits that PipeWire will bring: * PRO Audio features PipeWire can support both Desktop and PRO Audio use cases. PRO Audio application tend to use the JACK API and JACK daemon, which is hard to setup and integrates poorly with the rest of the system (and PulseAudio in particular). With a replacement libjack library, PRO Audio application can run directly on PipeWire and integrate seamlessly with other ALSA and PulseAudio applications. This would bring Fedora closer to the experience of other operating systems. * Flexibility/Integration PipeWire is designed to be multiprocess. It separates the processing of the multimedia graph and the management into separate processes. This makes it possible to better integrate with the other system components or swap out the default policy for a highly customized one (such as for automotive or embedded). This is in contrast to PulseAudio, which has all logic embedded into the daemon with limited configuration options. In the next phase we expect to greatly expand the user experience and configuration of the audio infrastructure with better integration throughout the system. * Performance PipeWire was designed for high performance and low-latency, using much of the same design as JACK. JACK application should run with comparable performance even in low-latency situations. * Security PipeWire enforces per client security. Object visibility and the actions on them can be configured independently per client. This makes it possible to enforce a security policy for sandboxed applications (Flatpak) such as denying access to certain audio capture devices or block them from interfering with other applications. * Maintainability Both PulseAudio and JACK have very slow development cycles with few new features. The more flexible and distributed nature of the design of PipeWire should encourage more new features and use-cases. == Scope == * Proposal owners: We would make a pipewire-pulse package that provides the same features as the pulseaudio (daemon) package. We would only provide a drop-in replacement daemon, the pulseaudio client libraries will remain unchanged. The idea is that when installing pipewire-pulse, only the pulseaudio package is removed and replaced by the pipewire-pulse implementation. In the same way, installing the pulseaudio package would remove the pipewire-pulse package, making it possible to switch between implementations. This will also allow for an easy rollback. We also need to check and correct the dependencies of other packages. As of this writing, some packages do not state their dependencies correctly and get removed when pulseaudio is removed. We also need to check the JACK to make sure they still install with the replacement JACK client library. The JACK client libraries will be installed in the same way, removing the old JACK client libraries. * Other developers: The distribution needs to default to the pipewire-pulse package instead of pulseaudio. JACK applications need to install the pipewire-libjack client library. * Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engineering is needed) * Policies and guidelines: * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == The pulseaudio package will be uninstalled and pipewire-pulse will be installed. pipewire-pulse does not yet implement all the features of pulseaudio but it is expected that comparable functionality will be implemented later. Most notable features that are likely not going to be available for fedora 34 * avahi network discovery and audio routing. This is not enabled by default but can be activated with paprefs. this includes TCP and RTP transport of audio. * make devices available as UPNP media servers. Not enabled by default, paprefs can be used. * easy configuration of combining all sinks. Questionable feature but possible via paprefs. User scripts will still work but custom configurations of the pulseaudio daemon will not be used anymore. Most of the JACK workflow of managing the JACK daemon is not going to be needed anymore as things will work out-of-the-box. As of this writing, these things are missing from the JACK implementation, we hope to implement them before fedora 34: * latency reporting: useful to align streams * freewheeling: used when rendering a project * jackdbus: used by some tools to manage the graph == How To Test == This change needs to be tested on as many different audio cards as possible. The same test plan applies here as with PulseAudio. To test, one needs to install the pipewire-pulse library (which removes the pulseaudio package). To test the JACK support, one needs to install pipewire-libjack, which removes the original JACK client and server. After these changes, a restart is needed to make sure the new pipewire-pulse daemon is running. Audio functionality should be like it was before with the Pulseaudio daemon. Some things to verify: - patcl info should now list: Server Name: PulseAudio (on PipeWire 0.3.x) - gnome-control-center: check the audio tab, check the volume sliders and do the audio channel test. Change the card profile, plug/unplug headphones and observe correct switch. - pavucontrol: check volumes in the input devices tabs and check the microphone volumes - firefox: check out a website with audio/video such as youtube and verify that audio works as usual. Check out a website with a video chat test page (bluejeans.com/111) - rhythmbox: check if playback works as expected - bluetooth devices, connect as usual and verify working behaviour with PipeWire. Check volume changes etc. - Regular system usage and performance should not change. - JACK tools such as catia, carla should run and can be used to inspect the graph. == User Experience == In general, users should not be able to see any change when using PulseAudio applications. The big change is when using JACK application: - They will start without having to configure and start the daemon. this includes the period size and sample rates. - All devices will be visible in the graph with meaningful names. Devices will be automatically slaved when needed without needing any configuration. - bluetooth devices will be usable as well. == Dependencies == Other packages might need to have their requirements fixed to work with the replacement packages but this is under our control. == Contingency Plan == * Contingency mechanism: Keep existing pulseaudio and JACK client libraries as defaults * Contingency deadline: beta freeze * Blocks release? No * Blocks product? No == Documentation == [https://pipewire.org](PipeWire website) [https://www.youtube.com/watch?v=8LZt4loZu64&t=14s](Video with Current status) [https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/INSTALL.md](… guide) [https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/README.md](h… to use/test) -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

52 139

F34 gdm login prompt goes crazy when a fingerprint reader with no enrolled prints is present
by Hans de Goede 09 Mar '21

09 Mar '21

Hi Benjamin, Ray, I noticed this problem while dogfooding F34, I'm fully up2date as of today. Today's gdm update did help in making the problem more clear. What happens is that as soon as I press enter / click my main user in gdm, the password entry box keeps getting updated (and clearing its content) every 1 - 2 seconds with a "failed to authenticate with fingerprint" (or something like that) briefly showing below the password entry box every time it gets cleared. After a non-fixed amount of tries it stops doing this and only then I can successfully login. The same happens on the lock screen of gnome-shell, except that there it never stops doing this. The "failed to authenticate with fingerprint" is new as of todays gdm update, before this it was just "failed to authenticate". Now that I know fprintd is involved I've masked fprintd and that works around this. As said I'm running a fully up2date F34 on a Thinkpad X1 carbon 8th gen, with the "Linux" fingerprint firmware installed by fwupd. I don't think I have ever enrolled a fingerprint, which might be part of the problem, but in that case it should really just act as if there is no fingerprint reader present. The login dialog / fprintd should certainly _not_ repeatedly show the error IMHO even showing it once would be wrong here, but it would be a big improvement. Let me know if you need any logs, want a bugzilla for this, or if there is anything else which I can do to help debug this. Regards, Hans

13 54

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 February 2021