I have not created any bugzila's for these yet. I have not checked to see if these are in -testing already. This is just a list showing what packages currently do not install from EPEL 7.
airinv airrac airtsp drawtiming opentrep perl-Image-SubImageFind perl-X11-GUITest php-magickwand python-jenkins-job-builder ripright rmol sevmgr simcrs simfqt slack-cleaner spyder stdair trademgen travelccm
This is a much smaller list than in the past. I appreciate everyone's efforts to keep EPEL7 an installable repo. Troy
On 04. 05. 20 18:11, Troy Dawson wrote:
I have not created any bugzila's for these yet. I have not checked to see if these are in -testing already. This is just a list showing what packages currently do not install from EPEL 7.
airinv airrac airtsp drawtiming opentrep perl-Image-SubImageFind perl-X11-GUITest php-magickwand python-jenkins-job-builder ripright rmol sevmgr simcrs simfqt slack-cleaner spyder stdair trademgen travelccm
This is a much smaller list than in the past. I appreciate everyone's efforts to keep EPEL7 an installable repo.
I don't know how that list was assembled, but I know about at least about 1 more package (already has a bugzilla open):
$ mock -r epel-7-x86_64 install python34-requests ... Resolving Dependencies --> Running transaction check ---> Package python34-requests.noarch 0:2.14.2-2.el7 will be installed --> Processing Dependency: python(abi) = 3.4 for package: python34-requests-2.14.2-2.el7.noarch --> Processing Dependency: python34-chardet for package: python34-requests-2.14.2-2.el7.noarch --> Processing Dependency: python34-idna for package: python34-requests-2.14.2-2.el7.noarch --> Processing Dependency: python34-urllib3 for package: python34-requests-2.14.2-2.el7.noarch --> Running transaction check ---> Package python34.x86_64 0:3.4.10-4.el7 will be installed --> Processing Dependency: python34-libs(x86-64) = 3.4.10-4.el7 for package: python34-3.4.10-4.el7.x86_64 --> Processing Dependency: libpython3.4m.so.1.0()(64bit) for package: python34-3.4.10-4.el7.x86_64 ---> Package python34-chardet.noarch 0:3.0.4-1.el7 will be installed ---> Package python34-idna.noarch 0:2.7-2.el7 will be installed ---> Package python34-urllib3.noarch 0:1.25.6-1.el7 will be installed --> Processing Dependency: python34-six >= 1.12.0 for package: python34-urllib3-1.25.6-1.el7.noarch --> Processing Dependency: python34-pysocks for package: python34-urllib3-1.25.6-1.el7.noarch --> Running transaction check ---> Package python34-libs.x86_64 0:3.4.10-4.el7 will be installed ---> Package python34-pysocks.noarch 0:1.6.8-6.el7 will be installed ---> Package python34-urllib3.noarch 0:1.25.6-1.el7 will be installed --> Processing Dependency: python34-six >= 1.12.0 for package: python34-urllib3-1.25.6-1.el7.noarch --> Finished Dependency Resolution Error: Package: python34-urllib3-1.25.6-1.el7.noarch (epel) Requires: python34-six >= 1.12.0 You could try using --skip-broken to work around the problem
On Mon, May 4, 2020 at 9:35 AM Miro Hrončok mhroncok@redhat.com wrote:
On 04. 05. 20 18:11, Troy Dawson wrote:
I have not created any bugzila's for these yet. I have not checked to see if these are in -testing already. This is just a list showing what packages currently do not install from EPEL 7.
airinv airrac airtsp drawtiming opentrep perl-Image-SubImageFind perl-X11-GUITest php-magickwand python-jenkins-job-builder ripright rmol sevmgr simcrs simfqt slack-cleaner spyder stdair trademgen travelccm
This is a much smaller list than in the past. I appreciate everyone's efforts to keep EPEL7 an installable repo.
I don't know how that list was assembled, but I know about at least about 1 more package (already has a bugzilla open):
$ mock -r epel-7-x86_64 install python34-requests ... Resolving Dependencies --> Running transaction check ---> Package python34-requests.noarch 0:2.14.2-2.el7 will be installed --> Processing Dependency: python(abi) = 3.4 for package: python34-requests-2.14.2-2.el7.noarch --> Processing Dependency: python34-chardet for package: python34-requests-2.14.2-2.el7.noarch --> Processing Dependency: python34-idna for package: python34-requests-2.14.2-2.el7.noarch --> Processing Dependency: python34-urllib3 for package: python34-requests-2.14.2-2.el7.noarch --> Running transaction check ---> Package python34.x86_64 0:3.4.10-4.el7 will be installed --> Processing Dependency: python34-libs(x86-64) = 3.4.10-4.el7 for package: python34-3.4.10-4.el7.x86_64 --> Processing Dependency: libpython3.4m.so.1.0()(64bit) for package: python34-3.4.10-4.el7.x86_64 ---> Package python34-chardet.noarch 0:3.0.4-1.el7 will be installed ---> Package python34-idna.noarch 0:2.7-2.el7 will be installed ---> Package python34-urllib3.noarch 0:1.25.6-1.el7 will be installed --> Processing Dependency: python34-six >= 1.12.0 for package: python34-urllib3-1.25.6-1.el7.noarch --> Processing Dependency: python34-pysocks for package: python34-urllib3-1.25.6-1.el7.noarch --> Running transaction check ---> Package python34-libs.x86_64 0:3.4.10-4.el7 will be installed ---> Package python34-pysocks.noarch 0:1.6.8-6.el7 will be installed ---> Package python34-urllib3.noarch 0:1.25.6-1.el7 will be installed --> Processing Dependency: python34-six >= 1.12.0 for package: python34-urllib3-1.25.6-1.el7.noarch --> Finished Dependency Resolution Error: Package: python34-urllib3-1.25.6-1.el7.noarch (epel) Requires: python34-six >= 1.12.0 You could try using --skip-broken to work around the problem
Huh ... you are correct. python34-requests starts out on the overall list, and as I filter things down to package names, it disapears. Hold time, there might be more added to this list.
On Mon, May 04, 2020 at 09:11:00AM -0700, Troy Dawson wrote:
I have not created any bugzila's for these yet. I have not checked to see if these are in -testing already. This is just a list showing what packages currently do not install from EPEL 7.
perl-Image-SubImageFind perl-X11-GUITest
I can install these two packages. They were built 6 years ago. Can you provide more details.
The only issue with them I can see is that they were retired in Fedora master.
-- Petr
On Tue, May 5, 2020 at 12:23 AM Petr Pisar ppisar@redhat.com wrote:
On Mon, May 04, 2020 at 09:11:00AM -0700, Troy Dawson wrote:
I have not created any bugzila's for these yet. I have not checked to see if these are in -testing already. This is just a list showing what packages currently do not install from EPEL 7.
perl-Image-SubImageFind
- nothing provides libMagickCore.so.5()(64bit) needed by perl-Image-SubImageFind-0.03-1.el7.x86_64 - nothing provides libMagick++.so.5()(64bit) needed by perl-Image-SubImageFind-0.03-1.el7.x86_64
perl-X11-GUITest
perl-X11-GUITest-0.28-1.el7.x86_64 requires perl(Image::SubImageFind), but none of the providers can be installed
I can install these two packages. They were built 6 years ago. Can you provide more details.
If you are running RHEL or CentOS 7.8 then you cannot install them due to the updated ImageMagick.
It looks like you just need to rebuild perl-Image-SubImageFind and both packages should be able to install.
Troy
On Tue, May 05, 2020 at 06:35:14AM -0700, Troy Dawson wrote:
On Tue, May 5, 2020 at 12:23 AM Petr Pisar ppisar@redhat.com wrote:
On Mon, May 04, 2020 at 09:11:00AM -0700, Troy Dawson wrote:
I have not created any bugzila's for these yet. I have not checked to see if these are in -testing already. This is just a list showing what packages currently do not install from EPEL 7.
perl-Image-SubImageFind
- nothing provides libMagickCore.so.5()(64bit) needed by
perl-Image-SubImageFind-0.03-1.el7.x86_64
- nothing provides libMagick++.so.5()(64bit) needed by
perl-Image-SubImageFind-0.03-1.el7.x86_64
perl-X11-GUITest
perl-X11-GUITest-0.28-1.el7.x86_64 requires perl(Image::SubImageFind), but none of the providers can be installed
I can install these two packages. They were built 6 years ago. Can you provide more details.
If you are running RHEL or CentOS 7.8 then you cannot install them due to the updated ImageMagick.
I see. ImageMagick-6.9.10.68 released in RHEL 7.8 broke ABI. But I was able to install them because RHEL does not remove old packages from repositories and my package manager simply chose the older compatible build (because I did not have installed ImageMagick before).
It looks like you just need to rebuild perl-Image-SubImageFind and both packages should be able to install.
I will rebuild them.
-- Petr
On Tue, May 05, 2020 at 04:00:28PM +0200, Petr Pisar wrote:
On Tue, May 05, 2020 at 06:35:14AM -0700, Troy Dawson wrote:
On Tue, May 5, 2020 at 12:23 AM Petr Pisar ppisar@redhat.com wrote:
On Mon, May 04, 2020 at 09:11:00AM -0700, Troy Dawson wrote:
I have not created any bugzila's for these yet. I have not checked to see if these are in -testing already. This is just a list showing what packages currently do not install from EPEL 7.
perl-Image-SubImageFind
- nothing provides libMagickCore.so.5()(64bit) needed by
perl-Image-SubImageFind-0.03-1.el7.x86_64
- nothing provides libMagick++.so.5()(64bit) needed by
perl-Image-SubImageFind-0.03-1.el7.x86_64
perl-X11-GUITest
perl-X11-GUITest-0.28-1.el7.x86_64 requires perl(Image::SubImageFind), but none of the providers can be installed
I can install these two packages. They were built 6 years ago. Can you provide more details.
If you are running RHEL or CentOS 7.8 then you cannot install them due to the updated ImageMagick.
I see. ImageMagick-6.9.10.68 released in RHEL 7.8 broke ABI. But I was able to install them because RHEL does not remove old packages from repositories and my package manager simply chose the older compatible build (because I did not have installed ImageMagick before).
It looks like you just need to rebuild perl-Image-SubImageFind and both packages should be able to install.
I will rebuild them.
Fixed with perl-Image-SubImageFind-0.03-2.el7.
-- Petr
epel-devel@lists.fedoraproject.org
-
Miro Hrončok -
Petr Pisar -
Troy Dawson