== 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
* 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
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
To get beautiful changelogs, you also need to add
%buildsys_name Your name
%buildsys_email Your email
== User Experience ==
N/A Packager experience change only
== Dependencies ==
The change is a spin-off of
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
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
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 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.
Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2020-09-17 16:00 UTC in #fedora-meeting-1 on
Local time information (via. uitime):
================= Day: Thursday ==================
2020-09-17 09:00 PDT US/Pacific
2020-09-17 12:00 EDT --> US/Eastern <--
2020-09-17 16:00 UTC UTC
2020-09-17 17:00 BST Europe/London
2020-09-17 18:00 CEST Europe/Berlin
2020-09-17 18:00 CEST Europe/Paris
2020-09-17 21:30 IST Asia/Calcutta
---------------- New Day: Friday -----------------
2020-09-18 00:00 HKT Asia/Hong_Kong
2020-09-18 00:00 +08 Asia/Singapore
2020-09-18 01:00 JST Asia/Tokyo
2020-09-18 02:00 AEST Australia/Brisbane
Links to all tickets below can be found at:
= Followup Issues =
#topic #907 Which %__foo macros for executables are acceptable?
= Followup Pull Requests =
#topic #pr-814 Add SELinux Independent Policy Guidelines.
= Open Floor =
For more complete details, please visit each individual ticket. The
report of the agenda items can be found at:
If you would like to add something to this agenda, you can:
* Reply to this e-mail
* File a new ticket at: https://pagure.io/packaging-committee
* E-mail me directly
* Bring it up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
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
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
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/
Meeting started by geppetto at 16:00:29 UTC. The full logs are available
* Roll Call (geppetto, 16:00:29)
* Schedule (geppetto, 16:05:11)
* LINK: https://pagure.io/packaging-committee/issue/907 also looks
like it might be done? (geppetto, 16:15:39)
* Open Floor (geppetto, 16:22:26)
* ACTION: decathorpe Look through all the non-meeting tickets to see
if any are stuck and need to be discussed. (geppetto, 16:24:33)
Meeting ended at 16:30:08 UTC.
* decathorpe Look through all the non-meeting tickets to see if any are
stuck and need to be discussed.
Action Items, by person
* decathorpe Look through all the non-meeting tickets to see if any
are stuck and need to be discussed.
People Present (lines said)
* geppetto (34)
* zodbot (16)
* mhroncok (12)
* tibbs (11)
* decathorpe (5)
* King_InuYasha (3)
* limburgher (3)
* carlwgeorge (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
an interesting problem has been reported in Bugzilla 3 years ago:
tl;dr There are generated files in /usr/share/mime without owning packages.
When update-mime-database database is run (by RPM trigger), files are generated
in /usr/share/mime, such as:
│ ├── andrew-inset.xml
│ ├── annodex.xml
│ ├── ...
│ └── zstd.xml
│ ├── audio-cdda.xml
│ ├── ....
│ └── win32-software.xml
The files are generated based on content form multiple packages. I.e.
shared-mime-info cannot list all the files as %ghosts because the list of files
As a specific example, on my system, I have:
The file in packages/ is shipped and owned by the openscad package.
The file in application/ is generated by update-mime-database.
So I guess the questions are:
Should shared-mime-info %ghost all files created by update-mime-database when
only shared-mime-info is installed? (That seems to be easy enough).
Should individual packages shipping mime files %ghost the files generated from
them? E.g. should openscad %ghost /usr/share/mime/application/x-openscad.xml?
Is there a better (possibly automated) way of doing it? Or is it not worth it
and we simply say that the files are OK not being owned?
Please have a look on this issue and give your +1 or -1:
> Golang package review exception to update a lot of packages
I have finish all the Package Reviews and I'm ready for some dist-git action.
Thanks for your time,