[EPEL-devel] Re: EPEL 7 - Packages that won't install - Pass 1
On Thu, 10 Oct 2019 at 14:47, Troy Dawson wrote: > > On Thu, Oct 10, 2019 at 7:46 AM Robert-André Mauchin > wrote: > > > > On Wednesday, 9 October 2019 23:22:11 CEST Troy Dawson wrote: > > > * golang-*-devel (Not really broken, you should never need to install > > > these) > > > ** I will not file bugzilla's on these. These -devel packages are only > > > used for rpm making. > > > golang-github-aws-aws-sdk-go-devel > > > golang-github-coreos-go-log-devel > > > golang-github-goraft-raft-devel > > > golang-github-rackspace-gophercloud-devel > > > golang-github-spacemonkeygo-spacelog-devel > > > golang-golangorg-oauth2-devel > > > golang-google-golangorg-cloud-devel > > > > Eh, who's taking care of the Golang stack in RHEL8? These are old packages, > > it > > would have been better to use the stack we rebuilt in F31 which is known to > > be > > working and up to date. Anything before is probably broken. > > > > These are from EPEL7, not 8. > As far as I can tell, there aren't any golang library packages in EPEL8. As far as I can tell there aren't any in EPEL-8 either. -- Stephen J Smoogen. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-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/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL 7 - Packages that won't install - Pass 1
On Thu, Oct 10, 2019 at 7:46 AM Robert-André Mauchin wrote: > > On Wednesday, 9 October 2019 23:22:11 CEST Troy Dawson wrote: > > * golang-*-devel (Not really broken, you should never need to install these) > > ** I will not file bugzilla's on these. These -devel packages are only > > used for rpm making. > > golang-github-aws-aws-sdk-go-devel > > golang-github-coreos-go-log-devel > > golang-github-goraft-raft-devel > > golang-github-rackspace-gophercloud-devel > > golang-github-spacemonkeygo-spacelog-devel > > golang-golangorg-oauth2-devel > > golang-google-golangorg-cloud-devel > > Eh, who's taking care of the Golang stack in RHEL8? These are old packages, it > would have been better to use the stack we rebuilt in F31 which is known to be > working and up to date. Anything before is probably broken. > These are from EPEL7, not 8. As far as I can tell, there aren't any golang library packages in EPEL8. Troy ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-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/epel-devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 11 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-4ca0c60e5b mbedtls-2.16.3-1.el8 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-04183e6fbf scapy-2.4.3-2.el8 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-1c488e885d python-ecdsa-0.13.3-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing chromium-77.0.3865.90-3.el8 fstrm-0.5.0-1.el8 libcutl-1.10.0-17.el8 libtorrent-0.13.8-1.el8 ntfs-3g-2017.3.23-11.el8 ntfs-3g-system-compression-1.0-2.el8 perl-Image-ExifTool-11.70-1.el8 perl-Net-SSLGlue-1.058-10.el8 perl-XML-TreePP-0.43-13.el8 po-debconf-1.0.21-1.el8 quotatool-1.6.2-13.el8 rtorrent-0.9.8-1.el8 Details about builds: chromium-77.0.3865.90-3.el8 (FEDORA-EPEL-2019-ca762fcbf8) A WebKit (Blink) powered web browser Update Information: Build for EPEL-8. fstrm-0.5.0-1.el8 (FEDORA-EPEL-2019-a4e1f3ebc6) Frame Streams implementation in C Update Information: fstrm 0.5.0 for epel8 References: [ 1 ] Bug #1760298 - Please build packagges for EPEL8 https://bugzilla.redhat.com/show_bug.cgi?id=1760298 libcutl-1.10.0-17.el8 (FEDORA-EPEL-2019-a703e6c6ac) C++ utility library from Code Synthesis Update Information: - New package References: [ 1 ] Bug #1754200 - Rebuild on epel8 https://bugzilla.redhat.com/show_bug.cgi?id=1754200 libtorrent-0.13.8-1.el8 (FEDORA-EPEL-2019-d09d39de3a) BitTorrent library with a focus on high performance & good code Update Information: libtorrent: 0.13.8 release rtorrent: 0.9.8 release References: [ 1 ] Bug #1760099 - [RFE] EPEL8 branch of libtorrent https://bugzilla.redhat.com/show_bug.cgi?id=1760099 [ 2 ] Bug #1757080 - rtorrent is missing for EPEL8 https://bugzilla.redhat.com/show_bug.cgi?id=1757080 ntfs-3g-2017.3.23-11.el8 (FEDORA-EPEL-2019-44ed272dbd) Linux NTFS userspace driver Update Information: Build ntfs-3g and ntfs-3g-system-compression for EPEL-8. References: [ 1 ] Bug #1759987 - Request to package ntfs-3g for EPEL 8 https://bugzilla.redhat.com/show_bug.cgi?id=1759987 ntfs-3g-system-compression-1.0-2.el8 (FEDORA-EPEL-2019-44ed272dbd) NTFS-3G plugin for reading "system compressed" files Update Information: Build ntfs-3g and ntfs-3g-system-compression for EPEL-8. References: [ 1 ] Bug #1759987 - Request to package ntfs-3g for EPEL 8 https://bugzilla.redhat.com/show_bug.cgi?id=1759987 perl-Image-ExifTool-11.70-1.el8 (FEDORA-EPEL-2019-6097899ea8) Utility for reading and writing image meta info Update Information: New build for EPEL-8. perl-Net-SSLGlue-1.058-10.el8 (FEDORA-EPEL-2019-15c5df941d) Add/extend SSL support for common perl modules --
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 421 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 163 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c499781e80 python-gnupg-0.4.4-1.el7 161 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b bubblewrap-0.3.3-2.el7 97 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-12067fc897 dosbox-0.74.3-2.el7 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-600b4ad49c yara-3.10.0-3.el7 11 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-8b6b5df244 mbedtls-2.7.12-1.el7 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-180a83b5fc suricata-4.1.5-3.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-6ca75fc39a nginx-1.16.1-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-b69e8f60ca libapreq2-2.13-13.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-40a9ceccd5 radare2-3.9.0-1.el7.1 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-3bcbd2f338 opendmarc-1.3.2-1.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-4e8faaa263 python34-3.4.10-4.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-301b621e07 golang-1.13.1-1.el7 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-86a4692b13 scapy-2.4.3-2.el7 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-ef109e65c0 python-ecdsa-0.13.3-1.el7 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-35adef43f8 koji-1.18.1-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing libfm-qt-0.14.1-5.el7 liblxqt-0.14.1-5.el7 libqtxdg-3.3.1-5.el7 libsysstat-0.4.2-3.el7 lximage-qt-0.14.1-3.el7 lxqt-about-0.14.1-3.el7 lxqt-admin-0.14.1-3.el7 lxqt-build-tools-0.6.0-3.el7 lxqt-config-0.14.1-3.el7 lxqt-globalkeys-0.14.1-3.el7 lxqt-notificationd-0.14.1-3.el7 lxqt-openssh-askpass-0.14.1-3.el7 lxqt-panel-0.14.1-3.el7 lxqt-policykit-0.14.1-3.el7 lxqt-powermanagement-0.14.1-3.el7 lxqt-qtplugin-0.14.0-7.el7 lxqt-runner-0.14.1-3.el7 lxqt-session-0.14.1-3.el7 lxqt-sudo-0.14.1-3.el7 lxqt-themes-0.14.0-3.el7 menu-cache-1.1.0-1.el7.5 obconf-qt-0.14.1-3.el7 openbox-theme-mistral-thin-0-6.20170125.el7 pavucontrol-qt-0.14.1-3.el7 pcmanfm-qt-0.14.1-3.el7 perl-Image-ExifTool-11.70-1.el7 qterminal-0.14.1-3.el7 qtermwidget-0.14.1-3.el7 wabt-1.0.12-1.el7 Details about builds: libfm-qt-0.14.1-5.el7 (FEDORA-EPEL-2019-18ce705d1b) Companion library for PCManFM Update Information: LXQt 0.14 for epel7 LxQt 0.11.0 ChangeLog: * Fri Sep 20 2019 Zamir SUN - 0.14.1-5 - Improve compatibility with epel7 * Thu Jul 25 2019 Fedora Release Engineering - 0.14.1-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild * Mon Jun 17 2019 Jan Grulich - 0.14.1-3 - rebuild (qt5) * Wed Jun 5 2019 Jan Grulich - 0.14.1-2 - rebuild (qt5) * Mon Apr 15 2019 Zamir SUN - 0.14.1-1 - Update to version 0.14.1 * Mon Mar 4 2019 Kevin Kofler - 0.14.0-3 - Rebuild for Qt 5.12.1 * Wed Feb 13 2019 Zamir SUN - 0.14.0-2 - Add l10n sub package * Wed Feb 13 2019 Zamir SUN - 0.14.0-1 - Prepare for LXQt 0.14.0 * Fri Feb 1 2019 Fedora Release Engineering - 0.13.1-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild * Thu Dec 13 2018 Rex Dieter - 0.13.1-3 - rebuild (qt5) * Fri Sep 21 2018 Jan Grulich - 0.13.1-2 - rebuild (qt5) * Thu Aug 9 2018 Zamir SUN - 0.13.1-1 - Update to 0.13.1 * Fri Aug 3 2018 Zamir SUN - 0.13.0-2 - Add menu-cache-devel as Require, otherwise cmake report 'Imported target "fm-qt" includes non-existent path' * Fri Aug 3 2018 Zamir SUN - 0.13.0-1 - Update to version 0.13.0 * Fri Jul 13 2018 Fedora Release Engineering - 0.11.2-14 - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild * Thu Jun 21 2018 Rex Dieter - 0.11.2-13 - rebuild (qt5) * Sun May 27 2018 Rex Dieter - 0.11.2-12 - rebuild (qt5) * Wed Feb 14 2018 Jan Grulich - 0.11.2-11 - rebuild (qt5) * Wed Feb 7 2018 Fedora Release Engineering - 0.11.2-10 - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild * Mon Jan 1 2018 Rex Dieter - 0.11.2-9 - rebuild (qt5) * Sun Nov 26 2017 Rex Dieter - 0.11.2-8 - rebuild (qt5) * Wed Oct 11 2017 Rex Dieter - 0.11.2-7 - BR: qt5-qtbase-private-devel * Thu Aug 3 2017 Fedora Release Engineering - 0.11.2-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild * Wed Jul 26 2017 Fedora Release Engineering - 0.11.2-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild * Fri Feb
[EPEL-devel] Re: EPEL 7 - Packages that won't install - Pass 1
On Wednesday, 9 October 2019 23:22:11 CEST Troy Dawson wrote: > * golang-*-devel (Not really broken, you should never need to install these) > ** I will not file bugzilla's on these. These -devel packages are only > used for rpm making. > golang-github-aws-aws-sdk-go-devel > golang-github-coreos-go-log-devel > golang-github-goraft-raft-devel > golang-github-rackspace-gophercloud-devel > golang-github-spacemonkeygo-spacelog-devel > golang-golangorg-oauth2-devel > golang-google-golangorg-cloud-devel Eh, who's taking care of the Golang stack in RHEL8? These are old packages, it would have been better to use the stack we rebuilt in F31 which is known to be working and up to date. Anything before is probably broken. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-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/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: A plan regarding SCLs in EPEL 8
On Wed, Oct 9, 2019 at 4:05 PM Kevin Fenzi wrote: > On Mon, Oct 07, 2019 at 01:16:47PM -0500, Merlin Mathesius wrote: > > I was asked to draft a plan stating what EPEL 8 should do regarding > > Software Collections. The draft I came up with is included below. > > Looks good to me. +1 here. > > > EPEL Steering Committee: Please ratify this plan or provide feedback as > > necessary. When it's ready, and I will prepare a PR for this to land in > > https://pagure.io/epel/blob/master/f/docs/source > > That would be great... > Thanks! Anyone else? I went ahead and created https://pagure.io/epel/pull-request/81 Merlin > kevin > -- > > > > Regards, > > > > Merlin > > > > -- > > > > > > *Regarding EPEL and Software Collections* > > *Background* > > > > For RHEL 8, Red Hat made the decision to provide multiple versions of > > software in the form of App Stream modules instead of Red Hat Software > > Collections (RHSCLs). > > > > SCLs are maintained by the CentOS Software Collections SIG, not the EPEL > > SIG. > > > > RHEL 8 comes with the scl-utils and scl-utils-build packages--which > contain > > tools for using and building SCLs. These packages appear to function as > > expected with RHEL 8 and CentOS 8. > > > > *Recommendations* > > > > EPEL will not provide SCL support, although it will not prohibit use of > the > > SCL tools provided with RHEL 8. > > > > EPEL will not provide any SCLs. > > > > EPEL encourages the community to follow Red Hat’s lead and provide > multiple > > versions of software for RHEL 8 and CentOS 8 in the form of modules > rather > > than SCLs. > > > > For use cases that require the parallel installation of multiple versions > > of the same component, EPEL recommends the same solution as RHEL 8: > > containers. > > > > -- > > > ___ > > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > > To unsubscribe send an email to epel-devel-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/epel-devel@lists.fedoraproject.org > > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-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/epel-devel@lists.fedoraproject.org > ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-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/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: A plan regarding SCLs in EPEL 8
On Thu, 10 Oct 2019 at 04:04, LAHAYE Olivier wrote: > > Hi, > > What is the strategy regarding packages like nextcould that has a major > update every 5/6 months? > I mean, regarding incompatible upgrades policy. > The incompatible upgrades policy was something we could never really enforce and so is a gentleman's agreement that it won't happen. [I thought I also removed all references to it on our policies but seem to have missed it somewhere.] The problem is that EPEL is a volunteer group. No one is assigned to work permanently on making EPEL work. It is done by people who are either assigned temporarily to make something go.. or just by the rest of us when we have finished our regular day-to-day tasks. This means we try to put in policies to allow people to self-manage problems as best they can. In the case of any incompatible upgrades, the current policy is that the maintainer should email the lists that they want to upgrade to a version which will break things. They outline the plan they have and why they are doing it. The EPEL Steering Committee checks it over and usually says 'ok that makes sense, make it so.' The maintainer then emails epel-announce and epel-devel and any other lists that it is going to happen. They then put the packages in epel-testing and see how much it breaks things. If they get negative karma they don't push to stable.. if they don't they push after 3-6 weeks. However it is up to the maintainer to have the volunteer time to do this > Right now, nextcloud-V10 is in EPEL7 and is not upgraded. On nextcloud site, > it is obsolete and the current version is nextcloud-V17.0.0 > https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule > > Nextcloud supports upgrading from one version to another, but now, upgrading > from v10 to V17 is impossible. > > How will EPEL8 handle those kind of software? Will there be a specific repo > for those kind of software that constantly evolve or will it be frozen for > entire EPEL8 life? Or will it never be eligible for inclusion in EPEL8 due to > its lifecycle? > For EPEL-8 it would be that the person would make a module for nextcloud, and give it a 12 month lifetime in pdc. Then they would update to the next version as time went on. Or they could just put the package in playground-epel8 and update the sets whenever they wanted. > Regards, > > Olivier. > > Le 09/10/2019 23:05, « Kevin Fenzi » a écrit : > > On Mon, Oct 07, 2019 at 01:16:47PM -0500, Merlin Mathesius wrote: > > I was asked to draft a plan stating what EPEL 8 should do regarding > > Software Collections. The draft I came up with is included below. > > Looks good to me. +1 here. > > > EPEL Steering Committee: Please ratify this plan or provide feedback as > > necessary. When it's ready, and I will prepare a PR for this to land in > > https://pagure.io/epel/blob/master/f/docs/source > > That would be great... > > kevin > -- > > > > Regards, > > > > Merlin > > > > -- > > > > > > *Regarding EPEL and Software Collections* > > *Background* > > > > For RHEL 8, Red Hat made the decision to provide multiple versions of > > software in the form of App Stream modules instead of Red Hat Software > > Collections (RHSCLs). > > > > SCLs are maintained by the CentOS Software Collections SIG, not the EPEL > > SIG. > > > > RHEL 8 comes with the scl-utils and scl-utils-build packages--which > contain > > tools for using and building SCLs. These packages appear to function as > > expected with RHEL 8 and CentOS 8. > > > > *Recommendations* > > > > EPEL will not provide SCL support, although it will not prohibit use of > the > > SCL tools provided with RHEL 8. > > > > EPEL will not provide any SCLs. > > > > EPEL encourages the community to follow Red Hat’s lead and provide > multiple > > versions of software for RHEL 8 and CentOS 8 in the form of modules > rather > > than SCLs. > > > > For use cases that require the parallel installation of multiple > versions > > of the same component, EPEL recommends the same solution as RHEL 8: > > containers. > > > > -- > > > ___ > > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > > To unsubscribe send an email to epel-devel-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/epel-devel@lists.fedoraproject.org > > > > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedorapro
[EPEL-devel] Re: A plan regarding SCLs in EPEL 8
Hi, What is the strategy regarding packages like nextcould that has a major update every 5/6 months? I mean, regarding incompatible upgrades policy. Right now, nextcloud-V10 is in EPEL7 and is not upgraded. On nextcloud site, it is obsolete and the current version is nextcloud-V17.0.0 https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule Nextcloud supports upgrading from one version to another, but now, upgrading from v10 to V17 is impossible. How will EPEL8 handle those kind of software? Will there be a specific repo for those kind of software that constantly evolve or will it be frozen for entire EPEL8 life? Or will it never be eligible for inclusion in EPEL8 due to its lifecycle? Regards, Olivier. Le 09/10/2019 23:05, « Kevin Fenzi » a écrit : On Mon, Oct 07, 2019 at 01:16:47PM -0500, Merlin Mathesius wrote: > I was asked to draft a plan stating what EPEL 8 should do regarding > Software Collections. The draft I came up with is included below. Looks good to me. +1 here. > EPEL Steering Committee: Please ratify this plan or provide feedback as > necessary. When it's ready, and I will prepare a PR for this to land in > https://pagure.io/epel/blob/master/f/docs/source That would be great... kevin -- > > Regards, > > Merlin > > -- > > > *Regarding EPEL and Software Collections* > *Background* > > For RHEL 8, Red Hat made the decision to provide multiple versions of > software in the form of App Stream modules instead of Red Hat Software > Collections (RHSCLs). > > SCLs are maintained by the CentOS Software Collections SIG, not the EPEL > SIG. > > RHEL 8 comes with the scl-utils and scl-utils-build packages--which contain > tools for using and building SCLs. These packages appear to function as > expected with RHEL 8 and CentOS 8. > > *Recommendations* > > EPEL will not provide SCL support, although it will not prohibit use of the > SCL tools provided with RHEL 8. > > EPEL will not provide any SCLs. > > EPEL encourages the community to follow Red Hat’s lead and provide multiple > versions of software for RHEL 8 and CentOS 8 in the form of modules rather > than SCLs. > > For use cases that require the parallel installation of multiple versions > of the same component, EPEL recommends the same solution as RHEL 8: > containers. > > -- > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-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/epel-devel@lists.fedoraproject.org ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-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/epel-devel@lists.fedoraproject.org
