RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal
by Ben Cotton
https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changel...
== Summary ==
redhat-rpm-config will be updated so users of the auto framework get
automated release and changelog bumping.
== Owner ==
* Name: [[User:nim| Nicolas Mailhot]]
* Email: <nicolas.mailhot at laposte.net>
== Detailed Description ==
This is a system-wide change because all packages build with
redhat-rpm-config, but it only concerns packages that opted to use
this part of redhat-rpm-config (auto framework).
The change will make those packages auto-bump and auto-changelog at
the rpm level, in an infrastructure-independent way.
== Benefit to Fedora ==
Autobumping removes a huge packager shore and makes timestamping in
changelogs more reliable.
== Scope ==
* Proposal owners: The feature is coded and works at the rpm level.
Unfortunately, mock filters away the srpms containing the bump state,
so it does not work in upper layers.
* Other developers: The feature requires buy-in by mock developers
(and probably koji developers) to lift the restrictions that block it
above the rpm level. Also, it requires a mechanism to pass the user
name and email that will be used in bumped changelogs (defining two
variables in ~/.rpmmacros is sufficient at rpm level)
* Mock issue: https://github.com/rpm-software-management/mock/issues/599
* Release engineering: https://pagure.io/releng/issue/9567
* Policies and guidelines: maybe eventually if things work out on the
technical level
* FPC issue: https://pagure.io/packaging-committee/issue/998
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This is a pure build tooling update, it changes how things are built
not what is built.
== How To Test ==
A redhat-rpm-config packages with the changes and some example
packages are available in
https://copr.fedorainfracloud.org/coprs/nim/refactoring-forge-patches-aut...
Since the mock/copr layer is currently blocking the feature, you need
to install the redhat-rpm-config and forge macro packages available in
this repo locally. Afterwards you can take any of the example packages
in the repo and rebuild them with rpmbuild -ba to your heart content,
and see the releases bump and the changelogs being updated
accordingly.
To get beautiful changelogs, you also need to add
<pre>
%buildsys_name Your name
%buildsys_email Your email
</pre>
in ~/.rpmmacros
== User Experience ==
N/A Packager experience change only
== Dependencies ==
The change is a spin-off of
https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_mac...
Therefore, it depends on the success of that other change and will
probably need rebasing if the code in this other change evolves during
the redhat-rpm-config merge.
It also depends on mock / copr/ koji buy-in and changes, that may add
their own requirements.
== Contingency Plan ==
There is no contingency plan because the change will happen or not at all.
== Documentation ==
There is as much documentation as the average redhat-rpm-config change
(ie comments in the macro files themselves)
== Release Notes ==
N/A Packager productivity change only
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 1 month
Odd problem with obsoletes in EPEL8
by Martin Jackson
Hello,
I'm having a problem I don't understand how to fix, and I would
appreciate some guidance. I'm maintaining nagios-plugins, which bundles
a number of different "check" plugins and has some metapackages that
include different subsets of those check plugins.
In the EL 8.2 release cycle, one of the dependencies of one of those
plugins was moved from EPEL into EL proper, which broke new installs of
that plugin and the -all metapackage. A user filed a bug, so as a
temporary workaround, I stopped building the plugin package with that
dependency (nagios-plugins-ssl_validity, and had that version
(nagios-plugins-2.3.3-3) obsolete the ssl_validity plugin, since leaving
it around caused it to want to keep the base package in conflict with
other packages that were upgrading.
Now that CentOS 8.2 is released, and the dependency is available, I've
issued an update
(https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-70bcfe5382)
that builds ssl_validity again, and also adds it back to the -all
subpackage. I can upgrade it sucessfully (which installs the
ssl_validity plugin again, as expected), but subsequent calls to dnf
upgrade give this error:
Obsoleting Packages
nagios-plugins.x86_64 2.3.3-3.el8 epel
nagios-plugins-ssl_validity.x86_64 2.3.3-4.el8 @epel-testing
nagios-plugins 2.3.3-3 is not installed anymore, and there are no
explicit Obsoletes: in the ssl_validity package. I'm not sure what
needs to be done here, but whatever it is I'm willing to make the
change. Also wondering if this is expected behavior.
Thanks,
Marty
2 years, 2 months
Directory ownership of %{_datadir}/icons/hicolor
by Otto Urpelainen
Hello packagers,
I have problems interpreting Packaging Guidelines section File and
Directory Ownership [1] for icons application place in
%{_datadir}/icons/hicolor. I ran into this during package review for
dosbox-x [2], but I think the issue is more general than that, because
many applications add their icons to the (default, fallback) hicolor theme.
So the package places application's icon to
%{_datadir}/icons/hicolor/scalable/apps/dosbox-x.svg. From the
guidelines, it is clear that for all directories in the chain, one of
the following has to be true:
1. Package owns the directory
2. A dependency package owns the directory
3. _filesystem_, _man_ or "other explicitly created -filesystem
package" own the directory
Item 3 takes care of %{_datadir}/icons part, because that is included in
_filesystem_. The remainder hicolor/scalable/apps is unclear for me.
Method 1 could be used. But there is also package _hicolor-icon-theme_.
Is that package an "explicitly created -filesystem package", so method 3
could be used? That would feel natural, because hicolor is the fallback
theme that must exist according to freedesktop.org specification.
Related but separate question about the guidelines: Section Unowned
Directories:Inaccessible Directories [3] discusses a problem that is
only relevant to Fedora < 9 and RHEL < 5.3. It does not really contain
any information that is relevant today. Should that section simply be
removed?
Otto
[1]:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_dire...
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=1919639
[3]:
https://docs.fedoraproject.org/en-US/packaging-guidelines/UnownedDirector...
2 years, 2 months
Macro to smoke-test-import a Python module in %check
by Miro Hrončok
Hello Python RPM packagers,
based on some discussion in the "F35 Change: Python Packaging Guidelines
overhaul (System-Wide Change proposal)" thread [0], I've drafted a macro that
can help to test-import a Python module in %check when no other tests exist or
are when they cannot be executed during build [1].
The semantics is quite simple:
%check
%py3_check_import mymodule mymodule.submodule
When all listed modules are successfully imported, "nothing happens", when at
lest one fails to import, the entire build fails. The above line is translated
very-roughly to `python3 -c 'import mymodule, mymodule.submodule'` (see the
implementation [0] for more accurate representation). Given the Python
semantics, it is possible to use commas as module separators as well (but no
parentheses).
The %buildroot's %pythn3_site{lib,arch} is added to PYTHONPATH.
The runtime dependencies are obviously needed for this to work, so they need to
be manually BuildRequired or even better, generated in %generate_buildrequires
via `%pyproject_buildrequires -r` to use this macro.
The macro can be used repeatedly when importing multiple modules at once is
undesired (e.g. when only one module can be imported from the same Python
interpreter):
%check
%py3_check_import mymodule.either
%py3_check_import mymodule.or
Before I merge this and backport to all Fedoras and EPELs, I'd like to know:
- Do you have better ideas for the macro name?
- Do you have better ideas for the macro semantics?
[0]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
[1] https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/99
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
2 years, 2 months
Re: Licensing question
by Ian McInerney
On Tue, Jun 29, 2021 at 1:09 PM Nicolas FORMICHELLA <stigpro(a)outlook.fr>
wrote:
> Hello,
>
> Currently wanting to repakage kicad for EL8 (to propose it to EPEL/RPM
> Fusion ultimately), I would like to have a precision about the
> liscencing for Fedora packages specfiles, mainly what licences those
> are under.
> It would really save me a lot of time if I could take the file as a
> basis and just adjust what is needed for a port.
>
>
Why do you want to repackage it instead of requesting an EPEL8 branch on
the existing package in the Fedora repo? Also, KiCad's license is
compatible with Fedora (and we already have a Fedora package for version
5.1 of it), so I don't see why RPMFusion needs to be brought into this.
-Ian
2 years, 2 months
Licensing question
by Nicolas FORMICHELLA
Hello,
Currently wanting to repakage kicad for EL8 (to propose it to EPEL/RPM
Fusion ultimately), I would like to have a precision about the
liscencing for Fedora packages specfiles, mainly what licences those
are under.
It would really save me a lot of time if I could take the file as a
basis and just adjust what is needed for a port.
Nicolas FORMICHELLA
GPG KEY : E8E2E5902F07A9CFE33962BD6CF8D3A4170BD77B @ keys.openpgp.org
2 years, 2 months