Hi all!
I'm preparing the testing/ -> stable/ move right now; I noticed that in
testing there are often two versions of a package; random example:
koan-0.6.1-2.el5.src.rpm
koan-0.6.2-2.el5.src.rpm
I think that's fine for the proper repo (one can then reinstall the
older version for a short-term-workaround after a update hit the repo
that broke something), but I don't see much need for it in testing, as
one still can go back to the package from testing normally.
Thus I propose we keep only the latest version in testing/ in the
future. If nobody yells loudly over the next few days in response to
this mail I'll "just do it"(tm).
Cu
knurd

Hello all,
I'm built the first icewm-el5 package two weeks ago and it's still in
epel-testing.
Is it being auto-pushed into epel-release, or do I need to manually push
it. (F7-style.)
Googling for answer didn't return any meaningful answers.
Thanks,
Gilboa

I am working on a project that requires EPEL RPMs as part of the installation
process. We also need to support environments where the target machines are
disconnected from the Internet. My question is, how would you (the EPEL
maintainers) prefer to have these packages distributed? Here are the options as
I see them:
1. Include the needed EPEL RPMS on our distribution media.
2. Include the epel-release RPM only and provide instructions for setting up a
local EPEL mirror and modifying the epel.repo file to point to that local mirror.
We will certainly give credit to the EPEL project in our documentation and
clearly indicate which RPMS are pulled from EPEL regardless of how we distribute
things.
Let me know if anyone here has an opinion on this topic.
Thanks,
Perry
--
|=- Red Hat, Engineering, Emerging Technologies, Boston -=|
|=- Email: pmyers(a)redhat.com Phone: +1 703 362 9622 -=|
|=- GnuPG: E65E4F3D 88F9 F1C9 C2F3 1303 01FE 817C C5D2 8B91 E65E 4F3D -=|

Got a new bug report[1] today about being unable to install Ejabberd on
EL-5. Ejabberd requires Erlang. Ejabberd is in the stable repository,
but Erlang is in the testing repository. So if you don't enable the
testing repository you can't install Ejabberd due to missing
dependencies.
Can either Erlang or Ejabberd be moved so that they are both available
in the same repository? I'd be fine with Ejabberd being moved back to
the testing repository.
Jeff
[1] https://bugzilla.redhat.com/show_bug.cgi?id=360371

So I have been looking over my current workplace and asking around at my old
places to get an idea about where things were.. and came up with the
following statistics.. which are really rough ended. I am trying to get
better numbers versus off the cuff.
Servers [~800 boxes across various sites [not counting clusters]]
EL-2 ~5%
EL-3 60%
EL-4 30%
EL-5 ~5%
The majority of EL-3 items are going to be in place for at least 2+ more
years with many of them probably going to EL-5 and some going to EL-4. It
usually depends on what the Enterprise software is supported for, how
comfortable the people are jumping to another version if they dont
absolutely have to, etc.
Workstations/Desktops [~300 or so]
EL-3 ~5%
EL-4 75%
EL-5 20%
EL-4 is going down and EL-5 is going up. The EL-3 are people who have a
desktop that needs to interact exactly with the code they have run on their
servers... and the desktops arent used much except for that.
Most of the clusters are at either EL-4 or going to EL-5 in their next
interaction and will be running on whatever they are based at for hardware
lifetime [~4 years] so that scientists are using the same code-bases. If
they need newer stuff they will go to the next cluster.
I started asking around yesterday after reading the Scientific Linux email
about them having to put EL-3 on life-support versus end-of-life because
several science projects have not been able to move to a newer code base and
might not until their next 'project' starts. It got me to think about what
EPEL software I could place where and when (beyond my desktop and 1-2
servers). The biggest realization was that I couldn't use FUNC for a while
because most of our systems will not work with it :). Sigh.
--
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

Hi all,
find below the list of topics that are planed to come up in the next
EPEL SIG meeting which is scheduled for tomorrow, Wednesday at 17:00 UTC
in #fedora-meeting on irc.freenode.org.
> /topic EPEL SIG Meeting | http://fedoraproject.org/wiki/EPEL/Tasks/NextTestingStableMove -- nirik
> /topic EPEL SIG Meeting | http://fedoraproject.org/wiki/EPEL/Tasks/RhelMetaData -- stahnma
> /topic EPEL SIG Meeting | http://fedoraproject.org/wiki/EPEL/Tasks/Misc -- remove ntfs-3g and fuse from EPEL4
> /topic EPEL SIG Meeting | http://fedoraproject.org/wiki/EPEL/Tasks/Misc -- Jeff_S: UPDATE-CAREFULLY files created as discussed?
> /topic EPEL SIG Meeting | Free discussion around EPEL
You want something to be discussed? Send a note to the list in reply to
this mail (please adjust the subject) and we'll add it to the schedule
(I can't promise we will get to it tomorrow, but it most likely will if
we don't run out of time). You can also propose topics at the end of the
meeting itself when "Free discussion around EPEL" comes up.
*If your name/nick is on above list*: please give a status update on the
list *and* in the wiki on the individual task pages (linked from the
schedule page: http://fedoraproject.org/wiki/EPEL/Schedule ). That way
all the interested parties know what up ahead of the meeting; that will
avoid long delays and "status update monologues" in the meeting.
Thanks everyone!
CU
knurd