[EPEL-devel] Re: Bodhi 4 in EPEL 7

2019-06-14 Thread Orion Poplawski
On 6/13/19 4:03 PM, Randy Barlow wrote:
> Greetings!
> 
> Fedora Infrastructure recently deployed Bodhi 4.0.0 to production,
> which included quite a few backwards incompatible changes[0]. Some of
> the changes have resulted in older Bodhi clients (less than 4.0.0) not
> being compatible with the new version of the server.
> 
> In Fedora, FESCo decided to allow the Bodhi 4.0.0 update to go to
> Fedora 29 and 30, and for us to add a bodhi3 compat client package in
> case there were any users counting on using the bodhi3 client with a
> non-Fedora Bodhi server[1] (believe it or not, there are other Bodhi
> deployments out there!)
> 
> EPEL 7 currently has a fairly old Bodhi version (2.11.0). This version
> is also not compatible with the Bodhi 4 server.
> 
> What do you think about upgrading Bodhi in EPEL 7 as well?
> 
> There are a few things I'd like to highlight for consideration here:
> 
> * Bodhi 4 is Python 3 only. Bodhi 2 is Python 2 only. So, upgrading to
>   Bodhi 4 isn't just a switch to a newer Bodhi, it will also mean a
>   switch in Python versions. This will affect dependencies (there are a
>   few).

I think that's fine.  Lot's of things have been moving to python3 in EPEL7.

> * I think we might be missing Python 3 dependencies for Bodhi 4.

Could be.  Hopefully not to hard to remedy that.

> * It might be good to consider dropping the Bodhi server as we do this.
>   EPEL 7 has versions of some of Bodhi's server dependencies that are
>   too old for Bodhi 4. I *think* the client should be OK with the
>   client dependency versions, but of course you never know until you
>   try.

Fine by me.

> * Would we want to maintain a bodhi2 compat package for EPEL 7,
>   analagous to the bodhi3 compat package we made for Fedora?

I guess the question is are there any bodhi2 servers running on EL7 out there?
 Probably won't know until someone screams.  I wouldn't add it unless someone
complains.

> * What about EPEL 6? It's still on Bodhi 0.9, and I have never seen or
>   worked on that codebase. Unfortunately, it has Python 2.6 and not any
>   verison of Python 3, to my knowledge.

EPEL 6 does have python 3.4, I would just let that rot as is.

-- 
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



smime.p7s
Description: S/MIME Cryptographic Signature
___
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: KDE rebuild for RHEL8

2019-05-09 Thread Orion Poplawski
On 5/8/19 4:09 PM, Troy Dawson wrote:
> On Fri, Jan 18, 2019 at 9:03 AM Troy Dawson  wrote:
>>
>> I have uploaded my build to my fedora people area.  Unfortunately the
>> source rpm's wouldn't fit.  I'll work on getting just the packages
>> that I changed into the source rpm area.  Hopefully that trims it down
>> for those that want to see what got changed.
>> I also uploaded a repo file [1], the build order [2] , what didn't
>> build [3] , and a README [4] that includes how to install the desktop.
>>
>> == How to install KDE on rhel8-beta
>> -- # First make sure you can get regular rhel8-beta packages
>> -- # All of these should be done as root or sudo
>> -- wget -O /etc/yum.repos.d/rhel8-beta-kde.repo
>> https://tdawson.fedorapeople.org/epel8/kde/rhel8-beta-kde.repo
>> -- dnf group install "KDE Plasma Workspaces"
>> -- (Optional) dnf group install kde-desktop
>> -- (Optional) dnf group install kde-apps
>> -- (Optional) dnf group install kde-media
>> -- (Optional) dnf group install kde-education
>> -- (Optional) dnf group install kde-software-development
>> -- (Optional) dnf group install kf5-software-development
>> -- # Currently gdm does not like to start plasma, use sddm instead
>> -- dnf install switchdesk system-switch-displaymanager
>> -- switchdesk kde
>> -- system-switch-displaymanager sddm
>> -- # Incase you aren't in graphical mode yet
>> -- systemctl set-default graphical.target
>>
>> Troy
>>
>> [1] - https://tdawson.fedorapeople.org/epel8/kde/rhel8-beta-kde.repo
>> [2] - https://tdawson.fedorapeople.org/epel8/kde/rhel8-beta-kde.build-order
>> [3] - https://tdawson.fedorapeople.org/epel8/kde/rhel8-beta-kde.not-built
>> [4] - https://tdawson.fedorapeople.org/epel8/kde/readme.txt
>>
> 
> Just a heads up, incase people are wondering.
> My KDE build that I built on RHEL8 beta works [1] on RHEL8 final release.
> I have taken a RHEL8-Beta, already running KDE, and updated it to
> RHEL8, and everything updated, and worked [1]
> I have also taken a fresh installed, and updated, RHEL8 minimal, and
> run the above commands to install KDE, and it worked also.
> 
> That doesn't mean this repo will be up forever, but it should last
> until we get KDE in EPEL8, whenever that happens.
> 
> Troy
> 

Thanks for your work on this.  My observation is - do want KDE to be a module
for EPEL8?  I'm actually slightly surprised to find that Gnome does not appear
to be modular in RHEL8, but if we face something at all like the KDE 4->plasma
transition during RHEL8's lifetime it seems like a good thing to have.

Also, I've found them quite useful for building ordered sets of dependencies
and dealing with updates.


-- 
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



smime.p7s
Description: S/MIME Cryptographic Signature
___
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: postgis-2.0.7-2.el7 still in epel7-testing

2019-04-21 Thread Orion Poplawski

On 4/21/19 5:32 PM, Sérgio Basto wrote:

On Fri, 2019-04-12 at 09:36 +0200, Danny Smit wrote:

Hi all,

I'm looking for a fix in postgis, which seems to be fixed already in
postgis-2.0.7-2.el7.

However that package seems to be 'stuck' in the epel7-testing
repository for a long time:
   https://koji.fedoraproject.org/koji/buildinfo?buildID=750618
   https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-b6c229157e

Can the package be pushed to stable?


I gave +1 karma and more one and package will be pushed to updates
automatically .

Can someone give one more positive karma ? please

Thanks


I pushed it to batched.


--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



smime.p7s
Description: S/MIME Cryptographic Signature
___
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: yum update problem

2019-04-05 Thread Orion Poplawski

On 4/5/19 7:06 AM, m...@tdiehl.org wrote:

Hi,

I am seeing the following error when trying to run yum update:
(tigger pts11) # yum update
Loaded plugins: changelog, fastestmirror, langpacks, priorities
Loading mirror speeds from cached hostfile

...
Transaction check error:
   file 
/usr/lib/python3.4/site-packages/virtualenv-15.1.0-py3.4.egg-info from 
install of python34-virtualenv-15.1.0-3.el7.noarch conflicts with file 
from package python34-virtualenv-15.1.0-2.el7.noarch


Error Summary
-

(tigger pts11) #


I am seeing this anywhere I have python34-virtualenv from epel installed.

Anyone know how to resolve this short of uninstalling python34-virtualenv?


Should be fixed with:

 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-813cc12887


--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



smime.p7s
Description: S/MIME Cryptographic Signature
___
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: EPEL: Python34 moving to Python36

2019-03-13 Thread Orion Poplawski

On 3/13/19 9:05 PM, Chris wrote:

Amazing work!

I just wanted to ask if it was a bug that the Python v2 branch provided 
the following RPMs, but the Python v3.6 did not:

- python36-requests-oauthlib
- python36-oauthlib


The above python2 packages are in RHEL7, so new python3- packages will 
need to be created in Fedora for EPEL7.



- python36-markdown
- python36-pytest-runner


These are now in epel-testing.  Buildroot overrides would need to be 
created for them for them to be in the buildroot.




Perhaps these ones just haven't been ported over yet? Thoughts?
Here's the source of my prob: 
https://koji.fedoraproject.org/koji/taskinfo?taskID=33463886


Chris




--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.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


[EPEL-devel] Re: EPEL: Python34 moving to Python36

2019-03-13 Thread Orion Poplawski

On 3/13/19 11:48 AM, Miro Hrončok wrote:

On 13. 03. 19 18:42, Wart wrote:

Transaction check error:
   file /usr/lib/python3.4/site-packages/six-1.11.0-py3.4.egg-info from
install of python34-six-1.11.0-2.el7.noarch conflicts with file from
package python34-six-1.11.0-1.el7.noarch


IS that a file to directory problem? Otherwise 
python34-six-1.11.0-2.el7.noarch should just replace 
python34-six-1.11.0-1.el7.noarch "naturally" without any specific conflict.




I think I figured this out.  During the install step if we didn't have a 
tests_require package installed we got:


running install_egg_info
Writing 
/builddir/build/BUILDROOT/python3-six-1.11.0-2.el7.noarch/usr/lib/python3.4/site-packages/six-1.11.0-py3.4.egg-info
BUILDSTDERR: /usr/lib64/python3.4/distutils/dist.py:260: UserWarning: 
Unknown distribution option: 'tests_require'

BUILDSTDERR:   warnings.warn(msg)

and ended up with a file egg-info instead of a directory.

I've rebuilt python3-six with the test requirements installed for both 
versions now.  I'll add python3-six-1.11.0-3.el7.src.rpm to the update.


--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.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


[EPEL-devel] Re: EPEL: Python34 moving to Python36

2019-03-13 Thread Orion Poplawski

On 3/13/19 9:46 AM, Dridi Boukelmoune wrote:

Hello,

On Wed, Mar 13, 2019 at 3:37 PM Stephen John Smoogen  wrote:


Over the last 5 days, Troy Dawson, Jeroen van Meeuwen, Carl W George,
and several helpers have gotten nearly all of the python34 packages
moves over to python36 in EPEL-7.  They are being included in 6 Bodhi
pushes because of a limitation in Bodhi for the text size of packages
in an include.


I was about to start a thread about this, so it saves me a fair amount of time.

I have been working on this today, so this is very fresh:

https://github.com/varnishcache/pkg-varnish-cache/pull/124

My complaint is that the current packages for
python34-{sphinx,docutils} don't seem to have provides with a
"python3-" prefix. So while I can live with that fact, I'm not happy
with the prospect of having to break the continuity soon and have to
move my BuildRequires to a python36- prefix.


That's a reasonable suggestion.  I would suggest you file an RFE request 
again python-rpm-macros in EPEL to have the %python_provide macro 
produce a Provides: python3-%{name} for the "active" python3 version.



One more thing about those two specific packages, they also don't
provide binaries suffixed with "-3" so that means having to change
packaging again so that configures picks up rst2man-3.6 instead of
rst2man-3.4 and that's not a comfortable place to be in downstream.


The python3{4,6}-sphinx packages do provide /usr/bin/sphinx-build-3, 
etc.  In fact one reason why you currently cannot install both.


As for docutils, file a bug against python3-docutils in EPEL and we'll 
get that fixed up.





The current day for these package groups to move into EPEL regular is
April 2nd. We would like to have all tests we find in the next week or
so also added so that the updates can occur in a large group without
too much breakage.

https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f2d195dada
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-9e9f81e581


I'm a bit confused because it seems the update above contains both
builds for the packages I'm interested in, and seems to keep building
the 3.4 variant of the package in addition to the new 3.6 builds.

That means I should not worry about having to move away from today's
work, right?


Most EPEL python3 package will build for both python3 versions.  We are 
not (yet) dropping python34.  It's just that the default 
/usr/bin/python3 is switching to python 3.6, and packages that only 
build for one python3 version are now shipping for 3.6.


--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.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


[EPEL-devel] Re: EPEL: Python34 moving to Python36

2019-03-13 Thread Orion Poplawski

On 3/13/19 11:48 AM, Miro Hrončok wrote:

On 13. 03. 19 18:42, Wart wrote:

Transaction check error:
   file /usr/lib/python3.4/site-packages/six-1.11.0-py3.4.egg-info from
install of python34-six-1.11.0-2.el7.noarch conflicts with file from
package python34-six-1.11.0-1.el7.noarch


IS that a file to directory problem? Otherwise 
python34-six-1.11.0-2.el7.noarch should just replace 
python34-six-1.11.0-1.el7.noarch "naturally" without any specific conflict.




It appears to be a directory -> file problem.  Why did this change?

# ls -l /usr/lib/python3.4/site-packages/six-1.11.0-py3.4.egg-info
total 16
-rw-r--r--. 1 root root1 Sep 28 12:18 dependency_links.txt
-rw-r--r--. 1 root root 1818 Sep 28 12:18 PKG-INFO
-rw-r--r--. 1 root root  253 Sep 28 12:18 SOURCES.txt
-rw-r--r--. 1 root root4 Sep 28 12:18 top_level.txt

# repoquery --enablerepo=epel-testing -l 
python34-six-1.11.0-2.el7.noarch | grep egg

/usr/lib/python3.4/site-packages/six-1.11.0-py3.4.egg-info


--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.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


[EPEL-devel] Re: Koji Build Failure Due To Dependency EPEL Dependency Issue

2019-02-23 Thread Orion Poplawski
COPR builds against CentOS, EPEL builds against RHEL, which can lead to 
differences.  Bringing in the EPEL list to see what others have to say.


But my RHEL7 seven machine can see it:

python2-oauthlib.noarch 2.0.1-8.el7  rhel-7-server-rpms

On 2/23/19 2:36 PM, Chris wrote:

 > Perhaps a link to the koji build might be helpful?

Certainly,

Here is a working Copr link:
https://copr.fedorainfracloud.org/coprs/build/861900/

Same .src.rpm, here is a failing Koji one:
https://koji.fedoraproject.org/koji/taskinfo?taskID=32993375

Here is the COPR post output:
copr-cli build apprise python-apprise-0.7.3-1.el7.nuxref.src.rpm
Uploading package python-apprise-0.7.3-1.el7.nuxref.src.rpm
100% || 589kB 1.4MB/s eta 0:00:00
Build was added to apprise:
https://copr.fedorainfracloud.org/coprs/build/861900/
Created builds: 861900
Watching build(s): (this may be safely interrupted)
   15:58:20 Build 861900: pending
   15:58:51 Build 861900: running
   16:02:25 Build 861900: succeeded


Where as here is the Koji one:
koji build --scratch epel7 python-apprise-0.7.3-1.el7.nuxref.src.rpm
Uploading srpm: python-apprise-0.7.3-1.el7.nuxref.src.rpm
[] 100% 00:00:00 566.16 KiB 756.73 
KiB/sec

