Co-maintainers for my ham packages
by Matt Domsch
Due to an impending move to NYC and related downsizing of my house into a
2-bedroom apartment, I'm selling all my ham radio gear. Therefore I won't
be able to test any of the Fedora packages I maintain with actual
hardware. Would anyone be interested in maintaining or co-maintaining
these?
- direwolf - Sound Card-based AX.25 TNC
- CubicSDR - Cross-Platform Software-Defined Radio Panadapter
- liquid-dsp - Digital Signal Processing Library for Software-Defined Radios
- sdrpp - SDRPlusPlus bloat-free SDR receiver software
- SoapySDR - A Vendor Neutral and Platform Independent SDR Support Library
- soapy-rtlsdr - SoapySDR module for RTL-SDR hardware
Thanks,
Matt N5MLD
5 months, 2 weeks
DNF5: Checking signatures of packages installed out of a repository?
by Petr Pisar
Hello,
DNF5 got a complaint
<https://github.com/rpm-software-management/dnf5/issues/991> that "dnf update
https://..." skips verifying package signatures:
$ sudo dnf update https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.... https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2....
[...]
Warning: skipped PGP checks for 2 package(s).
A DNF5 developer confirmed that old DNF4 does not verify signatures too.
The verification happens only for packages comming from a repository. Why DNF5
looks bad is because it actually prints the warning and thus keeps the user
better informed.
The nonchecking behavior probably exists to make installing local packages
easy. If DNF5 would insist on checking the signatures, Fedora users would have
to pass --no-gpgchecks option to their "dnf5" commands to override the new
default, or start signing their packages. As always security is not easy.
Because this an old behavior and some users probably depend on it, enabling
the verification for all cases looks like an abrupt change.
I would would like to hear your opinion: Should DNF5 start verifying all
packages? Should DNF5 keep ignoring signatures for out-of-repository packages?
Or should rather narrow the verification skip to packages from a local file
system? Any other options?
-- Petr
5 months, 2 weeks
Automate your Fedora package maintenance using Packit
by Laura Barcziova
If you're a Fedora package maintainer, we've got an exciting automation
solution for you!
At the beginning of the year, we announced a new feature called
pull_from_upstream that eases the process of bringing upstream releases
into Fedora. This feature can be easily configured directly in the dist-git
repository without access to the upstream (as opposed to our previously
introduced automation). It is most suitable for simple packages with
straightforward update processes (e.g. without patches, or need to build in
side tags).
Our automation works on top of the Upstream Release Monitoring [1], and
here's how to set it up:
1.
Enable Upstream Release Monitoring for your Fedora package: set the
mapping of the project in Anitya and in the left column in
https://src.fedoraproject.org/rpms/$YourPackage, change *Monitoring
status* to *Monitoring*.
2.
Add the Packit configuration with the *pull_from_upstream* job to your
dist-git repository (see example
https://packit.dev/docs/configuration/downstream/pull_from_upstream#example
).
Once set up, here's how it works:
-
Upstream Release Monitoring creates a Bugzilla bug when new upstream
versions are detected.
-
As a reaction to that, Packit:
-
automatically uploads the upstream archive to the lookaside cache,
-
creates dist-git pull request(s) at https://src.fedoraproject.org/
<https://src.fedoraproject.org/rpms/$YourPackage> with all the
necessary changes, like updates to the specfile and sources.
If you are interested in this, read the previously published full post with
the details of the setup here: https://packit.dev/posts/pull-from-upstream.
Since the publication of this post, many users have adopted this feature
and provided valuable feedback, allowing us to enhance the UX. We're now
excited to assist you in automating the process as well!
In addition to creating pull requests in dist-git, Packit can also automate
Koji builds and Bodhi updates:
-
https://packit.dev/docs/configuration/downstream/koji_build
-
https://packit.dev/docs/configuration/downstream/bodhi_update
For complete automation documentation, don't miss our comprehensive Fedora
release guide at: https://packit.dev/docs/fedora-releases-guide. It
contains all the essential information and setup tips.
For any questions, feel free to contact us: https://packit.dev/#contact.
Best regards,
Packit team!
[1]
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release...
5 months, 3 weeks
Request for comment- tuned replacing power-profiles-daemon plan
by Kate Hsuan
Hi Folks,
We would like to replace power-profiles-daemon with tuned. There are
many power-related software that offer similar functions. Advanced
users may install several power management tools, for example, tuned
and power-profiles-daemon (ppd), and get confused about which tools
manage the system and cause unexpected behaviors for the system. By
integrating power-profiles-daemon with tuned, the user can get extra
features to finetune the system, and the basic feature provided by ppd
can be used according to the user's demand. It also can reduce the
efforts of the maintainer.
The impact of this plan would be gnome-control-center (power panel),
KDE, sysprof, and tuned (or some projects depending on ppd). We should
move the ppd API and features to tuned to provide the same features of
it. From the API aspect, we also can design a new API for the basic
feature, ppd provided but the software dependent on ppd should be
modified to use the new API. Although, for the long-term plan, a set
of new API is a good option. For the short-term plan, moving the
original one to tuned is good for those applications depending on ppd.
Moreover, the detailed change proposal can be found here.
https://fedoraproject.org/wiki/Changes/TunedReplacesPower-profiles-daemon
If you have any suggestions, please let us know.
Thank you. :)
--
BR,
Kate
6 months
openmpi 5.0.0 update coming - drops i686 and C++ API
by Orion Poplawski
I'm going to start building openmpi 5.0.0 and its requirements (pmix
4.2.7, prrte 3.0.2) and dependencies in a side-tag starting tomorrow.
Notable changes are:
* Dropping support for 32-bit
* Dropping support for C++ API
* Change in the environment variable to allow oversubscription (running
with more processes than available cores)
I will be making changes to dependent packages to address these changes.
I've been rebuilding deps in COPR
(https://copr.fedorainfracloud.org/coprs/orion/pmix-4.2/builds/) and
most rebuild fine. One exception is MUSIC which depends on the C++ API.
There is a longstanding upstream issue to address this. Hopefully
this will finally get dealt with.
There are no soname bumps, but pmix has proved problematic in the past
but its deps will be rebuilt.
--
Orion Poplawski
he/him/his - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 https://www.nwra.com/
6 months
OK to have same license file in multiple sub-packages?
by Tom Stellard
Hi,
I've run into a problem with the cmake package, and I'm trying to figure out how
to solve it. This issue is that the cmake license files are included in both
the cmake and cmake-doc packages. This creates a conflict when up trying to
update cmake while an older version of cmake-doc is installed on the system.
What's the best way to fix this? Should I remove the license file from cmake-doc
or should I have cmake-doc Require (or Conflict?) with the cmake package?
Thanks,
Tom
6 months, 1 week
