What is the current update policy for EPEL? The stated one seems to be
along the lines of "no major changes" (
http://fedoraproject.org/wiki/Updates_Policy ) but it seems more like
"whatever the packager is willing to maintain" is the actual policy.
I ask because a bugzilla was just opened against a package I maintain (
https://bugzilla.redhat.com/show_bug.cgi?id=1201808 ) and I wanted to know
how I should handle it.
Does it need to be closed as wontfix? Or should a "notice of upcoming major
update" policy be put in place to handle things like this?
Thanks,
Dave
#10: Unretire xerces-c
-----------------------------+----------------------------
Reporter: smooge | Owner: epel-wranglers
Type: task | Status: new
Priority: critical | Milestone:
Component: Package request | Version:
Keywords: |
-----------------------------+----------------------------
This package was accidently retired, and needs a full review to get back
in. Need a bugzilla ticket for getting it reviewed, and we will have an
epel-wrangler do as fast a re-review as possible to get it back in.
Further policy changes to deal with this in the future are in ticket #4
--
Ticket URL: <https://fedorahosted.org/epel/ticket/10>
Extra Packages for Enterprise Linux <https://fedoraproject.org/wiki/EPEL>
Extra Packages for Enterprise Linux
#21: EPEL Wrangler Request : Review python27
-----------------------------+----------------------------
Reporter: smooge | Owner: epel-wranglers
Type: defect | Status: new
Priority: major | Milestone:
Component: Package request | Version:
Keywords: |
-----------------------------+----------------------------
{{{
EPEL Review Request: python27 - Parallel-installable Python 2.7 for EL6
Inbox
x
Fed-DT-List
x

Moez Roy moez.roy(a)gmail.com via lists.fedoraproject.org
01:26 (13 hours ago)

to epel-devel
Review Request: python27 - Parallel-installable Python 2.7 for EL6
https://bugzilla.redhat.com/show_bug.cgi?id=829892
Can some one take a look into this?
Thanks.
_______________________________________________
epel-devel mailing list
epel-devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
}}}
--
Ticket URL: <https://fedorahosted.org/epel/ticket/21>
Extra Packages for Enterprise Linux <https://fedoraproject.org/wiki/EPEL>
Extra Packages for Enterprise Linux
#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