devel January 2021

devel@lists.fedoraproject.org

216 participants
347 discussions

pdftk retired?
by Michael J Gruber 08 Sep '21

08 Sep '21

I just git a "broken dependencies" notice for a package that I maintain. The reason is that "pdftk" got retired just the other day. I may have missed a corresponding post on fedora-devel, but I think a heads up notice to maintainers of depending packages may be in order before you retire a package, as a general idea. You see, unretiring a package is so much more work than changing maintainership. As for pdftk: I see 2 failed builds for version 1.45 and none for the current version 2.02 (which probably breaks the api anyways). What are the plans? Retire pdftk completely? Start fresh with pdftk2? pdflabs, the maker of pdftk, provide binary as well as source rpms for pdftk 2.02, by the way. I might even look into packaging it but don't want to duplicate any existing efforts. Michael

17 26

Fedora 34 Change: LTO Build Improvements (System-Wide Change proposal)
by Ben Cotton 12 Aug '21

12 Aug '21

https://fedoraproject.org/wiki/Changes/LTOBuildImprovements == Summary == Currently all packages that are not opted out of LTO include -ffat-lto-objects in their build flags. This proposal would remove -ffat-lto-objects from the default LTO flags and only use it for packages that actually need it. == Owner == * Name: [[User:law | Jeff Law]] * Email: law(a)redhat.com == Detailed Description == -ffat-lto-objects was added to the default LTO flags to ensure that any installed .o/.a files included actual compiled code rather than just LTO bytecodes (which are stripped after the install phase). However, that is wasteful from a compile-time standpoint as few packages actually install any .o/.a files. This proposal would remove -ffat-lto-objects from the default LTO flags and packages that actually need the option would have to opt-in via an RPM macro in their .spec file. This should significantly improve build times for most packages in Fedora. To ensure that we can identify packages that need the opt-in now and in the future, the plan is to pass to brp-strip-lto a flag indicating whether or not the package has opted into -ffat-lto-objects. If brp-strip-lto finds .o/.a files, but the package has not opted into -ffat-lto-objects, then brp-strip-lto would signal an error. == Benefit to Fedora == The key benefit to Fedora is improved package build times and lower load on the builders. == Scope == * Proposal owners: The feature owner (Jeff Law) will need to settle on a suitable RPM macro to indicate an opt-in to -ffat-lto-objects, implement the necessary tests in brp-strip-lto and opt-in the initial set of packages. This will be accomplished by doing the prototype implementation locally, building all the Fedora packages to generate the opt-in set. Committing the necessary opt-ins, then committing the necessary changes to the RPM macros. * Other developers: There should be minimal work for other developers. The most likely scenarios where other developers will need to get involved would include: # Packages which are excluded from x86_64 builds and which need the opt-in will need the appropriate package owners to add the opt-in. # Packages which are FTBFS when the builds are run to find the set of packages that need to opt-in and which need to opt-in will need packager attention. # It is possible that the faster builds may trigger build failures in packages that have missing dependencies in their Makefiles. We saw a few of these during the initial LTO work and those packages were either fixed or -j parallelism removed. This work may expose more of these problems. I expect these all to be relatively rare occurences, but with 9000+ packages in Fedora I wouldn't be surprised if we see a few of each of these issues. * Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engineering is needed) This should have no release engineering impacts. * Policies and guidelines: The packaging guidelines will need to be updated to document the new macro. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: This proposal does not align with any current Fedora Objectives. == Upgrade/compatibility impact == This change should have zero impact on upgrade/compatibility. In fact, the change should have no user visible impacts. == How To Test == No special testing is needed. Any issues with this proposal will show up as FTBFS issues. == User Experience == Users should see no changes to the user experience. == Dependencies == Packages which need to opt-in to -ffat-lto-objects will need their .spec files updated to include the new macro. == Contingency Plan == If this can not be completed by final development freeze, then the RPM macro changes would not be installed and the change could defer to Fedora 35. * Contingency mechanism: Proposal owner will only commit the RPM macro changes once the opt-in package set has been identified and opt-ins added to those package's spec files. So no special contingency mechanism should be needed * Contingency deadline: It is most beneficial to have this completed before the mass rebuild; however, the drop dead date should be beta freeze. * Blocks release? No * Blocks product? No == Documentation == No upstream documentation. Packaging guidelines will need a minor update. == Release Notes == I do not expect this change to require any release notes. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

