How to easily automate test builds in a COPR project
by Richard Shaw
I maintain a suite of ham radio related packages. The developer is very
active and often creates test versions adding and incrementing the "tweak"
part of the version which is removed for the full releases and the patch
level incremented.
Currently I'm just trying to keep up with them by hand using pagure forks
of the official repos so I don't accidentally pollute SCM with the changes
and build them in COPR.
Things I need to manage automagically:
1. Monitor the test URLs to look for new versions.
I could write a bash script for this and add a cron or systemd timer but I
was hoping for something that took less time as I don't have a lot of that
:)
Would it be permissible to create a <package>-testing entry in
release-monitoring.org?
2. Trigger a "fedpkg clone" and add a tweak version.
This could probably be managed with macros easy enough, %{?tweak}, or
something like that. And then use a script to substitute into "%global
tweak ..."
3. I need to download the files from a different location.
%if %{?tweak}
... use difference Source0?
4. Build the packages in COPR.
Easy enough using a bash script but is there a better way?
Thanks,
Richard
2 years, 8 months
The future of legacy BIOS support in Fedora.
by Jóhann B. Guðmundsson
Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes
it beg the question if now would not be the time to stop supporting
booting in legacy bios mode and move to uefi only supported boot which
has been available on any common intel based x86 platform since atleast
2005.
Now in 2017 Intel's technical marketing engineer Brian Richardson
revealed in a presentation that the company will require UEFI Class 3
and above as in it would remove legacy BIOS support from its client and
datacenter platforms by 2020 and one might expect AMD to follow Intel in
this regard.
So Intel platforms produced this year presumably will be unable to run
32-bit operating systems, unable to use related software (at least
natively), and unable to use older hardware, such as RAID HBAs (and
therefore older hard drives that are connected to those HBAs), network
cards, and even graphics cards that lack UEFI-compatible vBIOS (launched
before 2012 – 2013) etc.
This post is just to gather feed back why Fedora should still continue
to support legacy BIOS boot as opposed to stop supporting it and
potentially drop grub2 and use sd-boot instead.
Share your thoughts and comments on how such move might affect you so
feedback can be collected for the future on why such a change might be
bad, how it might affect the distribution and scope of such change can
be determined for potential system wide proposal.
Regards
Jóhann B.
1.
https://fedoraproject.org/wiki/Changes/CleanupGnomeHiddenBootMenuIntegration
2 years, 9 months
Thoughts about packaging a standalone python-PyQt5-sip?
by Michel Alexandre Salim
Hi all,
Neal and I are looking at getting ButterManager packaged, and it
depends on sip and PyQt5-sip:
https://github.com/egara/buttermanager/blob/master/requirements.txt
Now, this is where things get a bit odd:
- the current sip (4.19.24) does not have autogenerated Python
provides, but sip5 does:
$ sudo dnf repoquery --provides sip
Last metadata expiration check: 1:48:00 ago on Wed 30 Dec 2020 02:50:53
PM PST.
sip = 4.19.24-1.fc33
sip(x86-64) = 4.19.24-1.fc33
sip-macros = 4.19.24-1.fc33
$ sudo dnf repoquery --provides sip5
Last metadata expiration check: 1:48:05 ago on Wed 30 Dec 2020 02:50:53
PM PST.
python-sip5 = 5.5.0-1.fc33
python3-sip5 = 5.5.0-1.fc33
python3.9-sip5 = 5.5.0-1.fc33
python3.9dist(sip) = 5.5
python3dist(sip) = 5.5
sip5 = 5.5.0-1.fc33
sip5(x86-64) = 5.5.0-1.fc33
- sip ships PyQt5 bindings with matching version, but sip 5 seems to no
longer do so
$ sudo dnf info python3-pyqt5-sip
Last metadata expiration check: 1:51:03 ago on Wed 30 Dec 2020 02:50:53
PM PST.
Installed Packages
Name : python3-pyqt5-sip
Version : 4.19.24
Release : 1.fc33
Architecture : x86_64
Size : 244 k
Source : sip-4.19.24-1.fc33.src.rpm
Repository : @System
From repo : fedora
Summary : SIP - Python 3/C++ Bindings Generator for pyqt5
URL : https://riverbankcomputing.com/software/sip/intro
License : GPLv2 or GPLv3 and (GPLv3+ with exceptions)
Description : This is the Python 3 build of pyqt5-SIP.
- https://pypi.org/project/PyQt5-sip/ has PyQt5-sip 12.8.1 but
https://pypi.org/project/sip/ has sip 5.5.0 which matches the sip5 in
Fedora (available since last month)
- there's a lot of packages that depend on python3-pyqt5-sip (though
none use the canonical python3dist(pyqt5-sip) unfortunately)
$ sudo dnf repoquery --repo rawhide,rawhide-source --whatrequires
'python3dist(pyqt5-sip)'
Last metadata expiration check: 0:15:20 ago on Wed 30 Dec 2020
04:28:29 PM PST.
$ sudo dnf repoquery --repo rawhide,rawhide-source --whatrequires
python3-pyqt5-sip
Last metadata expiration check: 0:15:30 ago on Wed 30 Dec 2020
04:28:29 PM PST.
calibre-0:4.23.0-3.fc34.x86_64
krita-0:4.4.1-1.fc34.i686
krita-0:4.4.1-1.fc34.x86_64
libarcus-0:4.8.0-1.fc34.src
mingw-python-qt5-0:5.15.0-4.fc34.src
pyqtwebengine-0:5.15.0-2.fc33.src
python-pyface-0:7.1.0-1.fc34.src
python-pynest2d-0:4.8.0-1.fc34.src
python-qt5-0:5.15.0-5.fc34.src
python3-arcus-0:4.8.0-1.fc34.x86_64
python3-arcus-lulzbot-0:3.6.21-8.fc34.x86_64
python3-poppler-qt5-0:0.75.0-6.fc33.x86_64
python3-pyqtchart-0:5.15.2-1.fc34.i686
python3-pyqtchart-0:5.15.2-1.fc34.x86_64
python3-qgis-0:3.16.1-2.fc34.i686
python3-qgis-0:3.16.1-2.fc34.x86_64
python3-qscintilla-qt5-0:2.11.5-1.fc34.x86_64
python3-qt5-base-0:5.15.0-5.fc34.i686
python3-qt5-base-0:5.15.0-5.fc34.x86_64
qhexedit2-0:0.8.9-2.fc33.src
scidavis-0:2.3.0-2.fc33.src
veusz-0:3.3.1-1.fc34.src
veusz-0:3.3.1-1.fc34.x86_64
Any idea what's the best way to handle this? and/or why PyQt5-sip's
versioning get so far ahead of sip?
Thanks,
--
Michel Alexandre Salim
profile: https://keyoxide.org/michel@michel-slm.name
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2
2 years, 11 months
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
3 years
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 years
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
3 years, 1 month
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
3 years, 1 month
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
3 years, 1 month
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
3 years, 1 month
