When running dnf, Version 1.8.5 is still installed, but this version seems to be 3 years old.
The current version is 1.8.12.
Is there any reason why the current version (or any newer version than 1.8.5) is not used?
I noticed that chocolate-doom wasn't showing up in the package search results, so I decided to look into why and help out if I could.
When the Fedora 32 mass rebuild happened, chocolate doom failed to build because of changes in the default settings in GCC 10. I submitted a patch to upstream to fix it and it was accepted to master. Now I want to make sure that the package makes it into Fedora 32. What needs to be done to make that happen? What is the policy for packages that fail to build? What's the deadline for getting it fixed? If upstream doesn't cut a release before the deadline, should we carry my patch downstream?
I'm performing scratch koji builds based on a src.rpm created on f30,
and starting from today epel6 (koji build --nowait --scratch el6-candidate) and epel7 (koji build --nowait --scratch epel7) builds fail
ERROR: Command failed:
# /usr/bin/dnf --installroot /var/lib/mock/dist-6E-epel-build-19970421-1413977-bootstrap/root/ --setopt=install_weak_deps=0 --disableplugin=local --disableplugin=spacewalk install dnf dnf-plugins-core --setopt=tsflags=nocontexts
Unable to detect release version (use '--releasever' to specify release version)
No matches found for the following disable plugin patterns: local, spacewalk
Last metadata expiration check: 0:00:05 ago on Sun Mar 22 19:43:38 2020.
No match for argument: dnf
No match for argument: dnf-plugins-core
Error: Unable to find a match: dnf dnf-plugins-core
DEBUG util.py:427: Unsharing. Flags: 134217728
DEBUG util.py:600: Traceback (most recent call last):
DEBUG util.py:600: File "/usr/bin/dnf", line 57, in <module>
DEBUG util.py:600: from dnf.cli import main
DEBUG util.py:600: File "/usr/lib/python2.7/site-packages/dnf/__init__.py", line 30, in <module>
DEBUG util.py:600: import dnf.base
DEBUG util.py:600: File "/usr/lib/python2.7/site-packages/dnf/base.py", line 29, in <module>
DEBUG util.py:600: import libdnf.transaction
DEBUG util.py:600: File "/usr/lib64/python2.7/site-packages/libdnf/__init__.py", line 3, in <module>
DEBUG util.py:600: from . import conf
DEBUG util.py:600: File "/usr/lib64/python2.7/site-packages/libdnf/conf.py", line 17, in <module>
DEBUG util.py:600: _conf = swig_import_helper()
DEBUG util.py:600: File "/usr/lib64/python2.7/site-packages/libdnf/conf.py", line 16, in swig_import_helper
DEBUG util.py:600: return importlib.import_module('_conf')
DEBUG util.py:600: File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in import_module
DEBUG util.py:600: __import__(name)
DEBUG util.py:600: ImportError: No module named _conf
I'm stuck on how to reset a service unit on upgrades; originally it
was suggested to me on devel@ to use `fedora-release` but it doesn't
This is the current spec file and line in question:
My best guess at the moment is this should be
%triggerpostun -- fedora-release-common < 32
I have a question raised from an ongoing review process : does every package which provides a library requires to provide unversioned copy of the library?
Here the libpasraw library only provides versioned copy of the library. It's just a private library which is used only by other projects from the same author which require the library only at runtime.
The reviewer asks me to patch the source code to provide an unversioned copy of the library and release it in a -devel subpackage. Is it mandatory to provide an unversioned copy of the lib?
A fonts packaging policy rewrite proposal has been pushed to FPC today:
It should be clearer, more opinionated, and take into account:
– updates of The OpenType standard
– variable fonts
– web fonts
– upstream depreciation of non OpenType formats: final stages of the
Harfbuzz consolidation decided at the 2006 Text Layout summit
– appstream & fonts
– weak dependencies
– and probably more I forget here
It is based on the new fonts-rpm-macros project for automation:
This project builds on tooling enhancements in redhat-rpm-config and rpm
itself, done during the past two years for the Forge and Go sets of
packaging macros. It started 2 years ago as a fork of fontpackages,
which is the core of our current fonts packaging guidelines.
It will require putting the fonts-srpm-macros package in the default
build root, like is done for other domain-specific packaging macro
– better documentation (clearer and more complete)
– better automation (less packager hassle for better and more complete
– tools and scripts
– fixing metadata with ttname
Mostly because no one seems willing to maintain those scripts, or port
ttname to python 3.
showcases the new policy on 62 real-world source packages, generating
139 installation packages. Some of those are badly delayed updates to
Fedora packages, others are brand-new packages ready for Fedora
inclusion. They include major font packages such as Stix, DejaVu, Droid,
Existing Fedora packages will continue to build, the old fontpackages
macros are grandfathered in fonts-rpm-macros for now. They will be
removed in a few years to give packagers time to apply the new