Orphaned packages looking for new maintainers
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 be retired when the affected package gets retired. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ This report is available at: https://churchyard.fedorapeople.org/orphans-2020-10-26.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager.fedorainfracloud.org/ For all orphaned packages, see https://packager.fedorainfracloud.org/orphan Package (co)maintainersStatus Change === apache-commons-configuration fnasser, mizdebsk, orphan, spike 2 weeks ago arpwatch orphan 0 weeks ago celt071orphan 0 weeks ago dnscap orphan 0 weeks ago electrum orphan 0 weeks ago huborphan, ralph, sgallagh3 weeks ago jboss-interceptors-1.2-api orphan 6 weeks ago jboss-jsf-2.1-api orphan 2 weeks ago libbindorphan 0 weeks ago log4j12mizdebsk, orphan 6 weeks ago metadata-extractor2cquad, orphan 2 weeks ago mingw-gtkglext epienbro, maci, orphan 0 weeks ago pipsi orphan, python-sig 4 weeks ago pyqtrailer orphan 2 weeks ago python-XStatic-jQuery openstack-sig, orphan, rdopiera3 weeks ago python-beanbag orphan 2 weeks ago python-libsass orphan 2 weeks ago pytrailer orphan 2 weeks ago rofi orphan, sway-sig 0 weeks ago vdr-skinsoppalusikka orphan 5 weeks ago vrpn orphan 0 weeks ago vtun orphan 5 weeks ago The following packages require above mentioned packages: Depending on: celt071 (1), status change: 2020-10-20 (0 weeks ago) mumble (maintained by: carlwgeorge, ngompa) mumble-1.3.2-2.fc34.src requires celt071-devel = 0.7.1-20.fc33 mumble-1.3.2-2.fc34.x86_64 requires celt071(x86-64) = 0.7.1-20.fc33 Depending on: jboss-interceptors-1.2-api (1), status change: 2020-09-13 (6 weeks ago) geronimo-jcdi-1.1-api (maintained by: jjelen) geronimo-jcdi-1.1-api-1.0-10.fc33.src requires mvn(org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.2_spec) = 1.0.1.Final Depending on: jboss-jsf-2.1-api (1), status change: 2020-10-06 (2 weeks ago) apache-commons-chain (maintained by: jjelen) apache-commons-chain-1.2-24.fc33.noarch requires mvn(org.jboss.spec.javax.faces:jboss-jsf-api_2.1_spec) = 2.0.2.Final apache-commons-chain-1.2-24.fc33.src requires mvn(org.jboss.spec.javax.faces:jboss-jsf-api_2.1_spec) = 2.0.2.Final Depending on: libbind (1), status change: 2020-10-20 (0 weeks ago) dnscap (maintained by: orphan) dnscap-141-19.fc33.src requires libbind-devel = 6.0-22.fc33 dnscap-141-19.fc33.x86_64 requires libbind.so.4()(64bit) Depending on: log4j12 (3), status change: 2020-09-13 (6 weeks ago) apache-commons-configuration (maintained by: fnasser, mizdebsk, orphan, spike) apache-commons-configuration-1.10-15.fc32.src requires mvn(log4j:log4j:1.2.17) = 1.2.17 apache-log4j-extras (maintained by: coolsvap, gil, moceap) apache-log4j-extras-1.2.17.1-18.fc33.noarch requires mvn(log4j:log4j:1.2.17) = 1.2.17 apache-log4j-extras-1.2.17.1-18.fc33.src requires mvn(log4j:log4j:1.2.17) = 1.2.17 azureus (maintained by: djuran) azureus-5.7.6.0-13.fc34.noarch requires log4j12 = 1.2.17-30.fc34 azureus-5.7.6.0-13.fc34.src requires log4j12 = 1.2.17-30.fc34 Depending on: python-XStatic-jQuery (1), status change: 2020-09-28 (3 weeks ago) python-XStatic-jquery-ui (maintained by: mrunge, openstack-sig, rdopiera)
F34 Change proposal: AArch64 KDE Plasma Desktop image (Self-Contained Change)
https://fedoraproject.org/wiki/Changes/AArch64_KDE_Plasma_Desktop_image == Summary == Add an AArch64 KDE Plasma Desktop spin disk image to deliverables in Fedora 34. == Owner == * Name: [[User:ngompa | Neal Gompa]] * Email: ngomp...@gmail.com * Product: KDE Plasma * Responsible WG: KDE SIG == Detailed Description == We currently offer Workstation, Xfce, Minimal and Server images for use with AArch64 computers. We would like to add a variant offering the KDE Plasma Desktop. == Benefit to Fedora == Better user experience and an additional desktop choice for AArch64 computers. == Scope == * Proposal owners: The KDE SIG will make the kickstart changes needed to support adding the desktop image to the compose. * Other developers: N/A * Release engineering: Enable building of the AArch64 KDE desktop image. Small tweaks may be required to the pungi configs or fedora kickstarts but those will be completed by the SIG and sent as pull requests. Issue[ https://pagure.io/releng/issue/9815 #9815] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == No upgrade compatibility required, this is a new image variant. == How To Test == Testing can be completed on any supported AArch64 computer using the existing arm-image-installer. Any additional instructions will be added to the ARM installation documentation. == User Experience == Users will have increased choice in desktop offerings for AArch64 computers. Those who wish to use the KDE Plasma Desktop on AArch64 computers will have an easy option to use. == Dependencies == N/A (not a System Wide Change) == Contingency Plan == * Contingency mechanism: N/A * Contingency deadline: N/A * Blocks release? No * Blocks product? No == Documentation == All documentation will be added or updated via the ARM Landing Page. == Release Notes == -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
F34 Change proposal: MariaDB 10.5 (Self-Contained Change)
https://fedoraproject.org/wiki/Changes/MariaDB_10.5
== Summary ==
Update of MariaDB ('mariadb' package) in Fedora from 10.4 to 10.5 version.
[[Category:Package MariaDB]]
== Owner ==
* Name: [[User:mschorm| Michal Schorm]]
* Email: msch...@redhat.com
== Detailed Description ==
Update of MariaDB package in Fedora from 10.4 version to 10.5 version.
== Benefit to Fedora ==
I'm cooperating with the upstream to bring the latest stable software to
Fedora users.
10.5 series introduces number of enhancements, which cannot be found in
previous series.
Overview of the new features can be found here:
https://mariadb.com/kb/en/changes-improvements-in-mariadb-105/
== Scope ==
* Proposal owners:
**Prepare MariaDB 10.4 as a module for Rawhide and atleast one stable
Fedora release (done)so users which want to stay on the current
release have the possibility.This also serve as a failover mechanism
in case of issues with the 10.5.
**Prepare MariaDB 10.5 as a module for Rawhide and atleast one stable
Fedora release (done in Rawhide; the rest in BODHI)so users can test
the 10.5 in advance. (installing 10.5 module on already stable release)This also serve as a upgrade path - users can install 10.5 module on
Fedora release which have 10.4 in base; and then upgrade to 10.5 module on
a Fedora release which will have 10.5 in base.
**Release MariaDB 10.5 to Rawhide (blocked; 10.5 modules needs testing
first)
**Check software that requires or depends on 'mariadb' or 'galera' package
for incompatibilitiesThis shouldn't be an issue in general, as vast
majority of the software requires client library, provided by
"mariadb-connector-c" package, which won't change.
**Gather user input on the changes between MariaDB 10.4 and 10.5
* Other developers: N/A (not a System Wide Change)
* Release engineering:
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
The MariaDB client library is compatible, so the shouldn't be any issues
and / or need for rebuild of dependent packages.
==='''UPDATE (10/2020)'''===
MariaDB 10.5 modules are now available for Fedora Rawhide and in BODHI for
the stable releases
== How To Test ==
Usual testing as when upgrading between major MariaDB versions.
Test that all other software runs well with MariaDB 10.5.
Report any issues, so I can reach the different upstreams and check if they
plan update their software to support MariaDB 10.5 and when.
== User Experience ==
The users will have to upgrade their databases the same way as between
major MariaDB versions.
If the users want to stick with MariaDB 10.4 for a little longer, the
MariaDB 10.4 module is available for them in all stable Fedora releases as
well as in Rawhide.
If the users want to test the 10.5 series beforehand, the MariaDB 10.5
module is available.
== Dependencies ==
Since the client library ('mariadb-connector-c') is not changing, dependent
software should work fine.
Only a rare cases builds against the server part of MariaDB. (e.g. building
a server plugin)
== Contingency Plan ==
Modules will provide the functional version of MariaDB 10.4, available to
all users.
* Contingency mechanism: Fedora Modules for 10.4 available
* Contingency deadline: already in place
* Blocks release? N/A (not a System Wide Change)
* Blocks product? N/A (not a System Wide Change)
== Documentation ==
Upgrade startegy:
https://mariadb.com/kb/en/library/upgrading-from-mariadb-104-to-mariadb-105/
Upgrading and incompatibilities:
https://mariadb.com/kb/en/library/upgrading-from-mariadb-104-to-mariadb-105/#incompatible-changes-between-104-and-105
== Release Notes ==
Release notes for each release:
https://mariadb.com/kb/en/library/release-notes-mariadb-105-series/
Overall overview of the changes and improvements:
https://mariadb.com/kb/en/library/changes-improvements-in-mariadb-105/
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
GitLab AMA Topic Discussion: Permissions & Access
Hi everyone, Thanks again for your involvement in the GitLab AMA session on IRC in September. As promised, this is the first of a 5-part series breaking down main topics that came up during the session. I will send a topic every week for discussion to both Fedora and CentOS devel lists. I have pulled the relevant questions and answers from the original hackmd doc into one email. If you would like to discuss this topic specifically, here might be a good place to do so. I dont consider myself technical enough to weigh in on details, but I am happy to facilitate as best I can via email. And more importantly (for me), learn from the discussion too. Here are some links to resources as well: * Questions and Answers hackmd link https://hackmd.io/RW8HahOeR7OJPON1dwuo3w * Chat log from session https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-10/ama_session_with_gitlab.2020-09-10-13.31.log.html * AMA Blog post https://communityblog.fedoraproject.org/gitlab-ama-follow-up/#more-9346 * Here is this email in hackmd if you wish to view it there: https://hackmd.io/1pjX1cVnTjekOLVowj5UiQ?view ## Topic: Permission and Access - Question: Fedora has a group-based access system. People in the `packager` group have (commit) access to only the packages they maintain. People in the `provenpackager` group have (commit) access to all the active packages, but a few (for legal reason). People in the `releng` group have commit access to all the packages. Is this an access model that GitLab can support? If not, how would this work in a GitLab world? How would notifications work (Esp consider people in the `provenpackager` or `releng` group do not want to be notified for all the projects they have access to)? - Answer: What I explored was something along the lines of : - Packager → Using GitLab’s Maintainer or Developer role for the project they maintain (Maintainer have the ability to access project settings and change pretty much everything there, so that might be blocking here, Developer only have commit access, so we need another way to change some settings for Packagers) - Co-Maintainer → Using GitLab’s Developer role (commit access) - Proven-Packager → GitLab’s Developer role on all repo (expect 2) - Release Engineer/Admin/etc .. → GitLab’s Owner role on all repos - This is not an exact matching with what we currently have but should give us a way to experiment with this and look at what is acceptable or not. - There is also a GitLab ticket (https://gitlab.com/gitlab-org/gitlab/-/issues/7626) to implement policies for the project that could give more granular control of permissions. - Gitlab’s notifications are quite granular and can be managed at the different levels (Merge Requests, Projects, Group, Global) https://docs.gitlab.com/ee/user/profile/notifications.html#global-notification-settings - Question: Fedora supports the concept of a retired `project` (ie: archived) that no-one can commit to. Does GitLab have an equivalent concept? (The retired status is not something project admins can change) - Answer: There is an option to have a “retired” group which is configured to have nobody with commit access. Then retiring a project would simply mean to move the project from the “rpm” group to “retired” group for example. There is also possibility to simply archive projects https://docs.gitlab.com/ee/user/project/settings/#archiving-a-project - Question: could gitlab (inc) maintain a Community Edition GitLab instance that Fedora uses? - Answer: There is no plan to create custom versions of GitLab for customers. Instead, GitLab encourages paid customers and free users alike to contribute upstream to make sure that GitLab continues to work well for the most amount of users possible. As an open core company, GitLab has a public roadmap and works with its community members to build a great product. GitLab regularly engages with its community and takes into account its feedback. As a result, features are often ported down into lower tiers in order to make the Community Edition and Free tiers continuously more useful (see example of 18 features moved to open source). GitLab hosting is available to users of GitLab.com SaaS, but GitLab does not offer hosting and management for GitLab CE or EE instances. - Question: Can project creation be restricted to a specific group of people in GitLab? - Answer: Yes this can be configured at the instance level (https://gitlab.com/help/user/admin_area/settings/visibility_and_access_controls.md#default-project-creation-protection) or at the group level (https://gitlab.com/help/user/group/index.md#default-project-creation-level) - Question: Can project (main project, not fork) deletion be restricted to a specific group of people in GitLab? (ie: project owner/maintainer must not be allowed to delete a main project, they can delete their own fork of course) - Answer: There is an issue