Created task: 32993375
Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=32993375
Watching tasks (this may be safely interrupted)...
32993375 build (epel7, python-apprise-0.7.3-1.el7.nuxref.src.rpm): free
32993375 build (epel7, python-apprise-0.7.3-1.el7.nuxref.src.rpm): free 
-> open (buildvm-ppc64-06.ppc.fedoraproject.org 
<http://buildvm-ppc64-06.ppc.fedoraproject.org>)
   32993376 buildArch (python-apprise-0.7.3-1.el7.nuxref.src.rpm, 
noarch): open (buildvm-28.phx2.fedoraproject.org 
<http://buildvm-28.phx2.fedoraproject.org>)
   32993376 buildArch (python-apprise-0.7.3-1.el7.nuxref.src.rpm, 
noarch): open (buildvm-28.phx2.fedoraproject.org 
<http://buildvm-28.phx2.fedoraproject.org>) -> FAILED: BuildError: error 
building package (arch noarch), mock exited with status 30; see root.log 
for more information

   0 free  1 open  0 done  1 failed
32993375 build (epel7, python-apprise-0.7.3-1.el7.nuxref.src.rpm): open 
(buildvm-ppc64-06.ppc.fedoraproject.org 
<http://buildvm-ppc64-06.ppc.fedoraproject.org>) -> FAILED: BuildError: 
error building package (arch noarch), mock exited with status 30; see 
root.log for more information

   0 free  0 open  0 done  2 failed

32993375 build (epel7, python-apprise-0.7.3-1.el7.nuxref.src.rpm) failed

Chris

On Sat, Feb 23, 2019 at 4:29 PM Orion Poplawski <mailto:or...@nwra.com>> wrote:


On 2/23/19 1:02 PM, Chris wrote:
 > The error:
 >
 > DEBUG util.py:490:  BUILDSTDERR: Error:
 > DEBUG util.py:490:  BUILDSTDERR:  Problem: conflicting requests
 > DEBUG util.py:490:  BUILDSTDERR:   - nothing provides
python2-oauthlib needed by python2-requests-oauthlib-0.8.0-5.el7.noarch
 > DEBUG util.py:634:  Child return code was: 1
 >
 > This same package builds fine using copr (done so here):
 > https://copr.fedorainfracloud.org/coprs/lead2gold/apprise/
 >
 > The spec file entry (that works fine for epel7 on Copr) is:
 > BuildRequires: python2-requests-oauthlib
 > BuildRequires: python2-oauthlib
 >
 > This entry just produces an error that all requirements couldn't
be met
 > and the scratch build aborts then too.
 > BuildRequires: python-oauthlib
 >
 > It appears to be an upstream issue... a missing entry in the
 > python-oauthlib such as:
 > Provides: python2-oauthlib
 >
 > I originally thought maybe i should be filing an issue with the
oauthlib
 > group, but then if that were the case, it wouldn't have worked
perfectly
 > fine on Copr.
     >
 > Thoughts? Advice?
 >
 > Chris

Perhaps a link to the koji build might be helpful?


-- 
Orion Poplawski

Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com <mailto:or...@nwra.com>
Boulder, CO 80301 https://www.nwra.com/




--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.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


[EPEL-devel] Zabbix 3.0 available for EPEL7

2019-01-06 Thread Orion Poplawski
Zabbix 3.0 is now available for EPEL7 via the zabbix30-* packages.  Enjoy.

-- 
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.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


[EPEL-devel] Re: Proposal for EPSCO: Python34 Moving to Python36

2018-11-17 Thread Orion Poplawski

On 11/15/18 10:08 AM, Stephen John Smoogen wrote:

I missed this in the last meeting from items that needed to be voted on.

The changes would be to make epel macros to have


%python3_pkgversion 36
%python3_other_pkgversion 34

This should allow for the build system to rebuild python3 items as
default. Then we will need a tracking ticket and bump/rebuild the
packages


Be aware that this will cause many current python34-* packages to 
disappear the next time they are rebuilt for EPEL7.


--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.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


[EPEL-devel] Re: EPEL-8 plans and needed work

2018-11-17 Thread Orion Poplawski

On 11/16/18 4:00 PM, Stephen John Smoogen wrote:

Yesterday, Red Hat announced its Red Hat Enterprise Linux 8 Beta, and
so we would like to start getting ideas on what people expect for
EPEL-8.

First off, we are not going to be able to do this like we did with
EPEL-5,6, or 7 because too much of the build infrastructure and tools
have changed since 2013 when we last started planning for EPEL-7.
Packages no longer have per branch permissions, packages can be ‘by
themselves’ and also modules, and modules really need more than one
packager to maintain run them. Plus we all know that there are points
of pain in the current EPEL structure where packages go and come from
the repository without much notice or planning.

I would like to open the floor on how a beta program this time should
be run and also how EPEL in the future should compose itself
(currently we completely compose daily without an update tree or other
tools) in the future. I would like any ideas to come with some
proposals on how it could be implemented (can be hand-wavy), and I
would like to ‘close’ debate on this by December 15th with a plan to
have a beta ready to start building in January.

As that may be a long delay for people who need openvpn and such, I
would like to look also at standing up a mini-epel in /pub/alt which
could be used to put packages in for users built using the methods we
currently use. This area would also be where attempts to make EPEL-8
and anything else we do more modular would be done without affecting
core EPEL until we are ready to make it happen.


I'm afraid I'm still very unfamiliar with modules, but it does seem like 
this will be very central to how we deliver packages to EPEL-8.  My 
initial questions are:


- Can we "simply" extend the platform for current modules to cover 
RHEL-8?  That way one could for example deliver octave 4.4 for both 
Fedora and EPEL-8 at the same time.  The main issue that I see is 
preventing packages that already exist in RHEL-8 from making it in.


- How do we build against the RHEL-8 modules?  I see that RHEL-8 has two 
perl and two php module streams:


perl  5.24   minimal, default
perl  5.26 [d]   minimal, default [d]
php   7.1devel, minimal, default [d]
php   7.2 [d]devel, minimal, default [d]

presumably if I want to builld say perl-Config-Simple for EPEL-8 we'll 
need/want to build it for both module streams?  How does one go about 
attaching that package to the RHEL-8 module?  Or will we need separate 
EPEL versions of the modules?


- Do we need to distinguish between EPEL packages that will be treated 
much like BaseOS packages in RHEL (very long lived and stable), and ones 
that are like the AppStream (shorter lifetimes)?  Do we just want to 
treat everything like AppStream packages?

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8-beta/html/using_application_stream/using-appstream_using-appstream

Some of what I wrote just might not make sense due to my limited 
understanding of modules.



--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.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


[EPEL-devel] Re: rhel 8 beta mock configs and EOLed mock configs

2018-11-16 Thread Orion Poplawski
On 11/15/18 3:05 PM, Miroslav Suchy wrote:
> Hi,
> I just released [1] new mock-core-config package which include new
> rhelbeta-8-* configs.
> This will allows you to build packages on top of RHEL 8 Beta. This is
> temporary config. I put them there so you can experiment with your
> builds and prepare for EPEL 8 once it will be available.
> This config will be removed when Beta ends.

I had trouble with using it with a bootstrap configuration because there is no
distribution-gpg-keys package available, which led to:

Curl error (37): Couldn't read a file:// file for
file:///usr/share/distribution-gpg-keys/redhat/RPM-GPG-KEY-redhat8-beta
[Couldn't open file
/usr/share/distribution-gpg-keys/redhat/RPM-GPG-KEY-redhat8-beta]

I ended up adding:

config_opts['dnf_install_command'] = 'install dnf dnf-plugins-core
https://kojipkgs.fedoraproject.org//packages/distribution-gpg-keys/1.26/1.el7/noarch/distribution-gpg-keys-1.26-1.el7.noarch.rpm'

-- 
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.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


[EPEL-devel] Updating python3-setuptools in EPEL7

2018-11-04 Thread Orion Poplawski
I'd like to update python3-setuptools from 19.6.2 to something newer (at 
least 20.8.1 but hopefully much later) without breaking the world. 
However, I don't have much experience with possible setuptools breakage. 
 Any suggestions would be greatly appreciated.



--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.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


[EPEL-devel] Re: Latest RHEL7 release v Xorg

2018-11-02 Thread Orion Poplawski
On 11/02/2018 08:48 AM, Orion Poplawski wrote:
> On 11/02/2018 05:11 AM, Bojan Smojver wrote:
>> It seems that right now the rhel7 build platforms are not in the state where 
>> this package (xorgxrdp) can be built. I'll look through the logs in detail 
>> to see what's going on.
>>
>> PS. I rebuilt F29/30 packages from the same sources without any trouble.
>>
> 
> Yup - we're having some issues with libglvnd, see
> https://pagure.io/releng/issue/7898
> 

This has been resolved, and xorgxrdp built.  Bojan - I'll let you submit the
update though.

-- 
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.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


[EPEL-devel] Re: Latest RHEL7 release v Xorg

2018-11-02 Thread Orion Poplawski
On 11/02/2018 05:11 AM, Bojan Smojver wrote:
> It seems that right now the rhel7 build platforms are not in the state where 
> this package (xorgxrdp) can be built. I'll look through the logs in detail to 
> see what's going on.
> 
> PS. I rebuilt F29/30 packages from the same sources without any trouble.
> 

Yup - we're having some issues with libglvnd, see
https://pagure.io/releng/issue/7898

-- 
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.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


[EPEL-devel] Re: EL-7.6 huh? packages

2018-11-01 Thread Orion Poplawski
On 11/01/2018 06:41 AM, Richard W.M. Jones wrote:
> On Thu, Nov 01, 2018 at 08:24:35AM -0400, Stephen John Smoogen wrote:
>> On Thu, 1 Nov 2018 at 06:00, Richard W.M. Jones  wrote:
>>>
>>> On Tue, Oct 30, 2018 at 08:57:29PM -0400, Stephen John Smoogen wrote:
>>>> =
>>>> OCAML
>>>> =
>>>> package: llvm-ocaml-3.4.2-8.el7.x86_64 from epel-base
>>>>   unresolved deps:
>>>>  ocaml(runtime) = 0:4.01.1
>>>>  ocaml(Unix) = 0:93736a394d3d85d6d127fe238ddc6092
>>>>  ocaml(Pervasives) = 0:36b5bc8227dc9914c6d9fd9bdcfadb45
>>>>  ocaml(Int64) = 0:3945db6e8df0d5a79bcbc949ee550d52
>>>>  ocaml(Int32) = 0:ad06f04cfca6d404d1de76c3dc67324a
>>>
>>> I've never heard of this package before.  In any case it needs to be
>>> rebuilt, because we rebased OCaml from 4.01 to 4.05 (in RHEL 7.5) and
>>> therefore all dependent OCaml packages outside RHEL must be rebuilt.
>>>
>>> Rich.
>>>
>>
>> Thank you for being proactive on checking on this. I was supposed to
>> reach out to you yesterday if you knew about this package and if it
>> needed a rebuild. I will put it on the list for proven packagers to
>> rebuild. Do you know if it needs an 'update'?
> 
> I see this is actually the ocaml subpackage of llvm, which makes
> more sense now -- it is the OCaml bindings to the LLVM C++ API.
> 
> The package hasn't been touched since c.2015.  However I did a simple
> bump and *scratch* rebuild:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=30595143
> 
> If that succeeds I'll push it and follow up with a real build.
> Otherwise I guess changes of some kind will be necessary.
> 
> Rich.

Just to be explicit - this is version 3.4 of LLVM (i.e. quite old).  There are
llvm3.7, llvm3.9, and llvm5.0 packages as well (as well as devtoolset versions
of 5.0).  So it may be time to just drop it.

-- 
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.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


[EPEL-devel] Question about appdata in EPEL7

2018-10-30 Thread Orion Poplawski
At some point it appears that appdata files moved from 
/usr/share/appdata to /usr/share/metainfo.  Does the libappstream-glib 
library or whatever cares about appdatafiles in RHEL7 
(libappstream-glib-0.7.8-2.el7) work with /usr/share/metainfo, or does 
it have to be /usr/share/appdata?  I'm leaning towards assuming metainfo 
will work  since both evince and control-center in RHEL7.6 install files 
there.  If this does prove true, perhaps we can have epel-rpm-macros 
changed?


Thanks.

I also find this interesting:

# rpm -qf /usr/share/appdata /usr/share/metainfo
file /usr/share/appdata is not owned by any package
file /usr/share/metainfo is not owned by any package


--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.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


[EPEL-devel] cairo issue with RHEL 7.6?

2018-10-30 Thread Orion Poplawski

I'm getting this:

DEBUG util.py:439:  Error: Package: cairo-1.15.12-3.el7.ppc64 (build)
DEBUG util.py:439: Requires: libEGL.so.1()(64bit)
DEBUG util.py:439:  Error: Package: cairo-1.15.12-3.el7.ppc64 (build)
DEBUG util.py:439: Requires: libGL.so.1()(64bit)

https://apps.fedoraproject.org/koschei/package/logback?collection=epel7

That appears to be the appropriate latest version of cairo in RHEL 7.6. 
Did it somehow not get properly rebuilt against the latest mesa-libGL/EGL?



--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.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


[EPEL-devel] Re: Moving EPEL7 to python3.6

2018-10-22 Thread Orion Poplawski

On 10/19/2018 01:22 PM, Stephen John Smoogen wrote:

Hi,

EPEL is a set of packages which work for CentOS and RHEL versions 6
and 7. In the version 7, we are currently using python34 and would
like to move this to python36. In doing so, we need help in both our
packaging rules and in updating a lot of packages to work for
python36.

First problem: Packaging rules.
Because there could be updates of python versions from 3.4 to 3.6 or
3.8, we wanted to make clear what python was used for any particular
library. This would make it so someone needing python-bottle did not
end up with one packaged with python-3.6 installed on a python-3.4
system. So we wanted the names to be more specific than python3 and
went with naming all the sub packages python34 or python36.

However, this was decided a while ago and it may not be the best
convention to use or one that the current python sig would like us to
use. I would like to get a naming convention cleared up and documented
so when we do a mass rebuild that the packages come out with either a
python3- or python36-


If you are going to be having different versions of python3 over the 
life of a release, I think it's imperative that it be explicit what 
version of python 3 a package is for.  Otherwise lies madness.



Second problem: When to do this update
We had been looking to do this in October, but it may make more sense
to do this in November after Fedora29 has shipped so that people can
help focus on this versus anything F29 related. It also gives us some
lead time to write blogs/magazine items. How does 2018-11-14 sound?

Third problem: Updating and rebuilding packages to work with python36

Below are the list of packages I found which were making
python34- packages currently in EPEL-7. In updating to
python36, I would like to have a combined Virtual Fedora Activity Day
where we work together on IRC. First we would get any scripts ready
and then work with release engineering to change macros in epel-macros
to point to the correct versions of python and any name changes. We
would then do a mass release bump and rebuild all the packages against
python3.6. As problems are found during that day we would make
appropriate changes and fix.

This might take 2 gos.


The biggest issue I have run into with Python 3 packaging in EPEL is 
version lock.  Python modules (like most software) have atrocious 
backwards compatibility.  For example, we have python3-scipy at version 
0.18.1.  If we add a python3_other_pkgversion package to it for 
python36, we get python36-scipy-0.18.1 whereas we really want 
python36-scipy-1.15.2 (not just to get the latest and greatest - though 
that is important - the old version of the module just may not work with 
the latest python).  We can't update to that though in the python34 
stack or we'll break things.  This plays havock with the original vision 
of just flip a macro switch and rebuild everything, which means rolling 
out a new python version will take time and consideration of each package.


So I think we need another approach.  Some ideas:

- Can we make epel7-py36 branches, and somehow have %python3_version, 
et. al. be 3.6 for those builds?


- Can we just make it easier for people to create python3X- packages 
from existing python3- or python3(X-n)- packages?  And just drop the 
whole macro thing altogether, since sed -i -e s/pyton34-/python36-/ 
*.spec does 90% of the work?



Orion

--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.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


[EPEL-devel] Re: php

2018-05-21 Thread Orion Poplawski

On 05/21/2018 09:18 PM, Sérgio Basto wrote:

Hi,
Latest php 5.4 release was in 2015-Sep-04 ( php-5.4.45.tar.gz )
3 years ago ...
We will have el 7 until 2024 , more 6 years, can we update php to 5.6
on el 7 ? or PHP apps for epel have to move to remi repo ?


php is provided by RHEL.  EPEL does not supercede the base.


--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.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/W5CQME6EDC2VFYDROJ6YUGB2BDE24QQ5/


[EPEL-devel] Re: RHEL 7.5 fallout

2018-04-11 Thread Orion Poplawski
These were koschei builds of my epel7 packages.  Seems to have cleared up now
though so perhaps just an import issue.

On 04/10/2018 08:18 AM, Stephen John Smoogen wrote:
> Do you have any information that htis is EPEL packages or just EL7.5 items?
> 
> On 10 April 2018 at 09:57, Orion Poplawski <or...@nwra.com> wrote:
>> I'm seeing this in the root.log of some packages:
>>
>> DEBUG util.py:439:  Error: initscripts conflicts with
>> 1:redhat-release-server-7.4-1.x86_64
>>
>> --
>> Orion Poplawski
>> Manager of NWRA Technical Systems  720-772-5637
>> NWRA, Boulder/CoRA Office FAX: 303-415-9702
>> 3380 Mitchell Lane   or...@nwra.com
>> Boulder, CO 80301 https://www.nwra.com/
>> ___
>> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
>> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> 
> 
> 


-- 
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] RHEL 7.5 fallout

2018-04-10 Thread Orion Poplawski

I'm seeing this in the root.log of some packages:

DEBUG util.py:439:  Error: initscripts conflicts with 
1:redhat-release-server-7.4-1.x86_64


--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] Re: Current state of dual repository packages.

2017-08-14 Thread Orion Poplawski
On 08/14/2017 08:31 AM, Paul Howarth wrote:
> On 2017-08-11 19:00, Stephen John Smoogen wrote:
>> I have opened 2 tickets in RELENG to have these packages
>> removed/blocked for EPEL.
>>
>> Packages which are newer in EPEL than RHEL-7.4
>>
>> https://pagure.io/releng/issue/6948
>>
>> Packages which are older in EPEL than RHEL-7.4 but exist in aarch64,
>> x86_64, ppc64, and ppc64le
>>
>> https://pagure.io/releng/issue/6950
>>
>> The remaining packages which are not in all architectures BUT are very
>> old (and may break other things). These need some sort of
>> update/rebuild I expect.
> 
> I took a look at the three I am maintainer of:
> 
>> perl-Crypt-PasswdMD5
> 
> This package is unchanged from the EPEL package, just rebuilt (apart from the
> EPEL package having a "0." release prefix to indicate that it's one of the
> limited arch packages). I don't really think anything needs to be done with 
> this.
> 
>> python-crypto
> 
> This is basically a clone of the existing EPEL package, with conditionals
> added around the python3 package so it doesn't get built for RHEL, which
> doesn't have python3.x. Updating this to match the RHEL package would result
> in dropping the python3 support, so I think this should be left alone too.

Available Packages
python2-crypto.x86_64   2.6.1-13.el7   epel
python2-crypto.x86_64   2.6.1-15.el7   rhel-7-server-extras-rpms
python34-crypto.x86_64  2.6.1-13.el7   epel

If this is a "limited arch package", shouldn't the release have 0. prefix as 
well?

>> python-paramiko
> 
> This one has had a version bump to a major new version that uses a different
> crypto backend (python-cryptography rather than python-crypto). This one
> should be cloned into the epel7 branch, a "0." prepended to Release: and the
> python3 package enabled I think.

Available Packages
python-paramiko.noarch 2.1.1-2.el7   rhel-7-server-extras-rpms
python2-paramiko.noarch1.16.1-2.el7  epel
python34-paramiko.noarch   1.16.1-2.el7  epel

I think you're correct.

-- 
Orion Poplawski
Technical Manager  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] Re: Pull request/Changes to CentOS Extras repo??

