devel July 2021

devel@lists.fedoraproject.org

194 participants
365 discussions

Fedora 33 network configuration (ifcfg*) migration guide available?
by Peter Boy 27 Sep '21

27 Sep '21

With Fedora 33 network configuration is by default persisted in /etc/NetworkManager/system-connections/*.nmconnection files. The old /etc/sysconfig/network-scripts/ifcfg* files are „legacy“. They are still being processed for the time being, but obviously it is time to migrate. (cf https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_if…) Is there a kind of „mapping“ ifcfg-* —> *-nmconnection. ? Most items are simple to migrate, but servers in particular sometimes have unusual configurations, e.g. - for p2p Connections: SCOPE="peer xxx.yyy.zzz.aaa" - and corresponding a lot of (ADDRESSx / NETMASKx / GATEWAYx ) entries in route-{ifname} file How do I handle that kind of config items in *.nmconnection ? The "search engine I trust" couldn't answer that for me (or I couldn’t ask the right question). Thanks Peter

7 9

Any thoughts about adding Apache Arrow to Fedora+EPEL ?
by Kaleb Keithley 21 Sep '21

21 Sep '21

Hi, Ceph is on the threshold of adding a dependency on Apache Arrow[1]. Ceph has had a long history of bundling dependencies so that they can be built when the platform either doesn't have the dependency or the dependency is too old. But this time, for a number of factors, the preference is to not bundle it. At this point I'm just exploring the possibility of getting it added to Fedora; whether anyone has any show stopper objections, etc. Let me know if you have any objections or questions. Thanks [1] https://arrow.apache.org/ -- Kaleb

2 2

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

Linux 5.13 To Allow Zstd Compressed Modules, Zstd Update Pending With Faster Performance
by Reon Beon 12 Sep '21

12 Sep '21

LINUX KERNEL -- Adding to the variety of places where the Linux kernel supports making use of Zstd compression, kernel modules moving forward can now enjoy size reductions with Zstd. Linux already supports optional Gzip and XZ compression of kernel modules while beginning with Linux 5.13 there is support added for Zstd. In user-space, KMOD 28 already supports dealing with Zstd-compressed modules. The compressed modules are suffixed .ko.zst. The support for Zstd compressed kernel modules was sent in as part of the Kbuild updates for the Linux 5.13 merge window. The Kbuild updates also include more LLVM Clang compiler handling work and other alterations, including an indicator whether the kernel was built with link-time optimizations (LTO). Separate from the Kbuild updates and likely for post-5.13, there is renewed work on getting the latest Zstd code within the kernel updated against the upstream state. These patches get the Zstd code in the kernel updated against the latest upstream code, which is much newer than the current Zstd 1.3.1 derived code in the kernel. The Zstd kernel code is now generated automatically from the upstream Zstd code. With this pending Zstd code update for the kernel, Btrfs with Zstd compression is 5~15% faster, SquashFS decompression is ~15% faster, F2FS Zstd is 3~20% faster, kernel Zstd decompression is 35% faster, Zram decompression and read is 30% faster, and initramfs Zstd compression is around 5% faster. Plus there are bug fixes and other improvements in re-basing the kernel's Zstd code-base. https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.13-Zstd-Modules

6 12

Announcing fmt library soversion bump
by Vitaly Zaitsev 09 Sep '21

09 Sep '21

Hello. fmt 8.0.x update will include soversion bump from .7 to .8. All dependent packages must be rebuilt in Rawhide. -- Sincerely, Vitaly Zaitsev (vitaly(a)easycoding.org)

7 19

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

perl-Data-Properties License change
by Emmanuel Seyman 07 Sep '21

07 Sep '21

Hello, folks. Sometime over the coming week, I'm going to update the perl-Data-Properties package from the current 0.02 to 1.05. Among other changes, the license changes from ASL 2.0 to the Perl license (GPL+ or Artistic). Please holler if this creates a problem for you. Regards, Emmanuel

1 1

replace memtest86+ with pcmemtest, needs maintainer
by Chris Murphy 03 Sep '21

03 Sep '21

[Bug 1988142] memtest boot entry on Fedora install media does not work since Fedora-Rawhide-20210728.n.3 https://bugzilla.redhat.com/show_bug.cgi?id=1988142 This bug might be gcc, but also includes a note about the upstream being kinda weak, possibly non-existent these days. Neal Gompa mentioned pcmemtest earlier this year https://github.com/martinwhitaker/pcmemtest It would need a maintainer. Any takers? Fedora doesn't have a release criterion covering the memory tester, or really any option appearing in the install media's boot menu other than the one that launches the installer. But I think it's better to not ship a memory tester at all, than to ship a broken one (given the options). Memtest86+ is bios only, where pcmemtest can be compiled to run on either firmware type. If we want it to work with UEFI Secure Boot enabled, it'd need to be signed with Fedora's key (I think the same as the one used for GRUB and/or the kernel?). This would be in scope for Fedora 36, assuming the above bug can be easily fixed. But if that bug is hard to fix, and pcmemtest could be a drop-in replacement (i.e. bios only, just like now) maybe that's doable for Fedora 35, and better than having no memory tester. Chris Murphy -- Chris Murphy

12 27

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

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel July 2021