Our meetings have been scheduled for 19:30 UTC monday's, but I have
been slacking on running them then, for a number of reasons:
* Mondays are busy, catching up on things from the weekend, etc.
* I have a FESCo meeting just before this.
* The fedora-fr folks are meeting at that time now due to daylight
So, I would like to propose we move to another day/time.
Does anyone have a preference?
We could possibly also just switch to 'on demand' meetings. Ie, no
meeting unless someone proposes topic(s) for one. Currently EPEL is in
a 'stable' phase, so there's not too many issues needing discussion,
For those wanting an implementation of Python 2.7 with a Just-In-Time
compiler in EPEL, I've built PyPy, for EPEL 5 and EPEL 6:
I haven't tested them yet. [am in the middle of firefighting another
issue, but I saw that the builds ran to completion; there were some test
failures in the logs, but the great majority of the selftest suite
So if you're feeling adventurous, please try these builds out (and give
karma to the update accordingly).
Note that this is *not* an official Red Hat-supported thing, and that I
intend to rebase pypy in EPEL to later versions after upstream releases
The latest release of nsca finally increases the 512 characters message
limitation to 4096 and is backward compatible with older client using
the 512 characters message. This was a long awaited change. The only
limitation is the nsca server needs to be upgraded first.
The update is already in Rawhide and I plan to push this as an update in
all Fedora and EPEL testing repos and keep it there for some time before
pushing to stable so people have a change to catch up.
I believe it is ok to push such a change if correctly documented and
advertised on selected mailing lists. Am I correct ?
Today the fail2ban team patched a bug that causes it to die when parsing
certain formats of data/time stamps. I need this fix in order to use
fail2ban with log from one of our systems.
I'm wondering if someone could please build an updated RPM from the newly
released code please, for RHEL 5.7.
Forgive me if this is the wrong way to go about requesting this, I'd be
happy to direct my request to whoever you folks suggest.
John Delisle | Sr Technical Analyst | Ceridian Canada Ltd. | ceridian.ca
400 ? 125 Garry Street | Winnipeg, MB R3C 3P2 | p: 204-975-5909 |
This communication is intended to be received only by the individual[s] or entity[s] to whom or to which it is addressed, and contains information which is confidential, privileged and subject to copyright. Any unauthorized use, copying, review or disclosure is prohibited. Please notify the sender immediately if you have received this communication in error [by calling collect, if necessary] so that we can arrange for its return at our expense. Thank you in advance for your anticipated assistance and cooperation.
Cette communication est destinée uniquement à la personne ou à la personne morale à qui elle est adressée. Elle contient de l’information confidentielle, protégée par le secret professionnel et sujette à des droits d'auteurs. Toute utilisation, reproduction, consultation ou divulgation non autorisées sont interdites. Nous vous prions d’aviser immédiatement l’expéditeur si vous avez reçu cette communication par erreur (en appelant à frais virés, si nécessaire), afin que nous puissions prendre des dispositions pour en assurer le renvoi à nos frais. Nous vous remercions à l’avance de votre coopération.
I would like to request the following Fedora packages be built for
EPEL-6 if at all possible:
python-cssutils, I know src.rpm (from Fedora 16 anyway) rebuilds in
CentOS 6 mock without problem but I have not done any QA on the module
to make sure it behaves, but it's a typical noarch module so I would be
surprised if Fedora QA was not sufficient.
calibre does not rebuild. I tried two fedora src.rpm's :
Second (newer) gets quite a bit further than the first, and is where I
would (and may) put my effort into trying to fix for an EPEL-6 build.
python-cssutils is a build dependency for the calibre, and seems to be
the only build dependency that is not already in CentOS/EPEL 6.
Having both in EPEL would benefit me as bug fixes would roll in to my
system with yum updates.
My interest is strictly to have an eBook reader available on my devel
system for initial testing of output of an EPUB generation tool I am
working on, but there may be other people interested in having an eBook
reader as a general desktop application.
I predict that epub is going to replace PDF as the off-line downloadable
viewing option web sites commonly offer their users, so getting a
frequently used reader into EPEL now may be a good thing.
I don't have a Red Hat account to request EPEL builds through that
process and I objected to providing what they wanted me to provide to
get one back when I looked into it, I believe it wanted my phone number,
and I guard that and won't back down on that.
I also can't file bug reports as a result (such as the build failure of
calibre in CentOS/EPEL 6) but if I do get calibre to properly build I
will forward what I did to the fedora maintainer and this list.
I maintain mozilla-https-everywhere, and upstream is going to release
version 2.0 soon. I hope. Anyway. If 2.0's only changes are new
supported sites, would it be acceptable to push it to EPEL, or should
I just use the repo I already have on repos.fedorapeople.org? If
indeed the only change is new rulesets, backporting would make the
resulting package 1.x in name only.
Fedora Project Contributor
"We are the Borg. Lower your shields and surrender your ships. We will
add your biological and technological distinctiveness to our own. Your
culture will adapt to service us. Resistance is futile."