[EPEL-devel] [OT] Re: Re: EPEL Proposal #1: Rechartering

[Michael A. Peters]

On 02/18/2016 01:39 PM, Bryan J Smith wrote:



Non-Red Hat customers running CentOS usually have a much easier task
of enabling EPEL, although there can still be some issues.


Yes it is a bit odd to me that the free CentOS is in many respects 
easier to use than the paid RHEL.


Would be nice where support is needed to be able to install CentOS and 
then buy an RHEL support license but keep using CentOS.

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

[EPEL-devel] Re: Please test Xfce 4.12 for inclusion in EPEL - 7

[Mukundan Ragavan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/26/2016 05:01 AM, john tatt wrote:
> Hi
> 
> Do you think you will build it also for i386 arch ?
> 
> Thx
> 
> 


I don't think COPR supports 32-bit for EPEL-7 ... So, no plans at the
moment.


- -- 
GPG Key - E5C8BC67
- ---


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJW0jeoAAoJEHE/1K3lyLxnw2QP/04v5YaPmg3QG64NFcwtQbyN
FJ7ck217NMpQf6x0jY7ajU3s08IBHOxBFcJo79suInRM5pQaX9iYIiyFsgUWevEE
Y7HuQVQwCYra4sNV89/l95a6lqhRgU6WqGaCB6jxCBCMpq8mvpDIDd30leQ1tj9O
CqaKIgUswCwywuqWfdlK9cu9KvAqlAhgnq/G2u5uH8udRY7KqsHDNaXyUfEDpEcI
L6m2Elwh9rVbhy0BiwawEuM3lW5BlZrkBeSlOdTyz3d7ksergOTEQrddXVcw38Wh
5QyKkacqcDOQV0Q9IzUpXfX9FIzjN9/XqZehADSW28YWPlJjuHDw3kIjTUgfiKLE
/5RxmDH0fy3hRL/+bUrSuC++QkUg3cQnWSY/5ozn1XyzsX2ax+i6EnfJ/Aa/rZ/S
wAPKb5OSWGY3y9gc/eu+wipHv4yxIAeNoXTmVF2W7GYYkCqEBVhJ0NUg5G/B3pV2
U280bV3v9dCyklS0QkT8tTVkkFWXCdVVYkWdideQX0Rj/01Zpu60ia83/b4OFiBn
8L0jpzHRXWcHkgruC7j/pzb78BDVxEPdNKIOxLscuNwKjoK9MrW0ZPjijfXLevrN
hhnHAuUYau7lBubh5cdazyIo8iPyhHXtoEaKT061zaztzUGEA/1mpm7DdIKQ2r6E
AprySZM4xOmGai1pidiT
=vFIo
-END PGP SIGNATURE-
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Please test Xfce 4.12 for inclusion in EPEL - 7

[Mukundan Ragavan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/27/2016 03:47 PM, Kevin Fenzi wrote:
> On Sat, 27 Feb 2016 20:17:39 + (UTC) john tatt
>  wrote:
> 
>> Hi I sis a yum install xfce4* . Maybe xfwm4 was not in the
>> dependencies ?
> 
> Thats not going to work. Xfce has many components that don't start
> with xfce4.
> 
> You could try 'yum groupinstall xfce-desktop' but I am not sure
> the comps are setup right for that in epel7. So, instead just list
> all the packages in the copr...
> 
> yum install xfwm4 xfdesktop xfdashboard xfconf
> xfce4-weather-plugin xfce4-verve-plugin xfce4-time-out-plugin
> xfce4-terminal xfce4-systemload-plugin xfce4-settings
> xfce4-session xfce4-sensors-plugin xfce4-screenshooter
> xfce4-pulseaudio-plugin xfce4-power-manager xfce4-panel
> xfce4-notifyd xfce4-netload-plugin xfce4-mount-plugin
> xfce4-mailwatch-plugin xfce4-genmon-plugin xfce4-eyes-plugin
> xfce4-diskperf-plugin xfce4-dict xfce4-dev-tools 
> xfce4-cpugraph-plugin xfce4-clipman-plugin xfce4-appfinder
> xfce-polkit xfburn tumbler thunar-volman thunar-vfs
> thunar-media-tags-plugin thunar-archive-plugin Thunar ristretto
> parole orage libxfce4util libxfce4ui gtk-xfce-engine garcon exo
> 
> (or remove plugins you don't want).
> 
> kevin
> 
> 


yum groups install xfce-desktop should also work on EPEL-7. Just did
that yesterday.

One potential issue is - xfce4-mixer might complain. It should be
replaced by xfce4-pulseaudio-plugin.


- -- 
GPG Key - E5C8BC67
- ---


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJW0jckAAoJEHE/1K3lyLxnC10QAINclFcAZOAnJDP5TTqBfS6T
e2kz0vzW4H4aA9w7tnheDbFS+slzVaYUwNxU4kGKZP6C5LjUiqzt8N24C1UrFW7U
qFMzH5sTsmWcYaY58rzfmkoTmyMlSuESesS1nZ+0ZP7vQbwkUCpjd6Uzw3w7bgHY
2Onf/X4OQOppdOGe5Ae6nUFYfaxLglcXFVXjRYUZrmksKzsoijFgGUKlnpfc/jQM
+4hhe6qz+hbPkikM+UdjjvshyM6EBRisQMmeFQjGSRW2/0MX7IYNFyIKER1YFagc
C4NX8YZFxa1Xv2g6OBQT/zkRinwnOzyKS5WkZEfT2vqXMedW7XjTc1zPQhzgaIZr
IU/D0kLVI7xNPtKkfqvkk3ZR3tsA/m4YLaPrNh4/oVy7laNJNv4WwKLZc01aij20
WxqwAP5/LzOQeqkvqw3/QgD+35qbpo3NUU00K2KCTngB3qw85uvJmKLhs0hbeFal
0cWNfb03ORK3cQFPouotJhnH3GOmiREMGS1eNbNBsp50rwaVeoqDO9XXBEKGuEXq
j0H4qVv+AshSPW6UJPS82yEffnk4Xd6bPkms//68pDBdSunO7ieWBeNkLoH0MO26
2/11nOXg1inhJyTvgI5tN8sbPXbN8L9z6t+ZKPgokNFqt56zYLjH2DxdzbrdHkNa
fxU4BxvzNhrMkBVvVLib
=Ml2P
-END PGP SIGNATURE-
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Please test Xfce 4.12 for inclusion in EPEL - 7

[john tatt]

Hi
I sis a yum install xfce4* . Maybe xfwm4 was not in the dependencies ?
J


  De : Kevin Fenzi 
 À : epel-devel@lists.fedoraproject.org 
Cc : john tatt 
 Envoyé le : Samedi 27 février 2016 21h02
 Objet : [EPEL-devel] Re: Please test Xfce 4.12 for inclusion in EPEL - 7
   
On Sat, 27 Feb 2016 09:36:37 + (UTC)
john tatt  wrote:

> Hi
> it seems to come without windows manager. Had to uninstall.

Odd, xfwm4 is there and seems fine. 

How did you install?

kevin
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org


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

[EPEL-devel] Re: Virtual packages providing python2-*

[Kevin Fenzi]

On Wed, 24 Feb 2016 14:50:42 -0600
Jason L Tibbitts III  wrote:

> I'm actually just going to submit a review for a python2-setuptools
> dummy package to take care of the most annoying case.  If someone
> really dislikes this idea enough to block that, then I guess I'll
> find out.

I guess the only issue I see with it is that it could cause confusion.
ie, someone wants to remove python-foo and there's an epel provided
python2-foo that they don't understand why it's there. 

Otherwise, it should work... 

kevin


pgpVkZya0J65g.pgp
Description: OpenPGP digital signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: EPEL Proposal #1: Rechartering

[Bryan J Smith]

Q:
Do you understand the purpose of RHSCL PR EPEL?  ;)

You want RHEL, but neither RHSCL nor EPEL is it, nor designed to be it.

That's why I said ...

EPEL's ideal aimpoint, when feasible, should be like RHSCL.  ;)

-- bjs

DISCLAIMER: Sent from phone, please excuse any typos
-- 
Bryan J Smith - Technology Mercenary
b.j.sm...@ieee.org - http://linkedin.com/in/bjsmith

On Feb 18, 2016 18:37, "Dave Johansen"  wrote:

> On Thu, Feb 18, 2016 at 3:54 PM, Bryan J Smith  wrote:
>
>> Dave Johansen wrote:
>> > RHSCL is a non-starter where I work (and I imagine at other
>> > locations). 2-3 years of support just isn't enough to make it a
>> > worthwhile investment.
>>
>> Well, there usually _is_ more than one (1) [RH]SCL per RHEL release.
>> So it's more like 2-3 releases that "rebase" every 2+ years, for 6-7
>> years total of the RHEL release.
>>
>> The idea here is that you have up to three (3) years to "rebase."  ;)
>>
>> Not that [RH]SCL is 3 years and that's it.  I mean ... understand my
>> intent here.  Sustaining engineering is _not_ free, it's _not_
>> upstream, and people should be expected to rebase every 2-3 years,
>> when it comes closer to Upstream.
>>
>> Again, understand the "bigger picture" of my "suggestion."
>>
>> > For example, we just barely started upgrading to EL 7 ... (cut)
>>
>> _So_ you will likely be on the _second_ [RH]SCL release for RHEL 7,
>> instead of the _first_.  So ... what's the problem?
>>
>> So ... I have to now ask ... have you used [RH]SCL?  ;)
>>
>> I.e., Again, it's _not_ only 3 years of RHEL, but 3 years per release,
>> with each RHEL releases getting 2-3 releases over 6-7 years.
>>
>> Ergo ...
>>
>
> SCL is an AWESOME idea, but for our organization, having to jump to the
> next version of an SCL every 2-3 years just isn't possible. We use RHEL
> because of its long support life cycle and starting to use the SCL breaks
> that idea. If SCL had a lifecycle more akin to RHEL (i.e. something like
> release half as often and support for twice as long), then it would be a
> different story.
>
>
>> > For most packages, leaving the version that's there alone is probably
>> > a decent solution, but for packages where security fixes continue to
>> > happen and are important, then an "official" upgrade path would be
>> > good. Maybe something like:
>> > 1) Current maintainer identifies upgraded version and reason for update
>> > (hopefully limited to security fixes or something along those lines and
>> not
>> > just "I want a newer version"),
>> > 2) Notifies intention on mailing list,
>> > 3) Feedback from community, and
>> > 4) Perform upgrade
>>
>> Which works out very well for something that rebases every 2-3 years
>> ... like [RH]SCL.
>>
>> Again, I wasn't trying to say "be like [RH]SCL," but more like,
>> "Here's a Red Hat add-on that kinda already has this 'lifecycle' that
>> Red Hat customers would understand."
>>
>
> Sorry, what I was trying to get across was the idea of having a process
> that discouraged but allowed for upgrades in a controlled manner while
> giving users plenty of time to prepare for it.
>
> ___
> epel-devel mailing list
> epel-devel@lists.fedoraproject.org
>
> http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
>
>
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: EPEL Proposal #1: Rechartering

