Hey all,
I just deployed bodhi 0.6.0 to app1-6 and releng{2,1.stg}. This release
contains patches from both Dennis Gilmore and myself to support pushing
updates for EPEL.
I just submitted my first EPEL update into bodhi, so things seem to be
working properly so far. It should be safe to start queueing EPEL
updates, and we'll try doing a small push early next week.
Please file bugs here: https://fedorahosted.org/bodhi/newticket
Thanks,
luke
Here's the topic list for tomorrow's EPEL meeting, which will take
place at 21:00 UTC in #fedora-meeting on irc.freenode.net.
Koji/Bodhi - All done?
Pushing Packages to stable too soon.
Pushing schedules (stable/testing).
Bug day this weekend.
Dealing with incompatible upgrades (moinmoin, nagios, rdiff-backup,
duplicity,etc)
Repoclosure/QA scripts
Orphans
If there is something else that folks would like to discuss, please
followup to this email or mention it in the Open Floor section of the
meeting at the end. Hope to see everyone there!
kevin
I meant to post this a while back.
This is the current list of orphaned packages in EPEL.
Some of them were retired for good reason, see the
https://fedoraproject.org/wiki/Retired_packages
page to find out if thats the case.
Some of them simply need new maintainers to step up and give them
love. ;)
SDL_image
abcde
apt
cd-discid
chrpath
csync2
cvs2cl
djvulibre
fakechroot
fedora-package-config-apt
fedora-package-config-smart
freetennis
fxload
gedit-plugins
ginac
gkrellm
gkrellm-volume
greylistd
gtkhtml38
hellanzb
homestead
horde
imp
ingo
jeta
js
kronolith
libFoundation
libburn
libcdaudio
libid3tag
libmodplug
mach
ms-sys
nopaste
otrs
perl-Class-MethodMaker
perl-Text-CharWidth
perl-Text-WrapI18N
po4a
python-dbsprockets
python-paramiko
pytz
reciteword
redet
redet-doc
scim-chewing
scim-hangul
shapelib
smart
sos
sqlite
svn2cl
synaptic
tpm-tools
turba
viewmtn
vpnc
windowlab
Before taking ownership of any of these, please check the retired
packages page, and consider contacting the former maintainer for more
information.
kevin
Hello all,
I bring this to the list being that the issue isn't necessarily a bug,
rather a concern about implementation. Per the documentation [http://www.fail2ban.org/wiki/index.php/MANUAL_0_8
] fail2ban is _capable_ of supporting shorewall (among other things)
and even states that "the following software is optional but
recommended" with reference to shorewall. However, fail2ban does not
_require_ shorewall to function.
That said, having a 'Requires: shorewall' in the fail2ban spec seems
unnecessary and in my opinion improper. Breaking the package out into
a sub package doesn't seem necessary either... being that the only
file(s) I see that could be split off would be:
]# rpm -ql fail2ban | grep shorewall
/etc/fail2ban/action.d/shorewall.conf
Regardless, for the sake of those that have no interest in shorewall
(and in particular those that want to avoid having to support
shorewall) I'd like to suggest that fail2ban-shorewall be broken off
in a sub-package so that the dependency of shorewall is only enacted
when desired.
Thoughts?
Thank you for your time.
---
derks
EPEL bug day is fast approaching and we are looking for your help. This is a
chance to get involved with EPEL and help make the overall product a little
better.
Goal: Reduce or update bugs from EPEL.
Strategy: The vast majority of EPEL bugs have been classified loosely into
three categories.
* ActualBug -- A real bug, often times with upstream software issues, or
perhaps packaging dependencies. To triage, see if you can reproduce, ask for
more input, and in general see what can be done to fix it.
* PackageBranch -- This is a request to get something into EPEL that currently
isn't there. To triage, see if the package has been branched in CVS. Perhaps
the maintainer simply hasn't built it yet. Or, if it requires dependencies,
contact the maintainer for those dependencies, open another bug, and create the
proper relationship between them.
* UpdatePackage -- Requests to update packages can be difficult in EPEL, but
each should be evaluated. Ask for reasons why the update is required (security
is an extremely valid reason). Sometimes the old version is no longer
maintained upstream, etc. Keep in mind that updates that cause breakage should
at least be mentioned on the epel-announce mailing list.
Feel free to take a bug and help out. It's a 24 hour event, and we have about
135 bugs. If we can get 6 bugs an hour triage and updated, that would be all of
them.
Event coordination and collaboration will occur in #epel on irc.freenode.net.
(Also you don't have to wait until July 11 to start)
More Information:
* https://fedoraproject.org/wiki/EPEL_Bug_Day_July_2009
Current Bug List
* http://tr.im/epelbugs
Just a quick reminder/note that there are several new mailing lists in
EPEL land:
epel-announce:
https://admin.fedoraproject.org/mailman/listinfo/epel-announce
A low volume list that contains announcements of interest to users of
EPEL (Extra Packages for Enterprise Linux).
(ie, this is a list to tell end users of EPEL to subscribe to for
occasional announcements of interest to them).
and
epel-package-announce:
https://admin.fedoraproject.org/mailman/listinfo/epel-package-announce
This mailing list is used for announcing package updates for the Fedora
EPEL Project.
(This is the list that bodhi sends announcements about security
updates, and other stable updates. Subscribe to this if you want to
know as soon as packages are pushed to stable).
Tell your friends to subscribe today!
kevin