co/lead-maintainer sought: python-mailmerge (python)
by Brian (bex) Exelbierd
Hi,
I added python-mailmerge to Fedora Linux as it was super important to
large parts of my work as FCAIC. In my current $dayjob I use it less
frequently, though I know of colleagues who still depend on it.
I'd love to find a maintainer to help me with it. There is a new
release pending, which I suspect will just be "build the rpm with new
code; test it; ship it" level effort. I am happy to hand the whole
thing off to someone or to work with you.
Thank you.
regards,
bex
--
Did this email arrive after work for you? Stop reading it and enjoy
some work/life balance.
Brian "bex" Exelbierd (he/him/his)
Community Business Owner, RHEL Product Management
@bexelbie | http://www.winglemeyer.org
bexelbie(a)redhat.com
2 years, 6 months
co/lead-maintainer sought: gocryptfs+dependencies (go-lang)
by Brian (bex) Exelbierd
Hi,
While I still actively use gocryptfs, I am busy enough with my $dayjob
that I know I am not able to put enough time into maintaining it.
Right now this has been OK as they have stopped new releases while
they get v2.0 out the door. However, that will ship soon.
I'd love to get some help maintaining the main rpm and the 6
dependencies I have for it. I am happy to hand it all over to you or
to work with you.
Thank you.
regards,
bex
--
Did this email arrive after work for you? Stop reading it and enjoy
some work/life balance.
Brian "bex" Exelbierd (he/him/his)
Community Business Owner, RHEL Product Management
@bexelbie | http://www.winglemeyer.org
bexelbie(a)redhat.com
2 years, 6 months
Orphaning the cura-lulzbot package set
by Tom Callaway
This fork of cura has basically been abandoned by upstream, and the new
company that acquired Lulzbot has gone out of compliance with the source
code for the firmware. They have made it very clear that they have no real
interest in working with the community to improve this situation, and I no
longer have any motivation to maintain these packages.
Accordingly, I've orphaned the following packages:
* cura-lulzbot
* lulzbot-marlin-firmware
* CuraEngine-lulzbot
* python-uranium-lulzbot
~spot
P.S. I opened an upstream pull request to add support for the Lulzbot TAZ
Pro and the Mini 2 in the main Cura codebase (still actively maintained). I
would highly recommend that anyone considering reviving these packages
devote their efforts in that direction instead.
2 years, 6 months
Fedora 35 Change: Add Fedora Kinoite as a variant (Self-Contained
Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Fedora_Kinoite
== Summary ==
Introduce Fedora Kinoite as a variant of Fedora alongside Fedora Silverblue.
== Owner ==
* Name: [[User:siosm| Timothée Ravier]] (travier AT redhat DOT com)
* FESCo shepherd: [[User:Ngompa| Neal Gompa]] (ngompa13 A gmail D com)
* SIG: [[SIGs/KDE|KDE SIG]]
== Detailed Description ==
Fedora Kinoite is an immutable desktop operating system featuring the
KDE Plasma desktop. It is based on the same technologies as Fedora
Silverblue (rpm-ostree, Flatpak, podman). Fedora Kinoite is to the
Fedora KDE Spin what Fedora Silverblue is to Fedora Workstation.
We chose the Kinoite name for the following reasons:
* KDE based projects traditionally start with a 'K'
* Kinoite is a blue mineral (https://en.wikipedia.org/wiki/Kinoite),
thus referring to both the 'silver' and 'blue' part of Silverblue and
the blue color of the KDE logo.
* "Kinoite" means "There is a tree" in Japanese
(https://translate.google.com/?sl=auto&tl=en&text=kinoite&op=translate),
thus referring to the 'tree' in 'ostree'.
== Benefit to Fedora ==
This will make Fedora more attractive to users that are interested in
immutable OSes and underlying technologies but would prefer to use the
KDE desktop environment. This should also strengthen Silverblue as
more effort may be put into fixing the issues in the shared
technologies.
== Scope ==
* Proposal owners:
** The KDE SIG will submit the [https://pagure.io/pungi-fedora Pungi
changes] needed to add this new variant to the compose.
** The KDE SIG will submit the changes to add a new sub-package to
[https://src.fedoraproject.org/rpms/fedora-release fedora-release].
** The KDE SIG will maintain the Kinoite specific rpm-ostree config in
the [https://pagure.io/workstation-ostree-config
workstation-ostree-config repo].
* Other developers: N/A (not a System Wide Change)
* Release engineering: Submitted as [https://pagure.io/releng/issue/9952 #9952].
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: The "Fedora Kinoite" trademark has been
[https://pagure.io/Fedora-Council/tickets/issue/344 approved]
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
This edition has been built and made available as an unofficial
preview and can be tested with the instructions from this
[https://fedoramagazine.org/discover-fedora-kinoite/ Fedora Magazine
article].
== User Experience ==
Current limitations (last updated 2021-01-18):
* No rpm-ostree support in Discover (graphical package and update
manager). A Season of KDE is in progress to work on that.
* Partial Flatpak support in Discover.
* [https://pagure.io/fedora-kde/SIG/issue/13 KDE applications are not
yet available as Flatpak from the Fedora registry].
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
Report to the next release.
* Contingency mechanism: N/A (not a System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
* Blocks product? N/A
== Documentation ==
A lot of the known issues impacting Fedora Kinoite are shared with
Silverblue and their resolution is the same:
https://docs.fedoraproject.org/en-US/fedora-silverblue/troubleshooting/.
It is not clear for now if Kinoite specific documentation is needed
but a landing page with pointer to known issues might be good.
== Release Notes ==
Fedora Kinoite has been introduced as a new variant of Fedora Linux
featuring the KDE desktop environment and the same technologies as
Silverblue (rpm-ostree, Flatpak, podman).
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 6 months
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
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, 7 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, 7 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, 7 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, 7 months
pdftk retired?
by Michael J Gruber
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
2 years, 7 months