2017-05-03 Thread Orion Poplawski
On 04/04/2017 02:42 AM, Martin Juhl wrote:
> Ok... now I have a complete list:
> 
> For building "python-flask-whooshee" in the copr project.. I need:
> 
> python3-blinker:
>No other dependencies
> 
> python3-flask:
>python3-itsdangerous
>python3-sqlalchemy

again, already in EPEL7

>python3-werkzeug - Depends on python3-sphinx

python3-sphinx is a hairy mess last I checked.  I've either disabled docs or
built with python-sphinx.

> python3-flask-sqlalchemy
>No other dependencies
> 
> So all in all, it's 7 packages...
> 
> I have the specs for building only the python3.. 
> 
> What should I do to commit these for review???

Same as any other review.  Just note in the comments that it is EPEL only.


> I'm already in the fedora packager group...
> 
> Thanks...
> 
> 
> /Martin
> 
> - Original meddelelse -
> Fra: "Orion Poplawski" <or...@cora.nwra.com>
> Til: "epel-devel" <epel-devel@lists.fedoraproject.org>
> Sendt: fredag, 31. marts 2017 16:39:37
> Emne: [EPEL-devel] Re: Pull request/Changes to CentOS Extras repo??
> 
> On 03/30/2017 04:41 AM, Martin Juhl wrote: 
>> Hi Again... 
>>
>> So... I forgot that python34 comes from EPEL, so the CentOS guys can't 
>> enable python3 builds... 
>>
>> So I guess these builds should be done in EPEL?? 
>>
>> I haven't got a list, but it's stuff like: 
>>
>> python-blinker-1.3-2.el7.src.rpm 
>> python-sqlalchemy-0.9.8-1.el7.src.rpm 
> 
> FYI - python3-sqlalchemy is already in EPEL7. 
> 
> python34-sqlalchemy.x86_64 1.1.3-1.el7 epel 
> 
> 
> 


-- 
Orion Poplawski
Technical Manager  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] Re: Pull request/Changes to CentOS Extras repo??

2017-03-31 Thread Orion Poplawski

On 03/30/2017 04:41 AM, Martin Juhl wrote:

Hi Again...

So... I forgot that python34 comes from EPEL, so the CentOS guys can't enable 
python3 builds...

So I guess these builds should be done in EPEL??

I haven't got a list, but it's stuff like:

python-blinker-1.3-2.el7.src.rpm
python-sqlalchemy-0.9.8-1.el7.src.rpm


FYI - python3-sqlalchemy is already in EPEL7.

python34-sqlalchemy.x86_64   1.1.3-1.el7  epel



--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] Re: lxc update on centos6 creates _have command not found

2016-12-21 Thread Orion Poplawski
On 12/21/2016 10:54 AM, Tony Schreiner wrote:
> The most recent update of lxc is causing the error upon login for centos6
> -bash: _have: command not found
> 
> this comes from /etc/bash-completion.d/lxc
> 
> and I gather the reason it is that  bash-completion changed the have function
> to _have  at version 2.1, which rhel7 has but rhel6 is still on version 1.3
> 
> Tony Schreiner

You should file a bug if one doesn't already exist.  
https://bugzilla.redhat.com/


-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] %_pkgdocdir in EPEL

2016-12-06 Thread Orion Poplawski
%_pkgdocdir was added in RHEL7.3, but incorrectly - see
https://bugzilla.redhat.com/show_bug.cgi?id=1392354

I've added a fixed version to epel-rpm-macros -
https://bodhi.fedoraproject.org/updates/epel-rpm-macros-7-11

And went ahead and added it for EPEL6 as well:

https://bodhi.fedoraproject.org/updates/epel-rpm-macros-6-16

I've submitted buildroot overrides as well, so they should be active in koji.
Please test and give feedback.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] Re: Help with resurrect two Orphans/Retired packages

2016-11-30 Thread Orion Poplawski

On 11/29/2016 03:46 AM, Mattias Ryrlén wrote:

Hi,

I'm quite new to this and wonder how we can proceed to get two packages
back to epel6 that got deleted due to flagged as orphaned this night 24/11

The packages i am talking about:
* rubygem(uuidtools)
* rubygem(aws-sdk) (requires rubygem(uuidtools))



Probably just the tip of the iceberg - uuidtools requires rspec.  Who 
knows what else.


My recollection is that ruby was getting pretty hard to maintain in EL6, 
so be prepared for a large undertaking.


As for how to do it - packagers need to step forward to unretire the 
packages in the EPEL6 branch, that's it.



--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] Re: Wrong mpich dependencies?

2016-11-21 Thread Orion Poplawski
On 11/21/2016 06:08 AM, Tuomo Soini wrote:
> On Mon, 21 Nov 2016 12:52:12 +0100
> Antonio Trande <anto.tra...@gmail.com> wrote:
> 
>> Hi all.
>>
>> 'petsc' build is failing on epel7 because missing 'mpich-devel';
>> however, devel package looks provides as
>> 'mpich-3.0-devel-3.0.4-10.el7.x86_64'.
>>
>> https://kojipkgs.fedoraproject.org//work/tasks/2209/16552209/root.log
>>
> 
> Yes. 'hypre' needs fixing.

FWIW, I've filed https://bugzilla.redhat.com/show_bug.cgi?id=1397192 for the
missing provides.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] %autoupdate -p is broken in RHEL6.8

2016-11-16 Thread Orion Poplawski
%autoupdate -p is broken in RHEL6.8 - I've submitted
https://bodhi.fedoraproject.org/updates/epel-rpm-macros-6-15 to fix it until a
RHEL update is done

Bug 1310704 – %autosetup -pN parsing doesn't terminate at EOL -
https://bugzilla.redhat.com/1310704

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] Django 1.8 in EPEL6 notes

2016-11-15 Thread Orion Poplawski
So, I've been playing around with trying to get cobbler and django 1.8 built
with python2.7 for EPEL6 here:

https://copr.fedorainfracloud.org/coprs/g/python/python2.7_epel6/packages/

I've basically got this working, with the following caveats:

- You can only have one (python) version of mod_wsgi installed/loaded in
httpd.  Currently in EPEL, there is only the system python version of mod_wsgi
available, although in Fedora there is also a python3 version available with
this same condition.  It does:

$ cat /etc/httpd/conf.modules.d/10-wsgi-python3.conf
# NOTE: mod_wsgi_python3 can not coexist in the same apache process as
# mod_wsgi (python2).  Only load if mod_wsgi is not already loaded.


LoadModule wsgi_module modules/mod_wsgi_python3.so


So I've done the same thing with python2.7-mod_wsgi for EPEL6.  This will
cause an upgrade issue though for EPEL6 users as they will need to remove or
disable mod_wgsi after the upgrade.  This shouldn't affect EPEL7 at the moment
as Django 1.8 should be able to be built with the system python 2.7.


- I built python2.7-django1.8 as a versioned egg
(https://fedoraproject.org/wiki/Packaging:Python_Eggs#Multiple_Versions).
This requires dependent packages to use pkg_resources from setuptools to load
the dep.  For example:

+import pkg_resources
+pkg_resources.require("Django >= 1.8")

I don't think this is too onerous for allowing us to upgrade the version of
Django later.  I don't know if there can be upper version limits and if so
whether they should be used or not.


Comments?

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] Re: Django stable RPMs

2016-11-10 Thread Orion Poplawski
On 11/09/2016 03:13 AM, Stephen Finucane wrote:
> On 2016-11-08 18:06, Matthias Runge wrote:
>> On 08/11/16 16:31, Brian Bouterse wrote:
>>> I believe the future of Django in EPEL is a topic that is being
>>> discussed on the EPSCO meetings last week and this week (18:00 UTC on
>>> Wednesdays in #fedora-meeting, iirc).
>>>
>>> I'm hoping that even if a newer, 1.8 based Django package is added to
>>> EPEL6, that the existing one named Django14 can be kept for legacy
>>> usage. The Django14 package having that unconventional name would allow
>>> a new package to use the more conventional python-django name which is
>>> convenient.
>>
>> I believe I can shed a light here:
>> - Django14 followed the old Django naming scheme in Fedora. Django was
>> renamed to python-django there.
>> - Django-1.4 was the old long term supported version and works with
>> pythons up to python 2.6
>> - Django14 should be retired IMO
> 
> I agree. It's rather decrepit at this point.
> 
>> - Django-1.8 (current long term supported version) requires python 2.7.
>> That means, we can not have a recent Django in EPEL6 with system python.
> 
> Per the docs [1]
> 
>   Django 1.8 requires Python 2.7, 3.2, 3.3, 3.4, or 3.5
> 
> EPEL 7 comes with Python 3.4, correct? If so, 'python3-django' seems like a
> thing that can be done.

We are building up a Python 3.4 stack on EPEL 6 & 7, so that is an option.

I'm also poking at Python 2.7 on EPEL6 here:
https://copr.fedorainfracloud.org/coprs/g/python/python2.7_epel6/packages/

Anyone in the python sig group and build there and play along/help out.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] Re: Django stable RPMs

2016-11-09 Thread Orion Poplawski

On 11/09/2016 03:21 PM, Kevin Fenzi wrote:

On Wed, 09 Nov 2016 10:13:48 +
Stephen Finucane <step...@that.guru> wrote:
..snip...


Yes, so Django 1.6 [2] is the one currently provided on EPEL 7.
However, that's Python 2.7. Would it be possible to add a Python 3
version using Django 1.8? Alternatively (and this might be heresy),
what's the possibility of bundling that version of Django in the
Reviewboard package only, or renaming it to something like
'python-django-rb', to free up the 'python-django' namespace for
Django 1.8?


I think we should have 1.8 in the name... if/when it drops out of
support and we want to move to 1.10, we can just retire 1.8 and move to
1.10 without having a specific flag day that breaks everyone using 1.8.



+1

--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] Reviving suitesparse for EL6 ppc64

2016-11-03 Thread Orion Poplawski
I'm asking unretirement for suitesparse on EPEL6 as a limited arch 
package for ppc64




Task 16281237 on buildppcle-02.phx2.fedoraproject.org
Task Type: build (noarch)
Link: https://koji.fedoraproject.org/koji/taskinfo?taskID=16281237

Task 16281238 on buildppc-03.phx2.fedoraproject.org
Task Type: buildArch (ppc64)
Link: https://koji.fedoraproject.org/koji/taskinfo?taskID=16281238
logs:
  https://kojipkgs.fedoraproject.org/work/tasks/1238/16281238/root.log
  https://kojipkgs.fedoraproject.org/work/tasks/1238/16281238/state.log
  https://kojipkgs.fedoraproject.org/work/tasks/1238/16281238/build.log
rpms:

https://kojipkgs.fedoraproject.org/work/tasks/1238/16281238/suitesparse-doc-3.4.0-0.9.el6.noarch.rpm

https://kojipkgs.fedoraproject.org/work/tasks/1238/16281238/suitesparse-3.4.0-0.9.el6.ppc64.rpm

https://kojipkgs.fedoraproject.org/work/tasks/1238/16281238/suitesparse-static-3.4.0-0.9.el6.ppc64.rpm

https://kojipkgs.fedoraproject.org/work/tasks/1238/16281238/suitesparse-debuginfo-3.4.0-0.9.el6.ppc64.rpm

https://kojipkgs.fedoraproject.org/work/tasks/1238/16281238/suitesparse-devel-3.4.0-0.9.el6.ppc64.rpm
srpms:

https://kojipkgs.fedoraproject.org/work/tasks/1238/16281238/suitesparse-3.4.0-0.9.el6.src.rpm

http://koji.fedoraproject.org/koji/taskinfo?taskID=16281237


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] Re: links browser update, now needs xWindows?

2016-10-24 Thread Orion Poplawski
On 10/24/2016 10:41 AM, be...@technologist.com wrote:
> hi there.got pointed here from the centos list...
> 
> The new update for the links browser takes it from 2.8-2 to 2.13-1.  But yum 
> includes 21 xWindows dependencies that weren't required before.
> 
> I'd rather not install them - it's a headless server.  Was this intentional?
> 
> 
>  Package Arch   Version   
> Repository   Size
> 
> Updating:
>  links   x86_64 1:2.13-1.el7  
> epel2.8 M

Looks like it was a big jump from links 2.8 to 2.13, and links appears to be a
graphical browser as well now: http://links.twibright.com/features.php

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] Re: libgeos-3.4.2 Error: CentOS 7

2016-09-26 Thread Orion Poplawski
On 09/26/2016 06:41 AM, Jibran Khan wrote:
> I was trying to install PostGIS on CentOS7 (x64) based machine.
> 
> # sudo yum install postgis2_95 postgis2_95-client
> 
> But, got this error: 
> 
> Error:  Package: grass-libs-6.4.4-7.el7.x86_64 (@epel)
> 
>  Requires: libgeos-3.4.2.so()(64bit)
> 
> Removing: geos-3.4.2-2.el7.x86_64 (@epel) libgeos-3.4.2.so()(64bit)
> 
>  Updated By: geos-3.5.0-1.rhel7.x86_64 (pgdg95) ~libgeos-3.5.0.so()(64bit)
> 
>  Available: geos-3.4.2-1.rhel7.x86_64 (pgdg94)  libgeos-3.4.2.so()(64bit)
> 
> Available: geos-3.2.2-2.el6.x86_64 (elgis)
> 
>  ~libgeos-3.2.2.so()(64bit)  Available: geos-3.3.0-1.el6.x86_64 (elgis) 
> 
> ~libgeos-3.3.0.so()(64bit)  Available: geos-3.3.1-2.el6.x86_64 (elgis)
> 
>  ~libgeos-3.3.1.so()(64bit)  Available: geos-3.3.6-1_0.el6.x86_64 (elgis) 
> 
> ~libgeos-3.3.6.so()(64bit)  Available: geos-3.3.8-2.el6.x86_64 (elgis) 
> 
> ~libgeos-3.3.8.so()(64bit) 
...
> Not nice! Any help would be highly appreciated?

Looks like you are mixing several repositories (epel, elgis, pgdg94).  Unless
there are specific commitments to maintaining compatibility among
repositories, this generally leads to problems like the ones you are seeing.

You can try using yum-priorities and playing with different priorities for the
different repos, but this is difficult and error prone as well.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] Re: Update the Old version of R(3.2.2) to new version 3.3.1

