[EPEL-devel] Fedora EPEL 6 updates-testing report

2018-05-18 Thread updates 
The following Fedora EPEL 6 Security updates need testing:
 Age  URL
  41  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-5aca1d385d   
remctl-3.14-1.el6
  38  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-dd6e4a3f0b   
python34-3.4.8-1.el6
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-db2f6088bd   
seamonkey-2.49.3-1.el6
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-228dbec48f   
mysql-mmm-2.2.1-3.el6


The following builds have been pushed to Fedora EPEL 6 updates-testing

ansible-2.5.3-1.el6
copr-cli-1.70-1.el6
libabigail-1.3-1.el6
wordpress-4.9.6-1.el6

Details about builds:



 ansible-2.5.3-1.el6 (FEDORA-EPEL-2018-6a235ab252)
 SSH-based configuration management, deployment, and task execution system

Update Information:

Update to 2.5.3 with bugfixes.
https://github.com/ansible/ansible/blob/stable-2.5/changelogs/CHANGELOG-v2.5.rst

ChangeLog:

* Thu May 17 2018 Kevin Fenzi  - 2.5.3-1
- Update to 2.5.3. Fixes bug #1579577 and #1574221

References:

  [ 1 ] Bug #1574221 - firewalld module fails with "global name 'fw_offline' is 
not defined" error
https://bugzilla.redhat.com/show_bug.cgi?id=1574221
  [ 2 ] Bug #1579577 - ansible-2.5.3 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1579577




 copr-cli-1.70-1.el6 (FEDORA-EPEL-2018-09c2a45fba)
 Command line interface for COPR

Update Information:

- deprecate mock-config subcommand

ChangeLog:

* Fri May 18 2018 clime  1.70-1
- deprecate mock-config command
* Mon Apr 30 2018 Dominik Turecek  1.69-1
fix non-passing unittests under f28+
* Thu Apr 26 2018 Dominik Turecek  1.68-1
- simplify bar.finish logic
- rpkg deployment into COPR - containers + releng continuation
- #280 cli upload to nonexisting project makes terminal cursor disappear
- #220 copr-cli doesn't display build progress in non-interactive terminal
- add download-build --dest description to man page
- add `copr delete-build` build into man pages




 libabigail-1.3-1.el6 (FEDORA-EPEL-2018-414cb7e9cf)
 Set of ABI analysis tools

Update Information:

Update to upstream 1.3 version

ChangeLog:

* Wed May 16 2018 Dodji Seketeli  - 1.3-1
- Update to upstream 1.3 version
- Make sure to disable python3




 wordpress-4.9.6-1.el6 (FEDORA-EPEL-2018-e388ea1c80)
 Blog tool and publishing platform

Update Information:

Update to 4.9.6, Privacy and Maintenance Release See
https://wordpress.org/news/2018/05/wordpress-4-9-6-privacy-and-maintenance-
release/ for more information.

ChangeLog:

* Fri May 18 2018 Kevin Fenzi  - 4.9.6-1
- Update to 4.9.6. Fixes bug #1579584

References:

  [ 1 ] Bug #1579584 - wordpress-4.9.6 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1579584

___
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/message/B3GA27F74JT3RAKB6ZXLVIXZMSLN5MG2/

[EPEL-devel] Re: wine 3 package

2018-05-18 Thread Ken Taylor 

On 05/18/2018 04:47 PM, Rex Dieter wrote:

Ken Taylor wrote:


It would be nice if both architectures could be made available in the
epel wine package

I'll say it one more (last) time:  epel(*) cannot build i686 packages

(*) In it's current setup.  There's been previous talk about using centos7
i686 for this purpose... but so far it's only been talk.

-- Rex
___
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/message/G7T4QYW4JKN4XYTYDZWT5SKDZKBYY4VM/


Thank you Rex,

I don't want to be argumentative and perhaps there is a nuance which I 
do not understand. Bottom line, whatever these packages I have are, they 
will install on CentOS 7.5 - just did a second test PC - and they will 
run my three 32 bit Windows programs. That achieves my objective.


Have a great weekend.

Ken
___
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/message/XW2UGQEXKOD2EFJE7MFUCBEZYRMM7K4B/

[EPEL-devel] Re: wine 3 package

2018-05-18 Thread Rex Dieter 
Ken Taylor wrote:

> It would be nice if both architectures could be made available in the
> epel wine package

