devel March 2021

devel@lists.stg.fedoraproject.org

208 participants
445 discussions

libvirt and systemd-resolved integration?
by Juan Orti Alcaine 19 Sep '21

19 Sep '21

Hello, In the network bridges that libvirt creates there's a dnsmasq daemon to resolve the VM's IPs. Is there any way to signal systemd-resolved from libvirt to say that in the bridge interface there is a DNS server and a domain? Thank you.

7 13

Re-Launching the Java SIG
by Fabio Valentini 15 Sep '21

15 Sep '21

This past weekend I finally decided to jump off the cliff and attempt to re-launch the Java SIG. It seems there's some interest in keeping the Java stack maintained, it's just not focused or organized right now. What we did when starting the Stewardship SIG seems to have worked out pretty well, so I'm trying to follow in those footsteps here: - new proper FAS / pkgdb group: java-maint-sig ("java-sig" is occupied by an old, unused bot account) - new private mailing list: java-maint-sig (for RHBZ bugs - so, possibly, also CVEs - hence, private) - tracking project on pagure: https://pagure.io/java-maint-sig (for maintenance scripts, tracking tickets, awesome package dashboards, etc.) There's already a public fedora mailing list for Java (java-devel), and and IRC channel (#fedora-java on freenode.net) which we will continue to use. Sadly, the existing wiki page for the Java SIG is hopelessly outdated, so I'm tempted to just scrap it and point readers to the pagure tracking project once it's set up beyond a basic README file. Major upcoming projects for the "new" Java Package Maintainers group include: - managing OpenJDK 11 / Java 11 transition for hundreds of Java packages in fedora 33 - starting to transition well-maintained Java packages from the Stewardship SIG back into Java SIG - possibly porting packages from gradle to maven to fix build issues and broken dependencies - transitioning from old java.net / JavaEE projects to the new ones now under the eclipse-ee4j umbrella I know that - among others - the PKI team, Neuro SIG, and Eclipse maintainers depend on parts of the java stack for their packages, so I hope that we can work together with them on these things, as well. So, if you're interested, please consider joining this group effort. I'll get new members set up with the FAS group / pagure project / mailing list. Let's make this happen. Fabio

36 90

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 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
by Ben Cotton 31 Aug '21

31 Aug '21

https://fedoraproject.org/wiki/Changes/Autoconf_271 == Summary == Autoconf upgrade from version 2.69 to the last upstream version 2.71 in Fedora. == Owner == * Name: [[User:odubaj| Ondrej Dubaj]] * Email: odubaj(a)redhat.com == Detailed Description == Upgrading autoconf from version 2.69 to version 2.71 according to new upstream release. Version 2.70 is skipped due to multiple ABI incompatibilities, where some of them were fixed in version 2.71. Years of development differ these two releases, so problems are expected. This change might easily cause fails during builds of multiple packages, as some of them still require autoconf-2.69. This step must be properly discussed with maintainers of dependent packages, which should forward this change proposal to their upstream projects. == Benefit to Fedora == Brings a stable and up-to-date version of autoconf according to upsteam release. It is expected, that in the future many upstream development teams will use autoconf-2.71 as their default builder, so Fedora will be prepared for such a step. == Scope == * Proposal owners: **Prepare autoconf-2.71 as RPM package for Fedora Rawhide **Check software that requires `autoconf` or `autoconf-2.69` and rebuild it with autoconf-2.71 **Build autoconf-2.71 to Rawhide in a side-tag (https://fedoraproject.org/wiki/Package_update_HOWTO#Creating_a_side-tag) **Rebuild depended packages with autoconf-2.71 in the side-tag **Merge the side-tag to Rawhide * Other developers: **Check if their packages can be build with autoconf-2.71 * Release engineering: [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == Problems during build can appear in multiple packages what can lead to build failure, as multiple packages require autoconf-2.69 as their upstream dependency. These problems have to be resolved before adding autoconf-2.71 into Fedora. It seems aprox. 20% of dependent packages are having problems during build, which could be caused by a problem with same pattern. == How To Test == Rebuilding your packages with autoconf-2.71 dependency in copr (https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/) Mass rebuild of dependent packages in a side tag. == User Experience == Users will be able to use the newer version (2.71) of autoconf, and building packages with autoconf-2.69 won't be available, as it won't be present on the specific fedora version. This can affect 3rd partly packages, which are not part of Fedora. == Dependencies == Hundreds of packages have build dependency on autoconf, therefore it is a huge step forward for Fedora, what should be properly discussed and tested. List of dependent packages with their ability to be built with autoconf-2.71 can be found in the given copr project (https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/packages/) We should also look at dependent packages of `libtool` and `automake` (other critical autotools packages), as there might be some incompatibilities with the new autoconf version. == Contingency Plan == * Contingency mechanism: moving this change to Fedora 36, if not successfully finished until Fedora 35 branching from Rawhide * Contingency deadline: Fedora 35 branching from Rawhide (2021-08-10) * Blocks release? No == Documentation == Latest autoconf documentation: https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/in… == Release Notes == Release notes for autoconf-2.70: https://lists.gnu.org/archive/html/autotools-announce/2020-12/msg00001.html Release notes for autoconf-2.71: https://lists.gnu.org/archive/html/autotools-announce/2021-01/msg00000.html -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

24 82

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

Offering strongswan for (co)maintaining
by Petr Menšík 18 Jun '21

18 Jun '21

Hello, strongswan and NetworkManager-strongswan packages were passed to me from previous maintainer. I admit I have little experience with them and do not run any service based on them. Because IPSsec is quite complex technology, I am looking for help with its maintenance. I was always using OpenVPN based solutions myself, so I guess I am not the best person as main admin. I would like to transfer main admin to anyone doing a good job, not not immediately. That is why I haven't orphaned it already. I would like to keep commit access for a while, but I would share at least commit access with anyone willing to improve those packages. Especially someone using they (almost) everyday would be ideal maintainer. Regards, Petr -- Petr Menšík PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

3 3

Sundials-5.7.0
by Antonio T. sagitter 17 May '21

17 May '21

Hi all. 'sundials-5.7.0' is coming in Rawhide branch. Is reasonable pushing it in f34 too? Release notes: https://computing.llnl.gov/projects/sundials/release-history -- --- Antonio Trande Fedora Project mailto: sagitter(a)fedoraproject.org GPG key: 0x29FBC85D7A51CC2F GPG key server: https://keys.gnupg.net/

3 6

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