2016-09-15 Thread Orion Poplawski
On 09/15/2016 12:26 AM, vikaschi...@gmail.com wrote:
> Hello
> 
> Presently am working with elastic search so I need a "elastic" package in R. 
> But the version of R is 3.2.2 due to which am not able to install the 
> "elastic" package with its respected dependencies package.Can  you please 
> update the EPEL repositories of R.

The version of R in EPEL6/7 already is 3.3.1.

Available Packages
R.x86_64  3.3.1-2.el6 epel

R.x86_64  3.3.1-2.el7 epel

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org


[EPEL-devel] Re: new DNF for everyone

2016-08-26 Thread Orion Poplawski
On 08/26/2016 12:26 PM, Sérgio Basto wrote:
> On Sex, 2016-07-01 at 13:04 -0400, Honza Šilhan wrote:
>> Hi,
>>
>> DNF is in EPEL for more than one year, unfortunately there was still
>> the old
>> DNF-0.6.4
>> version. Over that time in DNF were implemented a lot of great
>> features and
>> plenty of bugs
>> have been fixed. DNF (especially its libraries) could not be updated
>> in EPEL
>> repository
>> because of its policy. Now we have prepared fresh DNF-1.1.9 for RHEL
>> 7 and
>> CentOS 7 users
>> in our COPR repository [1].
>>
>> In order to install DNF follow the instructions here [2].
>>
> 
> Can't we add this to epel 7 for "Red Hat Enterprise Linux 7.3" 
> 
> dnf in epel it is a bit useless, it doesn't have copr plugin for
> example . 

This is the problem:

Available Packages
hawkey.x86_64  0.5.8-2.git.0.202b194.el7  rhel-7-server-rpms
hawkey.x86_64  0.6.3-4.el7rhel-7-server-beta-rpms
libsolv.x86_64 0.6.11-1.el7   rhel-7-server-rpms
libsolv.x86_64 0.6.20-5.el7   rhel-7-server-beta-rpms

libsolv.x86_64   0.6.20-4.el7.centos
group_rpm-software-management-dnf-stack-el7
hawkey.x86_64 0.6.3-4.el7.centos
group_rpm-software-management-dnf-stack-el7

But it does like it will be possible to update dnf in EPEL7 when EL7.3 comes
out with updated hawkey and libsolv.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org


[EPEL-devel] Re: Fwd: [rhelv6-beta-list] Red Hat Enterprise Linux 7.3 Beta Now Available