I'll say it one more (last) time:  epel(*) cannot build i686 packages

(*) In it's current setup.  There's been previous talk about using centos7 
i686 for this purpose... but so far it's only been talk.

-- Rex
___
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/message/G7T4QYW4JKN4XYTYDZWT5SKDZKBYY4VM/

[EPEL-devel] Re: wine 3 package

2018-05-18 Thread Ken Taylor 

On 05/18/2018 02:14 PM, Rex Dieter wrote:

Ricardo J. Barberis wrote:


El Viernes 18/05/2018 a las 00:33, Rex Dieter escribió:

Ken Taylor wrote:

On 05/16/2018 11:00 PM, Rex Dieter wrote:

Ken Taylor wrote:

I installed the wine 3 package from epel-testing this morning  on a
newly installed CentOS 7.5 machine. The installation seemed to go
fine. If I may ask two questions...

Does this version of wine support 32 bit Windows programs on CentOS
7.5?

No.  rhel7 (and epel7 by extension) does not support i686 arch, which
is required for win32 support

Based on my experience, rhel7 and centos7 DO support i686. epel has a
whole bunch of ...-devel.i686 packages. I have been running wine 1.8
i686 on CentOS 7 for more than two years. I am attempting to build wine
3 from source and the epel src.rpm as I write this.

I guess the question really is... is 32 bit support included in the
epel binary rpm?

No, I looked.  Here's a snippet from wine.spec hinting at it:
# x86-32 parts
%ifarch %{ix86} x86_64
%if 0%{?fedora} || 0%{?rhel} <= 6
Requires:   wine-core(x86-32) = %{version}-%{release}
Requires:   wine-capi(x86-32) = %{version}-%{release}
Requires:   wine-cms(x86-32) = %{version}-%{release}
Requires:   wine-ldap(x86-32) = %{version}-%{release}
Requires:   wine-twain(x86-32) = %{version}-%{release}
Requires:   wine-pulseaudio(x86-32) = %{version}-%{release}

Note, only included if rhel is <=6

Then I tried to tell you why (that rhel7 has no i686 edition and epel7
has
no i686 buildroot), but you didn't believe me.  Suit yourself.

There's no rhel7 i686 edition, but there is i686 support in the x86_64
edition, I beieve.

At least CentOS 7 has several i686 rpms, according to random mirror:

$ lynx -dump http://centos.eecs.wsu.edu/7/os/x86_64/Packages/ | grep -c
i686 4446

Mere existence of i686 rpms in rhel7/centos7 is does not imply either that
wine.i686 exists or that epel7 can build it.  That's the point I've been
trying to make (poorly, apparently).

-- Rex
___
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/message/SDGDS54WWXHBGVZ6MBSGTKRSKN7WDZIE/


wine.i686 may not exist but it IS possible to build it from the epel 
source rpm. I used the .spec file provided in this thread 
https://www.linuxquestions.org/questions/linux-software-2/wine-3-0-3-centos-7-5-run-32-bit-windows-programs-4175629844/. 
After tracking down a bunch of necessary ...devel.i686 packages, most 
from epel, the command "rpmbuild -bb --target=i686 wine.spec.yes" did 
the trick (where wine.spec.yes is the file provided by member yes). 
I haev installed and run 32 bit Windows programs on the CentOS 7.5 machine.


yes has also tracked down and built a boat load of dependency rpms 
along with the base wine rpm. If I throw them all in a directory and 
issue "yum install *" I end up with a functioning 32 bit wine environment.


The Ubuntu wine 3.0.1, as best I can tell, installs both architectures. 
I can set it for 32 bit programs by:


1 - delete ~/.wine

2 - WINEARCH=win32

3 - running winecfg to build my new ~/.wine structure in 32 bit flavor.

It would be nice if both architectures could be made available in the 
epel wine package although that is beyond my skill set.


Ken



Ken

___
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/message/4TOGZNV5EWPFO6BWSLH7CLPNAVXWXX7U/

[EPEL-devel] Re: wine 3 package

2018-05-18 Thread Rex Dieter 
Ricardo J. Barberis wrote:

