thinking journal retention timelimits
by Matthew Miller
As we start a new year, I'm thinking about data retention in general. :)
In my experience, it's pretty rare on an end-user laptop or desktop system for
logs from much more than the previous boot to be interesting. Maybe I
occasionally want to look back a little while to see if a problem just
started. It's exceedingly rare that I need (or want) to look back more than
a month.
Right now, we don't set MaxRetentionSec, so journal expiry on Workstation is
entirely based on disk usage.
Logs can accidentally contain sensitive data, and it's just plain faster to
work with them when there's less. I propose we set this to something like
six months by default.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
1 week, 5 days
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
3 weeks, 1 day
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
1 month, 1 week
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
1 month, 2 weeks
Policy proposal (draft): Don't push knowingly broken or
work-in-progress work to dist git
by Miro Hrončok
Hello,
When we work on rebuilding Python packages with new Python version and when
other provenpackagers rebuild multiple packages at once, I've seen several
problems with packages failing to build from source and/or creating unexpected
breakage in rawhide when built. Usually, some of the following happens:
1. Untested changes
Packager pushes a "simple update" to dist git without checking if it even
builds. It doesn't. Packager has no time to fix this, so they move on for now.
Or they submit a build but never check if it actually built. Provenpackagers who
need to rebuild the package need to figure this out and fix the problem if it is
trivial, or revert the recent commit, when the failure blocks them.
IMHO Provenpackagers should not need to worry about this. Changes should be at
least smoke tested by a mock/scratch build and installation check before
shipping them.
2. Changes that work but are waiting on external factors
Packager pushes a breaking change to dist git (such as a soname bump) before
coordinating the change with the dependent packages, not intending to
immediately build it. A provenpackager rebuilds the package for a different
reason (such as a different soname bump), accidentally shipping the
not-yet-wanted upgrade to rawhide.
IMHO Provenpackagers should not need to worry about this. Commits should land in
dist git only when they are intended to be built (close to) immediately. The
only reasonable exception is when building the pushed changes in a side tag and
even then, packagers should communicate their intentions.
3. Work-in-progress changes
Packager works on a package. They have a work in progress solution to their
problem, but no time to finish. They push a "WIP" commit that either breaks the
build or produces a broken package. The symptoms are similar to (1) or (2). I've
heard packagers saying "but this is rawhide, this is where development happens,
so this is expected" - I disagree.
---
I'd like to explicitly say that neither of this is considered a good behavior.
I'd like to have a policy that more or less says:
1. Packagers MUST NOT push changes that are not considered ready to be built and
shipped at the time of the push. Using Pull Requests (clearly marked as not
ready to be merged) is a better place to present/save changes that are not ready
yet.
2. Packagers SHOULD preemptively check if the changes they intend to push work.
At least checking if the intended change builds and the package installs with it
is strongly recommended. In cases where the check is skipped for time reasons
(e.g. when a testing build takes several hours and the changes are urgent),
packagers SHOULD be ready to fix the build/installation failure in timely manner
after it is discovered by the actual build.
Before I try to word it more carefully I'd like to hear some feedback on this.
What do you think?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1 month, 2 weeks
Needing Some Maintenance Help
by Erich Eickmeyer
Hi All,
Over the course of the past few months, I have become employed by a
company to provide their user software experience. This has limited the
time that I have, and, unfortunately, my involvement in Fedora has, and
needs to, decrease.
I currently maintain the Fedora Jam lab, and would like some help with
that. Just last night, while I was trying to relax after my day, I was
CC'd on two bug reports only because I'm Jam's maintainer, when really
the responsibility for the issues in question (pipewire related in
Rawhide) lie on the change owner(s) for the Pipewire-By-Default change.
I fixed a couple of packages only as a courtesy that were related to
the issue (unable to install the @audio group), but that responsibility
lies with the change owner(s), of which I'm not a part due to time
restrictions. I removed myself from the bug report after that and had
explained that they needed to add the change owner(s).
This same person that CC'd me on that decided to then file a bug report
against Jam 34 which is currently FTBFS due to the aforementioned issue
with the @audio group. Since we (spin/lab maintainers) get automated
emails about these things, I told them not to file bug reports against
spins/labs in the future and closed it as errata. I realize this person
was only trying to help, but it caused me some undo stress.
This made me realize that I need to take a step back. Not only have I
gained employment with a company that is using Ubuntu as their base
(specifically Kubuntu with Ubuntu Studio partnership), but I've also
become a MOTU with Ubuntu ("Master Of The Universe [repository]", much
like a proven packager here). As such, Fedora isn't exactly integral to
what I do, but I'd like to keep my rpm packaging skills somewhat
sharpened, which is why I'll be keeping certain packages that I have
direct involvement upstream with (e.g. studio-controls).
So, here's what I'm looking for:
* Someone to help me maintain Jam
* Including fedora-jam-backgrounds and fedora-jam-kde-theme packages
* Co-maintainers and/or new maintainers for the following packages:
* Add64
* dssi
* dssi-vst
* fluidsynth
* fluidsynth-dssi
* freqtweak
* giada
* gnome-guitar
* harmonyseq
* hexter-dssi
* jackctlmmc
* jmeters
* libinstpatch
* lv2-c++-tools
* lv2-fabla
* lv2-ll-plugins
* lv2-mdaEPiano
* lv2-newtonator
* lv2-sorcer
* lv2-swh-plugins
* lv2-vocoder-plugins
* meterbridge
* python-alsaaudio
* python-jack-client
* radium-compressor
* realTimeConfigQuickScan
* soundtracker
* whysynth-dssi
* xsynth-dssi
Simply let me know which package you'd like and if you'd like to
maintain or co-maintain along with your fas username.
Thanks in advance,
Erich
--
Erich Eickmeyer
Maintainer
Fedora Jam
1 month, 4 weeks
Fedora 34 Change: Enable btrfs transparent zstd compression by
default (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/BtrfsTransparentCompression
== Summary ==
On variants using btrfs as the default filesystem, enable transparent
compression using zstd. Compression saves space and can significantly
increase the lifespan of flash-based media by reducing write
amplification. It can also increase read and write performance.
== Owners ==
* Name: [[User:salimma|Michel Salim]], [[User:dcavalca|Davide
Cavalca]], [[User:josef|Josef Bacik]]
* Email: michel(a)michel-slm.name, dcavalca(a)fb.com, josef(a)toxicpanda.com
== Detailed description ==
Transparent compression is a btrfs feature that allows a btrfs
filesystem to apply compression on a per-file basis. Of the three
supported algorithms, zstd is the one with the best compression speed
and ratio. Enabling compression saves space, but it also reduces write
amplification, which is important for SSDs. Depending on the workload
and the hardware, compression can also result in an increase in read
and write performance.
See https://pagure.io/fedora-btrfs/project/issue/5 for details. This
was originally scoped as an optimization for
https://fedoraproject.org/wiki/Changes/BtrfsByDefault during Fedora
33.
== Benefit to Fedora ==
Better disk space usage, reduction of write amplification, which in
turn helps increase lifespan and performance on SSDs and other
flash-based media. It can also increase read and write performance.
== Scope ==
* Proposal owners:
** Update anaconda to perform the installation using <code>mount -o
compress=zstd:1</code>
** Set the proper option in fstab (alternatively: set the XATTR)
** Update disk image build tools to enable compression:
*** lorax
*** appliance-tools
*** osbuild
*** imagefactory
** [optional] Add support for
[https://github.com/kdave/btrfs-progs/issues/328 setting compression
level when defragmenting]
** [optional] Add support for
[https://github.com/kdave/btrfs-progs/issues/329 setting compression
level using `btrfs property`]
* Other developers:
** anaconda: review PRs as needed
* Release engineering: https://pagure.io/releng/issue/9920
* Policies and guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
This Change only applies to newly installed systems. Existing systems
on upgrade will be unaffected, but can be converted manually with
<code>btrfs filesystem defrag -czstd -r</code>, updating `/etc/fstab`
and remounting.
== How to test ==
Existing systems can be converted to use compression manually with
<code>btrfs filesystem defrag -czstd -r</code>, updating `/etc/fstab`
and remounting.
== User experience ==
Compression will result in file sizes (e.g. as reported by du) not
matching the actual space occupied on disk. The
[https://src.fedoraproject.org/rpms/compsize compsize] utility can be
used to examine the compression type, effective compression ration and
actual size.
== Dependencies ==
Anaconda will need to be updated to perform the installation using
<code>mount -o compress=zstd:1</code>
== Contingency plan ==
* Contingency mechanism: will not include PR patches if not merged
upstream and will not enable
* Contingency deadline: Final freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
https://btrfs.wiki.kernel.org/index.php/Compression
== Release Notes ==
Transparent compression of the filesystem using zstd is now enabled by
default. Use the compsize utility to find out the actual size on disk
of a given file.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
2 months
Copr in 2020 and outlook for 2021
by Miroslav Suchý
Let me sum up what we - the Copr team - did in 2020:
* We enabled CDN for repos. https://fedora-copr.github.io/posts/copr-cdn
* We enabled runtime dependecies on repositories https://fedora-copr.github.io/posts/runtime-dependencies
* We migrated all our servers from PHX datacenter to AWS. With zero downtime for your repos.
* Pavel Raiskup became the new Mock project leader, and he released seven new versions of Mock during 2020.
https://github.com/rpm-software-management/mock/wiki
* Our small team has been renamed to Community Packaging Team (CPT) because beside Copr, we maintain other tools as
well: Mock, dist-git, Tito...
* We drove changes in createrepo_c, which allowed us better throughput. Now, Copr can build thousands of builds per day.
* We worked on Fedora packages website, which was outdated and do not work on recent Fedora. Unfortunately, it will not
be likely used, and static pages will be used as it will require less maintenance.
* We introduced Project scoring for projects in Copr (up/down vote) http://frostyx.cz/posts/upvoting-projects-in-copr
* We allowed you to delete multiple builds at once. https://fedora-copr.github.io/posts/deleting-list-of-builds
* You can use Github Actions now https://pavel.raiskup.cz/blog/github-push-actions-and-copr.html
* We created modulemd-tools for low-level handling of repositories and modules. And tool for generating
module-build-macros. https://github.com/rpm-software-management/modulemd-tools
* We worked hard on better EOL handling of Copr repositories.
* We parallelized copr-dist-git imports.
* We wrote code for Ansible DNF Copr module. This still needs to land in a proper place like Ansible Galaxy.
https://pagure.io/copr/copr/blob/master/f/ansible
* We provided --isolation=* and --bootstrap=* knob in Copr
* We started an experimental "external dependencies" feature in Mock.
https://github.com/rpm-software-management/mock/wiki/Feature-external-deps
* We created a new python module "templated-dictionary" as a spin-off from Mock's code.
https://github.com/xsuchy/templated-dictionary
* We wrote four articles "4 cool new projects to try in COPR" https://fedoramagazine.org/tag/copr/
* Users now have the ability to change the build timeout up to a maximum of 48 hours
* Users can group builds in batches now. https://pavel.raiskup.cz/blog/build-ordering-by-batches-in-copr.html
We already have plans to do:
* Verify GPG checks in DNF using DNSSEC. https://pagure.io/copr/copr/issue/406
* Improve hooks (in cooperation with Packit team)
* We are going to EOL APIv1 and APIv2 https://fedora-copr.github.io/posts/EOL-APIv1-APIv2
What will we do in 2021? We have some ideas. Some of them are yours, some of them are ours. At the end of this email is
a link to Google Form where you can vote what you would like to get. We will consider your vote. (listed in no specific
order)
* When you create a project, you may specify that it will be for Package Review. We do some settings for you, and
`rpminspect` will be run automatically at the end of the build. We can guide users on how to file Package Review BZ. Or
do that automatically on their behalf.
* Contribute to fedpkg/Koji that tagged commits will be automatically built in Koji and may be automatically sent to Bodhi.
* Help with automatic changelog entries.
* Native support for Fedora in Travis.
* Continue on external dependencies. https://github.com/rpm-software-management/mock/wiki/Feature-external-deps
* Finish rpm-spec-wizard https://github.com/xsuchy/rpm-spec-wizard
* Better integration with Koshei.
* Automatic rebuilds in Copr when dependency change (likely with the help of Koshei)
* Enhance release-monitoring and rebase-helper to automatically open PR in Pagure when new version is available.
* Enhance `Mock --chain` to try to set %bootstrap when standard loop fails. When the set succeeds, rebuild the
bootstrapped package again without %bootstrap macro.
https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping
* Improve the process of finding a sponsor for the first package.
* Contribute to fedpkg/koji to have machine-readable output.
Please vote here: https://forms.gle/UuH86ECzfZNHJgEr8
The results are intentionally publicly available. You may check them anytime.
CPT team consist of Pavel Raiskup, Silvie Chlupova, Jakub Kadlcik and this year we also had in the team Dominik Turecek
and Tomas Hrnciar.
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
2 months