Upstream tip wanted: CI service for Big Endian acrhes
by Miro Hrončok
Recently I've reported some Big Endian related test failures to an
upstream project [0].
I was asked by an upstream project maintainer, whether I know some free
Continuous Integration services where they can easily run their
testsuite on Big Endian.
Any tips?
* Upstream uses Travis CI to test on x86_64 Linux (Ubuntu)
* Upstream uses AppVeyor to test on Microsoft Windows
* It's a pure Python project, noarch, but some changes need to be done
when loading/saving binary data (LE) with NumPy on BE system.
What I've considered:
* COPR (but there is no big endian arch)
* (Ab)using Koji (I guess that would be considered a bad practice?)
* using QUEMU on Travis CI [1]
Any better tips? Thanks
[0] https://github.com/mikedh/trimesh/issues/249
[1]
https://developer.ibm.com/linuxonpower/2017/07/28/travis-multi-architectu...
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
2 years, 5 months
Meaning of Size Directories
by Sergio Belkin
Hi,
Tools such as ls or stat report the size of a directory. Of course it is
not the content size.
stat -c %s /home/sergio/.config
6550
What does 6550 mean in btrfs context?
Thanks in advance!
--
--
Sergio Belkin
LPIC-2 Certified - http://www.lpi.org
2 years, 6 months
What to do about EPEL package branch with no active maintainer?
by Henrik Nordström
I recently took over Radare2 maintenance for Fedora after it was
orphaned, and now noticed it is also packaged in EPEL-8.
I am not in a good position to actively maintain the EPEL-8 release. I
am not an EPEL user, no interest in EPEL, and and not very comfortable
with doing "blind" maintenance by simply merging changes from fedora
and and hope for the best.
The question is then what should be done with the stale and known
broken EPEL branch of the package? Just let it bitrot further?
Anyone who wants to maintain the EPEL-8 branch of Radare2?
Or co-maintain the Fedora version?
Regards
Henrik
2 years, 6 months
Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/DefaultPipeWire
== Summary ==
This change proposal is to route all audio from PulseAudio and JACK to
the PipeWire Audio
daemon by default.
== Owner ==
* Name: [[User:Wtaymans| Wim Taymans]]
* Email: wim.taymans(a)gmail.com
== Detailed Description ==
Currently, all desktop audio is handled by the PulseAudio daemon.
Applications make use of the
PulseAudio client library to communicate with the PulseAudio daemon
that mixes and manages the audio streams from the clients.
The desktop shell (gnome-shell) and the control panel
(gnome-control-panel) both use the
Pulseaudio client libraries to manage the volume and configuration of
the PulseAudio daemon.
This proposal is to replace the PulseAudio daemon with a functionally
compatible implementation
based on PipeWire. This means that all existing clients using the
PulseAudio client library
will continue to work as before, as well as applications shipped as Flatpak.
All PRO audio is handled with the JACK client library, which talks to
the JACK server. This
proposal will install a JACK client library replacement that talks
directly to PipeWire. All
existing PRO audio jack applications will then work on top of PipeWire.
For legacy ALSA clients, we will install an ALSA plugin that routes
the audio directly to
PipeWire.
With these 3 changes, all audio will be routed to PipeWire. There will
then be no more need to
install the PulseAudio and JACK daemons.
== Feedback ==
The owner of this proposal has been in context with both the
PulseAudio and JACK maintainers and community.
PipeWire is considered to be the successor of both projects.
== Benefit to Fedora ==
The end goal is to end up with one audio infrastructure for both
Desktop and Pro audio use cases.
This will end the fragmentation of the audio landscape.
Some of the benefits that PipeWire will bring:
* PRO Audio features
PipeWire can support both Desktop and PRO Audio use cases. PRO
Audio application tend to use
the JACK API and JACK daemon, which is hard to setup and integrates
poorly with the rest of
the system (and PulseAudio in particular).
With a replacement libjack library, PRO Audio application can run
directly on PipeWire and
integrate seamlessly with other ALSA and PulseAudio applications.
This would bring Fedora
closer to the experience of other operating systems.
* Flexibility/Integration
PipeWire is designed to be multiprocess. It separates the
processing of the multimedia graph
and the management into separate processes. This makes it possible
to better integrate with
the other system components or swap out the default policy for a
highly customized one (such as
for automotive or embedded). This is in contrast to PulseAudio,
which has all logic embedded
into the daemon with limited configuration options.
In the next phase we expect to greatly expand the user experience
and configuration of the
audio infrastructure with better integration throughout the system.
* Performance
PipeWire was designed for high performance and low-latency, using
much of the same design as
JACK. JACK application should run with comparable performance even
in low-latency situations.
* Security
PipeWire enforces per client security. Object visibility and the
actions on them can be
configured independently per client. This makes it possible to
enforce a security policy for
sandboxed applications (Flatpak) such as denying access to certain
audio capture devices or
block them from interfering with other applications.
* Maintainability
Both PulseAudio and JACK have very slow development cycles with few
new features. The more
flexible and distributed nature of the design of PipeWire should
encourage more new features
and use-cases.
== Scope ==
* Proposal owners:
We would make a pipewire-pulse package that provides the same features
as the pulseaudio (daemon) package.
We would only provide a drop-in replacement daemon, the pulseaudio
client libraries will remain unchanged.
The idea is that when installing pipewire-pulse, only the pulseaudio
package is removed and replaced by the
pipewire-pulse implementation. In the same way, installing the
pulseaudio package would remove the pipewire-pulse
package, making it possible to switch between implementations. This
will also allow for an easy rollback.
We also need to check and correct the dependencies of other packages.
As of this writing, some packages do
not state their dependencies correctly and get removed when pulseaudio
is removed. We also need to check the
JACK to make sure they still install with the replacement JACK client library.
The JACK client libraries will be installed in the same way, removing
the old JACK client libraries.
* Other developers:
The distribution needs to default to the pipewire-pulse package
instead of pulseaudio.
JACK applications need to install the pipewire-libjack client library.
* Release engineering: [https://pagure.io/releng/issues #Releng issue
number] (a check of an impact with Release Engineering is needed)
* Policies and guidelines:
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
The pulseaudio package will be uninstalled and pipewire-pulse will be installed.
pipewire-pulse does not yet implement all the features of pulseaudio
but it is expected that
comparable functionality will be implemented later. Most notable
features that are likely
not going to be available for fedora 34
* avahi network discovery and audio routing. This is not enabled by
default but can be activated
with paprefs. this includes TCP and RTP transport of audio.
* make devices available as UPNP media servers. Not enabled by
default, paprefs can be used.
* easy configuration of combining all sinks. Questionable feature but
possible via paprefs.
User scripts will still work but custom configurations of the
pulseaudio daemon will not be used
anymore.
Most of the JACK workflow of managing the JACK daemon is not going to
be needed anymore as things
will work out-of-the-box. As of this writing, these things are missing
from the JACK implementation,
we hope to implement them before fedora 34:
* latency reporting: useful to align streams
* freewheeling: used when rendering a project
* jackdbus: used by some tools to manage the graph
== How To Test ==
This change needs to be tested on as many different audio cards as
possible. The same test plan applies here as with PulseAudio.
To test, one needs to install the pipewire-pulse library (which
removes the pulseaudio package).
To test the JACK support, one needs to install pipewire-libjack, which
removes the original
JACK client and server.
After these changes, a restart is needed to make sure the new
pipewire-pulse daemon is running.
Audio functionality should be like it was before with the Pulseaudio
daemon. Some things to verify:
- patcl info should now list: Server Name: PulseAudio (on PipeWire 0.3.x)
- gnome-control-center: check the audio tab, check the volume sliders
and do the audio channel test. Change the card profile, plug/unplug
headphones and observe correct
switch.
- pavucontrol: check volumes in the input devices tabs and check the
microphone volumes
- firefox: check out a website with audio/video such as youtube and
verify that audio works as
usual. Check out a website with a video chat test page
(bluejeans.com/111).
- rhythmbox: check if playback works as expected
- bluetooth devices, connect as usual and verify working behaviour
with PipeWire. Check volume changes etc.
- Regular system usage and performance should not change.
- JACK tools such as catia, carla should run and can be used to
inspect the graph.
== User Experience ==
In general, users should not be able to see any change when using
PulseAudio applications.
The big change is when using JACK application:
- They will start without having to configure and start the daemon.
this includes
the period size and sample rates.
- All devices will be visible in the graph with meaningful names. Devices will
be automatically slaved when needed without needing any configuration.
- bluetooth devices will be usable as well.
== Dependencies ==
Other packages might need to have their requirements fixed to work
with the replacement packages
but this is under our control.
== Contingency Plan ==
* Contingency mechanism: Keep existing pulseaudio and JACK client
libraries as defaults
* Contingency deadline: beta freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
[https://pipewire.org](PipeWire website)
[https://www.youtube.com/watch?v=8LZt4loZu64&t=14s](Video with Current status)
[https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/INSTALL.md...
guide)
[https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/README.md]...
to use/test)
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 6 months
F34 gdm login prompt goes crazy when a fingerprint reader with no
enrolled prints is present
by Hans de Goede
Hi Benjamin, Ray,
I noticed this problem while dogfooding F34, I'm fully up2date as of today.
Today's gdm update did help in making the problem more clear.
What happens is that as soon as I press enter / click my main user in gdm,
the password entry box keeps getting updated (and clearing its content)
every 1 - 2 seconds with a "failed to authenticate with fingerprint"
(or something like that) briefly showing below the password entry box
every time it gets cleared.
After a non-fixed amount of tries it stops doing this and only then I
can successfully login. The same happens on the lock screen of gnome-shell,
except that there it never stops doing this.
The "failed to authenticate with fingerprint" is new as of todays
gdm update, before this it was just "failed to authenticate". Now that
I know fprintd is involved I've masked fprintd and that works around this.
As said I'm running a fully up2date F34 on a Thinkpad X1 carbon 8th gen,
with the "Linux" fingerprint firmware installed by fwupd. I don't think
I have ever enrolled a fingerprint, which might be part of the problem,
but in that case it should really just act as if there is no fingerprint
reader present.
The login dialog / fprintd should certainly _not_ repeatedly show the
error IMHO even showing it once would be wrong here, but it would be
a big improvement.
Let me know if you need any logs, want a bugzilla for this, or if there
is anything else which I can do to help debug this.
Regards,
Hans
2 years, 6 months
Status update for the new AAA system
by Aurelien Bompard
Hey folks!
As you've probably heard before, we're upgrading our authentication system to something that is based on FreeIPA.
Here's a quick status report on that initiative. We're currently in an integration phase, figuring out the smaller details of configuration and infrastructure setup before we switch production.
- The infra team wants to do a couple things that FreeIPA does not support out of the box, like enforcing 2FA for specific services such as sudo, so we need to think about how we want to do it.
- Also, using kinit with 2FA tokens proved to be more complex than we'd like it to be.
- We're trying out a more continuous approach to importing accounts, because a full run takes 3 days and during the migration we'll want to run the import script without having a 3 days downtime.
- We also have to do some FreeIPA performance tuning, because we have something like 120k accounts and the default configuration is not appropriate for that amount of data, especially when we want to list all groups or worse, all users.
To sum it up, we're currently working on integration and migration preparation. We need to fix these issues before we go to prod, but it's a bit difficult to say how long it's going to take (especially with perf tuning, fix one perf issue and there can be another one right behind).
One sure thing is that it's better to have these issues now rather than after the switch to prod.
Cheers!
Aurélien
2 years, 6 months
OCaml 4.12
by Jerry James
Richard, I see that the OCaml 4.12 release is not expected to happen
until next week, after the beta freeze:
https://discuss.ocaml.org/t/ocaml-4-12-0-first-release-candidate/7294
Some of my OCaml packages are currently not installable, due to the
dynlink hiccup, I think. Rather than enter beta freeze with them in
this state, I would like to rebuild them. I was thinking about
proceeding with the updates needed for OCaml 4.12, since I have to
build these packages anyway, and the updated versions also work with
OCaml 4.11. As a reminder, these are the updates:
- ocaml-base: 0.14.0 -> 0.14.1
- ocaml-migrate-parsetree: 1.8.0 -> 2.1.0
- ocaml-ppxlib: 0.15.0 -> 0.22.0
- ocaml-bisect-ppx: 2.5.0 -> 2.6.0
- ocaml-tyxml: apply this pull request to switch to ppxlib:
https://github.com/ocsigen/tyxml/pull/271
- ocaml-lwt: 5.3.0 -> 5.4.0
- ocaml-ppx-deriving: 5.1 -> 5.2.1
- ocaml-ppx-optcomp: 0.14.0 -> 0.14.1
- ocaml-ppx-sexp-conv: 0.14.1 -> 0.14.2
- ocaml-sedlex: 2.2 -> 2.3
- ocaml-ppx-custom-printf: 0.14.0 -> 0.14.1
- ocaml-ppx-fields-conv: 0.14.1 -> 0.14.2
- Retire ocaml-ppx-tools-versioned
along with a number of other package builds just to fix dependencies.
That would also simplify things for you when OCaml 4.12 is released,
as all of these updates would already be in place. What do you think?
Also, I would like to update ocaml-ocamlgraph to version 2.0.0 at some
point. The only Fedora consumers are frama-c and ocaml-dose3. The
current version of frama-c can already be built with either ocamlgraph
1.x or 2.x. The version of ocaml-dose3 in Fedora (5.0.1) cannot be
built with ocamlgraph 2.x. However, upstream has moved here:
https://gitlab.com/irill/dose3
and released a 6.x series that supports ocamlgraph 2.x.
Unfortunately, there are issues with moving to version 6.x. First,
and easiest, the new versions depend on camlbz2 and parmap, neither of
which are in Fedora. I've put together spec files for those two and
can submit them for review if nobody else wants to do so. Second,
upstream removed support for RPM in this commit:
https://gitlab.com/irill/dose3/-/commit/e656b5783f1fc5fd75e0e2716b0a40aca...
I don't know why. The commit message does not give a reason, and this
change is not mentioned in the project changelog. I assume RPM
support is important for the Fedora build of ocaml-dose3. I don't
know what the best approach is to resolve this issue, but it is
blocking the ocamlgraph update. Any thoughts on the matter are
appreciated.
Regards,
--
Jerry James
http://www.jamezone.org/
2 years, 6 months
Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
== Summary ==
This Change will move Fedora git repositories to use "main" as the
default git branch instead of "master". Specific repositories will be
manually moved and default git branch for new projects will be set to
use "main".
The Fedora Community strives to be open and welcoming. Some language
around our git repositories is dated and could be more inclusive. Many
git repositories currently use "master" as the default branch. This
Change will move many repositories (see below) to use a "main" branch
as default. This small bit of naming adjustment is in-line with
Fedora's vision for free and open source software built by inclusive,
welcoming, and open-minded communities.
== Owner ==
* Name: [[User:Kevin| Kevin Fenzi]], [[User:bcotton| Ben Cotton]],
[[User:pingou| pingou]], [[User:mohanboddu| Mohan Boddu]],
[[User:till| Till Maas]]
* Email: kevin(a)scrye.com, bcotton(a)redhat.com, pingou(a)pingoured.fr,
mboddu(a)bhujji.com, opensource(a)till.name
== Detailed Description ==
The Fedora Project controls a number of git repositories. This change
will move the default branch (that is, the git branch used when
nothing is specified) from 'master' to 'main'. Existing git clones
will need to pull to get the changed default branch. Existing Pull
Requests against the 'master' branch will need to be rebased against
the 'main' branch. Documentation will be updated.
== Benefit to Fedora ==
The Fedora Project will be a more welcoming place for new contributors.
== Scope ==
This change will take place in a number of phases:
=== Phase0 - 2020-12-14 ===
A guide will be published to explain how maintainers/project
managers can change the default
branch on pagure.io, which they can then do based in their projects desires.
=== Phase1 - 2020-12-15 ===
The following repos will be switched:
src.fedoraproject.org/flatpacks/*
pagure.io:
releng
releng/*
fedora-comps
fedora-kickstarts
fedora-infrastructure
fedora-lorax-templates
fedora-mediawikitheme
fedora-packager
fedora-infra/*
infra-docs
koji-fedmsg-plugin
workstation-ostree-config
pungi-fedora
github.com
fedora-infra/*
=== Phase2 - 2021-01-13 ===
src.fedoraproject.org/*
pagure.io default for new projects will be changed to 'main'
* Proposal owners:
Switching all above listed projects git repos to use 'main'
Deleting the 'master' branch
Announcing when changes have been made on devel-announce / other lists.
* Other developers:
Other developers are encouraged to change their upstream projects
on pagure.io, github or gitlab.
* Release engineering:
Releng will adjust any scripts that assume 'master' branch to use
'main' instead. The list includes and maybe few more
[https://pagure.io/releng/blob/master/f/scripts/update-critpath.py
update-critpath.py]
[https://pagure.io/releng/blob/master/f/scripts/block_retired.py
block_retired.py]
[https://pagure.io/releng/blob/master/f/scripts/update-docs.sh
update-docs.sh]
[https://pagure.io/releng/blob/master/f/scripts/find_unblocked_orphans.py
find_unblocked_orphans.py]
[https://pagure.io/releng/blob/master/f/scripts/mass-rebuild-second-run.py
mass-rebuild-second-run.py]
[https://pagure.io/releng/blob/master/f/scripts/adjust-eol-modules.py
adjust-eol-modules.py]
[https://pagure.io/releng/blob/master/f/scripts/pdc/adjust-eol-modules.py
adjust-eol-modules.py]
[https://pagure.io/releng/blob/master/f/scripts/pdc/adjust-eol-modules.py
adjust-eol-modules.py]
[https://pagure.io/releng/blob/master/f/scripts/pdc/adjust-eol.py
adjust-eol.py]
[https://pagure.io/releng/blob/master/f/scripts/pdc/create-new-release-bra...
create-new-release-branches.py]
[https://pagure.io/releng/blob/master/f/scripts/pdc/create-branch.py
create-branch.py]
[https://pagure.io/releng/blob/master/f/scripts/pdc/adjust-eol-all.py
adjust-eol-all.py]
[https://pagure.io/releng/blob/master/f/scripts/check-unretirement.py
check-unretirement.py]
[https://pagure.io/releng/blob/master/f/scripts/mass-rebuild-special.py
mass-rebuild-special.py]
[https://pagure.io/releng/blob/master/f/scripts/need-rebuild.py
need-rebuild.py]
[https://pagure.io/releng/blob/master/f/scripts/distgit-branch-unused.py
distgit-branch-unused.py]
[https://pagure.io/releng/blob/master/f/scripts/create-new-release-branche...
create-new-release-branches.py]
* Policies and guidelines: N/A
* Trademark approval: N/A
* Alignment with Objectives:
== Upgrade/compatibility impact ==
Users with old checkouts will need to update their git configuration
or re-clone repositories that have changed before they can see any new
changes.
Repos used to build content for docs.fedoraproject.org can change the
default git branch, but the Antora module version (in `antora.yml`)
should remain `master` pending support for alternate "unversioned"
versions upstream.
== How To Test ==
# git clone <one of the listed repositories>
# cd <repositoryname>
# git branch
should return: `* main`
== User Experience ==
Users and developers will see more welcoming language and that the
fedora project expended effort to be more welcoming to them.
== Dependencies ==
none
== Contingency Plan ==
* Contingency mechanism: Revert repositories, scripts, and docs back
to the unwelcoming 'master'
* Contingency date: 2020-01-13
== Documentation ==
A short guide on how to change this for pagure.io will be produced.
== Release Notes ==
Many git repositories used to create Fedora releases were moved to use
a 'main' branch instead of a 'master' branch. The Fedora Project
envisions a world where everyone benefits from free and open source
software built by inclusive, welcoming, and open-minded communities.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 6 months
Building custom kernels
by Julian Sikorski
Hi,
I am trying to test some Renoir s2idle patches [1]. It appears that
Fedora kernel source is now maintained on gitlab as kernel-ark [2]. What
I tried is adding the patches to the fedora-5.11 branch and running make
dist-srpm, but it failed due to config mismatch on CONFIG_INIT_STACK_NONE:
Processing
/home/julas/cvs/fedora/kernel-ark/redhat/configs/kernel-aarch64-fedora.config
... Error: Mismatches found in configuration files
Found CONFIG_INIT_STACK_NONE=y after generation, had
CONFIG_INIT_STACK_NONE=is not set in Source tree
make[1]: *** [Makefile:145: dist-configs-check] Błąd 1
Is this expected? Is there a better way of testing patches on Fedora
kernels? Thanks for the help in advance.
Best regards,
Julian
[1] https://gitlab.freedesktop.org/drm/amd/-/issues/1230
[2] https://gitlab.com/cki-project/kernel-ark
2 years, 6 months
Fedora 35 Change: rpmautospec - removing release and changelog fields
from spec files (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/rpmautospec
== Summary ==
The goal of this change is to deploy in production the
[https://docs.pagure.org/fedora-infra.rpmautospec/ rpmautospec]
project.
With it, the content of the `Release` and `%changelog` fields in spec
files can be auto-generated, either locally or in the builder using
the information present in the git repo (in the form of git tags).
Note: This proposal is about changing the way the `Release` and
`%changelog` sections of the '''spec files''' are filled, not about
removing them from the SRPM or binary RPM.
== Owner ==
* Name: [[User:pingou| Pierre-Yves Chibon]]
* Email: pingou - at - pingoured.fr
* Name: [[User:nphilipp| Nils Philippsen]]
* Email: nphilipp - at - redhat.com
== Detailed Description ==
rpmautospec offers packagers who want to use it the possibility of
replacing the content of the `Release` of their spec file by `Release:
%autorel` and/or replace the content of the `%changelog` section of
their spec file by:
%changelog
%autochangelog
Both `%autorel` and `%autochangelog` are RPM macros that will be
expanded or replaced when the SRPM is built on the build system by
their corresponding values according to rpmautospec.
An overview of how rpmautospec works can be found at:
https://docs.pagure.org/fedora-infra.rpmautospec/principle.html.
We will describe below how each macro works.
=== The %autorel macro ===
To determine the next release information, rpmautospec relies on the
build history of the package.
This information is extracted from the buildsystem when running as a
koji plugin and from git tags when running outside of the buildsystem.
Using the build history of the package (ie a list of NEVRs) as well as
the information provided by the packager in the spec file, rpmautospec
then computes the next best release number for the package.
Once defined, it prepends a suitably defined %autorel macro to the top
of the spec file, freezing the computed value of the release number
and thus allowing reproducible builds of the SRPM.
The [https://docs.pagure.org/fedora-infra.rpmautospec/autorel.html
documentation of the autorel macro] describes how packagers can use it
to provide extra information.
=== The %autochangelog macro ===
The %autochangelog macro is in fact more a placeholder that
rpmautospec fills in during the creation of the SRPM (or when ran
manually on a project).
rpmautospec uses two sources of information to automatically generate
the changelog:
* an optional `changelog` file that packagers can add to the repository
* the git history of the spec file
rpmautospec will include the `changelog` as is in the `%changelog`
section and will use all the commits made to the repository after the
last change of the `changelog` file to generate the changelog.
In other words, if the packager has a repository created on January
10th and works on it for 6 months, adds a `changelog` file on June
1st. All the commits made before that commit of June 1st will be
ignored in favor of the content of the `changelog` file.
Similarly, if the packager then edits the file on July 1st, all the
commits prior to that commit of July 1st will be ignored.
All the commits involving files ending with either ".spec" or ".patch"
(this list can be expended if desired) and made after July 1st will be
used to generate the changelog.
== Benefit to Fedora ==
In short: easier packaging in Fedora for the packagers who opt-in.
The `Release` and `%changelog` fields are the two most conflicting
fields in RPM spec files. They impact most pull requests if they
involve updating the package or if the package is updated/rebuilt
while pull-request are being reviewed.
We currently have three different change logs per package and while
they target different audiences (package maintainer: git, sysadmin:
%changelog and end-user: bodhi notes) they overlap a lot and in most
cases are redundant. With this proposal, package maintainers will only
have to cope with two changelogs: git and bodhi notes.
== Scope ==
* Proposal owners:
** Finish the work on the %autorel macro to support some of the use
cases not implemented currently
** Adjust the packaging so rpmautospec does not live in a specific,
versionized python environment (and thus could be use to bootstrap
python)
** Adjust rpmdev-bumpspec (used by releng for mass-rebuilds) so it
ignores spec files using %autorel/%autochangelog
** Adjust the mass-rebuild script so it only adds a suitable git
commit log message for spec files using %autorel/%autochangelog
** Adjust fedpkg to skip the NEVR check when using rpmautospec
** Add dependency on rpmautospec on redhat-rpm-config
* Other developers:
** Opt-in for those who want to use it
** Test changes in staging
** Provide feedback
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: Packaging guidelines should be adjust to
explain how rpmautospec works and can be used. Documentation at:
https://docs.pagure.org/fedora-infra.rpmautospec/ should provide a
good basis for this
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
Not applicable
== How To Test ==
In staging:
* Use `stg-koji` instead of `koji`
* Use `fedpkg-stage` instead of `fedpkg` (``dnf install fedpkg-stage``)
* Run `kinit <accountname>@STG.FEDORAPROJECT.ORG`
* Test with rawhide as rpmautospec is only available there in staging
at this point
* Install `rpmautospec-rpm-macros` to build packages locally.
* Edit the spec file to use either macro (or both)
* (Optional) Run `rpmautospec` on the git repository of your choice to
see what it does (you may have to run `rpmautospec tag-package` the
first time you run it).
* Build the package
* Check its release or changelog according to the macro set
In production:
* Edit the spec file to use either macro (or both)
* (Optional) Run `rpmautospec` on the git repository of your choice to
see what it does (you may have to run `rpmautospec tag-package` the
first time you run it).
* Build the package
* Check its release or changelog according to the macro set
Issues can be reported at: https://pagure.io/fedora-infra/rpmautospec/issues
Note that using this approach has some peculiarities, we've documented
the ones we've encountered at:
https://docs.pagure.org/fedora-infra.rpmautospec/peculiarities.html
== User Experience ==
Packagers not opting-in should not be affected in any way by this change.
Packagers opting-in should be able to stop worrying (or worry much
less) about the content of the Release/%changelog fields in their spec
file.
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism: rpmautospec is not deployed in koji
* Contingency deadline: N/A (this isn't tied to a Fedora release)
* Blocks release? No
== Documentation ==
All the upstream documentations can be
https://docs.pagure.org/fedora-infra.rpmautospec/
== Release Notes ==
N/A, this change will not affect end-users (except maybe for some
changes in the content of the rpm changelog).
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 6 months
