[EPEL-devel] Re: Proposed official change to EPEL guidelines: modules and RHEL

2020-02-13 Thread Pat Riehecky



On 2/13/20 6:54 AM, Matthew Miller wrote:

I've been saying this for a while as if it's fact, but of course it's not
actually fact until approved, so I'm puting this to the EPEL team to
hopefully do so.

The current guidelines * say:

EPEL packages should only enhance and never disturb the Enterprise Linux
distributions they were built for. Thus packages from EPEL should never
replace packages from the target base distribution - including those on the
base distribution as well as layered products; kernel-modules further are
not allowed, as they can disturb the base kernel easily.

With modularity in EPEL 8, we have the opportunity to allow more flexibility
while preserving the primary goal of not disturbing the base distribution.
Therefore, I propose adding:

   In EPEL 8 or later, it is permitted to have module streams which contain
   packages with alternate versions to those provided in RHEL. These packages
   may be newer, built with different options, or even older to serve
   compatibility needs. These MUST NOT be the default stream -- in every
   case, explicit user action must be required to opt in to these versions.


(Note that the base package _does not_ have to be part of a module for this
to work.)

What do you think?





I like it, but perhaps it is worth adding a note that EPEL8 packages 
must not include an 'Obsoletes' that targets packages shipped in RHEL 
itself.


--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.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: Added arches but no automatic rebuild?

2020-02-12 Thread Pat Riehecky

I'm showing:

# Needed until LibRaw is available on s390x and aarch64
%if 0%{?rhel} >= 8
ExclusiveArch:  x86_64 ppc64le
%endif

Within the SPEC file.

On 2/12/20 9:22 AM, Richard Shaw wrote:
On Wed, Feb 12, 2020 at 9:18 AM Stephen John Smoogen <mailto:smo...@gmail.com>> wrote:




On Wed, 12 Feb 2020 at 09:46, Richard Shaw mailto:hobbes1...@gmail.com>> wrote:

I'm sure it was announced but I've been very busy lately but
while trying to build a package for EPEL 8 I noticed that two
builds (arches) failed for missing dependencies but two did not.

I see that there are a number of arches not originally part of
RHEL 8, which is fine, but when the arches were added
shouldn't all of the affected packages been rebuilt to add the
new arches?


I don't know what you are seeing to say this. The arches which
were initially there were x86_64, ppc64le, s390x and aarch64. I
don't know of any arches added after that and those have been in
el8 since day 1.


My original build of OpenImageIO only has x86_64 and ppc64le which I 
believe are the two RHEL 8 arches, correct?


https://koji.fedoraproject.org/koji/buildinfo?buildID=1347855 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__koji.fedoraproject.org_koji_buildinfo-3FbuildID-3D1347855=DwMFaQ=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=JREsJ1UsNfneo0dfASSv7aXJ636AuoNqrvjWCNarRXM=JMa68hMTOYhiOstLaKCM545zbOgL8CU3MbhjB3C6qEE=>


I have never used ExcludeArch in OpenImageIO...

Thanks,
Richard

___
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://urldefense.proofpoint.com/v2/url?u=https-3A__docs.fedoraproject.org_en-2DUS_project_code-2Dof-2Dconduct_=DwIGaQ=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=JREsJ1UsNfneo0dfASSv7aXJ636AuoNqrvjWCNarRXM=mVV_yErzQEhhxdyMvDbkiv_oViMVis2uo6rwY8LCtuU=
List Guidelines: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_Mailing-5Flist-5Fguidelines=DwIGaQ=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=JREsJ1UsNfneo0dfASSv7aXJ636AuoNqrvjWCNarRXM=h_lYjzEIEJDX2E6sTA4sdFf81a50cSLYUgzVIhmCV7g=
List Archives: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedoraproject.org_archives_list_epel-2Ddevel-40lists.fedoraproject.org=DwIGaQ=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=JREsJ1UsNfneo0dfASSv7aXJ636AuoNqrvjWCNarRXM=g0LPIxaoeIpqaiUcgHeXbgEP_xnRNTSRu1K5mzN3hHE=


--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.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: How to support python 3.8 from RHEL 8.2 in EPEL?

2020-01-30 Thread Pat Riehecky



On 1/30/20 9:47 AM, Miro Hrončok wrote:

On 30. 01. 20 16:44, Pat Riehecky wrote:
While I lack good answers, perhaps another question.  What a the 
thoughts on using python `.pth` files for python modules that work in 
multiple interpreters?


