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
Fedora Update Policy
by Brad Bell
I have a package that runs all it's automated tests during the `%check phase` of the build process.
I am not sure what I should specify, for this case, during the `fedpkg updae` command ?
It seems that my updates have gotten stuck, with the options I have tried.
For example, see `20210000.3-3.fc33` on
http://rpms.remirepo.net/rpmphp/zoom.php?rpm=cppad
How can I move this version to `base` for fedora-33 ?
2 years, 6 months
Adding a metainfo file to a package
by Matti Pulkkinen
Hello!
I recently reported a bug [1] against RStudio because it wasn't showing
up in Gnome Software. The problem seems to have been that the package
did not ship a metainfo file. I tried making a metainfo file for this
package and attached it to the bug report, and it has since been added
to the package. However, RStudio still does not show up in Gnome
Software. Does something else still need to be done, or is the file I
created just bad?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1928992
--
Terveisin / Regards,
Matti Pulkkinen
2 years, 7 months
golang macros in epel
by Mattia Verga
Hello folks,
I'm trying to fix reg package FTB and I've successfully managed to port the specfile to use golang macros in Rawhide [1].
However, since the package is needed in Fedora infrastructure to run registry server, I would like to make it build in EPEL also. As I can see from scratch builds, golang macros don't exist in epel7 ('%gometa' is not recognized there), while in epel8 they seems to exist, but I get a failure in %prep section [2]:
+ %goprep -ke
/var/tmp/rpm-tmp.Zw57Mq: line 46: fg: no job control
Can anyone give me some advice how to handle that?
Thanks.
Mattia
[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=62621577
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=62621583
2 years, 7 months
Python extras: underscore supported?
by Frank R Dana Jr.
I recently committed[1] an updated package spec for python-webscrapbook[2].
Its setup.py file contains the following lines:
extras_require={
"adhoc_ssl": ["cryptography"],
},
I therefore wanted to include 'adhoc_ssl' as a Python Extras subpackage, as
documented[3] in the Packaging Guidelines.
However, if I remove the '%if 0' wrapper around line 36 in my spec file:
%{?python_extras_subpkg:%python_extras_subpkg -n python%{python3_pkgversion}-%{pypi_name} -i %{python3_sitelib}/*.egg-info adhoc_ssl }
a `fedpkg --release f33 local` build fails with the following errors:
~~~~~~~~~~~~~~~~
Processing files: python3-webscrapbook+adhoc-0.33.3-1.fc33.noarch
Error: The package name contains an extras name `adhoc` that was not found in the metadata.
Check if the extras were removed from the project. If so, consider removing the subpackage and obsoleting it from another.
error: Dependency tokens must begin with alpha-numeric, '_' or '/': *** PYTHON_EXTRAS_NOT_FOUND_ERROR___SEE_STDERR ***
Error: The package name contains an extras name `adhoc` that was not found in the metadata.
Check if the extras were removed from the project. If so, consider removing the subpackage and obsoleting it from another.
error: Dependency tokens must begin with alpha-numeric, '_' or '/': *** PYTHON_EXTRAS_NOT_FOUND_ERROR___SEE_STDERR ***
Provides: python-webscrapbook+adhoc = 0.33.3-1.fc33 python3-webscrapbook+adhoc = 0.33.3-1.fc33 python3.9-webscrapbook+adhoc = 0.33.3-1.fc33
~~~~~~~~~~~~~~~~
...As you can see, it's trying to package a nonexistent extra named
'python3-webscrapbook+adhoc', rather than the expected
'python3-webscrapbook_adhoc_ssl'.
Running `pip3 install --user 'webscrapbook[adhoc_ssl]`, executes fine (and checks
that the cryptography package was installed, as required by the adhoc_ssl extra),
so 'adhoc_ssl' does appear to be a valid Python package extra name.
I tried wrapping the extra name in double quotes, I tried backslash-escaping the
underscore... nothing seems to work.
* Am I doing something wrong?
* Do the RPM macros for extras not support names with underscores?
* Is there any way to convince them to take an extra name containing an underscore?
[1]: https://src.fedoraproject.org/rpms/python-webscrapbook/c/26f5e10fe03aa5b6...
[2]: https://src.fedoraproject.org/rpms/python-webscrapbook
[3]: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_python...
2 years, 7 months
Updating one-off contributions documentation
by Otto Urpelainen
Hi,
I would like to update the instructions for [One-off contributions][1]
to packages. First, they are outdated, there is no need for external Git
hosting since the anonymous checkout from src.fp.o method can now be
used. Second, anyone needing that info is probably new to Fedora
packaging and would appreciate something else than two terse paragraphs
added to the bottom of very detailed article that they cannot actually
utilize due to missing permissions.
Currently, the documnetation is in the wiki. Am I correct that this kind
of content should go to docs.fp.o? If so, I can make a pull request to
move it. Either the whole _Joint he package collection maintainers_
page, or just the one-off contributions section. Does anybody here know
what would be the correct course of action?
Docs would be a better location for the one-off contributions section in
particular. If anyone needs that information, they likely do not have
the required groups in the Fedora Accounts to update the wiki. In case
they discover anything is wrong or missing. With docs, that is not a
problem, since the pull request method works there.
Regards,
Otto
[1]:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#On...
2 years, 7 months