8 16

Assimp soname bump
by Rich Mattes 31 Jul '21

31 Jul '21

Hi, I plan to update assimp from 3.3.1 to the latest release (5.0.1) in rawhide this week. The following packages will be affected: fawkes-0:1.3.0-11.fc33.src mrpt-0:1.4.0-17.fc33.src pioneer-0:20200203-1.fc33.src vkmark-0:2017.08-0.8.20180123git68b6f23.fc32.src I will take care of the rebuilds and any fallout/updates that need to happen. Rich

2 2

How to easily automate test builds in a COPR project
by Richard Shaw 29 Jul '21

29 Jul '21

I maintain a suite of ham radio related packages. The developer is very active and often creates test versions adding and incrementing the "tweak" part of the version which is removed for the full releases and the patch level incremented. Currently I'm just trying to keep up with them by hand using pagure forks of the official repos so I don't accidentally pollute SCM with the changes and build them in COPR. Things I need to manage automagically: 1. Monitor the test URLs to look for new versions. I could write a bash script for this and add a cron or systemd timer but I was hoping for something that took less time as I don't have a lot of that :) Would it be permissible to create a <package>-testing entry in release-monitoring.org? 2. Trigger a "fedpkg clone" and add a tweak version. This could probably be managed with macros easy enough, %{?tweak}, or something like that. And then use a script to substitute into "%global tweak ..." 3. I need to download the files from a different location. %if %{?tweak} ... use difference Source0? 4. Build the packages in COPR. Easy enough using a bash script but is there a better way? Thanks, Richard

6 7

The future of legacy BIOS support in Fedora.
by Jóhann B. Guðmundsson 07 Jul '21

07 Jul '21

Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes it beg the question if now would not be the time to stop supporting booting in legacy bios mode and move to uefi only supported boot which has been available on any common intel based x86 platform since atleast 2005. Now in 2017 Intel's technical marketing engineer Brian Richardson revealed in a presentation that the company will require UEFI Class 3 and above as in it would remove legacy BIOS support from its client and datacenter platforms by 2020 and one might expect AMD to follow Intel in this regard. So Intel platforms produced this year presumably will be unable to run 32-bit operating systems, unable to use related software (at least natively), and unable to use older hardware, such as RAID HBAs (and therefore older hard drives that are connected to those HBAs), network cards, and even graphics cards that lack UEFI-compatible vBIOS (launched before 2012 – 2013) etc. This post is just to gather feed back why Fedora should still continue to support legacy BIOS boot as opposed to stop supporting it and potentially drop grub2 and use sd-boot instead. Share your thoughts and comments on how such move might affect you so feedback can be collected for the future on why such a change might be bad, how it might affect the distribution and scope of such change can be determined for potential system wide proposal. Regards Jóhann B. 1. https://fedoraproject.org/wiki/Changes/CleanupGnomeHiddenBootMenuIntegration

78 316

Remove old GPG keys?
by Miroslav Suchý 04 May '21

04 May '21

I just stumbled upon https://unix.stackexchange.com/questions/400634/does-anyone-bother-to-remov… with the nice link to: https://blog.laimbock.com/2014/05/02/how-to-remove-an-imported-gpg-key-from… And I wonder: is it a good idea to keep old gpg keys in RPM db? Or should we automate the removal of old keys? Mirek

15 29

Thoughts about packaging a standalone python-PyQt5-sip?
by Michel Alexandre Salim 27 Apr '21

27 Apr '21