In theory this would permit bit for bit identical libraries in 
multiple interpreters at once?


Where would you put the files on the filesystem level?

How would we handle different bytecode caches and extension modules?



Perhaps something like /usr/lib/python-epel?  I thought python 3.6+ used 
the __pycache__ directory that was able to distinguish between the 
various python bytecodes.


I believe extension modules must be compiled for a specific 
interpreter... I could be wrong there... I don't recall ever building 
one myself.


Pat

--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.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: How to support python 3.8 from RHEL 8.2 in EPEL?

2020-01-30 Thread Pat Riehecky



On 1/30/20 9:32 AM, Orion Poplawski wrote:

Folks -

Looks like RHEL 8.2 will have python 3.8 in addition to python 3.6.  From
the 8.2 beta:

Red Hat Enterprise Linux 8 for x86_64 - AppStream Beta (RPMs)
Name   Stream  Profiles   Summary
python27   2.7 [d][e]  common [d] Python programming
language, version 2.7
python36   3.6 [d][e]  build, common [d]  Python programming
language, version 3.6
python38   3.8 [d][e]  build, common [d]  Python programming
language, version 3.8

Currently, %python_pkgversion is set to 3 in
/usr/lib/rpm/macros.d/macros.python-srpm from python-srpm-macros.

python3-devel is still provided only by python36-devel, so presumably all
EPEL8 python packages will continue to be built against python 3.6.  But I
imagine that people will soon be asking for python 3.8 versions of EPEL
packages.  How can we provide those?  Does this have to be done in some
modular fashion - which seems to come back to the discussion of whether or not
every package has to become its own module or whether to group them together
somehow.  Or since both python modules are "default" modules and we can
install both python36-devel and python38-devel at the same time, perhaps we
can define the python3_other* macros again for python38 and just go that way?

Thoughts?



While I lack good answers, perhaps another question.  What a the 
thoughts on using python `.pth` files for python modules that work in 
multiple interpreters?


In theory this would permit bit for bit identical libraries in multiple 
interpreters at once?


Pat

--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.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: Graphical package manager for EPEL8

2019-11-05 Thread Pat Riehecky

I've generally been happy with the gnome-software app.

Pat

On 11/5/19 10:27 AM, Edward Diener wrote:
Has there been any attempt to add to a EPEL8 a graphical package 
manager, such as dnfdragora ? CentOS7, which I have used, had yumex 
but since CentOS8 uses dnf the old yumex does not work anymore. As I 
understand it yumex-dnf is no longer being developed and dnfdragora is 
the logical continuation of yumex-dnf. As a workstation user of CentOS 
I am not interested in having to use dnf from the command line so a 
dnfdragora for CentOS8 would be very welcome. Thank you !


Edward Diener
___
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://urldefense.proofpoint.com/v2/url?u=https-3A__docs.fedoraproject.org_en-2DUS_project_code-2Dof-2Dconduct_=DwIGaQ=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=LjoA7RuRzR3C0cLyJ5t2BpQMDDK7LYiZUm7DpcdpeO0=qWgaI7xk4QtLT_BsrUmgWLBzXL92Gv8-XLzG3w5bFpk= 
List Guidelines: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_Mailing-5Flist-5Fguidelines=DwIGaQ=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=LjoA7RuRzR3C0cLyJ5t2BpQMDDK7LYiZUm7DpcdpeO0=YnnheIdX_sY-JA7gpH2jWyYch1qlHb9mwKZyVYnhDuk= 
List Archives: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedoraproject.org_archives_list_epel-2Ddevel-40lists.fedoraproject.org=DwIGaQ=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=LjoA7RuRzR3C0cLyJ5t2BpQMDDK7LYiZUm7DpcdpeO0=ACx3GduD32EdnaHWij5g0VeFnaw09J0G5EBkAG8Cl-g= 



--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.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: Modularity Policy Discussion for EPEL 8.1

2019-08-27 Thread Pat Riehecky



On 8/26/19 3:33 AM, Petr Pisar wrote:

On Fri, Aug 23, 2019 at 01:56:09PM -0400, Stephen Gallagher wrote:

So, I see the following options for how to handle default streams in RHEL 8

Option 1: We disallow assigning default streams at all within EPEL 8.
This will protect us against a future change where RHEL wants to set a
default. Additionally, it means that all EPEL modules are explicitly
opt-in and so we don't ever surprise anyone.

