devel June 2021

devel@lists.stg.fedoraproject.org

214 participants
345 discussions

Stepping down as Fedora Jam maintainer
by Erich Eickmeyer 13 Aug '21

13 Aug '21

Hello all, A little over a year ago, I came to the Fedora project to revive and modernize the Fedora Jam project. I have successfully done that. My vision was that it would be a great way to help develop and test the most recent advancements in Linux audio. Unfortunately, or fortunately, life has a way of changing for the good or the bad. Back in November, I was offered an opportunity that I could not pass-up: becoming the User Experience Director for the Kubuntu Focus brand of laptops made by MindShareManagement. Since then, I have become an integral member of that team, directly reporting to the CTO, CEO, and President, working directly with the PR and Sales and Marketing directors. It has been a blast, and is a project that works directly with Ubuntu and Debian to create, as we put it, the "Ultimate Linux Laptop". As a MOTU for Ubuntu, this was a perfect fit. I didn't come here to be a shill for Ubuntu or to advertise my work, but rather, to illustrate the level of involvement. It has taken up a majority of my time, and my work with Ubuntu Studio is directly involved with the project as well as both Ubuntu Studio and the Kubuntu Focus laptop have similar synergies. Because of the amount of time involved in these projects, something has to give. For that reason, I must step-down as Fedora Jam maintainer. My plan is to continue to maintain certain packages within Fedora (which, admittedly, I've been slacking on), but I am orphaning the vast majority of my packages. Here's the list: Add64 dssi dssi-vst fedora-jam-backgrounds* fedora-jam-kde-theme* fluidsynth fluidsynth-dssi freqtweak gnome-guitar harmony-seq hexter-dssi jackctlmmc jmeters libinstpatch lv2-c++-tools lv2-fabla lv2-ll-plugins lv2-mdaEPiano lv2-newtonator lv2-sorcer lv2-swh-plugins lv2-vocoder-plugins meterbridge non-daw portmidi radium-compressor realTimeConfigQuickScan whysynth-dssi xsynth-dssi *These packages have pagure repos which I'd be happy to hand over to whoever takes these. I do want to thank everyone for the opportunity, including Matthew Miller, Ben Cotton, Neal Gompa, and many others that helped me revive this project. I'm sad to let it go, and I'm not sure what's going to happen to it, but I hope someone who has a passion for the latest technologies in Linux Audio and music production can take it over. Thanks, Erich Eickmeyer

6 8

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

Weird glibc recursive stack crash in Rawhide
by Richard W.M. Jones 10 Aug '21

10 Aug '21

It seems to affect only qemu for some reason. https://bugzilla.redhat.com/show_bug.cgi?id=1975693#c13 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top

3 5

Macro to smoke-test-import a Python module in %check
by Miro Hrončok 04 Aug '21

04 Aug '21

Hello Python RPM packagers, based on some discussion in the "F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)" thread [0], I've drafted a macro that can help to test-import a Python module in %check when no other tests exist or are when they cannot be executed during build [1]. The semantics is quite simple: %check %py3_check_import mymodule mymodule.submodule When all listed modules are successfully imported, "nothing happens", when at lest one fails to import, the entire build fails. The above line is translated very-roughly to `python3 -c 'import mymodule, mymodule.submodule'` (see the implementation [0] for more accurate representation). Given the Python semantics, it is possible to use commas as module separators as well (but no parentheses). The %buildroot's %pythn3_site{lib,arch} is added to PYTHONPATH. The runtime dependencies are obviously needed for this to work, so they need to be manually BuildRequired or even better, generated in %generate_buildrequires via `%pyproject_buildrequires -r` to use this macro. The macro can be used repeatedly when importing multiple modules at once is undesired (e.g. when only one module can be imported from the same Python interpreter): %check %py3_check_import mymodule.either %py3_check_import mymodule.or Before I merge this and backport to all Fedoras and EPELs, I'd like to know: - Do you have better ideas for the macro name? - Do you have better ideas for the macro semantics? [0] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… [1] https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/99 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

5 9

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

Heads-up: python-starlette 0.15.0 coming to Rawhide (minor API changes)
by Ben Beasley 27 Jul '21

27 Jul '21