> El Viernes 18/05/2018 a las 00:33, Rex Dieter escribió:
>> Ken Taylor wrote:
>> > On 05/16/2018 11:00 PM, Rex Dieter wrote:
>> >> Ken Taylor wrote:
>> >>> I installed the wine 3 package from epel-testing this morning  on a
>> >>> newly installed CentOS 7.5 machine. The installation seemed to go
>> >>> fine. If I may ask two questions...
>> >>>
>> >>> Does this version of wine support 32 bit Windows programs on CentOS
>> >>> 7.5?
>> >>
>> >> No.  rhel7 (and epel7 by extension) does not support i686 arch, which
>> >> is required for win32 support
>> >
>> > Based on my experience, rhel7 and centos7 DO support i686. epel has a
>> > whole bunch of ...-devel.i686 packages. I have been running wine 1.8
>> > i686 on CentOS 7 for more than two years. I am attempting to build wine
>> > 3 from source and the epel src.rpm as I write this.
>> >
>> > I guess the question really is... is 32 bit support included in the
>> > epel binary rpm?
>>
>> No, I looked.  Here's a snippet from wine.spec hinting at it:
>> # x86-32 parts
>> %ifarch %{ix86} x86_64
>> %if 0%{?fedora} || 0%{?rhel} <= 6
>> Requires:   wine-core(x86-32) = %{version}-%{release}
>> Requires:   wine-capi(x86-32) = %{version}-%{release}
>> Requires:   wine-cms(x86-32) = %{version}-%{release}
>> Requires:   wine-ldap(x86-32) = %{version}-%{release}
>> Requires:   wine-twain(x86-32) = %{version}-%{release}
>> Requires:   wine-pulseaudio(x86-32) = %{version}-%{release}
>>
>> Note, only included if rhel is <=6
>>
>> Then I tried to tell you why (that rhel7 has no i686 edition and epel7
>> has
>> no i686 buildroot), but you didn't believe me.  Suit yourself.
> 
> There's no rhel7 i686 edition, but there is i686 support in the x86_64
> edition, I beieve.
> 
> At least CentOS 7 has several i686 rpms, according to random mirror:
> 
> $ lynx -dump http://centos.eecs.wsu.edu/7/os/x86_64/Packages/ | grep -c
> i686 4446

Mere existence of i686 rpms in rhel7/centos7 is does not imply either that 
wine.i686 exists or that epel7 can build it.  That's the point I've been 
trying to make (poorly, apparently).

-- Rex
___
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/message/SDGDS54WWXHBGVZ6MBSGTKRSKN7WDZIE/

[EPEL-devel] Re: wine 3 package

2018-05-18 Thread Ricardo J. Barberis 
El Viernes 18/05/2018 a las 00:33, Rex Dieter escribió:
> Ken Taylor wrote:
> > On 05/16/2018 11:00 PM, Rex Dieter wrote:
> >> Ken Taylor wrote:
> >>> I installed the wine 3 package from epel-testing this morning  on a
> >>> newly installed CentOS 7.5 machine. The installation seemed to go fine.
> >>> If I may ask two questions...
> >>>
> >>> Does this version of wine support 32 bit Windows programs on CentOS
> >>> 7.5?
> >>
> >> No.  rhel7 (and epel7 by extension) does not support i686 arch, which is
> >> required for win32 support
> >
> > Based on my experience, rhel7 and centos7 DO support i686. epel has a
> > whole bunch of ...-devel.i686 packages. I have been running wine 1.8
> > i686 on CentOS 7 for more than two years. I am attempting to build wine
> > 3 from source and the epel src.rpm as I write this.
> >
> > I guess the question really is... is 32 bit support included in the epel
> > binary rpm?
>
> No, I looked.  Here's a snippet from wine.spec hinting at it:
> # x86-32 parts
> %ifarch %{ix86} x86_64
> %if 0%{?fedora} || 0%{?rhel} <= 6
> Requires:   wine-core(x86-32) = %{version}-%{release}
> Requires:   wine-capi(x86-32) = %{version}-%{release}
> Requires:   wine-cms(x86-32) = %{version}-%{release}
> Requires:   wine-ldap(x86-32) = %{version}-%{release}
> Requires:   wine-twain(x86-32) = %{version}-%{release}
> Requires:   wine-pulseaudio(x86-32) = %{version}-%{release}
>
> Note, only included if rhel is <=6
>
> Then I tried to tell you why (that rhel7 has no i686 edition and epel7 has
> no i686 buildroot), but you didn't believe me.  Suit yourself.

There's no rhel7 i686 edition, but there is i686 support in the x86_64 
edition, I beieve.