Option 2: We allow making EPEL streams the default stream if RHEL does
not currently provide a default stream. We set strict policy regarding
what a default stream may contain (such as "must not replace any
package provided by RHEL 8"). If RHEL later decides to set a default
for this stream, the RHEL release engineering must ensure that the
`data.version` value is higher than what EPEL 8 carries.

I'm somewhat more in favor of Option 1 here, mostly because it
minimizes the chance of conflicts and ensures the opt-in nature of
EPEL. But I'm willing to hear counter-arguments.


I don't like the Option 1. It makes adding modularized packages into a build
root impossible. Efectivelly forcing everbody to modularize everything or
nothing. That's exactly the deficiency the modularity has in Fedora and does
not have in RHEL. The Option 1 makes the modularity in EPEL terrible as in
Fedora.

Example: RHEL has two perl streams:

perl:5.24
perl:5.26 [d]

You can add a non-modular perl-Foo package into EPEL bacause EPEL magically
adds perl:5.26 into the build root.

If you add a perl-Foo module into EPEL, you won't be able to set a default
stream, hence you won't be able to have it in the build root and therefore you
won't be able to add a non-modular perl-Bar package that requires a perl-Foo
module component into EPEL.

The only solution would be either add perl-Bar as a module, or not add
perl-Foo as a module. If you go the second path (i.e. no modules), it means
you won't be able build none of the packages for the non-default streams (i.e.
perl:5.24).

That effectively pushes modules into the role of leaf-only dependencies.
That's quite awkward situation if you consider that RHEL delivers language
runtimes as modules. The proposed EPEL policy would devalute the non-default
runtimes.


Following up on the perl side of things with an example.  What, for 
example, would be the recommendation to get postgrey in EPEL8?


It requires perl, but nothing specific to 5.24 or 5.26.  It does, 
however, have several required perl modules.


It gets a bit more messy if I've got a home grown perl app that 
interfaces with SpamAssassin.


If EPEL8 says "just the default stream" for perl, then I have to keep 
migrating my app.  If every perl module becomes a Modularity Module, 
then 'dnf module list' is going to have a nearly endless list of perl 
packages, but if modules are only available for one stream, folks are 
going to find cpan a bit more friendly.


Pat


--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.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: [Bug 1647181] Cinnamon missing deps in 7.6

2018-11-08 Thread Pat Riehecky
I did a quick local test.  If caribou from F29[1] is branched for EPEL7 
cinnamon works as before and gnome-shell continues to function.


Pat