In one week, I will update python-starlette to 0.15.0 in Rawhide (https://bugzilla.redhat.com/show_bug.cgi?id=1975613) This includes some minor API changes; please see the release notes at https://github.com/encode/starlette/releases/tag/0.15.0. The following packages depend on this package, with maintainers in parentheses: • python-authlib (v02460) • python-databases (music) • python-fastapi (music); FTBFS due to dependency problems since Python 3.10 (https://bugzilla.redhat.com/show_bug.cgi?id=1968972) Maintainers of potentially-affected packages should have received this email directly. I have rebuilt all packages in a COPR (https://copr.fedorainfracloud.org/coprs/music/starlette-0.15/) without incident (except the pre-existing python-fastapi FTBFS), so I think no changes to dependent packages will be required.

1 3

rpmautospec deployment into production
by Nils Philippsen 25 Jul '21

25 Jul '21

Hi everybody, we've scheduled the rpmautospec plugin to be deployed into production for tomorrow, from 14:00 UTC on. This means installing the relevant packages and restarting kojid processes on the builders, which will restart any tasks which are being processed at that time, i.e. expect delays for builds in-flight at the time. We'll announce when the deployment is done. Cheers, Nils -- Nils Philippsen "Those who would give up Essential Liberty to Software Engineer purchase a little Temporary Safety, deserve neither Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: D0C1 1576 CDA6 5B6E BBAE 95B2 7D53 7FCA E9F6 395D

10 23

F35 Change: Filtered Flathub Applications (System-Wide Change proposal)
by Ben Cotton 21 Jul '21

21 Jul '21

https://fedoraproject.org/wiki/Changes/Filtered_Flathub_Applications == Summary == Enabling third-party repositories will now create a Flathub remote that is a filtered view of Flathub. == Detailed Description == '''''Note that this proposal is about user experience, procedures, and technology - the high-level concept has already been discussed and approved by the Fedora Council and FESCO.''''' Enabling third-party repositories will now create a Flathub remote that is a filtered view of Flathub. This means that applications on Flathub that have been explicitly approved (by a new process proposed here) will be available in GNOME Software and on the <code>flatpak</code> command line. If the user follows following the instructions on https://flatpak.org/setup/Fedora/, then the filter is removed, and the user gets a full view of Flathub. Roughly speaking, the criteria for including software is a) will not cause legal or other problems for Fedora to point to b) does not overlap Fedora Flatpaks or software in Fedora that could easily be made into a Flatpak c) works reasonably well. For Fedora 35, We expect to include all software from the top 50 most popular applications on Flathub that meet these criteria plus selected other software of interest to the Fedora target audience - Fedora community members are welcome to propose additions. Already reviewed: Zoom, Microsoft Teams, Skype, Bitwarden, Postman, Minecraft<br> Other likely software from the top 50: Discord, Anydesk, WPS Office, OnlyOffice, MasterPDFEditor, Slack, UngoogledChromium, Flatseal, WhatsAppQT, GreenWithEnvy The expectation is that many included applications will be things that are hard or impossible to package in Fedora - proprietary applications, Electron-based applications, and so forth. This is consistent with the third-party software policy, and does not reflect a change from what we do currently with third-party repositories. Fedora Workstation Issue: [https://pagure.io/fedora-workstation/issue/108 #108 Add selected Flathub apps to the third-party repos] == Conformance to Fedora policies == The goal here is to be in conformance with the Fedora [https://docs.fedoraproject.org/en-US/fesco/Third_Party_Repository_Policy/ Third-Party Repository Policy]. The current form of this policy was explicitly written and approved with the filtered view of Flathub being one of the use cases. See https://pagure.io/fesco/fesco-docs/pull-request/34 In detail, this proposal meets [https://docs.fedoraproject.org/en-US/fesco/Third_Party_Repository_Policy/#_… Key requirements for third-party repositories]. We consider each application included in the filter as a separate "mini" repository <blockquote> Third-party repositories must be approved by an active Fedora working group or SIG, or by FESCo. Groups who approve the inclusion of third party repositories must have a documented process which allows for community input, which produces a traceable history for each decision (for example, a ticket or other record). </blockquote> The traceable process is filing a merge request to https://pagure.io/fedora-flathub-filter/ <blockquote> Additionally, repositories included in an edition or spin’s third-party repository list must conform to the following requirements: * Just as with any software hosted by Fedora, third party repositories must not contain material that poses an undue legal risk for the Fedora Project or its sponsors. This risk includes, but is not limited to, software with known patent issues, copyright issues, or software tailored for conducting illegal activities. Fedora working groups should evaluate if a proposed addition or provider poses a significant risk, and if in doubt, confer with Fedora Legal for advice. </blockquote> This is done for each pull request to the `fedora-flathub-filter` repository. <blockquote> * Changes made by one Edition or spin should not impact other Fedora editions or spins. </blockquote> Each spin has the ability to include filtered view of Flathub or not. We do not foresee having *separate* filters for different spins. <blockquote> * Working groups and SIGs should maintain oversight over the software that is made available through third-party repositories, to prevent unvetted software being made available to Fedora users. As part of this, third-party repositories should allow easy auditing by Fedora Legal. This requirement implies that third-party repositories should limit themselves to a small number of packages, or that measures should be put in place to define which packages are made available from a particular repository by default. </blockquote> The filter is a "measure ... to define which packages are made available". == Technical implementation == * The <code>fedora-third-party</code> script added by [[Changes/Third_Party_Software_Mechanism]] will also include support for Flatpak repositories. * A new package <code>fedora-flathub-repository</code> will be added with a configuration file <code>/etc/fedora-third-party.d/flathub.conf</code> and a file <code>/etc/flatpak/filters/fedora-flathub.filter</code> that is referenced by the <code>flathub</code> remote when created. * The filter is maintained by the scripts and procedures in https://pagure.io/fedora-flathub-filter/ - additions correspond to pull requests. * If the user explicitly installs Flathub, by, for example, following the instructions on https://flatpak.org/setup/Fedora/, then the filter is removed, and the user gets a full view of Flathub. (This is standard behavior already implemented in the Flatpak client) == Benefit to Fedora == Fedora users who opt-in to third-party software repositories will have immediate access to more software out-of-the-box. == Scope == * Proposal owners ** Add flatpak support to the `fedora-third-party` script ** Add a `fedora-flathub-repository` package that is built from the output of `fedora-flathub-filter` and integrates with the `fedora-third-party` repository package. * Other developers: ** No actions needed * Release engineering: [https://pagure.io/releng/issue/10187 #10187] ** No actions needed * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: No significant alignment == Upgrade/compatibility impact == The expectation is that: * If the system already has a flathub remote installed, nothing happens, whether or not the user has opted-in to third-party software. * If the system does not have a flathub remote installed, and the user opts-in to third-party software at upgrade time, then the filtered-in apps are then available. == How To Test == * On a fresh install or upgrade, if the user opts-in to third-party software, applications such as Skype are visible in GNOME Software and `flatpak search`. * On a fresh install or upgrade, if the user does not opt-in to third-party software, applications such as Skype are not visible in GNOME Software and `flatpak search`. * If https://flatpak.org/setup/Fedora/ is followed before upgrade, the remote remains unfiltered. * If https://flatpak.org/setup/Fedora/ is followed after upgrade, the remote becomes unfiltered. == User Experience == Fedora users who opt-in to third-party software repositories will have immediate access to more software out-of-the-box. == Dependencies == This depends on [[Changes/Third_Party_Software_Mechanism]] == Contingency Plan == * Contingency mechanism: remove the dependency of fedora-workstation-release on `fedora-flathub-repository` * Contingency deadline: release candidate * Blocks release? No - the contingency plan could be used at any point == Documentation == The review process is described at https://pagure.io/fedora-flathub-filter/ == Release Notes == With Fedora 35, if the user opts-in to third-party software repositories selected applications from https://flathub.org are now available by default in GNOME Software, in KDE Discover, and on the Flatpak command line. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

11 19

building against epel8 modules
by Jiri Vanek 16 Jul '21

16 Jul '21

Hello! I have an ordinery package, which builds as is for epel7,and all fedoras, but not for epel8: Package openjdk-asmtools builds fine in fedora, epel7 and rhel8, but not in epel8: CentOS-8 - Extras 4.3 kB/s | 1.5 kB 00:00 Extra Packages for Enterprise Linux 8 - x86_64 75 kB/s | 4.7 kB 00:00 Error: Problem 1: conflicting requests - package maven-compiler-plugin-3.7.0-2.module_el8.0.0+30+832da3a1.noarch is filtered out by modular filtering Problem 2: conflicting requests - package maven-jar-plugin-3.1.0-1.module_el8.0.0+30+832da3a1.noarch is filtered out by modular filtering Problem 3: conflicting requests - package maven-local-5.3.0-2.module_el8.0.0+30+832da3a1.noarch is filtered out by modular filtering web search is failing me. Is there some magical spec switch which is enbaling... modules? or something? Thanx! j. -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09

9 18

← Newer
1
2
3
4
5
6
7
...
35
Older →

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