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

[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] Fedora EPEL 6 updates-testing report

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 135  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b6c663378c   
unrtf-0.21.9-8.el6
  25  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-6bc3a525a2   
libmad-0.15.1b-26.el6


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

R-Rcpp-0.12.19-1.el6
R-littler-0.3.5-1.el6

Details about builds:



 R-Rcpp-0.12.19-1.el6 (FEDORA-EPEL-2018-f99404a56d)
 Seamless R and C++ Integration

Update Information:

Update to version 0.12.19
https://cran.r-project.org/web/packages/Rcpp/ChangeLog

ChangeLog:

* Mon Oct 22 2018 Mattias Ellert  - 0.12.19-1
- Update to 0.12.19
* Tue Jul 31 2018 Florian Weimer  - 0.12.18-2
- Rebuild with fixed binutils

References:

  [ 1 ] Bug #1641428 - Please update it to 0.12.19
https://bugzilla.redhat.com/show_bug.cgi?id=1641428




 R-littler-0.3.5-1.el6 (FEDORA-EPEL-2018-df2a340e4b)
 littler: R at the Command-Line via 'r'

Update Information:

New version 0.3.5  https://cran.r-project.org/web/packages/littler/ChangeLog

ChangeLog:

* Mon Oct 22 2018 Mattias Ellert  - 0.3.5-1
- New upstream release 0.3.5

___
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] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 135  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3835d39d1a   
unrtf-0.21.9-8.el7
  85  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f9d6ff695a   
bibutils-6.6-1.el7 ghc-hs-bibutils-6.6.0.0-1.el7 pandoc-citeproc-0.3.0.1-4.el7
  69  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d   
condor-8.6.11-1.el7
  41  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3492a96896   
myrepos-1.20180726-1.el7
  32  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-bc87c43cdd   
libbson-1.3.5-6.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-a9ac6a18d2   
libgit2-0.26.7-1.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-aa66b877bb   
mosquitto-1.5.3-1.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-d46b0aab32   
lighttpd-1.4.51-1.el7


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

R-Rcpp-0.12.19-1.el7
R-littler-0.3.5-1.el7
Zim-0.68-4.el7
caddy-0.11.0-3.el7
julietaula-montserrat-fonts-7.200-4.el7
milter-greylist-4.6.2-2.el7
python-lark-parser-0.6.4-2.el7
teeworlds-0.6.5-1.el7

Details about builds:



 R-Rcpp-0.12.19-1.el7 (FEDORA-EPEL-2018-ecefe585e2)
 Seamless R and C++ Integration

Update Information:

Update to version 0.12.19
https://cran.r-project.org/web/packages/Rcpp/ChangeLog

ChangeLog:

* Mon Oct 22 2018 Mattias Ellert  - 0.12.19-1
- Update to 0.12.19
* Tue Jul 31 2018 Florian Weimer  - 0.12.18-2
- Rebuild with fixed binutils

References:

  [ 1 ] Bug #1641428 - Please update it to 0.12.19
https://bugzilla.redhat.com/show_bug.cgi?id=1641428




 R-littler-0.3.5-1.el7 (FEDORA-EPEL-2018-588b50e47f)
 littler: R at the Command-Line via 'r'

Update Information:

New version 0.3.5  https://cran.r-project.org/web/packages/littler/ChangeLog

ChangeLog:

* Mon Oct 22 2018 Mattias Ellert  - 0.3.5-1
- New upstream release 0.3.5




 Zim-0.68-4.el7 (FEDORA-EPEL-2018-ea7b66372f)
 Desktop wiki & notekeeper

Update Information:

Update to 0.68

ChangeLog:

