License field is now “effective license” in agenda, appeditor, gaupol, harmonyseq, libinstpatch, notejot, sequeler
by Benjamin Beasley
I’ve updated several of my packages to use only the “effective license” in their License fields, in cases where it was very clear that a single effective license was correct. The following packages are affected:
- agenda: “GPLv3+ and GPLv2+ and LGPLv2+ and CC0” becomes “GPLv3+”
- appeditor: “GPLv3 and LGPLv2+ and CC0” becomes “GPLv3”
- gaupol: “GPLv3+ and CC0” becomes “GPLv3+”
- harmonyseq: “GPLv3+ and GPLv2+ and CC0” becomes “GPLv3+”
- libinstpatch: “LGPLv2 and Public Domain” becomes “LGPLv2”
- notejot: “GPLv3+ and GPLv2+ and CC0” becomes “GPLv3+”
- sequeler: “GPLv3+ and GPLv2+ and LGPLv2+ and CC0” becomes “GPLv3+”
2 years, 9 months
pyproject-rpm-macros can now install Python BuildRequires from
requirements files
by Tomas Hrnciar
Hello,
a new version of pyproject-rpm-macros (0-43) landed in Rawhide. I'll try to
briefly summarize what is new.
%pyproject_buildrequires macro can now optionally take file names as
positional arguments and generate additional build dependencies from them.
You can supply multiple file names to %pyproject_buildrequires macro. E.g.:
%generate_buildrequires
%pyproject_buildrequires requirements/tests.in requirements/docs.in
This adds the requirements listed in the files as python3dist(...)
BuildRequires. Other usages of %pyproject_buildrequires remains the same as
before.
In case you want to use this feature without using the Python build system
(PEP517/setup.py) you can use a new -N (i.e. "No build system") option to
only install the dependencies from the provided files. With -N, any other
automatic generation of requirements is entirely disabled. -N option cannot
be used in combination with other %pyproject_buildrequires options (-r, -e,
-t, -x). In order to use the -N option, you need to have
pyproject-rpm-macros >= 0-43 installed on your developer machine as well
(or no version of that package at all).
Updates are ready for Fedora 33 and 34:
F34: https://bodhi.fedoraproject.org/updates/FEDORA-2021-5476e05676
F33: https://bodhi.fedoraproject.org/updates/FEDORA-2021-cc2936539e
Backport for CentOS Stream 9 can be found here:
https://gitlab.com/redhat/centos-stream/rpms/pyproject-rpm-macros/-/merge...
Regards,
Tomáš Hrnčiar
2 years, 9 months
Bochecha unavailable for a little while
by Pierre-Yves Chibon
Good Morning Everyone,
I am in contact with bochecha who has asked me that I announce his
un-availability for personal reason for a little while.
To this end, he has orphaned the package "buildstream" on Wednesday. There may
be more coming.
Bochecha still wants to come back to Fedora once things have settled down but he
didn't want for anything to wait on him while he is not available.
Pierre
2 years, 9 months
libavif soname bump
by Robert-André Mauchin
Hello everyone,
I'm planning a soname bump from 11 to 12 in libavif for version 0.9.2.
The affected packages are:
darktable-3.4.1-3.fc35.x86_64 libavif.so.11()(64bit)
gd-2.3.2-5.fc35.x86_64 libavif.so.11()(64bit)
kf5-kimageformats-5.83.0-1.fc35.x86_64 libavif.so.11()(64bit)
I will rebuild them using my PP.
If anyone has a question regarding this, feel free to leave any input.
Best regards,
Robert-André
2 years, 9 months
Cascading library dependencies with different versions?
by Richard Shaw
I had a hard time trying to describe what I'm talking about, perhaps
there's actually a term for it, but as I go through all the dependencies of
OpenEXR I wanted to know if this is a problem or not which I think is best
shown by example:
So part of the dependency chain for blender is:
Blender
---> OpenEXR
---> OpenVDB
---> OpenEXR
So is it OK for OpenVDB to link against OpenEXR 2.x (openexr2) while
Blender links with OpenEXR 3.x? Or does the whole dependency stack need to
be upgraded at one time?
Thanks,
Richard
2 years, 9 months
