Automatic virtual provides for RPM macros?
by Miro Hrončok
Hello,
today at Nest, somebody said "unfortunately, there is no way to tell what
package to install to get a particular RPM macro".
I think that having an RPM provides generator for "rpm-macro(__python3)" or
similar should be a fairly simple exercise.
Would you folks consider that useful?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
6 months, 2 weeks
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
Packaging Guidelines for Desktop Applications
by Johan Vromans
The Packaging Guidelines contain a section on the packaging of Desktop files: .desktop files and AppData files.
However, I could not find any information on how to handle applications that work with application-specific documents[*]. For this there must be document icons and XML files installed under %{_datadir}/mime and %{_datadir}/icons. Maybe there is need for some %post processing?
Are there any guidelines for this?
*) Application specific documents e.g. a text processor that handles .doc files. The application has an icon, and the documents (all *.doc files) have their own icon.
2 years
Re: Macro to smoke-test-import a Python module in %check
by Miro Hrončok
On 29. 06. 21 8:28, Felix Schwarz wrote:
>
> Am 28.06.21 um 21:44 schrieb Miro Hrončok:
>> The semantics is quite simple:
>>
>>
>> %check
>> %py3_check_import mymodule mymodule.submodule
>
> Looks great! Thank you.
>
> Please let us know when we should start adding that to our Python packages. :-)
Feel free to test it out in rawhide.
If there is no more feedback, I'll initiate the backports next week.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
2 years, 1 month