Phishing emails from fedora project
by Mark O'Brien
Hi All,
There have been some reports of phishing emails claiming to be from the
fedora project. An example of which can be seen here:
https://pagure.io/fedora-infrastructure/issue/10286
As always please be careful and follow basic guidelines when reading
your emails.
- Do not click on links or attachments from senders that you do not
recognize. Be especially wary of .zip or other compressed or executable
file types.
- Do not provide sensitive personal information (like passwords) over
email.
- Watch for email senders that use suspicious or misleading domain names.
- If you can’t tell if an email is legitimate or not, please contact
admin(a)fedoraproject.org
If in any doubt please reach out to us to confirm before sharing any
information or clicking any links you are unsure of in an email.
Mark
2 years, 6 months
F36 Change: OpenLDAP 2.5 (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Openldap_25
== Summary ==
OpenLDAP upgrade from version 2.4.59 to the last upstream version
2.5.8 in Fedora.
== Owner ==
* Name: [[User:spichugi| Simon Pichugin]]
* Email: spichugi(a)gmail.com
== Detailed Description ==
Upgrading OpenLDAP from version 2.4.59 to version 2.5.8 according to
the new upstream release. Years of development differ between these
two releases, so problems are expected.
This change might cause failures during builds of multiple packages.
These two versions have slight ABI incompatibility even though it's
easily fixable. This step must be properly discussed with maintainers
of dependent packages, which should forward this change proposal to
their upstream projects.
== Benefit to Fedora ==
Brings a stable and up-to-date version of OpenLDAP according to
upsteam release. OpenLDAP 2.4 will be out of support as soon as
OpenLDAP 2.6 is released which is planned for this year. Fedora will
be prepared for such a step.
== Scope ==
* Proposal owners:
**Prepare openldap-2.5.8 as RPM package for Fedora Rawhide
**Check software that requires `openldap` and rebuild it with openldap-2.5.8
**Build openldap-2.5.8 to Rawhide in a side-tag
(https://fedoraproject.org/wiki/Package_update_HOWTO#Creating_a_side-tag)
**Rebuild depended packages with openldap-2.5.8 in the side-tag
**Merge the side-tag to Rawhide
* Other developers: Check if their packages can be build with
openldap-2.5.8, if not, they are required to make the appropriate
changes to their packages.
* Release engineering: https://pagure.io/releng/issue/10349
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
Problems during build can appear in multiple packages what can lead to
build failure, as multiple packages require OpenLDAP as their upstream
dependency. These problems have to be resolved before adding
openldap-2.5.8 into Fedora. It seems aprox. 10% of dependent packages
are having problems during build, which could be caused by a problem
with same pattern.
== How To Test ==
Rebuilding your packages with openldap-2.5.8 dependency in copr
(https://copr.fedorainfracloud.org/coprs/spichugi/openldap-2.5/).
The best way to rebuild new version of package against openldap-2.5.8
is to create a pull-request against your dist-git repository (against
rawhide branch). After that, you package will be automatically rebuild
in the mentioned copr. Please find your package in the "Builds" tab
and search in the various sub-tabs for your build.
If possible, please prepare a pull-request, so you can easily merge
it, when the change will be executed.
For local testing and building, please download mock-config from the
given copr repository and use it with your mock:
`copr mock-config spichugi/openldap-2.5 fedora-rawhide-x86_64 >
spichugi-openldap-2.5_fedora-rawhide-x86_64.cfg`
`mv spichugi-openldap-2.5_fedora-rawhide-x86_64.cfg /etc/mock`
Now we may run:
`mock -r spichugi-openldap-2.5_fedora-rawhide-x86_64 --rebuild
<package-1.0-1.src.rpm>`
== User Experience ==
Users will be able to use the newer version (2.5) of OpenLDAP, and
building packages with openldap-2.4 won't be available, as it won't be
present on the specific fedora version. This can affect 3rd partly
packages, which are not part of Fedora.
To remediate the impact of the change the post-installation script
will be run with the package installation. And in case the
openldap-servers package is installed on the system, `dnf` will halt
the upgrade and notify the user with a message describing what and why
happened, and what steps to take to mitigate the issue.
The user will have to follow the Upstream upgrading guide and only
then concisely continue the upgrade:
https://www.openldap.org/doc/admin25/appendix-upgrading.html
== Dependencies ==
Tens of packages have build dependency on OpenLDAP, so they should be
properly notified and the upgradeshould be carefully tested. List of
dependent packages with their ability to be built with openldap-2.5
can be found in the given copr project
(https://copr.fedorainfracloud.org/coprs/spichugi/openldap-2.5/packages/)
== Contingency Plan ==
* Contingency mechanism: moving this change to Fedora 37, if not
successfully finished until Fedora 36 branching from Rawhide
* Contingency deadline: Fedora 36 branching from Rawhide (2022-02-08)
* Blocks release? No
== Documentation ==
Latest OpenLDAP documentation:
https://www.openldap.org/doc/admin25/
== Release Notes ==
Release notes for the latest OpenLDAP release:
https://www.openldap.org/software/release/
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 6 months
F37 Change: Ansible 5 (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Ansible5
== Summary ==
The ansible project has re-organized how they release and distribute
ansible. This change moves Fedora to be in sync with those changes and
retires the old 'ansible classic/2.9.x' package in favor of a
'ansible' package that pulls in ansible-core (the engine) and includes
all the collections in upstream ansible releases.
== Owner ==
* Name: [[User:kevin| Kevin Fenzi]] and [[User:dmsimard]]
* Email: kevin(a)scrye.com, dmsimard(a)redhat.com
== Detailed Description ==
The upstream ansible project found that maintaining a single
monolithic ansible package with everything included was not working
well ([https://www.ansible.com/blog/thoughts-on-restructuring-the-ansible-project
source]). Small changes had to wait for releases, some areas had no
subject matter reviewers, it was difficult to try and handle all the
issues and changes in a timely manner. So, the ansible engine was
split off and then the rest of the content was moved to separate
collections. These collections could then be maintained by communities
that care about that area and could release at their own pace. A
number of collections have agreed to release on the same cadence.
These collections, along with the ansible-core engine comprise a
upstream 'ansible' release.
The engine package (ansible-core) is already in Fedora 35+. Currently
the 'ansible' package is 'ansible classic', ie, the 2.9.x version from
before the reorganization. While Ansible 2.9.x will continue to be
maintained from a security perspective until 2022, it is desireable to
update to the latest release of both ansible-core and ansible in order
to benefit from continued updates, bug fixes and improvements.
This change will modify the existing 'ansible' package to include the
Ansible Collections that are provided in the upstream ansible releases
from PyPi. The ansible package will not include ansible-core but will
have a requirement (dependency) on it.
Having two separate packages will give users the ability to select the
best option based on their needs:
# Install the 'ansible' package to mirror the user experience when
installing ansible from PyPi: it will install ansible-core as well as
the collections as they are included in the upstream ansible release.
# Install just the 'ansible-core' package when no external collections
are necessary
# Install 'ansible-core' and then manually install collections either
from existing [https://koji.fedoraproject.org/koji/search?match=glob&type=package&terms=...
packages in Fedora], from [https://galaxy.ansible.com/ Ansible Galaxy]
or elsewhere.
== Benefit to Fedora ==
* On current upstream releases with bugfixes and enhancements.
* Increases flexibility by allowing users to choose which Ansible
collections to install and where they install it from.
* More rapid improvements for Fedora users.
== Scope ==
* Proposal owners: 'ansible' package needs to be modified for this
change (work is in progress already).
* Other developers: N/A
* Release engineering: N/A
* Policies and guidelines: Possibly policies for packaging collections?
* Trademark approval: N/A (not needed for this Change
* Alignment with Objectives:
== Upgrade/compatibility impact ==
On upgrade, ansible-2.9.x will be replaced by ansible-core + release
collections. Ansible playbooks will continue to run as before.
== How To Test ==
Playbooks that run as expected under Ansible 2.9 may behave
differently under Ansible 5 which effectively updates the
(ansible-core) runtime from 2.9 to 2.12.
Users are encouraged to take a look at the available porting guides
for both Ansible and ansible-core
(https://docs.ansible.com/ansible/devel/porting_guides/porting_guides.html)
and carefully test the behavior of their roles and playbooks in case
of any adjustments are needed.
The Ansible community package follows semantic versioning rules, so
incompatible changes are only made between major versions.
Unfortunately in this case, there are a number of major versions
between 2.9 and 5.0.
== User Experience ==
Users can remove the release collections and install separately
packaged collections or install from ansible-galaxy.
== Dependencies ==
Might need to conflict with some seperately packaged collections.
== Contingency Plan ==
* Contingency mechanism: Keep shipping ansible classic, but it will go
EOL and updates will become much harder.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
Ansible is now shipped as 'ansible-core' (the engine) and a curated
set of Ansible collections.
Users can use 'dnf install ansible' to install ansible-core as well as
the Ansible collections included in the upstream Ansible releases.
Users can also opt to 'dnf install ansible-core' and then install
collections manually from standalone packages or via ansible-galaxy.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 6 months
F36 Change: Make Authselect Mandatory (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Make_Authselect_Mandatory
== Summary ==
This change wants to make authselect required to configure
authentication and identity sources and forcefully update
non-authselect configuration to the sssd authselect profile to
eliminate any existing non-authselect setups.
Even though it will still be possible to manually modify the
configuration, users that require special configuration should create
and use custom authselect profile.
''Authselect is available in Fedora since Fedora 27 and enabled by
default on new installations since Fedora 28. Authconfig compatibility
tool was removed from Fedora 35 as a
[[Changes/RemoveAuthselectCompatPackage|system wide change page]]. It
is now well accepted by the community as well as the package
maintainers. The package maintainers have repeatedly requested to make
authselect mandatory for the users which lead to creation of
[https://bugzilla.redhat.com/show_bug.cgi?id=2000936 this bugzilla].''
== Owner ==
* Name: [[User:pbrezina|Pavel Březina]]
* Email: pbrezina(a)redhat.com
== Detailed Description ==
The following components must be updated to make authselect mandatory:
* authselect
* pam
* glibc
* packages that use it: systemd, ecryptfs, nss-mdns and fingerprint.
Required changes:
# Remove user-nsswitch.conf functionality from authselect
# Move ownership of /etc/nsswitch.conf and /etc/pam.d/{system-auth,
password-auth, smartcard-auth, fingerprint-auth, postlogin} to
authselect from glibc and pam
# Require authselect in pam
# Remove non-authselect support from systemd, ecryptfs, nss-mdns and fingerprint
# Select default profile when authselect is installed
# Select default profile when authselect is upgraded
=== Remove user-nsswitch.conf functionality ===
File /etc/authselect/user-nsswitch.conf was introduced in authselect
to allow partial user modifications of nsswitch.conf without the need
to create a custom authselect profile. The main driver was to enable
modules that are not included in authselect such as systemd-resolved
and nss-mdns.
This however made the situation more confusing to users and it is not
desirable any more if authselect is mandatory.
'''Authselect will drop user-nsswitch.conf functionality and instead
add more nsswitch modules to existing profiles and be more open about
future inclusion requests.'''
=== Own /etc/nsswitch.conf and /etc/pam.d/{system-auth, password-auth,
smartcard-auth, fingerprint-auth, postlogin} instead of glibc and pam
===
File /etc/nsswitch.conf is currently owned by glibc. It will be now
owned by authselect and removed from glibc.
PAM configuration generated by authselect is currently owned by pam.
It will be now owned by authselect and removed from pam.
''Note: that config-util and other will still be owned by pam since
these files are not generated by authselect.''
'''All files that are generated by authselect are now owned by authselect.'''
=== Require authselect in pam ===
The pam package will require authselect. This will tie pam and
authselect together and it will be impossible to uninstall authselect
without uninstalling pam which fundamentally makes authselect a hard
dependency on each system.
'''This step will make it impossible to uninstall authselect, making
it always available to RPM packages.'''
=== Remove non-authselect support from systemd, ecryptfs, nss-mdns and
fingerprint ===
'''Non-authselect configuration support will be dropped in these packages.'''
=== Select default profile when authselect is installed ===
If authselect configuration is not detected and this is a new
installation of authselect it will automatically select the
distribution default authselect profile by calling authselect select
--force with distribution specific parameters.
If existing authselect configuration is detected (perhaps from
previous installation), it will be updated (current behavior).
This makes sure that if authselect is installed (which is always) a
configuration is created.
Select default profile when authselect is upgraded
If authselect is upgraded from an older version and non-authselect
configuration is detected, it will forcefully overwrite it with
distribution defaults by calling authselect select --force with
distribution specific parameters.
This is a one time event so if someone does not want to use
authselect, it remains possible. However, non-authselect
configurations will not be supported by RPM packages mentioned above.
If authselect is upgraded on a system that already is configured by
it, the update process remains the same as it is now.
'''This step will forcefully update existing installations to
authselect configuration. It is a one time event and opt-out is still
possible but no longer supported.
'''
== Benefit to Fedora ==
'''Making authselect mandatory will provide better user and
maintainers experience and significantly reduce risk of breaking
system configuration.'''
The use of authselect-generated configuration is currently optional.
This means that users can uninstall authselect or just opt-out from it
by modifying the PAM and nsswitch.conf manually.
Additionally users that upgrade from pre-authselect systems (Fedora 27
and older) must opt-in to authselect manually, which is not the case
most of the time. Also sometimes an upgrade of a particular package
that did not handle authselect configuration correctly automatically
opted-out its users. Therefore we can split users into four groups:
* Those who are using authselect
* Those who were using authselect but are not anymore due to various
errors in packages
* Those who are not using authselect because they are not aware of it
and upgraded from older Fedora versions thus it was not automatically
enabled
* Those who are not using authselect knowingly
''Fedora is now split into two worlds: those who use authselect and
those who don’t. This however keeps two problems existing. Authselect
was designed to solve them both. But it will be solved only if the use
of authselect is a mandatory requirement.''
=== 1. It is difficult to deliver updates to configurations ===
FIles /etc/nsswitch.conf and /etc/pam.d/* are distributed as
%config(noreplace) which means that they are configuration files and
are only installed if they are not yet present. If they are present
then they are never overwritten with package updates, instead an
*.rpmnew file is created and the update responsibility is left
completely to the user.
It is done this way to prevent overwriting user changes
configurations. But at the same time it means that even configurations
that are not modified by the users can not be changed so we can not
deliver fixes and changes efficiently.
It is only possible through difficult scriptlets. As an example, we
can show this bugzilla where a change in Gnome required an update to
PAM otherwise the user could not authenticate. Delivering the change
was easy with authselect, but difficult for non-authselect systems.
Authselect already knows how the resulting configuration should look
and does not risk overriding user configuration. Making it mandatory
will help distribute important updates to nsswitch and PAM
configuration.
=== 2. Package maintainers wants to enable/disable nsswitch or PAM
modules automatically upon installation/uninstallation ===
Packages that install nsswitch modules (e.g. systemd, nss-mdns) or PAM
modules (e.g. ecryptfs, fprintd) want to enable the module
automatically upon RPM installation to provide a better user
experience. So they use various more or less complex and fragile
scriptlets in %post action of the RPM.
This is usually easier for the nsswitch module, when simple sed works
for most configurations. But it is not really possible for PAM
(because there is high risk of introducing security vulnerabilities or
breaking authentication completely) so the packages used authconfig
and now authselect.
Packages need to detect the current authselect state and either call
authselect when available or fallback to non-authselect scriptlets.
The end results tends to be the same for nsswitch modules but
different for PAM modules where it is either enabled with authselect
or nothing happens.
'''If authselect is made mandatory, packages can only support
authselect configuration which makes the change simple,
straightforward, easier to test and safe.'''
== Scope ==
* Proposal owners:
** authselect maintainers:
*** implement the changes described in "Detailed Description" in all
affected packages
*** open pull requests with the changes against affected packages
* Other developers:
** maintainers of affected packages must accept submitted merge request
* Release engineering: [https://pagure.io/releng/issue/10337 #10337]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
The system will be forcefully configured with authselect, selecting
the default distribution profile (sssd), if non-authselect
configuration is detected. It will will override users configuration.
A backup will be created, users can run 'authselect backup-restore
$id' to restore their configuration when desired.
== How To Test ==
* Authselect must keep working as expected.
* Ownership of the following files is transferred to authselect-libs package
** /etc/pam.d/fingerprint-auth
** /etc/pam.d/password-auth
** /etc/pam.d/postlogin
** /etc/pam.d/smartcard-auth
** /etc/pam.d/system-auth
** /etc/nsswitch.conf
* pam requires authselect
* updating from previous system with non-authselect configuration must
result in applied authselect configuration with sssd profile
* updating from previous system with authselect configuration must
remain intact (besides applying udated profiles)
* installing/removing affected packages (see Detailed Description)
must not break authselect configuration
== User Experience ==
PAM and nsswitch.conf configuration will be automatically updated when changed.
''Note: To request inclusion of a new nsswitch or PAM module in
default authselect profiles, either open an issue on authselect GitHub
project or open a bug against authselect component in Fedora
bugzilla.''
''Note: Users will still be able to create custom profiles to include
modules that are not supported by default authselect profiles.
However, such profiles will have limited update support. It is
possible to create a custom profile with some files as symlinks to
default profiles, those files will receive updates automatically.
However, modified files of the custom profiles still need to be
updated manually and the users are responsible for the update.
''
''Note: Users will still be able to opt-out from authselect, but such
configuration will no longer be updated on upgrades or touched by
package installation.''
== Dependencies ==
This change does not break any packages that depends on authselect.
== Contingency Plan ==
* Contingency mechanism: Revert changes in affected packages.
* Contingency deadline: Beta
* Blocks release? No
== Documentation ==
There is no upstream documentation.
== Release Notes ==
Configuring system authentication and identity sources with authselect
is now mandatory. Systems with non-authselect configuration will be
automatically forcefully upgraded to authselect configuration. Users
that require special configuration are encouraged to create and use
custom authselect profile.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 6 months
F36 Change: Retired Packages (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/RetiredPackages
== Summary ==
Easy the task of removing packages, which were retired and no longer
receives updates.
== Owner ==
* Name: [[User:msuchy| Miroslav Suchý]]
* Email: msuchy(a)redhat.com
== Detailed Description ==
This follows the [[Changes/Fedora-Retired-Packages]] which was
withdrawn. This time I provide a script `remove-retired-packages`
(presented in the package of the same name) which identifies packages
retired between N-1 and current (N) version. Alternatively, user can
run:
remove-retired-packages 32
which will look for packages between Fedora Linux 32 and the current version.
The packages are suggested to be removed one by one, which allows the
admin to skip the package and keep it on their machine despite being
retired.
Part of this proposal is to change
[https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/#sect-...
the documentation for the upgrade].
== Feedback ==
See [[Changes/Fedora-Retired-Packages#Feedback original feedback page]]
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
Discussion] on devel mailing list prior this proposal.
== Benefit to Fedora ==
* We suggest users to remove packages that are no longer maintained
and may contain security vulnerabilities.
* We make sure that archaic packages do not break upgrade between two
versions of Fedora.
== Scope ==
* Proposal owners:
Subpackage `remove-retired-packages` has been created (subpackage of
`fedora-upgrade`).
* Other developers: N/A (not needed for this Change)
* Release engineering: N/A (not needed for this Change)
* Policies and guidelines: N/A (not needed for this Change)
Edit of https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/#sect-...
- will be done after approval from FESCO.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
Packages that are no longer maintained are removed during a
distribution upgrade.
== Dependencies ==
None.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
TBD
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 6 months
Orphaned packages looking for new maintainers
by Miro Hrončok
The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will fail to install and/or build when the affected package gets retired.
Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/<pkgname>
Full report available at:
https://churchyard.fedorapeople.org/orphans-2021-10-04.txt
grep it for your FAS username and follow the dependency chain.
For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan
Package (co)maintainers Status Change
================================================================================
dnstracer orphan 4 weeks ago
fedmod nphilipp, orphan 1 weeks ago
golang-github-hanwen-fuse orphan 0 weeks ago
golang-github-jacobsa-crypto orphan 0 weeks ago
golang-github-jacobsa-oglemock orphan 0 weeks ago
golang-github-jacobsa-ogletest orphan 0 weeks ago
golang-github-jacobsa-reqtrace orphan 0 weeks ago
golang-github-rfjakob-gocryptfs orphan 0 weeks ago
golang-github-sabhiram- orphan 0 weeks ago
gitignore
jakarta-commons-httpclient java-maint-sig, mizdebsk, 6 weeks ago
orphan
kdevelop-python dvratil, jgrulich, kde-sig, 1 weeks ago
orphan
kdocker kde-sig, orphan, rdieter 1 weeks ago
mingw-brotli etrunko, orphan 1 weeks ago
mingw-libpsl etrunko, orphan 1 weeks ago
mingw-libunistring etrunko, orphan 1 weeks ago
perl-WebService-Dropbox mathstuf, orphan 1 weeks ago
python-email_reply_parser orphan, python-sig 1 weeks ago
python-first orphan, python-sig 1 weeks ago
python-graphene-sqlalchemy orphan 1 weeks ago
python-graphql-server orphan 1 weeks ago
python-opencensus orphan 5 weeks ago
python-parallel-ssh orphan 1 weeks ago
python-pipreqs orphan, python-sig 1 weeks ago
python-plette orphan, pkopkan, python-sig 1 weeks ago
python-power orphan, python-sig 1 weeks ago
python-ssh2-python orphan 1 weeks ago
python-yarg orphan, python-sig 1 weeks ago
rubygem-ancestry jaruga, orphan 1 weeks ago
rubygem-cliver orphan 3 weeks ago
rubygem-gem-patch orphan 3 weeks ago
rubygem-scoped_search orphan 3 weeks ago
trac-customfieldadmin-plugin orphan 1 weeks ago
trac-watchlist-plugin orphan 1 weeks ago
waiverdb lholecek, lucarval, orphan, 1 weeks ago
ralph, vmaljulin
yarock kde-sig, martinkg, orphan 1 weeks ago
The following packages require above mentioned packages:
Report too long, see the full version at
https://churchyard.fedorapeople.org/orphans-2021-10-04.txt
See dependency chains of your packages at
https://packager-dashboard.fedoraproject.org/
See all orphaned packages at https://packager-dashboard.fedoraproject.org/orphan
Affected (co)maintainers (either directly or via packages' dependencies):
berrange: mingw-libpsl, mingw-brotli, mingw-libunistring
dcavalca: golang-github-hanwen-fuse
dvratil: kdevelop-python
eclipseo: golang-github-hanwen-fuse
elmarco: mingw-libpsl, mingw-brotli, mingw-libunistring
eparis: golang-github-hanwen-fuse
etrunko: mingw-libpsl, mingw-brotli, mingw-libunistring
fidencio: mingw-libpsl, mingw-brotli, mingw-libunistring
fpokorny: golang-github-hanwen-fuse
go-sig: golang-github-hanwen-fuse
infra-sig: golang-github-hanwen-fuse
jaruga: rubygem-ancestry
java-maint-sig: jakarta-commons-httpclient
jchaloup: golang-github-hanwen-fuse
jgrulich: kdevelop-python
kalev: mingw-libpsl, mingw-brotli, mingw-libunistring
kde-sig: yarock, kdocker, kdevelop-python
lbazan: python-ssh2-python
lholecek: waiverdb
limb: golang-github-hanwen-fuse
lsm5: golang-github-hanwen-fuse
lucarval: waiverdb
martinkg: yarock, perl-WebService-Dropbox
mathstuf: perl-WebService-Dropbox
mattia: golang-github-hanwen-fuse
mizdebsk: jakarta-commons-httpclient
nphilipp: fedmod
olem: golang-github-hanwen-fuse
pkopkan: python-plette
python-sig: python-pipreqs, python-power, python-yarg,
python-email_reply_parser, python-first, python-plette
qulogic: golang-github-hanwen-fuse
ralph: waiverdb
rdieter: kdocker
rjones: mingw-libpsl, mingw-brotli, mingw-libunistring
smani: mingw-libpsl, mingw-brotli, mingw-libunistring
teuf: mingw-libpsl, mingw-brotli, mingw-libunistring
vbatts: golang-github-hanwen-fuse
victortoso: mingw-libpsl, mingw-brotli, mingw-libunistring
virtmaint-sig: mingw-libpsl, mingw-brotli, mingw-libunistring
vmaljulin: waiverdb
--
The script creating this output is run and developed by Fedora
Release Engineering. Please report issues at its pagure instance:
https://pagure.io/releng/
The sources of this script can be found at:
https://pagure.io/releng/blob/main/f/scripts/find_unblocked_orphans.py
2 years, 6 months