At least CentOS 7 has several i686 rpms, according to random mirror:

$ lynx -dump http://centos.eecs.wsu.edu/7/os/x86_64/Packages/ | grep -c i686
4446

Cheers,
-- 
Ricardo J. Barberis
Usuario Linux Nº 250625: http://counter.li.org/
Usuario LFS Nº 5121: http://www.linuxfromscratch.org/
Senior SysAdmin / IT Architect - www.DonWeb.com
___
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/message/CIFJ2ZHAI2I7XL7JBLPWXJTGT4CEQXVA/

[EPEL-devel] Re: Blue Sky Discussion: EPEL-next or EPIC

2018-05-18 Thread Ian Pilcher 

On 05/17/2018 06:53 PM, Stephen John Smoogen wrote:

I think with our horrible history of naming this project EPEC is what
we go with. I just want the new logo not to look like a horse's butt
with tail.


Already taken.


https://www.openstack.org/themes/openstack/images/project-mascots/Cinder/OpenStack_Project_Cinder_vertical.jpg

--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 

___
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/message/FZIJFTZFI37UUCOJQIVPFAOYFDWSVRZR/

[EPEL-devel] Re: Blue Sky Discussion: EPEL-next or EPIC

2018-05-18 Thread Neal Gompa 
On Fri, May 18, 2018 at 8:27 AM Martin Jackson  wrote:

> I agree that it makes sense to associate EPIC releases with EL "point"
> or "y" releases.

> Some orgs (like us) download new content on timers, and while it's not
> wrong to say that people should read release notes and updates, there is
> currently a *lot* of content in EPEL etc to keep track of, and I think
> people find it really valuable to have a repo that makes the "don't
> overwrite/upgrade core" promise.  I like the differentiation that is
> starting to develop in the CentOS ecosystem where there are some more
> "experimental" repos (like YUM4) that *do* overwrite, and say so
> explicitly.  The ecosystem also has good tools to mix and match these
> repositories with core content (pulp/Satellite).  Generally, we sync all
> of EPEL but only use the command-line bits; I'm unaware of any user
> reporting problems due to a GTK rebase in an EL minor release.

> IUS used to talk a bit about repo safety on their web page, does this
> need to be something more explicit for repos in general?  Or something
> that might be reflected in metadata somehow?


One of the things that I've been talking to the DNF team about is making
DNF/YUM4 more repo-aware so that it follows user tracks on where packages
come from unless the user specifically requests it to be switched. This
behavior would help resolve a long-standing issue of user expectations on
following certain update paths (w.r.t. package update sources). Things like
EPIC would be generally less dangerous because the risk of switching
between sources mid-stream (as current Yum/DNF behavior is now) would be
substantially lower.

This feature has always been available to us, we just never wired it up. So
we would get one of the principal benefits of Modularity for virtually all
packages for free.

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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/message/QIZQM2CJ7HBYFMRISQDC3ODJBQWW7NLQ/

[EPEL-devel] Re: Blue Sky Discussion: EPEL-next or EPIC

2018-05-18 Thread Martin Jackson 
I agree that it makes sense to associate EPIC releases with EL "point" 
or "y" releases.


Some orgs (like us) download new content on timers, and while it's not 
wrong to say that people should read release notes and updates, there is 
currently a *lot* of content in EPEL etc to keep track of, and I think 
people find it really valuable to have a repo that makes the "don't 
overwrite/upgrade core" promise.  I like the differentiation that is 
starting to develop in the CentOS ecosystem where there are some more 
"experimental" repos (like YUM4) that *do* overwrite, and say so 
explicitly.  The ecosystem also has good tools to mix and match these 
repositories with core content (pulp/Satellite).  Generally, we sync all 
of EPEL but only use the command-line bits; I'm unaware of any user 
reporting problems due to a GTK rebase in an EL minor release.


IUS used to talk a bit about repo safety on their web page, does this 
need to be something more explicit for repos in general?  Or something 
that might be reflected in metadata somehow?


Thanks,

Marty

On 5/17/2018 10:01 PM, heelsl...@163.com wrote:

good idea,
EPIC release --> rhel release, centOS release
keep the old RPMS when EPIC package upgrade.
no compatibility issue any more.
___
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/message/QVRJ4RLWDSNZ3AQJMKJ2SIMNLEYSQPAR/

___
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/message/TP7JWI3CRGDI6WPKGBENU5MOWDWTD445/