* Mon Oct 22 2018 Robin Lee  - 0.68-4
- Fix for epel7
* Thu Jul 19 2018 Robin Lee  - 0.68-3
- Use python2_sitelib macro (BZ#1603334)
* Thu Jul 12 2018 Fedora Release Engineering  - 0.68-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
* Thu Apr 26 2018 Iryna Shcherbina  - 0.68-2
- Update Python 2 dependency declarations to new packaging standards
  (See https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3)
* Mon Apr  2 2018 Robin Lee  - 0.68-1
- Update to 0.68
* Wed Feb  7 2018 Fedora Release Engineering  - 0.67-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Tue Jan 30 2018 Igor Gnatenko  - 0.67-3
- Remove obsolete scriptlets
* Wed Jul 26 2017 Fedora Release Engineering  - 0.67-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild




 caddy-0.11.0-3.el7 (FEDORA-EPEL-2018-960cae316e)
 HTTP/2 web server with automatic HTTPS

Update Information:

- Enable httpd_can_network_connect selinux boolean to connect to ACME endpoint
rhbz#1641158 - Define UDP 80/443 as selinux http_port_t for QUIC rhbz#1608548 -
Define TCP 5033 as selinux http_port_t for HTTP challenge rhbz#1641160

ChangeLog:

* Fri Oct 19 2018 Carl George  - 0.11.0-3
- Enable httpd_can_network_connect selinux boolean to connect to ACME endpoint 
rhbz#1641158
- Define UDP 80/443 as selinux http_port_t for QUIC rhbz#1608548
- Define TCP 5033 as selinux http_port_t for HTTP challenge rhbz#1641160
* Thu Jul 12 2018 Fedora Release Engineering  - 
0.11.0-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild

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

[Tuomo Soini]

On Fri, 19 Oct 2018 15:22:01 -0400
Stephen John Smoogen  wrote:

> 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-

I'd very much prefer python3- naming just because it would make
python3 packaging much more consistent with fedora.

But I'd want to point out that add problem to all packages currently
named as python3- (packages where python2 counterpart is part of
rhel).

Because python3- can't have sub-package named python3-.

-- 
Tuomo Soini 
Foobar Linux services
+358 40 5240030
Foobar Oy 
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] [Fwd: [includepkgs=devtoolset*] Re: Cannot find -latomic when building for epel7 aarch64]

[Sérgio Basto]

Hello, 

Moving this subject to epel-devel ML 

Generically where I find devtoolset howto(s) ? and what should be mock-
core-configs ? 

And I'm confused what difference of rh-eclipse46 and devtoolset-4 [1] ?

Thanks 
[1]
https://www.softwarecollections.org/en/scls/rhscl/rh-eclipse46/
https://www.softwarecollections.org/en/scls/rhscl/devtoolset-4/



 Forwarded Message 
From: Sérgio Basto 
Reply-to: Development discussions related to Fedora

To: Development discussions related to Fedora 
Subject: [includepkgs=devtoolset*] Re: Cannot find -latomic when
building for epel7 aarch64
Date: Mon, 22 Oct 2018 16:48:45 +0100

On Sat, 2018-10-20 at 13:03 -0400, Todd Zullinger wrote:
> Sérgio Basto wrote:
> > I had checked mock-core-config [1] , which are in use in copr (I
> > guess)
> > and can't enable developer tools .
> > But on koji runs well , can you review this ? please .
> > 
> > I could build azureus [4] on koji [2] which need eclipse-swt , but
> > not
> > on copr `Error: No Package found for rh-eclipse46-eclipse-swt >=
> > 3.5` 
> > Unfortunately I didn't have much time to dig it ... 
> 
> Packages from the SCL repos in mock-core-configs are
> restricted via the following config entry¹:
> 
> includepkgs=devtoolset*
> 
> That limit was not included in the initial koji
> configuration, but my understanding was that was going to be
> corrected.
> 
> The only packages allowed to be used (or more specifically,
> BuildRequired) from the SCL repos in EPEL are devtoolset*.
> (Feel free to follow up on epel-devel on that, as that's
> where the folks who know best are.)
> 
> ¹ https://github.com/rpm-software-management/mock/blob/devel/mock-cor
> e-configs/etc/mock/epel-7-x86_64.cfg#L62


Thank you for the reply 

I improve my spec [1], I'm using devtoolset-4, I could build and run
azureus on el7 but unfortunately, this collection is EOL since Dec
2017; so I don't know if it is a good test, anyway with actual mock-
core-configs we can't install dependencies (rh-java-common-jpackage-
utils and rh-java-common-runtime).
if I add to [sclo-rh] includepkgs=devtoolset*,rh* it works .

In resume [2] fails with: [3]

Thanks 

[1]
https://github.com/sergiomb2/azureus/commits/master

[2]
mock -r epel-7-x86_64 --install devtoolset-4-eclipse-swt

[3]
Problem: cannot install the best candidate for the job
  - nothing provides rh-java-common-runtime needed by devtoolset-4-
eclipse-swt-1:4.5.2-5.4.el7.x86_64


-- 
Sérgio M. B.
___
devel mailing list -- de...@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@list
s.fedoraproject.org
-- 
Sérgio M. B.
___
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