#17: 2014-10-09 EPEL-7 orphan list
-----------------------------+----------------------------
Reporter: smooge | Owner: epel-wranglers
Type: defect | Status: new
Priority: major | Milestone:
Component: Package request | Version:
Keywords: |
-----------------------------+----------------------------
Thanks to Till for generating this.
{{{
More
29 of 36  

EPEL Orphan packages in epel7
Inbox
x
Fed-DT-List
x

opensource(a)till.name via lists.fedoraproject.org
7 Oct (2 days ago)

to epel-devel
The following packages are orphaned and might be retired eventually,
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
Note: If you received this mail directly you (co)maintain one of the
affected
packages or a package that depends on one. Please orphan the affected
package or
retire your package to avoid broken dependencies.
Package (co)maintainers
===========================================================================
SDL_mixer orphan, sdz
golang-github-gorilla-context orphan, golang-sig, lsm5, mattdm, vbatts
golang-github-gorilla-mux orphan, golang-sig, lsm5, mattdm, vbatts
golang-github-kr-pty orphan, golang-sig, lsm5, mattdm
golang-googlecode-net orphan, golang-sig, lsm5, mattdm, vbatts
golang-googlecode-sqlite orphan, golang-sig, lsm5, vbatts
libev orphan
mikmod orphan, s4504kr, sdz
mysql-connector-python orphan
ocaml-lablgl orphan, peter, rjones
perl-Log-Log4perl orphan, jplesnik, mmaslano, ppisar,
psabata
perl-Marpa-XS orphan, jplesnik, lkundrak, mmaslano,
perl-
sig, ppisar, psabata
perl-RPM2 orphan, jplesnik, mmaslano, ppisar,
psabata
pkcs11-helper orphan
python-gunicorn orphan, dcallagh
python-itsdangerous orphan, branto, dcallagh
python-paver orphan, lmacken, toshio
python-requests orphan, sagarun, terminalmage
python-urllib3 orphan, ralph, sagarun
qstat orphan
The following packages require above mentioned packages:
}}}
--
Ticket URL: <https://fedorahosted.org/epel/ticket/17>
Extra Packages for Enterprise Linux <https://fedoraproject.org/wiki/EPEL>
Extra Packages for Enterprise Linux
#2: How to handle systemd service activation defaults in EPEL7
----------------------------+----------------------------
Reporter: orion | Owner: epel-wranglers
Type: task | Status: new
Priority: major | Milestone: EPEL-7
Component: Policy problem | Version:
Keywords: |
----------------------------+----------------------------
See https://bugzilla.redhat.com/show_bug.cgi?id=1141609
According to
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Macroized_script…
one does something like:
%post
%systemd_post apache-httpd.service
%preun
%systemd_preun apache-httpd.service
and some other package (systemd in Fedora, rhel-release in RHEL) contains
a list of presets as to what services get enabled by default. Where do we
want that? I don't think we want to update epel-release that often.
--
Ticket URL: <https://fedorahosted.org/epel/ticket/2>
Extra Packages for Enterprise Linux <https://fedoraproject.org/wiki/EPEL>
Extra Packages for Enterprise Linux
#28: Broken buildSRPMFromSCM in EPEL 5 koji
-----------------------------+----------------------------
Reporter: ellert | Owner: epel-wranglers
Type: defect | Status: new
Priority: major | Milestone:
Component: Package request | Version:
Keywords: |
-----------------------------+----------------------------
See e.g. https://koji.fedoraproject.org/koji/taskinfo?taskID=8452446
The exact same build worked a few days ago (right after the GitPython
hickup was fixed):
https://koji.fedoraproject.org/koji/taskinfo?taskID=8428548
The error message says "BuildError: error retrieving sources." - i.e. the
"fedpkg sources" command fails.
According to root.log in the two builds fedpkg was installed when
preparing buildSRPMFromSCM for the successful build, but not for the
failing one.
Compare:
{{{
DEBUG util.py:283: Installing for group install "srpm-build":
DEBUG util.py:283: bash x86_64 3.2-33.el5_11.4
build 1.8 M
DEBUG util.py:283: buildsys-macros noarch 5-4.el5
build 2.5 k
DEBUG util.py:283: cvs x86_64 1.11.22-11.el5_8.1
build 738 k
DEBUG util.py:283: fedpkg noarch 0.5.9.2-1.el5
build 107 k
DEBUG util.py:283: gnupg x86_64 1.4.5-18.el5_10.1
build 1.8 M
DEBUG util.py:283: make x86_64 1:3.81-3.el5
build 471 k
DEBUG util.py:283: redhat-release x86_64 5Server-5.11.0.2
build 63 k
DEBUG util.py:283: redhat-rpm-config noarch 8.0.45-32.el5
build 54 k
DEBUG util.py:283: rpm-build x86_64 4.4.2.3-36.el5_11
build 304 k
DEBUG util.py:283: Installing for dependencies:
}}}
and
{{{
DEBUG util.py:283: Installing:
DEBUG util.py:283: bash ppc 3.2-33.el5_11.4
build 1.8 M
DEBUG util.py:283: buildsys-macros noarch 5-4.el5
build 2.5 k
DEBUG util.py:283: cvs ppc 1.11.22-11.el5_8.1
build 753 k
DEBUG util.py:283: gnupg ppc 1.4.5-18.el5_10.1
build 1.9 M
DEBUG util.py:283: make ppc 1:3.81-3.el5
build 476 k
DEBUG util.py:283: redhat-release ppc 5Server-5.11.0.2
build 63 k
DEBUG util.py:283: redhat-rpm-config noarch 8.0.45-32.el5
build 54 k
DEBUG util.py:283: rpm-build ppc 4.4.2.3-36.el5_11
build 314 k
DEBUG util.py:283: Installing for dependencies:
}}}
--
Ticket URL: <https://fedorahosted.org/epel/ticket/28>
EPEL <https://fedoraproject.org/wiki/EPEL>
Extra Packages for Enterprise Linux
#24: make EPEL trac e-mail subject shorter
-----------------------------+----------------------------
Reporter: till | Owner: epel-wranglers
Type: defect | Status: new
Priority: major | Milestone:
Component: Package request | Version:
Keywords: |
-----------------------------+----------------------------
Currently mails from EPEL trac contain a very long tag ({{{[Extra Packages
for Enterprise Linux]}}}) this makes the actual subject harder to read for
example on mobile devices, therefore please make it just {{{EPEL}}} or
{{{EPEL Trac}}}.
--
Ticket URL: <https://fedorahosted.org/epel/ticket/24>
Extra Packages for Enterprise Linux <https://fedoraproject.org/wiki/EPEL>
Extra Packages for Enterprise Linux
#15: Who retired libgeotiff
-----------------------------+----------------------------
Reporter: smooge | Owner: epel-wranglers
Type: defect | Status: new
Priority: major | Milestone:
Component: Package request | Version:
Keywords: |
-----------------------------+----------------------------
The libgeotiff package was retired for some reason out EPEL but not by the
maintainers? [Probably a quick what do we do with this and move on.]
{{{
EPEL RHEL6 libgeotiff package missing
Inbox
x
Fed-DT-List
x

Mika Heiskanen mika.heiskanen(a)fmi.fi via lists.fedoraproject.org
6 Oct (3 days ago)

to epel-devel, tuomo.lauri
Hello,
It seems like the libgeotiff package has been removed from the RHEL6
repository. We could not find any news on the subject. Does anyone
know if the package has been removed intentionally?
Our servers show the installed version to be as follows:
Name : libgeotiff
Arch : x86_64
Version : 1.2.5
Release : 5.el6
Size : 4.4 M
Repo : installed
From repo : epel
Summary : GeoTIFF format library
URL : http://www.remotesensing.org/geotiff/geotiff.html
Currently we cannot install some software to our new servers due to the
missing libgeotiff dependency. For example "yum install gdal" fails.
Regards,
Mika Heiskanen / FMI
_______________________________________________
epel-devel mailing list
epel-devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Till Maas via lists.fedoraproject.org
6 Oct (3 days ago)

to orion, EPEL, tuomo.lauri
Hi,
On Mon, Oct 06, 2014 at 10:24:30AM +0300, Mika Heiskanen wrote:
> It seems like the libgeotiff package has been removed from the RHEL6
> repository. We could not find any news on the subject. Does anyone
> know if the package has been removed intentionally?
the process to remove the package was started before May this year but
it was not finished (the package was retired in packagedb:
https://admin.fedoraproject.org/pkgdb/package/libgeotiff/)
Before recently, a second step was required to actually remove the
package from the repos. This is now automated, which is why the package
is now not available via the mirrors. I do not know how retired the
package, because it cannot be easily queried right now, but it might
have been Orion, who built the package the last time.
> Our servers show the installed version to be as follows:
>
> Name : libgeotiff
> Arch : x86_64
> Version : 1.2.5
> Release : 5.el6
> Currently we cannot install some software to our new servers due to the
> missing libgeotiff dependency. For example "yum install gdal" fails.
You can still download the package from kojipkgs if it helps you now:
https://kojipkgs.fedoraproject.org//packages/libgeotiff/1.2.5/5.el6/x86_64/…
However it is not maintained currently in EPEL 5 and 6. To get it back
into EPEL 6 someone needs to step up as a new maintainer and ask for a
re-review:
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#C…
Regards


Orion Poplawski via lists.fedoraproject.org
6 Oct (3 days ago)

to Devrim, Till, EPEL, tuomo.lauri
On 10/06/2014 10:39 AM, Till Maas wrote:
> Hi,
>
> On Mon, Oct 06, 2014 at 10:24:30AM +0300, Mika Heiskanen wrote:
>
>> It seems like the libgeotiff package has been removed from the RHEL6
>> repository. We could not find any news on the subject. Does anyone
>> know if the package has been removed intentionally?
>
> the process to remove the package was started before May this year but
> it was not finished (the package was retired in packagedb:
> https://admin.fedoraproject.org/pkgdb/package/libgeotiff/)
Don't think it was me. CC'ing Volker and Devrim.

}}}
--
Ticket URL: <https://fedorahosted.org/epel/ticket/15>
Extra Packages for Enterprise Linux <https://fedoraproject.org/wiki/EPEL>
Extra Packages for Enterprise Linux
Hi, epel List
In bug 1134624 [1] someone asked to build po4a for EPEL 7.
I miss some reading and po4a is only need to be build for ppc64 ,
because in meantime CentOS built it, but only for epel 7 not for 6 and
according Dominik Mierzejewski on comment #23 "... is part of CentOS
main distribution, which is x86_64 only". So when packages came from
CentOS they are x86_64 only and this happens with po4a .
By guidelines in comment #34 , I shouldn't build it with a new version
which unfortunately happened, I built po4a-0.45 when CentOS build
po4a-0.44 , but in comment #39 I concluded that is a copy of Fedora
source which was completely out-date , so I think the best solution was
Centos updated it also . If not, we need remove po4a-0.45-3.el7 from
epel7 stable , which I haven't way/permissions to do it ...
Suggestions please ?
[1]
https://bugzilla.redhat.com/show_bug.cgi?id=1134624
Thanks,
--
Sérgio M. B.