[Ken Dreyer]

On Fri, Feb 26, 2016 at 2:38 PM, Felix Schwarz
 wrote:
> Also as a sysadmin I dislike that stuff in EPEL can change at any time
> (whenever the maintainer can not support the old version anymore). If EPEL had
> some kind of "release" (e.g. tied to RHEL point releases) I'd like to see
> "most" incompatible upgrades happen at that time - with some kind of release
> notes where I can read about the changes before.
>
> Ideally I have some time (e.g. a month or so) to schedule the upgrade and deal
> with any fall-out.

I'm curious, do you test updates that are going through epel-testing?

- Ken
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Old scl-utils packages?

[Dave Johansen]

On Fri, Feb 26, 2016 at 10:25 PM, Stephen John Smoogen 
wrote:

> On 26 February 2016 at 21:01, Dave Johansen 
> wrote:
> > It looks like EPEL 5/6 have old versions of scl-utils. Those are probably
> > added back at a point when the base OS didn't have them, but they are now
> > older versions than what's available in the base OS.
> > Should EPEL versions be removed?
>
> I didn't know they were in the base OS but in a side channel. If they
> are in the base, then yes we should remove them.
>

Sorry, maybe I jumped the gun a bit. I actually didn't check if it's in a
side channel on RHEL, but was basing these statements on the fact that it's
in CentOS:
https://git.centos.org/summary/?r=rpms/scl-utils.git
http://mirror.centos.org/centos/6/os/x86_64/Packages/scl-utils-20120927-27.el6_6.x86_64.rpm
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Please test Xfce 4.12 for inclusion in EPEL - 7