Hi all, Neal and I are looking at getting ButterManager packaged, and it depends on sip and PyQt5-sip: https://github.com/egara/buttermanager/blob/master/requirements.txt Now, this is where things get a bit odd: - the current sip (4.19.24) does not have autogenerated Python provides, but sip5 does: $ sudo dnf repoquery --provides sip Last metadata expiration check: 1:48:00 ago on Wed 30 Dec 2020 02:50:53 PM PST. sip = 4.19.24-1.fc33 sip(x86-64) = 4.19.24-1.fc33 sip-macros = 4.19.24-1.fc33 $ sudo dnf repoquery --provides sip5 Last metadata expiration check: 1:48:05 ago on Wed 30 Dec 2020 02:50:53 PM PST. python-sip5 = 5.5.0-1.fc33 python3-sip5 = 5.5.0-1.fc33 python3.9-sip5 = 5.5.0-1.fc33 python3.9dist(sip) = 5.5 python3dist(sip) = 5.5 sip5 = 5.5.0-1.fc33 sip5(x86-64) = 5.5.0-1.fc33 - sip ships PyQt5 bindings with matching version, but sip 5 seems to no longer do so $ sudo dnf info python3-pyqt5-sip Last metadata expiration check: 1:51:03 ago on Wed 30 Dec 2020 02:50:53 PM PST. Installed Packages Name : python3-pyqt5-sip Version : 4.19.24 Release : 1.fc33 Architecture : x86_64 Size : 244 k Source : sip-4.19.24-1.fc33.src.rpm Repository : @System From repo : fedora Summary : SIP - Python 3/C++ Bindings Generator for pyqt5 URL : https://riverbankcomputing.com/software/sip/intro License : GPLv2 or GPLv3 and (GPLv3+ with exceptions) Description : This is the Python 3 build of pyqt5-SIP. - https://pypi.org/project/PyQt5-sip/ has PyQt5-sip 12.8.1 but https://pypi.org/project/sip/ has sip 5.5.0 which matches the sip5 in Fedora (available since last month) - there's a lot of packages that depend on python3-pyqt5-sip (though none use the canonical python3dist(pyqt5-sip) unfortunately) $ sudo dnf repoquery --repo rawhide,rawhide-source --whatrequires 'python3dist(pyqt5-sip)' Last metadata expiration check: 0:15:20 ago on Wed 30 Dec 2020 04:28:29 PM PST. $ sudo dnf repoquery --repo rawhide,rawhide-source --whatrequires python3-pyqt5-sip Last metadata expiration check: 0:15:30 ago on Wed 30 Dec 2020 04:28:29 PM PST. calibre-0:4.23.0-3.fc34.x86_64 krita-0:4.4.1-1.fc34.i686 krita-0:4.4.1-1.fc34.x86_64 libarcus-0:4.8.0-1.fc34.src mingw-python-qt5-0:5.15.0-4.fc34.src pyqtwebengine-0:5.15.0-2.fc33.src python-pyface-0:7.1.0-1.fc34.src python-pynest2d-0:4.8.0-1.fc34.src python-qt5-0:5.15.0-5.fc34.src python3-arcus-0:4.8.0-1.fc34.x86_64 python3-arcus-lulzbot-0:3.6.21-8.fc34.x86_64 python3-poppler-qt5-0:0.75.0-6.fc33.x86_64 python3-pyqtchart-0:5.15.2-1.fc34.i686 python3-pyqtchart-0:5.15.2-1.fc34.x86_64 python3-qgis-0:3.16.1-2.fc34.i686 python3-qgis-0:3.16.1-2.fc34.x86_64 python3-qscintilla-qt5-0:2.11.5-1.fc34.x86_64 python3-qt5-base-0:5.15.0-5.fc34.i686 python3-qt5-base-0:5.15.0-5.fc34.x86_64 qhexedit2-0:0.8.9-2.fc33.src scidavis-0:2.3.0-2.fc33.src veusz-0:3.3.1-1.fc34.src veusz-0:3.3.1-1.fc34.x86_64 Any idea what's the best way to handle this? and/or why PyQt5-sip's versioning get so far ahead of sip? Thanks, -- Michel Alexandre Salim profile: https://keyoxide.org/michel@michel-slm.name chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2

4 16

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

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

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

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