[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1093269

On 11/7/18 9:10 AM, Stephen John Smoogen wrote:


The package will need a new sponsor to take it over. I asked the 
maintainers to retire it because they were closing things wontfix.


On Wed, 7 Nov 2018 at 10:07, Pat Riehecky <mailto:riehe...@fnal.gov>> wrote:


These days cinnamon is my preferred desktop.  Thanks for the patch!

Any chance for an epel-testing package?

Pat

On 11/6/18 3:29 PM, Pablo Sebastián Greco wrote:


Missing link in previous email

https://src.fedoraproject.org/cgit/rpms/cinnamon.git/commit/?id=cfb06e44527f6d4fd6be1ef138ee29eb277e62fd

<https://urldefense.proofpoint.com/v2/url?u=https-3A__src.fedoraproject.org_cgit_rpms_cinnamon.git_commit_-3Fid-3Dcfb06e44527f6d4fd6be1ef138ee29eb277e62fd=DwMFaQ=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=ADuEvg2zWAATpb--cXRksLOy2RrG-iR0ZwQ5YpMPzqo=UQ_dLuka1pYnNzTMJSC87-Xtp_hQ7cDuQvAxIHM3iA8=>

El 6/11/18 a las 17:27, Pablo Sebastián Greco escribió:


Here's the removal patch. It would be good to know if the reason
is technical or personal, to see if we can come up with a solution.

Pablo.

El 6/11/18 a las 17:00, Pat Riehecky escribió:

Looks like cinnamon needs some work for RHEL 7.6 and someone to
do it...

Pat


 Forwarded Message 
Subject:[Bug 1647181] Cinnamon missing deps in 7.6
Date:   Tue, 6 Nov 2018 19:57:06 +
From:   bugzi...@redhat.com <mailto:bugzi...@redhat.com>


leigh scott  
<mailto:leigh123li...@googlemail.com>  changed:

What|Removed |Added

  Status|NEW |CLOSED
  Resolution|--- |WONTFIX
 Last Closed||2018-11-06 14:57:06



--- Comment #1 from leigh scott  
<mailto:leigh123li...@googlemail.com>  ---
I no longer support RHEL.

-- 
You are receiving this mail because:

You reported the bug.

___
epel-devel mailing list --epel-devel@lists.fedoraproject.org  
<mailto:epel-devel@lists.fedoraproject.org>
To unsubscribe send an email toepel-devel-le...@lists.fedoraproject.org  
<mailto:epel-devel-le...@lists.fedoraproject.org>
Fedora Code of Conduct:https://getfedora.org/code-of-conduct.html  
<https://urldefense.proofpoint.com/v2/url?u=https-3A__getfedora.org_code-2Dof-2Dconduct.html=DwMFaQ=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=ADuEvg2zWAATpb--cXRksLOy2RrG-iR0ZwQ5YpMPzqo=MUjfeiCKVPTm-7pjALvJ4GZs2dpQLbtorVN4b7IQ7ZU=>
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines  
<https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_Mailing-5Flist-5Fguidelines=DwMFaQ=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=ADuEvg2zWAATpb--cXRksLOy2RrG-iR0ZwQ5YpMPzqo=NcSb9OilgZw6mrAVAKnwdaNZAB_wM5_2dRHAZH3EKXA=>
List Archives:https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org  
<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedoraproject.org_archives_list_epel-2Ddevel-40lists.fedoraproject.org=DwMFaQ=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=ADuEvg2zWAATpb--cXRksLOy2RrG-iR0ZwQ5YpMPzqo=-cs3vcV8GZFJQ7J_5Q_DWB8DBZ5jsbhcgpvkcVEx9k0=>


___
epel-devel mailing list --epel-devel@lists.fedoraproject.org  
<mailto:epel-devel@lists.fedoraproject.org>
To unsubscribe send an email toepel-devel-le...@lists.fedoraproject.org  
<mailto:epel-devel-le...@lists.fedoraproject.org>
Fedora Code of Conduct:https://getfedora.org/code-of-conduct.html  
<https://urldefense.proofpoint.com/v2/url?u=https-3A__getfedora.org_code-2Dof-2Dconduct.html=DwMFaQ=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=ADuEvg2zWAATpb--cXRksLOy2RrG-iR0ZwQ5YpMPzqo=MUjfeiCKVPTm-7pjALvJ4GZs2dpQLbtorVN4b7IQ7ZU=>
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines  
<https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_Mailing-5Flist-5Fguidelines=DwMFaQ=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=ADuEvg2zWAATpb--cXRksLOy2RrG-iR0ZwQ5YpMPzqo=NcSb9OilgZw6mrAVAKnwdaNZAB_wM5_2dRHAZH3EKXA=>
List Archives:https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org  
<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedoraproject.org_archives_list_epel-2Ddevel-40lists.fedoraproject.org=DwMFaQ=gRgGjJ3BkIsb5y6s49Qq

[EPEL-devel] Re: Fwd: [Bug 1647181] Cinnamon missing deps in 7.6

2018-11-07 Thread Pat Riehecky

These days cinnamon is my preferred desktop.  Thanks for the patch!

Any chance for an epel-testing package?

Pat

On 11/6/18 3:29 PM, Pablo Sebastián Greco wrote:


Missing link in previous email 
https://src.fedoraproject.org/cgit/rpms/cinnamon.git/commit/?id=cfb06e44527f6d4fd6be1ef138ee29eb277e62fd


El 6/11/18 a las 17:27, Pablo Sebastián Greco escribió:


Here's the removal patch. It would be good to know if the reason is 
technical or personal, to see if we can come up with a solution.


Pablo.

El 6/11/18 a las 17:00, Pat Riehecky escribió:

Looks like cinnamon needs some work for RHEL 7.6 and someone to do it...

Pat


 Forwarded Message 
Subject:[Bug 1647181] Cinnamon missing deps in 7.6
Date:   Tue, 6 Nov 2018 19:57:06 +
From:   bugzi...@redhat.com


leigh scott  changed:

What|Removed |Added

  Status|NEW |CLOSED
  Resolution|--- |WONTFIX
 Last Closed||2018-11-06 14:57:06



--- Comment #1 from leigh scott  ---
I no longer support RHEL.

--
You are receiving this mail because:
You reported the bug.

___
epel-devel mailing list --epel-devel@lists.fedoraproject.org
To unsubscribe send an email toepel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:https://getfedora.org/code-of-conduct.html
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 toepel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:https://getfedora.org/code-of-conduct.html
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://urldefense.proofpoint.com/v2/url?u=https-3A__getfedora.org_code-2Dof-2Dconduct.html=DwIGaQ=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=ADuEvg2zWAATpb--cXRksLOy2RrG-iR0ZwQ5YpMPzqo=MUjfeiCKVPTm-7pjALvJ4GZs2dpQLbtorVN4b7IQ7ZU=
List Guidelines: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_Mailing-5Flist-5Fguidelines=DwIGaQ=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=ADuEvg2zWAATpb--cXRksLOy2RrG-iR0ZwQ5YpMPzqo=NcSb9OilgZw6mrAVAKnwdaNZAB_wM5_2dRHAZH3EKXA=
List Archives: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedoraproject.org_archives_list_epel-2Ddevel-40lists.fedoraproject.org=DwIGaQ=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=ADuEvg2zWAATpb--cXRksLOy2RrG-iR0ZwQ5YpMPzqo=-cs3vcV8GZFJQ7J_5Q_DWB8DBZ5jsbhcgpvkcVEx9k0=


--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org


[EPEL-devel] Fwd: [Bug 1647181] Cinnamon missing deps in 7.6

2018-11-06 Thread Pat Riehecky

Looks like cinnamon needs some work for RHEL 7.6 and someone to do it...

Pat


 Forwarded Message 
Subject:[Bug 1647181] Cinnamon missing deps in 7.6
Date:   Tue, 6 Nov 2018 19:57:06 +
From:   bugzi...@redhat.com


leigh scott  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |WONTFIX
Last Closed||2018-11-06 14:57:06



--- Comment #1 from leigh scott  ---
I no longer support RHEL.

--
You are receiving this mail because:
You reported the bug.

___
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://getfedora.org/code-of-conduct.html
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: incompatibility issue for mate-desktop

2018-04-25 Thread Pat Riehecky
EPEL tracks the latest RHEL release.  There are a number of fixes in 7.4 
and 7.5 that are really worth it.


Pat

On 04/25/2018 09:09 AM, Fred Liu wrote:

So abandon SL7.3? Does it mean EPEL doesn’t have consistent compatibility?

Thanks.

Fred




On Wed, Apr 25, 2018 at 9:57 PM +0800, "Pat Riehecky" 
<riehe...@fnal.gov <mailto:riehe...@fnal.gov>> wrote:


I would recommend updating to SL 7.4

Pat

On 04/25/2018 08:37 AM, Fred Liu wrote:
> Hi,
>
> I used to successfully install mate-desktop on SL7.3 by EPEL7. But
> today, when I tried again, I saw some incompatibility
> issues(glib2,gtk3+,etc). And I can successfully install it on OL7.5.
> Is normal? From my understanding, EPEL7 should work in both
> OSes.
>
> Any ideas?
>
>
> Thanks.
>
>
> Fred
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

-- 
Pat Riehecky


Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org



___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org

___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] Re: incompatibility issue for mate-desktop

2018-04-25 Thread Pat Riehecky

I would recommend updating to SL 7.4

Pat

On 04/25/2018 08:37 AM, Fred Liu wrote:

Hi,

I used to successfully install mate-desktop on SL7.3 by EPEL7. But
today, when I tried again, I saw some incompatibility
issues(glib2,gtk3+,etc). And I can successfully install it on OL7.5.
Is normal? From my understanding, EPEL7 should work in both
OSes.

Any ideas?


Thanks.


Fred
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


--
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] Re: python34 for EPEL6

2016-08-24 Thread Pat Riehecky



On 08/24/2016 04:58 PM, Dave Johansen wrote:
On Wed, Aug 24, 2016 at 3:38 PM, Orion Poplawski > wrote:


I have no idea if there is any interest in this or not.  I managed
to get the
EPEL7 python34 package to build on EL6 with a few modifications. 
Is there any

interest in supporting this?


How about using the Python SCLs?
https://www.softwarecollections.org/en/scls/?search=python3



I'd rather see https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3 
  extended to EL6 for hopefully easier packaging


Pat
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org