2016-08-26 Thread Orion Poplawski
On 08/25/2016 07:35 PM, Stephen John Smoogen wrote:
> So the RHEL7.3 beta is now available for testing. Doing a simplified
> check of what packages I could find in centos-7.2 and beta 7.3 it
> looks like there are 220+ packages with version updates and maybe 60
> added packages.
> 
> NetworkManager-1.0.6
> NetworkManager-1.4.0
> NetworkManager-libreswan-1.0.6
> NetworkManager-libreswan-1.2.4
> 
> [some of these updates may already have been done through the
> quarterly as I didn't factor those in.]
> 
> Developers and testers please download and see if you run into any
> issues with EPEL.

Missed one more:

cpuid.x86_64 20151017-1.el7  epel
cpuid.x86_64 20151017-4.el7  rhel-7-server-beta-rpms

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org


[EPEL-devel] Re: Fwd: [rhelv6-beta-list] Red Hat Enterprise Linux 7.3 Beta Now Available

2016-08-26 Thread Orion Poplawski
5-qttools-libs-designer.x86_64 5.6.1-2.el7 epel
qt5-qttools-libs-designercomponents.i686
 5.6.1-1.el7 rhel-7-server-beta-rpms
qt5-qttools-libs-designercomponents.x86_64
 5.6.1-1.el7 rhel-7-server-beta-rpms
qt5-qttools-libs-designercomponents.x86_64
 5.6.1-2.el7 epel
qt5-qttools-libs-help.i686   5.6.1-1.el7 rhel-7-server-beta-rpms
qt5-qttools-libs-help.x86_64 5.6.1-1.el7 rhel-7-server-beta-rpms
qt5-qttools-libs-help.x86_64 5.6.1-2.el7 epel
qt5-qttranslations.noarch5.6.1-1.el7 epel
qt5-qttranslations.noarch5.6.1-1.el7 rhel-7-server-beta-rpms
qt5-qtwebchannel.i6865.6.1-1.el7 rhel-7-server-beta-rpms
qt5-qtwebchannel.x86_64  5.6.1-1.el7 rhel-7-server-beta-rpms
qt5-qtwebchannel.x86_64  5.6.1-2.el7 epel
qt5-qtwebchannel-devel.i686  5.6.1-1.el7 rhel-7-server-beta-rpms
qt5-qtwebchannel-devel.x86_645.6.1-1.el7 rhel-7-server-beta-rpms
qt5-qtwebchannel-devel.x86_645.6.1-2.el7 epel
qt5-qtwebsockets.i6865.6.1-1.el7 rhel-7-server-beta-rpms
qt5-qtwebsockets.x86_64  5.6.1-1.el7 epel
qt5-qtwebsockets.x86_64  5.6.1-1.el7 rhel-7-server-beta-rpms
qt5-qtwebsockets-devel.i686  5.6.1-1.el7 rhel-7-server-beta-rpms
qt5-qtwebsockets-devel.x86_645.6.1-1.el7 epel
qt5-qtwebsockets-devel.x86_645.6.1-1.el7 rhel-7-server-beta-rpms
qt5-qtx11extras.i686 5.6.1-1.el7 rhel-7-server-beta-rpms
qt5-qtx11extras.x86_64   5.6.1-1.el7 rhel-7-server-beta-rpms
qt5-qtx11extras.x86_64   5.6.1-2.el7 epel
qt5-qtx11extras-devel.i686   5.6.1-1.el7 rhel-7-server-beta-rpms
qt5-qtx11extras-devel.x86_64 5.6.1-1.el7 rhel-7-server-beta-rpms
qt5-qtx11extras-devel.x86_64 5.6.1-2.el7 epel
qt5-qtxmlpatterns.i686   5.6.1-1.el7 rhel-7-server-beta-rpms
qt5-qtxmlpatterns.x86_64 5.6.1-1.el7 epel
qt5-qtxmlpatterns.x86_64 5.6.1-1.el7 rhel-7-server-beta-rpms
qt5-qtxmlpatterns-devel.i686 5.6.1-1.el7 rhel-7-server-beta-rpms
qt5-qtxmlpatterns-devel.x86_64   5.6.1-1.el7 epel
qt5-qtxmlpatterns-devel.x86_64   5.6.1-1.el7 rhel-7-server-beta-rpms

qt5-rpm-macros.noarch5.6.1-2.el7 rhel-7-server-beta-rpms
qt5-rpm-macros.noarch    5.6.1-3.el7 epel




-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org


[EPEL-devel] python34 for EPEL6

2016-08-24 Thread Orion Poplawski
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?

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
>From c5d5cf8463c47687c1ee8f7523079d5a526458d3 Mon Sep 17 00:00:00 2001
From: Orion Poplawski <or...@cora.nwra.com>
Date: Wed, 24 Aug 2016 15:34:12 -0600
Subject: [PATCH] Update to build on EL6

---
 python34-readline.patch | 14 ++
 python34.spec   | 27 +--
 2 files changed, 39 insertions(+), 2 deletions(-)
 create mode 100644 python34-readline.patch

diff --git a/python34-readline.patch b/python34-readline.patch
new file mode 100644
index 000..83601d8
--- /dev/null
+++ b/python34-readline.patch
@@ -0,0 +1,14 @@
+diff -up Python-3.4.3/Lib/test/test_readline.py.readline Python-3.4.3/Lib/test/test_readline.py
+--- Python-3.4.3/Lib/test/test_readline.py.readline	2016-08-24 14:12:57.026751263 -0600
 Python-3.4.3/Lib/test/test_readline.py	2016-08-24 14:13:28.768616872 -0600
+@@ -45,7 +45,7 @@ class TestHistoryManipulation (unittest.
+ 
+ class TestReadline(unittest.TestCase):
+ 
+-@unittest.skipIf(readline._READLINE_VERSION < 0x0600
++@unittest.skipIf(readline._READLINE_VERSION < 0x0601
+  and "libedit" not in readline.__doc__,
+  "not supported in this library version")
+ def test_init(self):
+diff -up Python-3.4.3/Misc/NEWS.readline Python-3.4.3/Misc/NEWS
+diff -up Python-3.4.3/Modules/readline.c.readline Python-3.4.3/Modules/readline.c
diff --git a/python34.spec b/python34.spec
index 45e632a..cc80561 100644
--- a/python34.spec
+++ b/python34.spec
@@ -104,11 +104,16 @@
 # (/usr/bin/python, rather than the freshly built python), thus leading to
 # numerous syntax errors, and incorrect magic numbers in the .pyc files.  We
 # thus override __os_install_post to avoid invoking this script:
+%if 0%{?fedora} || 0%{?rhel} >= 7
+%global brp_python_hardlink /usr/lib/rpm/brp-python-hardlink
+%else
+%global brp_python_hardlink /usr/lib/rpm/redhat/brp-python-hardlink
+%endif
 %global __os_install_post /usr/lib/rpm/brp-compress \
   %{!?__debug_package:/usr/lib/rpm/brp-strip %{__strip}} \
   /usr/lib/rpm/brp-strip-static-archive %{__strip} \
   /usr/lib/rpm/brp-strip-comment-note %{__strip} %{__objdump} \
-  /usr/lib/rpm/brp-python-hardlink 
+  %{brp_python_hardlink}
 # to remove the invocation of brp-python-bytecompile, whilst keeping the
 # invocation of brp-python-hardlink (since this should still work for python3
 # pyc/pyo files)
@@ -148,7 +153,7 @@
 Summary: Version 3 of the Python programming language aka Python 3000
 Name: python%{pyshortver}
 Version: %{pybasever}.3
-Release: 7%{?dist}
+Release: 8%{?dist}
 License: Python
 Group: Development/Languages
 
@@ -167,7 +172,11 @@ BuildRequires: db4-devel >= 4.7
 
 # expat 2.1.0 added the symbol XML_SetHashSalt without bumping SONAME.  We use
 # it (in pyexpat) in order to enable the fix in Python-3.2.3 for CVE-2012-0876:
+%if 0%{?fedora} || 0%{?rhel} >= 7
 BuildRequires: expat-devel >= 2.1.0
+%else
+Provides:  bundled(expat) = 2.1.0
+%endif
 
 BuildRequires: findutils
 BuildRequires: gcc-c++
@@ -251,6 +260,10 @@ Source8: check-pyc-and-pyo-timestamps.py
 # Was Patch0 in ivazquez' python3000 specfile:
 Patch1: Python-3.1.1-rpath.patch
 
+# readline test fails on EL6 readline 6.0
+# https://bugs.python.org/issue19884
+Patch2: python34-readline.patch
+
 # Some tests were removed due to audiotest.au not being packaged. This was
 # however added to the archive in 3.3.1, so we no longer delete the tests.
 #  Patch3: 3-remove-mimeaudio-tests.patch
@@ -818,7 +831,9 @@ Group:  Development/Libraries
 # this symbol (in pyexpat), so we must explicitly state this dependency to
 # prevent "import pyexpat" from failing with a linker error if someone hasn't
 # yet upgraded expat:
+%if 0%{?fedora} || 0%{?rhel} >= 7
 Requires: expat >= 2.1.0
+%endif
 
 %description libs
 This package contains files used to embed Python 3 into applications.
@@ -918,7 +933,9 @@ cp -a %{SOURCE7} .
 # Ensure that we're using the system copy of various libraries, rather than
 # copies shipped by upstream in the tarball:
 #   Remove embedded copy of expat:
+%if 0%{?fedora} || 0%{?rhel} >= 7
 rm -r Modules/expat || exit 1
+%endif
 
 #   Remove embedded copy of libffi:
 for SUBDIR in darwin libffi libffi_arm_wince libffi_msvc libffi_osx ; do
@@ -949,6 +966,7 @@ sed -r -i s/'_PIP_VERSION = "[0-9.]+"'/'_PIP_VERSION = "%{pip_version}"'/ Lib/en
 # Apply patches:
 #
 %patch1 -p1
+%patch2 -p1 -b .readline
 # 3: upstream as of Python 3.3.1
 
 %if 0%{?with_systemta

[EPEL-devel] Re: Adding the devtoolset repo for EPEL builds

2016-08-18 Thread Orion Poplawski

On 08/18/2016 05:57 PM, Jason L Tibbitts III wrote:

Can we not just have an updated gcc package in EPEL?  It wouldn't be
hard to make one.  Or do we have to not conflict with whatever Red Hat
might put in one of their addons?  Even then it would be easy to avoid
both file and package name conflicts.


I don't see why not (we only promise to not conflict with a couple base 
channels), though I'm willing to believe that it would be hard, 
especially for EL6.



--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org


[EPEL-devel] Re: Adding the devtoolset repo for EPEL builds

2016-08-18 Thread Orion Poplawski
On 08/16/2016 11:07 AM, Kevin Fenzi wrote:
> On Mon, 15 Aug 2016 14:24:21 -0400
> Tom Callaway <tcall...@redhat.com> wrote:
> 
>> Recently, I've been participating in some discussion as to how to
>> enable C++11 support for EPEL builds. Specifically, R (and its large
>> universe of addons in CRAN) would benefit significantly from C++11
>> support.
>>
>> After much discussion, it seems like the only sane way to do this is
>> to use the Red Hat Developer Toolset (for el6 and el7). It is my
>> understanding that all RHEL customers (and CentOS users) should be
>> able to enable this repository without restrictions.
>>
>> I'd like to propose that we enable the Developer Toolset repo in EPEL
>> and allow packages to depend on it. Thoughts?
> 
> So, this is a SCL of newer tools right?
> 
> Does this result in a runtime dependency? Or just a build time one?
> ie, will everyone using packages built with this have to install it
> also, or it's just a buildrequires?
> 
> kevin

Well, one question is the R-core-devel package.  Currently it requires gcc-c++
and gcc-gfortran.  Presumably if R were compiled with the devtoolset compiler,
it would need to require those to build add-ons locally.  Not sure though.
That's perhaps not many people though.

I'll also note that R currently BRs gcc-objc but I don't see any devtoolset
gcc-objc packages.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org


[EPEL-devel] Re: Update python-django EPEL7

2016-08-16 Thread Orion Poplawski
On 08/16/2016 10:17 AM, Germano Massullo wrote:
> Hello, I would like to ask if it is possible to update python-django
> for EPEL7 to, for example, 1.8 version.
> I am actually going to fill a Review Request for
> python-django-netjsongraph[1], and among its requirements, there is
> python-django-rest-framework that cannot actually be packaged for
> EPEL7 due python-django actual version
> 
> Thank you
> 
> [1]: https://github.com/interop-dev/django-netjsongraph

Yeah, django is a perennial issue in EPEL.  See
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/CBCLW2VUMZY2AXBBRMLPTKIWIYZRJMV2/#CBCLW2VUMZY2AXBBRMLPTKIWIYZRJMV2
for example.

Mainly I think it's going to take somebody who has the time and energy to do
the work.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org


[EPEL-devel] Re: Xfce 4.12 mega update coming to EL-7

2016-04-28 Thread Orion Poplawski
On 04/28/2016 11:05 AM, ToddAndMargo wrote:
> On 04/18/2016 04:10 PM, Mukundan Ragavan wrote:
>>
>>
>> All,
>>
>> After a trial run involving a COPR repo [1], I had written earlier
>> indicating that I started doing real builds of Xfce 4.12 packages for
>> EL-7 [2]. This is now complete and I have now submitted a update - a
>> mega update containing 53 packages total.
>>
>> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-262a3f39e1
>>
>>
>> Three points about the update -
>>
>> - libxfce4ui obsoletes libxfcegui4
>> (plugins using libxfcegui4 were never built for EL-7)
>>
>> - xfce4-pulseaudio-plugin obsoletes xfce4-mixer and xfce4-volumed
>> (xfce4-volumed is not even in the repos)
>>
>> - xfce4-pulseaudio-plugin uses pavucontrol as sound mixer which is
>> unavailable in EL-7 at the moment.
>>
>>
>> I have tested both upgrading a user configured Xfce 4.10 install and by
>> creating a new user. I did not notice any issues so far.
>>
>> Please enable epel-testing repo on a test machine, test these packages
>> and give karma on bodhi. I have set the stable karma to 12. Unless the
>> karma reaches 12, I intend to leave the update in testing for **three
>> weeks**.
>>
>>
>> Mukundan.
> 
> Hi Mukundan,
> 
> Dependencies for you to fix.
> 
> -T
> 
> 
> 
> Scientific Linux 7.2, x64
> 
> yum --enablerepo=* update
> --> Finished Dependency Resolution
> Error: Package: xfce4-notes-plugin-1.7.7-8.el7.x86_64
> (@/xfce4-notes-plugin-1.7.7-8.el7.x86_64)
   ^

This looks like a package you manually installed.  Where did it come from?
It's not in EPEL.



-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org


[EPEL-devel] kf5-baloo in EPEL7

2016-04-24 Thread Orion Poplawski

I don't think this was intentional?

I've filed https://bugzilla.redhat.com/show_bug.cgi?id=1329899

 Forwarded Message 
Subject: Anacron job 'cron.daily' on

/etc/cron.daily/0yum-daily.cron:

The following updates will be applied on

 PackageArch Version 
Repository


Size

Installing:
 kf5-baloo  x86_64   5.21.0-1.el7  epel 
  231 k

 replacing  baloo.x86_64 4.14.3-1.el7.centos
 python2-ecdsa  noarch   0.13-4.el7epel 
   83 k

 replacing  python-ecdsa.noarch 0.11-3.el7
Updating:
 pyhoca-gui noarch   0.5.0.5-1.el7 epel 
  795 k
 python-pandas  x86_64   0.17.1-1.el7  epel 
  6.6 M

Installing for dependencies:
 dbusmenu-qt5   x86_64   0.9.3-0.1.20150604.el7epel 
   87 k
 gstreamer1-plugins-goodx86_64   1.4.5-2.el7   sl 
   1.8 M
 kf5-baloo-libs x86_64   5.21.0-1.el7  epel 
  157 k
 kf5-filesystem x86_64   5.21.0-1.el7  epel 
   11 k
 kf5-karchive   x86_64   5.21.0-1.el7  epel 
   97 k
 kf5-kauth  x86_64   5.21.0-1.el7  epel 
  119 k
 kf5-kcodecsx86_64   5.21.0-1.el7  epel 
  180 k
 kf5-kcompletionx86_64   5.21.0-1.el7  epel 
  127 k
 kf5-kconfig-core   x86_64   5.21.0-1.el7  epel 
  278 k
 kf5-kconfig-guix86_64   5.21.0-1.el7  epel 
   46 k
 kf5-kconfigwidgets x86_64   5.21.0-1.el7  epel 
  372 k
 kf5-kcoreaddonsx86_64   5.21.0-1.el7  epel 
  384 k
 kf5-kcrash x86_64   5.21.0-1.el7  epel 
   29 k
 kf5-kdbusaddonsx86_64   5.21.0-1.el7  epel 
   64 k
 kf5-kfilemetadata  x86_64   5.21.0-2.el7  epel 
  123 k
 kf5-kguiaddons x86_64   5.21.0-1.el7  epel 
   59 k
 kf5-ki18n  x86_64   5.21.0-1.el7  epel 
  2.8 M
 kf5-kiconthemesx86_64   5.21.0-1.el7  epel 
  143 k
 kf5-kio-core   x86_64   5.21.0-1.el7  epel 
  622 k
 kf5-kio-core-libs  x86_64   5.21.0-1.el7  epel 
  483 k
 kf5-kio-docnoarch   5.21.0-1.el7  epel 
  1.9 M
 kf5-kio-ntlm   x86_64   5.21.0-1.el7  epel 
   19 k
 kf5-kio-widgetsx86_64   5.21.0-1.el7  epel 
  257 k
 kf5-kio-widgets-libs   x86_64   5.21.0-1.el7  epel 
  393 k
 kf5-kitemviews x86_64   5.21.0-1.el7  epel 
  125 k
 kf5-kjobwidgetsx86_64   5.21.0-1.el7  epel 
  134 k
 kf5-knotifications x86_64   5.21.0-1.el7  epel 
  155 k
 kf5-kservice   x86_64   5.21.0-1.el7  epel 
  343 k
 kf5-ktextwidgets   x86_64   5.21.0-1.el7  epel 
  296 k
 kf5-kwalletx86_64   5.21.0-1.el7  epel 
  343 k
 kf5-kwallet-libs   x86_64   5.21.0-1.el7  epel 
   90 k
 kf5-kwidgetsaddons x86_64   5.21.0-1.el7  epel 
  1.7 M
 kf5-kwindowsystem  x86_64   5.21.0-1.el7  epel 
  182 k
 kf5-solid  x86_64   5.21.0-1.el7  epel 
   40 k
 kf5-solid-libs x86_64   5.21.0-1.el7  epel 
  373 k
 kf5-sonnet-corex86_64   5.21.0-1.el7  epel 
  132 k
 kf5-sonnet-ui  x86_64   5.21.0-1.el7  epel 
  230 k
 lmdb-libs  x86_64   0.9.18-1.el7  epel 
   52 k
 phonon-qt5 x86_64   4.8.3-2.el7   epel 
  211 k
 phonon-qt5-backend-gstreamer   x86_64   4.8.2-2.el7   epel 
  139 k
 polkit-qt5-1   x86_64   0.112.0-1.el7 epel 
   73 k
 qt5-qtbase x86_64   5.6.0-7.el7   epel 
  3.0 M
 qt5-qtbase-common  noarch   5.6.0-7.el7   epel 
   24 k
 qt5-qtbase-gui x86_64   5.6.0-7.el7   epel 
  5.5 M
 qt5-qtdeclarative  x86_64   5.6.0-3.el7   epel 
  3.0 M
 qt5-qtscript   x86_64   5.6.0-3.el7   epel 
  1.0 M
 qt5-qtsvg  x86_64   5.6.0-3.el7   epel 
  153 k
 qt5-qttools-common noarch   5.6.0-3.el7   epel 
   21 k
 qt5-qttools-libs-designer  x86_64   5.6.0-3.el7   epel 
  2.7 M
 qt5-qtx11extrasx86_64   5.6.0-3.el7   epel 

[EPEL-devel] Re: python_provide macro in EPEL 7?

2016-04-10 Thread Orion Poplawski

On 04/09/2016 12:11 AM, Dave Johansen wrote:

On Thu, Apr 7, 2016 at 7:58 AM, Orion Poplawski <or...@cora.nwra.com
<mailto:or...@cora.nwra.com>> wrote:


I'm guessing that you are on Fedora 23 and that you need this update:

https://bodhi.fedoraproject.org/updates/FEDORA-2016-dcddcc1f06


That did resolve that issues, but the build fails:
http://koji.fedoraproject.org/koji/taskinfo?taskID=13601877



You are missing a BR on python%{python3_pkgversion}-setuptools and 
others.  I've checked in another fix.  This should have been caught on 
review and I've added a note to the review about that.



--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org


[EPEL-devel] Re: python_provide macro in EPEL 7?

2016-04-07 Thread Orion Poplawski

On 04/06/2016 10:00 PM, Dave Johansen wrote:

On Wed, Apr 6, 2016 at 8:39 PM, Orion Poplawski <or...@cora.nwra.com
<mailto:or...@cora.nwra.com>> wrote:

On 04/06/2016 09:31 PM, Dave Johansen wrote:

I'm trying to build python-breathe in EPEL 7 (
https://admin.fedoraproject.org/pkgdb/package/rpms/python-breathe/
).
What's the right way to use/replace the %python_provide macro there?

I get the following error:
https://admin.fedoraproject.org/pkgdb/package/rpms/python-breathe/

Thanks,
Dave




I've checked in the fix.


I tried doing a build and got this error:
$ fedpkg build
error: line 47: Unknown tag: ERROR:
python%{python3_pkgversion}-breathenot recognized.
error: query of specfile
/home/dlj/fedora-scm/python-breathe/python-breathe.spec failed, can't parse


I'm guessing that you are on Fedora 23 and that you need this update:

https://bodhi.fedoraproject.org/updates/FEDORA-2016-dcddcc1f06

--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org


[EPEL-devel] Re: python_provide macro in EPEL 7?

2016-04-06 Thread Orion Poplawski

On 04/06/2016 09:31 PM, Dave Johansen wrote:

I'm trying to build python-breathe in EPEL 7 (
https://admin.fedoraproject.org/pkgdb/package/rpms/python-breathe/ ).
What's the right way to use/replace the %python_provide macro there?

I get the following error:
https://admin.fedoraproject.org/pkgdb/package/rpms/python-breathe/

Thanks,
Dave





I've checked in the fix.

--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org


[EPEL-devel] orphaned leafpad in EPEL6

2016-04-05 Thread Orion Poplawski

I've orphaned leafpad in EPEL6.  Please pick it up if you care about it.

--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org


[EPEL-devel] Re: Keeping old packages

2016-02-19 Thread Orion Poplawski
On 02/19/2016 08:13 AM, Stephen John Smoogen wrote:
> On 18 February 2016 at 19:16, ~Stack~ <i.am.st...@gmail.com> wrote:
>> On 02/18/2016 06:29 PM, Stephen John Smoogen wrote:
>>> On 18 February 2016 at 14:13, ~Stack~ <i.am.st...@gmail.com> wrote:
>>>> On 02/18/2016 01:56 PM, Kevin Fenzi wrote:
>>>>> On Tue, 16 Feb 2016 23:24:58 -0700
>>>>> Stephen John Smoogen <smo...@gmail.com> wrote:
>>>> [snip]
>>>>>> 1. Packages will never disappear. [They don't disappear from Fedora 12
>>>>>>even if it is archived.. ]
>>>>>
>>>>> To my understanding we never made this promise. We should try and
>>>>> communicate why it's NOT something we promise.
>>>>
>>>> Could you elaborate on this please? I have asked before, but didn't
>>>> really get an answer. I don't understand this.
>>>>
>>>
>>> Software in EPEL follows many of the same rules as software in Fedora.
>>> If there isn't an active maintainer the software is removed. This is
>>> because a lot of people expect that the software is going to be
>>> getting updates and bug fixes when it is there. If it isn't there it
>>> is clear that it isn't getting any bug fixes.
>>>
>>> While as a user this is a major pain in the butt, on the other side
>>> (maintainers and developers of the software) it is a major pain when
>>> the opposite occurs. Developers get complaints about software they no
>>> longer have any interest in and try to find someone to get rid of the
>>> old software. People who are maintainers of other packages get long
>>> hate emails about why is this software still in XYZ repository if no
>>> one is going to care about it. It burnt out a lot of the early
>>> repository people because they had made a package for someone at some
>>> point but really didn't have any care for it to be there any longer
>>> but all they were getting was crap for it being there.
>>
>> Thanks for replying. Makes sense. But what would the harm be to move a
>> package into a separate "retired" repo? Community would know that it
>> isn't maintained and yet the package wouldn't just disappear completely.
>> I guess the difficult question would then be, how long is the package
>> kept till it needs to be pruned? 1yr? 6mo? Still, it would be nice to
>> give the user base the option to pull the packages they need out on a
>> long enough scale that they have time to discover it with new builds.
>>
> 
> So every package ever signed is still in the koji build server if you
> know where to look for it. However I am hoping next week to write up
> some proposals that could accomplish this.
> 
>> I also wonder how many people have been bit by this. I know I have
>> supplied packages out of my repos for others before, but it has only
>> been a handful. It seems to have bitten me several times in the last
>> year and all were for EL6, but (fingers crossed) I am done with the EL6
>> boxes in <2yrs with a full migration to either EL7 or Ubuntu LTS and
>> won't need the EL6 repo any more. :-)
>>
> 
> A lot of people have been bit as it is nearly a daily occurrence in
> #epel on the irc server.
> 
>> Thanks again!
>> ~Stack~

My first comment is that I think we need to do better communication, as I
don't think an announcement goes out to epel-users when a package is going to
be retired.

My proposal would be to:

- When building against RHEL X.Y, the epel packages end up in epel/X.Y with a
symbolic link of epel/X -> epel/X.Y.
- The last two versions are in http://dl.fedoraproject.org/pub/epel, with
older ones retired to http://archives.fedoraproject.org/pub/archive/epel


-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org


[EPEL-devel] Re: Issue with mock for EL 5?

2016-01-27 Thread Orion Poplawski
On 01/27/2016 09:43 AM, Dave Johansen wrote:
> I was trying to do some test builds with EL 5 using mock on CentOS 7.2 and I
> kept getting the following error:
>   Installing :
> 2:shadow-utils-4.0.17-23.el5.x86_64   
>
> 82/114
> /usr/sbin/groupadd: error while loading shared libraries: libselinux.so.1:
> cannot open shared object file: No such file or directory
> /usr/sbin/groupadd: error while loading shared libraries: libselinux.so.1:
> cannot open shared object file: No such file or directory
>   Installing :
> libutempter-1.1.4-4.el5.x86_64
>
> 83/114
> warning: group utmp does not exist - using root
> 
> Any ideas?

There must be some kind of dependency loop going on.  It may be:

libselinux -> setransd (mcstrans) -> /sbin/chkconfig (initscripts) ->
coreutils -> libselinux



-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org


[EPEL-devel] Re: Issue with mock for EL 5?

2016-01-27 Thread Orion Poplawski

On 01/27/2016 04:43 PM, Dave Johansen wrote:

On Wed, Jan 27, 2016 at 10:42 AM, Orion Poplawski <or...@cora.nwra.com
<mailto:or...@cora.nwra.com>> wrote:

On 01/27/2016 09:43 AM, Dave Johansen wrote:
> I was trying to do some test builds with EL 5 using mock on CentOS 7.2 
and I
> kept getting the following error:
>   Installing :
> 2:shadow-utils-4.0.17-23.el5.x86_64
> 82/114
> /usr/sbin/groupadd: error while loading shared libraries: libselinux.so.1:
> cannot open shared object file: No such file or directory
> /usr/sbin/groupadd: error while loading shared libraries: libselinux.so.1:
> cannot open shared object file: No such file or directory
>   Installing :
> libutempter-1.1.4-4.el5.x86_64
> 83/114
> warning: group utmp does not exist - using root
>
> Any ideas?

There must be some kind of dependency loop going on.  It may be:

libselinux -> setransd (mcstrans) -> /sbin/chkconfig (initscripts) ->
coreutils -> libselinux


Should I open a bugzilla? Or is this an issue that's already being worked?


I didn't find anything in bugzilla.  But this being EL5, I'm not sure it 
would be fixed at this point...



--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org


[EPEL-devel] Re: MPI Fortran compiler detection failed on EPEL7

2016-01-16 Thread Orion Poplawski

On 01/16/2016 03:44 PM, Antonio Trande wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello everybody,

OpenMPI Fortran compiler detection fails during
Sundials-OpenMPI(1.10.0) rebuilds on EPEL7:

http://koji.fedoraproject.org/koji/taskinfo?taskID=12582324

Unexpectedly, cmake's Fortran compiler test works on ppc64le arch,
but fails on x86_64.



-- Looking for MPI Fortran compiler script
/usr/lib64/openmpi/bin/mpifort



-- Trying to compile and link a simple MPI Fortran program...
FAILED



This does not happen on Fedora (OpenMPI-1.8.8) and EPEL6
(OpenMPI-1.8.1);  see

http://koji.fedoraproject.org/koji/taskinfo?taskID=12581901 (rawhide)
http://koji.fedoraproject.org/koji/taskinfo?taskID=12582140 (epel6)

Am I missing something?
Any comment/idea?


Really impossible to tell without the cmake output logs, specifically 
CMakeFiles/CMakeError.log.


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org


[EPEL-devel] Re: LibRaw is in EPEL testing and also in Base

2016-01-12 Thread Orion Poplawski
On 01/12/2016 08:28 AM, Johnny Hughes wrote:
> 'LibRaw-0.17.1-3.el7.x86_64 (epel-testing)' and
> 'LibRaw-0.14.8-5.el7.20120830git98d925.x86_64 (@base/$releasever)' are
> conflicting

I think there is some confusion around this.  It seems that it may have been
removed from RHEL7.2 but not CentOS/SL?


-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org


[EPEL-devel] Re: LibRaw is in EPEL testing and also in Base

2016-01-12 Thread Orion Poplawski
On 01/12/2016 11:02 AM, Pat Riehecky wrote:
> 
> 
> On 01/12/2016 11:54 AM, Orion Poplawski wrote:
>> On 01/12/2016 08:28 AM, Johnny Hughes wrote:
>>> 'LibRaw-0.17.1-3.el7.x86_64 (epel-testing)' and
>>> 'LibRaw-0.14.8-5.el7.20120830git98d925.x86_64 (@base/$releasever)' are
>>> conflicting
>> I think there is some confusion around this.  It seems that it may have been
>> removed from RHEL7.2 but not CentOS/SL?
>>
>>
> There is no reference to libraw I could find in the RHEL7.2 release
> notes.. typically removed packages are documented there.
> 
> Pat

I just know that I cannot find it on the RHEL server 7.2 source media or in
the normal RHEL 7.2 server channels on my 7.2 server.  I don't have access to
workstation so I can't say anything about that.


-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org


[EPEL-devel] Re: Which python3 versions to package for EPEL7?

2016-01-06 Thread Orion Poplawski
On 01/06/2016 10:51 AM, Kevin Fenzi wrote:
> On Wed, 6 Jan 2016 20:41:54 +1000
> Nick Coghlan <ncogh...@gmail.com> wrote:
> 
>> On 6 January 2016 at 13:48, Toshio Kuratomi <a.bad...@gmail.com>
>> wrote:
>>> Despite the confusion, my feeling is that we want the newer
>>> versions. People who want to run python3 are willing to live more
>>> on the bleeding edge.  What I've observed is that they want newer
>>> versions of libraries as well.  Building packages that nobody wants
>>> to use because they are too old isn't that helpful to those who
>>> want to use the system packages for their development.  For us
>>> packagers, getting applications to run on python3 frequently needs
>>> newer versions of supporting libraries due to bugfixes for python3
>>> going into those libraries.  Attempting to pin the python34
>>> versions to the versions that ship with RHEL or in EPEL as the
>>> python2 version will quickly become a hindrance to us in those
>>> efforts as well.  
>>
>> +1 from me for adopting newer package versions as baseline in the
>> python3X stacks.
> 
> +1 from me too. 
> 
> Also, now that 35 is out, do we want to switch epel7 to python35 before
> we go building out things much more?
> 
> kevin

Actually, I think it would be nice to test out the dual nature by adding 35 as
the "other" version for now.  Of course, this is dependent on someone
submitting a python35 package for review, which it something I'm not up for
taking on.


-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org


[EPEL-devel] Re: execstack on epel 7 ppc64le?

2016-01-05 Thread Orion Poplawski
On 12/23/2015 10:57 PM, Peter Robinson wrote:
>> I'm trying to build the ppc64le branch of OpenBLAS on EPEL7. But, I get the
>> following error message in the setup phase:
>>
>> DEBUG util.py:393:  Error: No Package found for /usr/bin/execstack
>>
>> Why would this binary not exist on ppc64le?
> 
> Because originally it was part of prelink, which was never supported
> on aarch64/ppc64le, in RHEL it's shipped as part of that package, it
> was dropped in F-23 and the useful execstack binary was split out into
> it's own package. It shouldn't be built in EPEL as it'll conflict with
> core RHEL packages.
> 
> Peter

But perhaps we could do
https://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages

add ppc64le to the list of ExclusiveArch, and only ship execstack?
See http://koji.fedoraproject.org/koji/taskinfo?taskID=12421692

Or perhaps we could just go ahead an ship execstack with a Conflicts: prelink.
 Not sure it's that big of a deal.


-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org


[EPEL-devel] Which python3 versions to package for EPEL7?

2016-01-05 Thread Orion Poplawski
So, I've started packaging up a bunch of python3 only packages for EPEL7 
for packages that were already in RHEL7.  I've started by packaging the 
latest version of the modules:


python34-py.noarch   1.4.30-2.el7  epel-testing
python34-setuptools.noarch   19.2-3.el7epel-testing

But these are much newer than the python2 versions:

python-py.noarch 1.4.27-1.el7
python-setuptools.noarch 0.9.8-4.el7

I'm afraid I was motivated by the possibilities of supporting newer 
python3 code, but Matthias RUnge makes the valid point that this may 
cause confusion and other problems[1].


What's the consensus here?

1 - https://bugzilla.redhat.com/show_bug.cgi?id=1294865#c3
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org


[EPEL-devel] Package Review component in Fedora EPEL product

2016-01-04 Thread Orion Poplawski
There is a Package Review component in the Fedora EPEL product in bugzilla.
Should there be?  I figured it was useful for EPEL only packages, but I've
also been told that even EPEL only reviews should go under the Fedora product.

The EPEL FAQ
https://fedoraproject.org/wiki/EPEL/FAQ#Is_it_possible_to_get_a_package_only_into_EPEL_and_not_Fedora.3F
seems to indicate just the normal process.

If that is the case, can we get the Package Review component removed from
Fedora EPEL?

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org


[EPEL-devel] Re: Additional python34 components for epel7

2015-12-30 Thread Orion Poplawski
On 12/30/2015 10:00 AM, Orion Poplawski wrote:
> On 12/30/2015 12:16 AM, Denis Fateyev wrote:
>> Actually, I've opened a bug against 'msgpack':
>> https://bugzilla.redhat.com/show_bug.cgi?id=1290393
>>
>> What we actually need is to clarify and officially approve python3 epel
>> proposal and guidelines, to start packaging things for epel7.
>>
>> I'm ready to help out with packaging and testing python34 things, since I 
>> need
>> some now.
>>
> 
> Some reviews are underway here:
> 
> https://bugzilla.redhat.com/showdependencytree.cgi?id=1294704_resolved=1
> 
> 

Copr -

https://copr.fedoraproject.org/coprs/g/python/python3_epel7/

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org


[EPEL-devel] Re: Additional python34 components for epel7

2015-12-30 Thread Orion Poplawski
On 12/30/2015 12:16 AM, Denis Fateyev wrote:
> Actually, I've opened a bug against 'msgpack':
> https://bugzilla.redhat.com/show_bug.cgi?id=1290393
> 
> What we actually need is to clarify and officially approve python3 epel
> proposal and guidelines, to start packaging things for epel7.
> 
> I'm ready to help out with packaging and testing python34 things, since I need
> some now.
> 

Some reviews are underway here:

https://bugzilla.redhat.com/showdependencytree.cgi?id=1294704_resolved=1


-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org


[EPEL-devel] Re: New package notification for Fedora EPEL

2015-12-22 Thread Orion Poplawski

On 12/22/2015 07:49 PM, Kevin Fenzi wrote:

On Mon, 21 Dec 2015 16:07:35 -0700
Orion Poplawski <or...@cora.nwra.com> wrote:


I think it would be handy to have new package notification for Fedora
EPEL, e.g. for mediawiki123.  I created:

https://release-monitoring.org/project/8480/

I think the next step would be for something to listen to those
messages and file bugs under the Fedora EPEL product.  Does that
sound right?


Yeah. The new hotness is the thing that does this for Fedora things.

I would think it wouldn't be too hard to also have it do Fedora EPEL?

Perhaps file a issue on it?

https://github.com/fedora-infra/the-new-hotness/issues

kevin


Thanks for the pointer for where to file - 
https://github.com/fedora-infra/the-new-hotness/issues/91


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org


[EPEL-devel] New package notification for Fedora EPEL

2015-12-21 Thread Orion Poplawski
I think it would be handy to have new package notification for Fedora EPEL,
e.g. for mediawiki123.  I created:

https://release-monitoring.org/project/8480/

I think the next step would be for something to listen to those messages and
file bugs under the Fedora EPEL product.  Does that sound right?

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org


[EPEL-devel] Alternate install prefixes

2015-12-17 Thread Orion Poplawski
I'm looking at packaging up cmake 3.4 for EPEL7 as cmake34 much like we 
did with cmake 2.8 in EPEL6 as cmake28.  Generally what we've done in 
the past is still install into the normal paths and rename binaries & 
directories asneeded.  With cmake this is quite tricky and requires an 
invasive patch.


It would be much easier to install into a different prefix and then 
symlink to /usr/bin/cmake34 - although I still have some doubts as to 
whether this would work or not - cmake seems to want to still spawn 
"cmake" which would use the system version (or not be found).  One might 
also be able to use environment-modules, though this would require more 
modification to spec files.


See https://bugzilla.redhat.com/show_bug.cgi?id=1290199 for some more 
details.


Thoughts?

--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org


[EPEL-devel]Re: python2-setuptools metapackage

2015-11-23 Thread Orion Poplawski

On 11/23/2015 06:00 PM, Dan Callaghan wrote:

Excerpts from John Dulaney's message of 2015-11-19 17:11 -05:00:

Since Fedora is now requiring python2 packages have a buildrequires
of python2-setuptools, I put together a quick metapackage(0)(1) that in turn
requires python-setuptools.  This will make packaging for Fedora and
epel to be somewhat easier.

What are your thoughts on this, and should we include this in epel?


At first it struck me as an abomination, but I've come around.


As an alternative, it may not be a bad idea to have one large metapackage
that builds sub-metapackages for the various similar situations.  Thoughts
on this?


I would go for the single meta-package, assuming we're talking more than 
5 or so package that need this.  And Version should be 0.  I've attached 
my version.  I've specified Release in the sub-package so that we don't 
have updates as packages are added/removed and the main release is 
bumped.  Also set license to MIT as that is the default license for spec 
files, and that's about all this is.



Would it be easier to request the RHEL packages to add a virtual
Provides for the python2-* name? That is, python-setuptools in RHEL
could provide python2-setuptools.


Well, one has already been made for setuptools: 
https://bugzilla.redhat.com/show_bug.cgi?id=1259474 with no comments so 
far.  RHEL 7.2 just came out so it will certainly be no sooner than 7.3.


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
Name:  python2-provides
Summary:   python2-provides metapackage
Version:   0
Release:   2%{?dist}
BuildArch: noarch
License:   MIT

%description
A collection of python2 metapackages to pull in python-foo when python2-foo is required.

%package  python2-setuptools
Summary:  python2-setuptools metapackage
Release:  1
Requires: python-setuptools

%description python2-setuptools
A meta-package to pull in python-setuptools when python2-setuptools is required.

%files python2-setuptools

%changelog
* Mon Nov 23 2015 Orion Poplawski <or...@cora.nwra.com> - 0-2
- Metapackage

* Thu Nov 19 2015 John Dulaney <jdula...@fedoraproject.org> - 1.0-1
- Initial package
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org


[EPEL-devel]Re: TexLive

2015-11-21 Thread Orion Poplawski

On 11/21/2015 04:22 AM, Germano Massullo wrote:

Il 21/11/2015 04:56, Orion Poplawski ha scritto:

On 11/20/2015 03:51 AM, Germano Massullo wrote:

I saw https://admin.fedoraproject.org/pkgdb/package/texlive/  that there
is not texlive for EPEL7.
But in a CentOS 7 installation, if I do "yum search texlive" you get
many packages. They have been simply automatically ported from the EPEL
6 repos? Why are them so less in amount, compared to the Fedora
texlive-full-scheme?


The main texlive package lives in RHEL.  For RHEL7 they stripped out a
lot of packages, which made a lot of people (including myself)
unhappy.  A couple have been added to RHEL7.2, but now there is also
texlive-extension in EPEL7 which provides some (but not all) of the
missing packages.

Did you try to ask them to include all TeXLive packages that are
available from upstream? If not, I can try


I've asked for some specific ones that I need, and it looks like others 
have too:


https://bugzilla.redhat.com/buglist.cgi?quicksearch=%3Atexlive-extension_id=4214066


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org


[EPEL-devel]Re: When will 7.2 be in EPEL7 buildroot?

2015-11-19 Thread Orion Poplawski
On 11/18/2015 03:24 PM, Alan Pevec wrote:
> Hi all,
> 
> python-jsonpointer is going into base with 7.2, so it needs to be
> retired from EPEL7[*]
> Before doing that, I wanted to check when will be 7.2 imported to
> Koji, so we don't end up with broken builldroots?
> 
> Cheers,
> Alan
> 
> [*] https://bugzilla.redhat.com/show_bug.cgi?id=1249138

Kevin just imported 7.2.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org


Re: [EPEL-devel] Orphaned Packages in epel7 (2015-10-26)

2015-10-26 Thread Orion Poplawski
On 10/26/2015 04:33 AM, Bastien Nocera wrote:
> 
> 
> - Original Message -
>> 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
> 
> Can you please just retire libgnomecups and be done with it? You've been 
> emailing
> us about this package since the end of June, the 6 weeks have been and gone 
> many
> times over.
> 
> Cheers
> 

Yeah, I have to say this is just leading to alert fatigue.  We need to either
act on these in a timely manner or not send out these emails.


-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: [EPEL-devel] gifsicle 1.87 for el6?

2015-10-26 Thread Orion Poplawski
On 10/21/2015 10:34 AM, Bond, Aaron wrote:
> Hello all,
> 
>  
> 
> I have a colleague in our software development department that would like to
> use gifsicle for our image repository application.
> 
>  
> 
> Unfortunately, there are some bugs and improvements that are hindering
> development that occurred after the last version available for el6 (1.60) in
> epel. 
> 
>  
> 
> I was wondering if there was any reason that 1.87 is available for el7 but is
> not available for el6?  Are there some dependencies that are also not
> available within el6 (either CentOS or RHEL)?  Are there any plans to provide
> this later version for the el6 repo?

No reason, just that no one had asked.  I don't typically update el releases
unless there seems to be a compelling reason.

Since you've asked:

https://bodhi.fedoraproject.org/updates/gifsicle-1.88-1.el6


-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: [EPEL-devel] EPEL package rebased upon RHEL update?

2015-10-16 Thread Orion Poplawski

On 10/15/2015 09:24 PM, Christopher Meng wrote:

Hi,

Redis in EPEL6 is pretty dated, I'd like to update it to the latest
2.x version but somehow I haven't done major update like this.

Is it allowed to update the package from 2.4 to 2.8 for new RHEL 6.x
like 6.8 release?


https://fedoraproject.org/wiki/EPEL_Updates_Policy#Stable_Releases

--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: [EPEL-devel] crlibm and libscs for EPEL 7?

2015-10-09 Thread Orion Poplawski

On 10/08/2015 05:59 PM, Rich Rauenzahn wrote:

On Wed, Oct 7, 2015 at 1:16 PM, Orion Poplawski <or...@cora.nwra.com> wrote:

On 10/07/2015 02:05 PM, Rich Rauenzahn wrote:

Tim got back to me quickly.  He doesn't have the time or need to
maintain them for EPEL 7.  He offers to pass on the ownership to
another packager.


You could ask to become the maintainer in EPEL:
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Become_a_co-maintainer


That looks like quite an involved process with an uncertain outcome ...

Is that the only viable option at the moment?  Adopt it myself?

Rich


Well, obviously not - any interested Fedora packager could take it over. 
 But it is the way you can take control and contribute to the community.


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: [EPEL-devel] crlibm and libscs for EPEL 7?

2015-10-07 Thread Orion Poplawski
On 10/07/2015 02:05 PM, Rich Rauenzahn wrote:
> Tim got back to me quickly.  He doesn't have the time or need to
> maintain them for EPEL 7.  He offers to pass on the ownership to
> another packager.

You could ask to become the maintainer in EPEL:
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Become_a_co-maintainer

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: [EPEL-devel] build gradle 2.5 for EPEL?

2015-09-09 Thread Orion Poplawski
On 09/09/2015 08:32 AM, matt_dom...@dell.com wrote:
> *Dell - Internal Use - Confidential *
> 
> Mikolaj, would you please build gradle 2.5 for EPEL 7?  My development team
> uses gradle for our builds, and I much prefer getting packages from the
> RHEL/CentOS and/or EPEL yum repositories whenever possible.

Doubt this will happen anytime soon, many missing BRs in EPEL7:

Error: No Package found for groovy >= 2.3
Error: No Package found for javapackages-local
Error: No Package found for mvn(cglib:cglib-nodep)
Error: No Package found for mvn(ch.qos.logback:logback-classic)
Error: No Package found for mvn(ch.qos.logback:logback-core)
Error: No Package found for mvn(com.esotericsoftware.kryo:kryo)
Error: No Package found for mvn(com.esotericsoftware.minlog:minlog)
Error: No Package found for mvn(com.esotericsoftware.reflectasm:reflectasm)
Error: No Package found for mvn(com.fasterxml.jackson.core:jackson-annotations)
Error: No Package found for mvn(com.fasterxml.jackson.core:jackson-core)
Error: No Package found for mvn(com.fasterxml.jackson.core:jackson-databind)
Error: No Package found for mvn(com.google.code.findbugs:findbugs)
Error: No Package found for mvn(com.google.code.gson:gson)
Error: No Package found for mvn(com.google.guava:guava-jdk5)
Error: No Package found for mvn(com.googlecode.jatl:jatl)
Error: No Package found for mvn(com.puppycrawl.tools:checkstyle)
Error: No Package found for mvn(com.uwyn:jhighlight)
Error: No Package found for mvn(net.jcip:jcip-annotations)
Error: No Package found for mvn(net.rubygrapefruit:native-platform)
Error: No Package found for mvn(net.sf.kxml:kxml2-min)
Error: No Package found for mvn(org.apache.ivy:ivy)
Error: No Package found for mvn(org.apache.maven:maven-builder-support)
Error: No Package found for mvn(org.bouncycastle:bcpg-jdk15)
Error: No Package found for mvn(org.bouncycastle:bcprov-jdk15)
Error: No Package found for mvn(org.codehaus.gpars:gpars)
Error: No Package found for mvn(org.codehaus.groovy:groovy-all)
Error: No Package found for mvn(org.codehaus.jcsp:jcsp)
Error: No Package found for mvn(org.codehaus.jsr166-mirror:extra166y)
Error: No Package found for mvn(org.codehaus.sonar:sonar-batch)
Error: No Package found for mvn(org.codehaus.sonar:sonar-batch-bootstrapper)
Error: No Package found for mvn(org.codehaus.sonar:sonar-plugin-api)
Error: No Package found for mvn(org.codenarc:CodeNarc)
Error: No Package found for mvn(org.eclipse.aether:aether-ant-tasks)
Error: No Package found for mvn(org.eclipse.aether:aether-api)
Error: No Package found for mvn(org.eclipse.aether:aether-connector-basic)
Error: No Package found for mvn(org.eclipse.aether:aether-impl)
Error: No Package found for mvn(org.eclipse.aether:aether-spi)
Error: No Package found for mvn(org.eclipse.aether:aether-transport-classpath)
Error: No Package found for mvn(org.eclipse.aether:aether-transport-file)
Error: No Package found for mvn(org.eclipse.aether:aether-transport-http)
Error: No Package found for mvn(org.eclipse.aether:aether-transport-wagon)
Error: No Package found for mvn(org.eclipse.aether:aether-util)
Error: No Package found for mvn(org.eclipse.sisu:org.eclipse.sisu.plexus)
Error: No Package found for mvn(org.gmetrics:GMetrics)
Error: No Package found for mvn(org.gradle.jarjar:jarjar)
Error: No Package found for mvn(org.jboss.netty:netty:3)
Error: No Package found for mvn(org.jdom:jdom2)
Error: No Package found for mvn(org.multiverse:multiverse-core)
Error: No Package found for mvn(org.parboiled:parboiled-core)
Error: No Package found for mvn(org.parboiled:parboiled-java)
Error: No Package found for mvn(org.pegdown:pegdown)
Error: No Package found for mvn(org.samba.jcifs:jcifs)
Error: No Package found for mvn(org.sonatype.pmaven:pmaven-common)
Error: No Package found for mvn(org.sonatype.pmaven:pmaven-groovy)
Error: No Package found for mvn(org.spockframework:spock-core)
Error: No Package found for mvn(xom:xom)

Might be nice to have a java push effort for EPEL7 though.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


[EPEL-devel] EPEL packaging items in RHEL7 workstation

2015-08-24 Thread Orion Poplawski
EPEL is packaging items that are in RHEL7 workstation because they are not
available in the EPEL7 buildroots, e.g.:

https://bugzilla.redhat.com/show_bug.cgi?id=1234052
https://bugzilla.redhat.com/show_bug.cgi?id=1256545

I saw a brief mention of this from the steering committee log from 7/10.  Has
this issue been considered more?

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


[EPEL-devel] TeXmacs maintainer wanted

2015-08-18 Thread Orion Poplawski
I'm putting TeXmacs into EPEL7 due to sympy deps and I figure someone must
like it.  But I'd really rather not maintain it.  If you would like to, please
apply:

https://admin.fedoraproject.org/pkgdb/package/TeXmacs/

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: [EPEL-devel] python34 packages for EPEL

2015-07-17 Thread Orion Poplawski
On 07/17/2015 11:47 AM, Kevin Fenzi wrote:
 On Wed, 15 Jul 2015 16:41:13 -0600
 Orion Poplawski or...@cora.nwra.com wrote:
 
 Sorry for the cross posting - let's follow up on the EPEL list

 We now have python34 in EPEL (yay - thanks Matej and others!).
 Starting to look at packaging some modules.  We have
 https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3 as a
 starting point which looks pretty good.  One wrinkle though is that
 we have a bunch of python2 packages provided by RHEL that we'll want
 to provide python3X versions for in EPEL, but not ship python2
 versions.  So a question becomes, where do they get maintained?
 Either:

 - epel7 branch of the python-blah package in Fedora?
 - a new python3X-blah package?

 And if in an epel7 branch of an existing package, is it conceivable to
 maintain a common spec across EPEL and Fedora?
 
 I think we should do: 
 
 - If the package is in rhel already as a python2 only package: 
 new review for python3-whatever in epel. This way we don't have to be
 carefull to sync versions to the rhel version and wont interfere with
 it. The package in epel should only build the python3 version of
 course. 
 
 - If the package is not in rhel, just python-foo branched from fedora
   and we can try and share specs to build things. 
 
 kevin

If you look closely at my diff, you'll see that it doesn't ship a python2
version in epel.  But yeah, it may be cleaner to a separate package.  It will
be a lot of reviews, but hopefully pretty straightforward.



-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: [EPEL-devel] python34 packages for EPEL

2015-07-17 Thread Orion Poplawski
On 07/17/2015 02:05 PM, Kevin Fenzi wrote:
 On Fri, 17 Jul 2015 13:53:30 -0600
 Orion Poplawski or...@cora.nwra.com wrote:
 
 If you look closely at my diff, you'll see that it doesn't ship a
 python2 version in epel.  But yeah, it may be cleaner to a separate
 package.  It will be a lot of reviews, but hopefully pretty
 straightforward.
 
 yes, but that won't work. Koji operates on source packages. 
 
 If python-foo is in epel, it doesnt/cannot use other parts of
 python-foo from rhel. It's all or nothing. This is why we can't just
 ship foo for ppc64 and keep using the rhel x86_64 one. ;( 

Ah, thanks for the reminder.


-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


[EPEL-devel] python34 packages for EPEL

2015-07-15 Thread Orion Poplawski
Sorry for the cross posting - let's follow up on the EPEL list

We now have python34 in EPEL (yay - thanks Matej and others!).  Starting to
look at packaging some modules.  We have
https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3 as a starting point
which looks pretty good.  One wrinkle though is that we have a bunch of
python2 packages provided by RHEL that we'll want to provide python3X versions
for in EPEL, but not ship python2 versions.  So a question becomes, where do
they get maintained?  Either:

- epel7 branch of the python-blah package in Fedora?
- a new python3X-blah package?

And if in an epel7 branch of an existing package, is it conceivable to
maintain a common spec across EPEL and Fedora?

I think this is somewhat representative of the changes needed in a more
complicated package (setuptools) which isn't actually too terrrible:

diff --git a/python-setuptools.spec b/python-setuptools.spec
index 7f37e90..cb96b9f 100644
--- a/python-setuptools.spec
+++ b/python-setuptools.spec
@@ -1,9 +1,9 @@
-%if 0%{?fedora}
+%if 0%{?fedora} || 0%{?rhel} = 7
 %global with_python3 1

 # This controls whether setuptools is build as a wheel or not,
 # simplifying Python 3.4 bootstraping process
-%global build_wheel 1
+%global build_wheel 0
 %else
 %{!?python_sitelib: %global python_sitelib %(%{__python} -c from
distutils.sysconfig import get_python_lib; print (get_python_lib()))}
 %endif
@@ -44,10 +44,10 @@ BuildRequires:  python-pip
 BuildRequires:  python-wheel
 %endif
 %if 0%{?with_python3}
-BuildRequires:  python3-devel
+BuildRequires:  python%{python3_pkgversion}-devel
 %if 0%{?build_wheel}
-BuildRequires:  python3-pip
-BuildRequires:  python3-wheel
+BuildRequires:  python%{python3_pkgversion}-pip
+BuildRequires:  python%{python3_pkgversion}-wheel
 %endif
 %endif # if with_python3
 # For unittests
@@ -68,7 +68,7 @@ This package also contains the runtime components of
setuptools, necessary to
 execute the software that requires pkg_resources.py.

 %if 0%{?with_python3}
-%package -n python3-setuptools
+%package -n python%{python3_pkgversion}-setuptools
 Summary:Easily build and distribute Python 3 packages
 Group:  Applications/System

@@ -76,7 +76,7 @@ Group:  Applications/System
 # has been present since python3-3.2.  We do not ship python3-3.0 or
 # python3-3.1 anywhere

-%description -n python3-setuptools
+%description -n python%{python3_pkgversion}-setuptools
 Setuptools is a collection of enhancements to the Python 3 distutils that allow
 you to more easily build and distribute Python 3 packages, especially ones that
 have dependencies on other packages.
@@ -156,6 +156,9 @@ chmod +x
%{buildroot}%{python3_sitelib}/setuptools/command/easy_install.py
 popd
 %endif # with_python3

+%if 0%{?epel}
+rm %{buildroot}/%{_bindir}/easy_install
+%else
 %if 0%{?build_wheel}
 pip2 install -I dist/%{python2_wheelname} --root %{buildroot}
--strip-file-prefix %{buildroot}
 %else
@@ -167,9 +170,11 @@ rm -rf %{buildroot}%{python_sitelib}/setuptools/tests
 sed -i '/^setuptools\/tests\//d' %{buildroot}%{python2_record}
 %endif

-install -p -m 0644 %{SOURCE1} %{SOURCE2} .
 find %{buildroot}%{python_sitelib} -name '*.exe' | xargs rm -f
 chmod +x %{buildroot}%{python_sitelib}/setuptools/command/easy_install.py
+%endif # 0%{?epel}
+
+install -p -m 0644 %{SOURCE1} %{SOURCE2} .

 %check
 %{__python} setup.py test
@@ -184,15 +189,17 @@ popd
 rm -rf %{buildroot}


+%if !0%{?epel}
 %files
 %defattr(-,root,root,-)
 %doc *.txt docs
 %{python_sitelib}/*
 %{_bindir}/easy_install
 %{_bindir}/easy_install-2.*
+%endif

 %if 0%{?with_python3}
-%files -n python3-setuptools
+%files -n python%{python3_pkgversion}-setuptools
 %defattr(-,root,root,-)
 %doc psfl.txt zpl.txt docs
 %{python3_sitelib}/*


One note - according to
https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3#Specfiles.2C_Macros.2C_Packaging_Process
%{python3_pkgversion} is supposed to be defined in Fedora, but I don't see it
(at least not in F22). In the review
(https://bugzilla.redhat.com/show_bug.cgi?id=1219411#c8) there seems to be
some uncertainty as to where it will land?

Comments?

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: [EPEL-devel] Could you please Put Ganglia 3.1.7 packages back to repository

2015-05-20 Thread Orion Poplawski

On 05/19/2015 05:04 PM, Andrei Bryleuski wrote:

Dear EPEL Dev team,

Could you please put the following Ganglia 3.1.7 packages back to
repository:

·ganglia-3.1.7-6.el6.x86_64.rpm

·ganglia-gmetad-3.1.7-6.el6.x86_64.rpm

·ganglia-gmond-3.1.7-6.el6.x86_64.rpm

·ganglia-gmond-python-3.1.7-6.el6.x86_64.rpm

·ganglia-web-3.1.7-6.el6.x86_64.rpm

The reason: our latest product release could not be installed since
Ganglia 3.1.7 (3.7.1 is not supported) is being installed by Setup
procedure from EPEL repository and now Ganglia 3.1.7 packages are
removed from repository.


I'm not sure I understand the question, but you probably want to contact 
the ganglia maintainers directly either via bugzilla.redhat.com or 
ganglia-ow...@fedoraproject.org.  But in general, no, once a package has 
been updated we don't go back unless there is a catastrophic failure. 
Update in question was here:


https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-5926/ganglia-3.7.1-1.el6

no comments on it before it was pushed.

--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: [EPEL-devel] cmake and cmake28 in RHEL 6?

2015-05-16 Thread Orion Poplawski

On 05/15/2015 10:57 PM, Dave Johansen wrote:

On Tue, Apr 21, 2015 at 8:07 PM, Orion Poplawski or...@cora.nwra.com
mailto:or...@cora.nwra.com wrote:

On 04/21/2015 08:48 PM, Dave Johansen wrote:

On Mon, Apr 20, 2015 at 9:40 PM, Orion Poplawski
or...@cora.nwra.com mailto:or...@cora.nwra.com
mailto:or...@cora.nwra.com mailto:or...@cora.nwra.com wrote:

 On 04/20/2015 09:32 PM, Dave Johansen wrote:

 I just noticed that the version of cmake that comes
with RHEL 6 is
 currently 2.8.12.2 and the EPEL has a cmake28 package
that is at
 version
 2.8.11.2. I believe that RHEL 6 originally shipped with
cmake
 2.6 and
 updated in a later point release, but I have two questions:
 1) Is the cmake28 a duplicate and need to be removed?


 Yes.


Ok. Is this already being worked on? Or does a bugzilla need to be
created for it?


A quick search:

https://bugzilla.redhat.com/buglist.cgi?quicksearch=%3Acmake28list_id=3417355

turns up: https://bugzilla.redhat.com/show_bug.cgi?id=1159351

There is some question as to whether or not it is worth the pain to
retire.  I suppose you could also consider it pulling things away
from EPEL users.  If it is kept, it probably should be updated at least.


Would it be possible to create a Bugzilla and request that a virtual
provide for cmake28 be added to the cmake package in RHEL? I believe
that would allow the package in EPEL to be retired without requiring
changes to existing .spec files. I'm guessing that a cmake28 symlink
might be needed as well, but it still seems possible and a solution that
shouldn't have too much headache.


Sure, anything is possible :).   Although I don't see what the big deal 
about changing the EPEL packages would be.   If anything, it would just 
bring them back in line with the Fedora branches.



--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: [EPEL-devel] Thunderbird in epel7

2015-05-13 Thread Orion Poplawski
On 05/13/2015 03:19 PM, Orion Poplawski wrote:
 Shouldn't thunderbird be retired from epel7?
 
 Available Packages
 thunderbird.x86_64   31.4.0-1.el7 epel
 thunderbird.x86_64   31.4.0-1.el7 rhel-7-server-optional-rpms
 thunderbird.x86_64   31.5.0-2.el7_1   rhel-7-server-optional-rpms
 

Or is it there for ppc64 support?  In which case shouldn't it be updated?  And
it should have a release with a leading 0 as indicated
https://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages


-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: [EPEL-devel] Help understanding failing Koji build

2015-05-09 Thread Orion Poplawski

On 05/08/2015 11:36 PM, Taylor Braun-Jones wrote:

Moving thread to this list (previously on de...@lists.fedoraproject.org
mailto:de...@lists.fedoraproject.org)

On Fri, May 8, 2015 at 6:11 PM, Taylor Braun-Jones
tay...@braun-jones.org mailto:tay...@braun-jones.org wrote:

On Fri, May 8, 2015 at 4:26 PM, Orion Poplawski or...@cora.nwra.com
mailto:or...@cora.nwra.com wrote:

suitesparse was not properly retired in EPEL.  It's being fixed
now.  Should
be working once the next EL6 repo gen is complete, hopefully 30
minutes or so.


Thanks! I'll try it when I get back on network that is not behind an
HTTP proxy (the HTTP proxy support in fedpkg is broken[1])


So x86_64 and i686 are fixed now - thanks. But ppc64 has the same
problem. From:

https://kojipkgs.fedoraproject.org//work/tasks/4419/9694419/root.log

...
DEBUG util.py:388:  Getting requirements for ceres-solver-1.10.0-4.el6.src
DEBUG util.py:388:   -- cmake28-2.8.11.2-1.el6.ppc64
DEBUG util.py:388:   -- eigen3-devel-3.2.3-1.el6.noarch
DEBUG util.py:388:  Error: No Package found for suitesparse-devel = 3.4.0-9
DEBUG util.py:499:  Child return code was: 1


I'm actually not clear how Koji/mock do ppc64 builds at all since CentOS
does not exist for ppc64.


So, the first thing to clarify is that EPEL builds against RHEL, not 
CentOS.  And unfortunately RHEL ppc64 is missing some packages as well, 
suitesparse may be one of them.  I'll let someone who has direct access 
confirm.


Choices are:

- Add ExcludeArch: ppc64 to ceres-solver
- Resurrect suitesparse in EPEL as a limited arch package:
https://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages




--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: [EPEL-devel] pam_mount for EPEL7 (and 6)

2015-04-27 Thread Orion Poplawski
On 04/27/2015 11:58 AM, Marco van Leeuwen wrote:
 Hi all,
 
 I am new to this list, so please feel free to point me to the proper channels
 in case this is not the right list/way to file a request.
 
 I am interested in using pam_mount on an EL7 based system (scientific linux
 7). I've been playing a bit with the available spec files etc, and it looks
 like this will just work based on the existing packages/spec files for Fedora:
 I managed to build the rpm on my system and am currently using it. I would be
 happy to test new version when needed etc.

File a bug request for an EPEL7 branch against the needed packages.  If you
are packager, indicate your willingness to help or be the primary maintainer
if needed.


-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: [EPEL-devel] cmake and cmake28 in RHEL 6?

2015-04-20 Thread Orion Poplawski

On 04/20/2015 09:32 PM, Dave Johansen wrote:

I just noticed that the version of cmake that comes with RHEL 6 is
currently 2.8.12.2 and the EPEL has a cmake28 package that is at version
2.8.11.2. I believe that RHEL 6 originally shipped with cmake 2.6 and
updated in a later point release, but I have two questions:
1) Is the cmake28 a duplicate and need to be removed?


Yes.


2) I'm working on packaging cppformat and on RHEL 6 when I build with
cmake28 everything works out of the box, but with cmake I have to add
-DCMAKE_SKIP_RPATH=OFF to get the linker to work properly?

Is #2 an error/incorrect assumption in the cmake setup for cppformat? Or
is it something wrong in the system cmake that is correct in cmake28?


It's a (longstanding) bug in the RHEL cmake package:
https://bugzilla.redhat.com/show_bug.cgi?id=640672



Thanks,
Dave


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




--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: [EPEL-devel] broken PPC64 libxml2-devel?

2015-04-01 Thread Orion Poplawski
On 04/01/2015 09:26 AM, Ken Dreyer wrote:
 On my PPC64 build of Ceph today [1], I'm seeing this really odd error
 regarding libxml2-devel:
 
 from root.log:
 ...
 DEBUG util.py:388:  Error: Package: libxml2-devel-2.9.1-5.el7_1.2.ppc (build)
 DEBUG util.py:388: Requires: libxml2.so.2
 DEBUG util.py:388:   You could try using --skip-broken to work around
 the problem
 DEBUG util.py:388:   You could try running: rpm -Va --nofiles --nodigest
 
 Is this a problem in EPEL, or in RHEL?
 
 - Ken
 
 [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=9393202

It's odd that it is trying to install libxml2-devel.ppc instead of
libxml2-devel.ppc64.  Perhaps an issue with the EPEL repos.


-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: [EPEL-devel] EPEL packages, CentOS packages

2015-03-31 Thread Orion Poplawski

On 03/31/2015 05:17 AM, Anssi Johansson wrote:

As of now, the following packages are in EPEL, but the same package also
exists in CentOS.

--- CentOS5 vs EPEL5
cmake


Was not properly retired. Fixed.  Thanks.


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


[EPEL-devel] Heads up: glib2 update in RHEL 7.1

2015-03-24 Thread Orion Poplawski
RHEL 7.1 updates glib2 from 2.36.3 to 2.40.0.  This adds a number of symbols.
 Unfortunately glib2 does not appear to be using symbol versioning so no
automatic rpm provides/requires are added to avoid incompatibilities.  This is
particularly an issue in times like these between the RHEL point release and
until CentOS, ScientificLinux, et. al. release their updates. This has already
hit one user of qtwebkit:

https://bugzilla.redhat.com/show_bug.cgi?id=1202735

You may want to make sure your glib2 using packages end up with a requires
glib2 = 2.40.0.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: [EPEL-devel] Python 3 discussion

2015-03-03 Thread Orion Poplawski
On 03/03/2015 06:31 AM, Bohuslav Kabrda wrote:
 Today, I've made some changes to the proposal to accomodate comments from the 
 previous meeting and from discussion on this list. The diff is here:
 
 https://fedoraproject.org/w/index.php?title=User%3ABkabrda%2FEPEL7_Python3diff=405180oldid=404782
 
 I'd appreciate comments, I hope I made it clearer and more explanatory.
 
 Thanks for your comments,
 Slavek
 ___

Can we add the proper _sitelib / _sitearch macros to the example spec file?
Thanks.


-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: [EPEL-devel] Python 3 discussion

2015-03-03 Thread Orion Poplawski
On 03/03/2015 08:35 AM, Kevin Fenzi wrote:
 On Tue, 3 Mar 2015 07:46:00 -0500 (EST)
 Bohuslav Kabrda bkab...@redhat.com wrote:
 
 ^ Is this step part of a coordinated mass-rebuild, or is this just a
 period of time after we make the announcement: Hey Packagers: be
 sure to rebuild for python35?

 That's a good question. I guess we should standardize how this will
 be done. Something like:
 - there's an announcement on epel-devel that python35 is the main
 python3 and packagers should rebuild their packagers (and users
 their apps/scripts/...)
 - wait for a week (two?)
 - open bugs for packages that haven't been rebuilt during the
 previous week and get them fixed ASAP
 
 I'd say just doing the mass rebuild by a provenpackager or the like
 would be easier than filing bugs and waiting. 

Yeah, just do the builds and be done with it.  Will need to get built in dep
order.

 Also, we need to coordinate the update with them in it... ideally they
 would all be in the same update?

That's seem sure to crash bodhi :)

As long as deps are pushed out in the right order things would be okay.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: [EPEL-devel] Python 3 discussion

2015-03-02 Thread Orion Poplawski

On 03/02/2015 05:11 AM, Dan Callaghan wrote:


Is there any reason why we shouldn't just upgrade applications to the
python35-* stack straight away, by providing python3-*?



The main issue here is that EPEL doesn't have releases, so there is no 
way to take time to build everything and then push it out as a group.



--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: [EPEL-devel] Python 3 discussion

2015-03-02 Thread Orion Poplawski
 would 
always provide that, so it wouldn't migrate.  Now I get it.


Had to work that one out.


What about all of the old python34 packages left on their systems after
retirement?  Is there some way they can get cleaned up automatically?


I'm not sure about that... and I'm also not sure we want to do that, people may 
still want to keep these around for their own non-system applications to 
migrate.

Thanks a lot for this discussion,
Slavek


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com

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




--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


[EPEL-devel] distribution component in bugzilla

2015-02-27 Thread Orion Poplawski
Could we get a Distribution component for Fedora EPEL in Bugzilla? 
Might be useful for things like 
https://bugzilla.redhat.com/show_bug.cgi?id=1197264


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


[EPEL-devel] Python 3 discussion

2015-02-27 Thread Orion Poplawski
This is a followup to the EPEL IRC meeting discussion about python 3.  I had a
couple questions which led me to take Slavek's excellent work and try some
changes here: https://fedoraproject.org/wiki/User:Orion/EPEL7_Python3

Main ideas:
- (bikeshedding) - I didn't like the wording other, so I went with next.
- I didn't like having to toggle a macro in the spec files, I'm lazy
- What happens on the user's end?

So:

Lifecycle of python3X stacks, rebuilding:

when a new python3X+1 is built in EPEL - let's say that there is python34
and python35 has just been introduced:
A new python3-pkgversion-macros is build defining the %python3_next*
macros.
(scripted) mass rebuild is run to build as much of the new stack
possible automatically.
At some point /usr/bin/python3 is switched from python34 to python35.
at a certain point at time an announcement is made that python34 is to
be retired and python35 is to be *the* one. At this point:
python3-pkgversion-macros is rebuilt removing the %python3_next*
macros.
python35 is rebuilt defining the normal %python3_* macros
all python34 packages are retired

At this point all packages build just python35-X subpackages



What I still don't understand is what this looks like on the user end, how do
they go from 34 to 35?  For app users (#!/usr/bin/python3), it seems like this
should be as automatic as possible.  So shouldn't they still use
/usr/bin/python3 rather than /usr/bin/python3X so they get updated 
automatically?

What about all of the old python34 packages left on their systems after
retirement?  Is there some way they can get cleaned up automatically?

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: [EPEL-devel] How can I commit a new package to EPEL5?

2015-01-27 Thread Orion Poplawski

On 01/27/2015 08:21 PM, Tetsuya Morimoto wrote:

For EPEL5, we can install python26 packages from epel repository.

http://fedoraproject.org/wiki/Python26


If I read the messages correctly, I believe this will be going away soon.



It would be nice if we can install python3 (python33 or python34) as
same as python26.


I'm sure it would be, but EL5 is OLD at this point and not getting much 
love in the volunteer space.


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: [EPEL-devel] Fwd: Re: Fwd: Re: spice-html5 for EL7

2014-12-17 Thread Orion Poplawski
On 12/17/2014 08:17 AM, Sandro Bonazzola wrote:
 Can anybody grant him permission?

Well, Eduardo Javier Echeverria Alvarado (echevemaster) would be correct
person to do it.  Not sure if anyone else can.

Looks like the branch request for epel7 was not processed correctly.
https://bugzilla.redhat.com/show_bug.cgi?id=910793#c33

 
   Messaggio Inoltrato 
 Oggetto: Re: Fwd: Re: [EPEL-devel] spice-html5 for EL7
 Data: Wed, 17 Dec 2014 09:16:09 -0600
 Mittente: Jeremy White jwh...@codeweavers.com
 A: Sandro Bonazzola sbona...@redhat.com
 
 Yes, and when I do that, I get permission denied, and all the evidence
 is that on this page:
   https://admin.fedoraproject.org/pkgdb/package/spice-html5/
 I do not have permission.
 
 I have applied for permission, and no one has granted it, and everyone
 we have asked seems to ignore that question.
 
 Cheers,
 
 Jeremy
 
 On 12/17/2014 09:13 AM, Sandro Bonazzola wrote:



   Messaggio Inoltrato 
 Oggetto: Re: [EPEL-devel] spice-html5 for EL7
 Data: Wed, 17 Dec 2014 08:04:48 -0700
 Mittente: Kevin Fenzi ke...@scrye.com
 Rispondi-a: EPEL Development List epel-devel@lists.fedoraproject.org
 Organizzazione: Scrye, INC
 A: epel-devel@lists.fedoraproject.org

 On Wed, 17 Dec 2014 10:27:23 +0100
 Sandro Bonazzola sbona...@redhat.com wrote:

 Hi,
 a few weeks ago I contacted jwhite, packager of spice-html5 package
 for Fedora and EPEL 6 asking a port to EPEL 7. He built the package
 http://kojipkgs.fedoraproject.org/packages/spice-html5/0.1.5/1.el7/
 but the build is not in bodhi:
 https://admin.fedoraproject.org/updates/search/spice-html5
 he had trouble trying to tag / commit the build there.
 Anybody can help him with this last step of the process?

 bodhi (the updates system) takes care of all of that. They simply need
 to submit the new build as part of a new update. Either with 'fedpkg
 update' or using the web interface.

 kevin




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


-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: [EPEL-devel] Orphaning EPEL-7 perl-TeX-Hyphen

2014-12-16 Thread Orion Poplawski

On 12/16/2014 01:37 AM, Jan Pazdziora wrote:

On Mon, Dec 15, 2014 at 07:13:48PM -0700, Stephen John Smoogen wrote:

The following packages have been orphaned or depend on orphaned packages
over 6 weeks. They will be removed on Wednesday 2014-12-17 unless packagers
take them.


[...]


perl-TeX-Hyphen


Looking at

https://admin.fedoraproject.org/pkgdb/package/perl-TeX-Hyphen/

the package has psabata as the contact for Fedora devel, Fedora 21,


I think he picked up a bunch of perl packages just after the email was sent.


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: [EPEL-devel] REMINDER: Orphaned EPEL-6 packages going away on Wednesday 2014-12-17

2014-12-16 Thread Orion Poplawski
On 12/16/2014 11:08 AM, Stephen John Smoogen wrote:
 
 
 On 15 December 2014 at 19:10, Stephen John Smoogen smo...@gmail.com
 mailto:smo...@gmail.com wrote:
 
 
 The following packages have been orphaned or depend on orphaned packages
 over 6 weeks. They will be removed on Wednesday 2014-12-17 unless
 packagers take them.
 
 
 abi-compliance-checker

It doesn't look like you are checking dates:

Depending on: ccache (16), status change: 2014-12-12 (0 weeks ago)
abi-compliance-checker (maintained by: orion)
abi-compliance-checker-1.99.9-1.el6.noarch requires ccache = 
3.1.6-2.el6

ccache was just orphaned.


-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: [EPEL-devel] Proposal for Python 3 packaging in EPEL 7

2014-12-11 Thread Orion Poplawski
Yeah, now that it all comes back to me, naming conflicts with SCLs is probably
the biggest issue.  The fact SCLs weren't given a prefix is a major issue for
many possible EPEL packages.

On 12/11/2014 09:46 AM, Carl George wrote:
 One thing to look out for would be SCL mod_wsgi.  In the SCL world they name
 it python33-mod_wsgi.  Most modules are %{SCL}-python-%{module}, but mod_wsgi
 is unique.  To avoid conflicts, the IUS project has committed to using the
 suffix u on our packages going forward (python34u-mod_wsgi).  Are you
 concerned at all about naming conflicts with SCL packages?
 
 I added the IUS coredev mailing list to the CC line.
 
 Carl George
 IUS Community Project
 
 --
 *From:* epel-devel-boun...@lists.fedoraproject.org
 [epel-devel-boun...@lists.fedoraproject.org] on behalf of Stephen John Smoogen
 [smo...@gmail.com]
 *Sent:* Wednesday, December 10, 2014 02:24 PM
 *To:* EPEL Development List
 *Subject:* Re: [EPEL-devel] Proposal for Python 3 packaging in EPEL 7
 
 
 
 On 10 December 2014 at 03:48, Bohuslav Kabrda bkab...@redhat.com
 mailto:bkab...@redhat.com wrote:
 
 Hi all,
 I know I've been promising this for quite some time to several people, so
 I finally managed to put together a proposal for packaging Python 3 in
 EPEL 7 (it'd also scale to EPEL 6 for that matter).
 I've created a wiki page [1] with the proposal and I'd like to hear
 comments and thoughts on it. There are some TODOs and variants in few
 places - I'd like to hear your opinions on these, or perhaps suggestions
 on better approaches.
 I'll create new documents with the updated proposal at some points during
 the discussion, so that people can easily see where the proposal is going
 without having to compare wiki revisions.
 
 Is there any other list/interested parties that should be put in CC of
 this mail? If so, please feel free to respond and do that yourself.
 
 
 THis proposal looks good at first blush. I think the time for retirement of
 python3X to python3(X+1) can be anywhere from 6 weeks to 2 months (if that
 isn't too long).
 
  
 
 Thanks!
 
 --
 Regards,
 Slavek Kabrda
 
 [1] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3
 ___
 epel-devel mailing list
 epel-devel@lists.fedoraproject.org 
 mailto:epel-devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/epel-devel
 
 
 
 
 -- 
 Stephen J Smoogen.
 
 
 
 ___
 epel-devel mailing list
 epel-devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/epel-devel
 


-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


  1   2   >