Fedora 33 network configuration (ifcfg*) migration guide available?
by Peter Boy
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_...).
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
2 years, 6 months
Any thoughts about adding Apache Arrow to Fedora+EPEL ?
by Kaleb Keithley
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 years, 6 months
libvirt and systemd-resolved integration?
by Juan Orti Alcaine
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.
2 years, 6 months
Where has the kernel-doc package gone?
by Nils K
I recently had to perform a bit of development/research where I often had to take a look in the kernel documentation.
Most of the time was spend offline so I wanted to download the `kernel-doc` package however it does not seem to exist.
Some old fedora documentations still refer to it however somewhere in the 2x iteration of fedora it seems to have gone missing.
CentOS 8 also still has it.
Would it be possible to add this back to the repos?
2 years, 6 months
Claiming ownership for gtg and pyhton-liblarch
by Miguel Reis de Araújo
Hello.
The gtg package was retired 3 years ago because of inactive upstream,
but it's been active for a while so I'd like to maintain it. To do
this, I need to become the owner of the "gtg" package and the
"python-liblarch" package, which is a dependency of "gtg" and was also
retired because of inactive upstream, but has returned to activity
along with gtg.
Thanks for your attention.
2 years, 6 months
Re-Launching the Java SIG
by Fabio Valentini
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
2 years, 6 months
Linux 5.13 To Allow Zstd Compressed Modules,
Zstd Update Pending With Faster Performance
by Reon Beon
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
2 years, 6 months
Announcing fmt library soversion bump
by Vitaly Zaitsev
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)
2 years, 6 months