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
9 months, 3 weeks
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
1 year, 10 months
Help reqest: dependencies for packaging writefreely (Golang)
by Edd Salkield
Hi all,
I'm currently working on packaging github.com/writeas/writefreely, a platform for building writing spaces. Some of its dependencies are currently not packaged for Fedora, so I'm seeking some advice on the granularity to which I should be packaging each dependency.
github.com/writeas/writefreely depends on github.com/writeas/web-core. This is a library that is used by the project developers (write.as) for all their shared code. It is likely that this will be used as a dependency for future packages (for example, when their photo sharing service, snap.as, gets released), but unlikely that it will ever be used by anyone other than these developers.
Therefore, should github.com/writeas/web-core be its own package, should I bundle it in with writefreely, should it be a subpackage of writefreely, or indeed something else?
Additionally, web-core has its own dependencies of the same kind. Where possible, I have submitted PRs[1,2,3] to their repo to reduce unnecessary dependencies, but web-core still depends upon github.com/writeas/impart and github.com/writeas/openssl-go. These libraries are both unlikely to be used anywhere else; should these be bundled too?
If the correct course of action is to bundle the dependencies (in a nested way), I would really appreciate somebody experienced at packaging Go packages to give some guidance on how to do this sensibly with the Go SPEC file macro system. This is especially since the current documentation[4] seems pretty light on the topic of dealing with SPEC files with multiple sources.
Also, this is my first time joining a mailing list to actually get involved with the Fedora project, so do let me know if this sort of question actually belongs elsewhere.
Kind regards,
Edd Salkield
[1] https://github.com/writeas/web-core/pull/6
[2] https://github.com/writeas/web-core/pull/8
[3] https://github.com/writeas/web-core/pull/10
[4] https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/
2 years, 8 months
Packaging fish config files
by Orion Poplawski
Background - https://bugzilla.redhat.com/show_bug.cgi?id=1878306
conda can provide an /etc/fish/conf.d/conda.fish file for fish users.
As usual, we do not want to add a dependency on fish for conda. For now
I think I'll just have conda own /etc/fish and /etc/fish/conf.d, but
what do we want to do going forward? Add it to filesystem? Create a
fish-filesystem package?
Surprisingly, I can't find any other packages that ship
/etc/fish/conf.d/* files, so maybe this just isn't an issue worth taking
on yet.
Thanks,
Orion
--
Orion Poplawski
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 https://www.nwra.com/
2 years, 8 months
Summary/Minutes from today's FPC Meeting (2020-09-03 16:00 - 16:45 UTC)
by James Antill
======================
#fedora-meeting-1: fpc
======================
Meeting started by geppetto at 16:00:39 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-03/fpc.2020-09...
.
Meeting summary
---------------
* Roll Call (geppetto, 16:00:39)
* Schedule (geppetto, 16:05:56)
* LINK:
https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproje...
(geppetto, 16:05:59)
* LINK:
https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproje...
(geppetto, 16:08:02)
* #pr-814 Add SELinux Independent Policy Guidelines. (geppetto,
16:08:14)
* LINK: https://pagure.io/packaging-committee/pull-request/814
(geppetto, 16:08:14)
* LINK:
https://pagure.io/packaging-committee/pull-request/814#request_diff
I guess (tibbs, 16:13:11)
* ACTION: mhroncok to speak to authors again, having a working example
might help a lot. (geppetto, 16:34:35)
* #1007 Golang pkg review exception to update a lot of packages
(geppetto, 16:34:56)
* LINK: https://pagure.io/packaging-committee/issue/1007 (geppetto,
16:34:56)
* ACTION: Golang pkg review exception to update a lot of packages
(+1:6, 0:0, -1:0) (geppetto, 16:40:19)
* Open Floor (geppetto, 16:41:22)
Meeting ended at 16:45:43 UTC.
Action Items
------------
* mhroncok to speak to authors again, having a working example might
help a lot.
* Golang pkg review exception to update a lot of packages (+1:6, 0:0,
-1:0)
Action Items, by person
-----------------------
* mhroncok
* mhroncok to speak to authors again, having a working example might
help a lot.
* **UNASSIGNED**
* Golang pkg review exception to update a lot of packages (+1:6, 0:0,
-1:0)
People Present (lines said)
---------------------------
* geppetto (49)
* zodbot (15)
* mhroncok (14)
* King_InuYasha (11)
* tibbs (7)
* carlwgeorge (2)
* decathorpe (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
2 years, 9 months