[john tatt]

Hi
it seems to come without windows manager. Had to uninstall.


  De : Mukundan Ragavan 
 À : epel-devel@lists.fedoraproject.org 
 Envoyé le : Vendredi 26 février 2016 0h15
 Objet : [EPEL-devel] Re: Please test Xfce 4.12 for inclusion in EPEL - 7
   
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/24/2016 11:58 PM, Orion Poplawski wrote:
> On 02/24/2016 06:35 PM, Mukundan Ragavan wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA512
>> 
>> 
>> 
>> All,
>> 
>> I have built Xfce 4.12 packages for EL-7 on COPR. The link for
>> the repo is
>> 
>> https://copr.fedorainfracloud.org/coprs/nonamedotc/xfce412-epel7/
>>
>>
>> 
I would appreciate it if people can install the packages and give it a
>> spin. Please report any issues directly to  me (and not in
>> bugzilla) as these are not official packages.
> 
> Can you add parole?  It built fine for me.
> 
> 

parole is also done.

I have to request the epel-7 branch though.

- -- 
GPG Key - E5C8BC67
- ---


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWz4sIAAoJEHE/1K3lyLxnwYAQAIgSIPd5o5U1LLiDqvUz5Xou
LteN+Nn8J47jCQ4V9VTnkBv3+xXFFgswWHvCxEr2y7ZBxduNW0Pq5vS97PM2+DK7
4fjBORZugKhMRG4wVBIAIXUDrz5phR4Vak/SE0+Lm6CR/VtFo88PYqAVUf7CvFBv
Tx45q7XoMH+LqWbwaTv0M2wvHQ1VMD/OviIDMsJPYq3mvuPYQ2OH1hYq4Nsa7+H2
84SfQsHfOMJ7eWVrFwtwKhEuFvZKVillnE2N2z8LQLaQ0M1ZaupZR/yszl4jlOo5
Ew/mPXzKk0ZfVw0R75EZ9tQrcROH25D+1PosuWt9VUyyoeOsZGOW12f1QaORPvZD
zBEamFwGv9WNNqKe7AXDIrUFDluA0yqqJbRYqiVmrdZvCzZEkOaRVdAP3N1aMIOb
iN+ipRJWMEg1gUXV6bA+4lExNYz6HUc6sP+7WfHc5lxy4brejw0vw4FIZHXZrOxh
J51cdLmC17yG/BBjg8YRiyBK1jU1o8yRPVgC/917q1G2XA3REUaTcJzA0ZyPgz6x
WldBwaw0QPXUydPKOcvWzHTs2yAZPn9uT53YIDdpcWJhUVoUDJRQHiu2jKMp9Zfg
DdPM3+9hPE1Vk0+YHIFgK2aN19Oc/OyP/sNvSJpG+aEhkl6b42iImVjiUjbtlYYy
EHk0/U7rBv+S0Yj0PkRZ
=xrxx
-END PGP SIGNATURE-
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org


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