Arduino software outdated on F31
by Ben Pack
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?
3 years, 6 months
FTBFS: chocolate-doom
by Jordan Christiansen
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[1] 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?
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1799222
3 years, 6 months
ImportError: No module named _conf
by Marcin Dulak
https://bugzilla.redhat.com/show_bug.cgi?id=1801065
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
epel6 https://koji.fedoraproject.org/koji/taskinfo?taskID=42704266
```
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
```
epel7 https://koji.fedoraproject.org/koji/taskinfo?taskID=42704200
```
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
```
3 years, 6 months
Fonts packaging policy rewrite proposal
by Nicolas Mailhot
Hi,
A fonts packaging policy rewrite proposal has been pushed to FPC today:
https://pagure.io/packaging-committee/pull-request/934
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
https://www.freedesktop.org/wiki/TextLayout/
– 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
sets.
Major additions:
– better documentation (clearer and more complete)
– better automation (less packager hassle for better and more complete
results)
Major removals:
– tools and scripts
– fixing metadata with ttname
Mostly because no one seems willing to maintain those scripts, or port
ttname to python 3.
https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros/builds/
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,
IBM Plex.
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
guidelines.
Regards,
--
Nicolas Mailhot
3 years, 6 months