Fedora EPEL Package Build Report 2007-05-30
by Fedora Koji Build System
Packages built and released for Fedora EPEL 5: 8
NEW dwatch-0.1.1-2.el5 : A program that watches over other programs
NEW ettercap-0.7.3-19.el5 : Network traffic sniffer/analyser, NCURSES interface version
gammu-1.11.0-1.el5
NEW gmrun-0.9.2-7.el5 : Lightweight "Run program" dialog box with search history and tab completion
moin-1.5.8-1.el5
NEW perl-Net-Server-0.96-1.el5 : Extensible, general Perl server engine
NEW vym-1.8.1-8.el5 : View your mind
yumex-1.9.7-1.0.el5
Packages built and released for Fedora EPEL 4: 7
NEW dwatch-0.1.1-2.el4 : A program that watches over other programs
NEW ettercap-0.7.3-19.el4 : Network traffic sniffer/analyser, NCURSES interface version
NEW fontforge-20061025-1.el4 : Outline and bitmap font editor
moin-1.5.8-1.el4
nfswatch-4.99.9-1.el4
NEW perl-Net-Server-0.96-1.el4 : Extensible, general Perl server engine
NEW wine-0.9.36-1.el4 : A Windows 16/32/64 bit emulator
Changes in Fedora EPEL 5:
dwatch-0.1.1-2.el5
------------------
* Thu May 24 2007 Bernard Johnson <bjohnson(a)symetrix.com> - 0.1.1-2
- fix dwatch.5 man page to use double quotes around argument
* Wed May 23 2007 Bernard Johnson <bjohnson(a)symetrix.com> - 0.1.1-1
- initial release
ettercap-0.7.3-19.el5
---------------------
* Wed Mar 28 2007 Jon Ciesla <limb(a)jcomserv.net> - 0.7.3-19
- /usr/bin/ettercap ownership fix.
gammu-1.11.0-1.el5
------------------
* Thu May 24 2007 Xavier Lamien < lxtnow[at]gmail.com > - 1.11.0-1
- Updated release.
* Wed May 23 2007 Xavier Lamien < lxtnow[at]gmail.com > - 1.10.6-1
- Updated release.
gmrun-0.9.2-7.el5
-----------------
* Sat Feb 10 2007 <gilboad AT gmail DOT com> - 0.9.2-7
- Preserve the source time-stamp.
moin-1.5.8-1.el5
----------------
* Wed May 16 2007 Matthias Saou <http://freshrpms.net/> 1.5.8-1
- Update to 1.5.8, which includes most previous security fixes.
- Remove the (apparently) no longer needed dos2unix conversion for patch.
- Use %{python_sitelib} macro.
perl-Net-Server-0.96-1.el5
--------------------------
* Fri May 18 2007 Kevin Fenzi <kevin(a)tummy.com> - 0.96-1
- Update to 0.96
- Inital EL-5 build
vym-1.8.1-8.el5
---------------
* Wed Mar 21 2007 Jon Ciesla <limb(a)jcomserv.net> - 1.8.1-8
- Converted patches to unified output format.
yumex-1.9.7-1.0.el5
-------------------
* Tue May 29 2007 Tim Lauridsen <tla(a)rasmil.dk> - 1.9.7-1.0
- Development Release 1.9.7-1.0
Changes in Fedora EPEL 4:
dwatch-0.1.1-2.el4
------------------
* Thu May 24 2007 Bernard Johnson <bjohnson(a)symetrix.com> - 0.1.1-2
- fix dwatch.5 man page to use double quotes around argument
* Wed May 23 2007 Bernard Johnson <bjohnson(a)symetrix.com> - 0.1.1-1
- initial release
ettercap-0.7.3-19.el4
---------------------
* Wed Mar 28 2007 Jon Ciesla <limb(a)jcomserv.net> - 0.7.3-19
- /usr/bin/ettercap ownership fix.
fontforge-20061025-1.el4
------------------------
* Tue May 29 2007 Kevin Fenzi <kevin(a)tummy.com> - 20061025-1
- Upgrade to 20061025-1
- Initial EL build
moin-1.5.8-1.el4
----------------
* Wed May 16 2007 Matthias Saou <http://freshrpms.net/> 1.5.8-1
- Update to 1.5.8, which includes most previous security fixes.
- Remove the (apparently) no longer needed dos2unix conversion for patch.
- Use %{python_sitelib} macro.
nfswatch-4.99.9-1.el4
---------------------
* Wed May 30 2007 Christian Iseli <Christian.Iseli(a)licr.org> 4.99.9-1
- new upstream version
perl-Net-Server-0.96-1.el4
--------------------------
* Fri May 18 2007 Kevin Fenzi <kevin(a)tummy.com> - 0.96-1
- Update to 0.96
- Inital EL build
wine-0.9.36-1.el4
-----------------
* Sat May 05 2007 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
0.9.36-1
- version upgrade
- minor fixes
For more information about the built packages please see the repository
or the Fedora Info Feed: http://fedoraproject.org/infofeed/
16 years
Likely no meeting this week
by Thorsten Leemhuis
Hi all!
>From #epel on freenode:
----
knurd> | dgilmore, stahnma, quaid, nirik, do you want to run a meeting
this week? mmcgrath and I will be on LinuxTag and likely not near a
computer so it would be only you four from the steering committee
dgilmore> | knurd: may be best to skip if people want to do it ill be
happy to run it
knurd> | sounds fine to me
[...]
quaid> | knurd_afk: I'm neutral; I can use the time constructively
either way
----
So in other words: There likely won't be a meeting this week. If you
want one just let us know.
CU
thl
16 years
EPEL report week 20, 2007
by Thorsten Leemhuis
Hi all! Please find below this weeks EPEL report. It's also in the wiki
at http://fedoraproject.org/wiki/EPEL/Reports/Week21
Cu
knurd
----
= Weekly EPEL Summary =
Week 21/2007
== Most important happenings ==
*
[https://www.redhat.com/archives/epel-devel-list/2007-May/msg00138.html
Noisy discussions] in reply to the meeting summary after the
"repotags/interaction with 3rd party repos" topic was discussed and
removed from the schedule; knurd will nevertheless bring it up in the
next meeting again, as it was no formal discussion (only three Steering
Committee members around then)
== EPEL SIG Meeting ==
=== Attending ===
>From the Steering Committee:
* knurd (ThorstenLeemhuis) (partly)
* mmcgrath (MikeMcGrath)
* nirik (KevinFenzi)
* stahnma (MichaelStahnke)
Missing from the Steering Committee:
* dgilmore (DennisGilmore)
* quiad (KarstenWade)
Others that participated the meeting: LetoTo, Jeff_S, rdieter, f13,
smooge
=== Summary ===
* 00:03 --- | knurd has changed the topic to: EPEL Meeting --
repotags/interaction with 3rd party repos -- owner: all
* I'm not going to write a summary on this, as this is a very
controversial and complicated topic. Sorry. Please read the full log.
* 00:45 --- | mmcgrath has changed the topic to: EPEL Meeting --
Investigate single RHEL subscription for EPEL maintainers -- quaid
* "It would be nice to get some RHEL subscriptions for our EPEL people
though I think quaid has quite a journey ahead of him first. It may be
easier once red hat can more easily realize the value of EPEL. knurd> |
I don't think this is high on out todo list; we'll talk about this next
time when quaid is around.
* 00:49 --- | mmcgrath has changed the topic to: EPEL Meeting --
bodhi/testing repo/final repo layout -- nirik/lmacken
* we need to look at converting epel to koji; f13> "there are some
roadblocks to that. like koji modifications that would make the
binaries used in the buildroots not publically available."
* some discussions around RH management, using RHEL for Building and
not CentOS
* mbonnet will look into enabling koji to make use of a repo htat's not
available to the public, which should make it possible to use koji for EPEL
* lmacken> "bodhi would work with plague if we could get it filesystem
access to the build results." ; he'll likely look into this, too, but
making bodhi working for F7 is more important atm
=== Full meeting log ===
See https://www.redhat.com/archives/epel-devel-list/2007-May/msg00138.html
== Stats ==
=== General ===
Number of EPEL Contributors 80
We welcome 6 new contributors: ed_AT_eh3.com, jspaleta_AT_gmail.com,
limb_AT_jcomserv.net, phuang_AT_redhat.com, pnemade_AT_redhat.com,
tagoh_AT_redhat.com, zhu_AT_redhat.com
=== EPEL 5 ===
Number of source packages: 292
Number of binary packages: 470
There are 67 new Packages:
* arp-scan | Scanning and fingerprinting tool
* autodir | Creates user directories on demand
* bugzilla | Bug tracking system
* cgdb | CGDB is a curses-based interface to the GNU Debugger (GDB)
* DMitry | Deepmagic Information Gathering Tool
* drgeo-doc | Html documentation for drgeo
* drgeo | Interactive educational geometry software
* freehdl | GPLed free VHDL
* gammu | Command Line utility to work with mobile phones
* gperiodic | Program for browsing the periodic table
* graphviz | Graph Visualization Tools
* halberd | Tool to discover HTTP load balancers
* ike-scan | IKE protocol tool to discover, fingerprint and test IPsec
VPN servers
* incron | Inotify cron system
* ircd-hybrid | Internet Relay Chat Server
* jasper | Implementation of the JPEG-2000 standard, Part 1
* libiptcdata | IPTC tag library
* libupnp | Universal Plug and Play (UPnP) SDK
* nbtscan | Tool to gather NetBIOS info from Windows networks
* ncarg | A Fortran and C based software package for scientific
visualization
* netcdf | Libraries for the Unidata network Common Data Form (NetCDF v3)
* nrpe | Host/service/network monitoring agent for Nagios
* ocaml | Objective Caml compiler and programming environment
* pdns | A modern, advanced and high performance authoritative-only
nameserver
* pdns-recursor | Modern, advanced and high performance recursing/non
authoritative nameserver
* perl-Affix-Infix2Postfix | Perl extension for converting from infix
notation to postfix notation
* perl-Apache-DBI | Persistent database connections with Apache/mod_perl
* perl-Boulder | An API for hierarchical tag/value structures
* perl-DBD-SQLite | Self Contained RDBMS in a DBI Driver
* perl-HTML-Table | Create HTML tables using simple interface
* perl-Image-Math-Constrain | Scaling math used in image size
constraining (such as thumbnails)
* perl-IO-Multiplex | IO-Multiplex module for perl
* perl-libwhisker2 | Perl module geared specificly for HTTP testing
* perl-Math-Base85 | Perl extension for base 85 numbers, as referenced
by RFC 1924
* perl-Net-IP-CMatch | Efficiently match IP addresses against IP ranges
with C
* perl-Net-Patricia | Patricia Trie perl module for fast IP address
lookups
* perl-Net-Pcap | Interface to pcap(3) LBL packet capture library
* perl-Nmap-Parser | Parse nmap scan data with perl
* perl-Proc-Daemon | Run Perl program as a daemon process
* perl-String-Approx | Perl extension for approximate matching (fuzzy
matching)
* perl-XML-DOM | DOM extension to XML::Parser
* perl-XML-RegExp | Regular expressions for XML tokens
* php-channel-phpunit | Adds phpunit channel to PEAR
* php-pear-DB | PEAR: Database Abstraction Layer
* php-pear-Log | Abstracted logging facility for PHP
* php-pear-Net-Ping | Execute ping
* php-pear-Net-Traceroute | Execute traceroute
* php-pecl-radius | Radius client library
* php-pecl-xdebug | PECL package for debugging PHP scripts
* plone | User friendly and powerful open source Content Management System
* Pound | Reverse proxy and load balancer
* python-cheetah | Template engine and code-generator
* python-docutils | A system for processing plaintext documentation
* python-krbV | Python extension module for Kerberos 5
* python-numarray | Python array manipulation and computational library
* python-protocols | Open Protocols and Component Adaptation for Python
* python-sqlite2 | DB-API 2.0 interface for SQLite 3.x
* qucs | Circuit simulator
* ruby-mysql | A Ruby interface to MySQL
* scponly | Restricted shell for ssh based file services
* specto | An desktop application that will watch configurable events
* ushare | UPnP (TM) A/V Media Server
* windowlab | Small and Simple Amiga-like Window Manager
* yum-arch | Extract headers from rpm in a old yum repository
* zope | Web application server for flexible content management
applications
=== EPEL 4 ===
Number of source packages: 194
Number of binary packages: 358
There are 36 new Packages:
* bugzilla | Bug tracking system
* DMitry | Deepmagic Information Gathering Tool
* drgeo-doc | Html documentation for drgeo
* drgeo | Interactive educational geometry software
* freehdl | GPLed free VHDL
* gperiodic | Program for browsing the periodic table
* halberd | Tool to discover HTTP load balancers
* ike-scan | IKE protocol tool to discover, fingerprint and test IPsec
VPN servers
* ircd-hybrid | Internet Relay Chat Server
* libupnp | Universal Plug and Play (UPnP) SDK
* nbtscan | Tool to gather NetBIOS info from Windows networks
* ncarg | A Fortran and C based software package for scientific
visualization
* netcdf | Libraries for the Unidata network Common Data Form (NetCDF v3)
* ocaml | Objective Caml compiler and programming environment
* pdns-recursor | Modern, advanced and high performance recursing/non
authoritative nameserver
* perl-Apache-DBI | Persistent database connections with Apache/mod_perl
* perl-Boulder | An API for hierarchical tag/value structures
* perl-HTML-Table | Create HTML tables using simple interface
* perl-libwhisker2 | Perl module geared specificly for HTTP testing
* perl-Math-Base85 | Perl extension for base 85 numbers, as referenced
by RFC 1924
* perl-Net-IP-CMatch | Efficiently match IP addresses against IP ranges
with C
* perl-Net-Patricia | Patricia Trie perl module for fast IP address
lookups
* perl-Nmap-Parser | Parse nmap scan data with perl
* perl-Proc-Daemon | Run Perl program as a daemon process
* perl-String-Approx | Perl extension for approximate matching (fuzzy
matching)
* perl-XML-DOM | DOM extension to XML::Parser
* perl-XML-RegExp | Regular expressions for XML tokens
* Pound | Reverse proxy and load balancer
* python-krbV | Python extension module for Kerberos 5
* python-numarray | Python array manipulation and computational library
* qucs | Circuit simulator
* ruby-mysql | A Ruby interface to MySQL
* scponly | Restricted shell for ssh based file services
* specto | An desktop application that will watch configurable events
* ushare | UPnP (TM) A/V Media Server
* windowlab | Small and Simple Amiga-like Window Manager
----
["CategoryEPELReports"]
16 years
Log from yesterdays (20070523) EPEL SIG meeting
by Thorsten Leemhuis
00:00 --- | knurd has changed the topic to: EPEL Sig meeting
-- Meeting rules at
http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines --
Init process
00:00 < knurd> | Hi everybody; who's around?
00:00 * | nirik is here.
00:00 < knurd> | sorry, I forgot to send the list of topics out
00:01 < knurd> | I was busy with preparation for my
FUDCon/Linuxtag talk
00:01 < stahnma> | ack
00:01 < > | listening in
00:01 * | mmcgrath is here
00:01 < LetoTo> | I'm around
00:01 --> | Jeff_S (Jeff Sheltren) has joined #fedora-meeting
00:02 < Jeff_S> | Hi
00:02 < knurd> | hmmmm
00:02 < knurd> | makes four people from the steeing committee afaics
00:02 < knurd> | so let's start
00:02 < stahnma> | do we have topics?
00:02 < knurd> | stahnma, http://fedoraproject.org/wiki/EPEL/Schedule
00:02 < knurd> | they are always in the meeting
00:02 < stahnma> | always a good start :)
00:03 < knurd> | everyone can add someting there if he likes to
00:03 --- | knurd has changed the topic to: EPEL Meeting --
repotags/interaction with 3rd party repos -- owner: all
00:03 < knurd> | well, the same old topic again
00:03 < knurd> | I'm still unsure myself what to do
00:03 < knurd> | put feed down?
00:03 * | mmcgrath notes that this is not a destination but
a journey.
00:03 < stahnma> | sure is
00:03 < knurd> | let someone work out repotag details with the FPC?
00:04 < mmcgrath> | I haven't followed the FPC's logs on this at all,
do they care?
00:04 < stahnma> | details as in implementation or dtails has in
figure out if we should use it?
00:04 < knurd> | mmcgrath, seems spot doesn't like them to much
00:05 < knurd> | stahnma, "details in implementation"
00:05 < knurd> | mmcgrath, thimm is for them
00:05 < nirik> | perhaps we should ask koji wizards how hard it
would be to make it add a repotag for epel builds in the buildsys?
00:05 < knurd> | mmcgrath, f13 against repotags afaics
00:05 < mmcgrath> | but they at least care enough to discuss it further?
00:05 < mmcgrath> | They won't just dismiss it?
00:05 < knurd> | mmcgrath, not sure
00:05 < mmcgrath> | <nod>
00:05 < knurd> | mmcgrath, last time I asked I got a " write a
proposal first" reply
00:05 < stahnma> | IIRC, if EPEL says yes, they won't overrule us
00:06 < nirik> | I don't like them, but dag, thimm, planetccrm,
etc are all mad... if it will make them happy and we can do it some way
easily I would do it just to make them all happy.
00:06 < stahnma> | else, they are not going to pursue it theirselves
00:06 < nirik> | at least then the topic would hopefully go away.
00:06 < knurd> | nirik, hopefully
00:07 < knurd> | so shall we vote on
https://www.redhat.com/archives/epel-devel-list/2007-May/msg00105.html ?
00:07 < knurd> | minus the " * no hacks to the buildsys or
modifications to the rpms after their
00:07 < knurd> | initial creation"
00:07 < stahnma> | I think we need the 3rd repos onboard for EPEL to
be sucessful, so an implemetnation shoudl be looked at
00:07 < stahnma> | knurd: should we get hte buildsys questions
answered before a vote?
00:07 < nirik> | yeah, that proposal as written isn't possible I
don;'t think./
00:08 < Jeff_S> | knurd: I think that either adding a %{?repo} tag,
or modifying the build system to add it to EPEL packages is the way to go
00:08 < knurd> | stahnma, there are lots of questions that would
need to be answered
00:08 < stahnma> | if we know the buildsys changes/requirements, I
think the vote will make more sense
00:08 < nirik> | I think the only easy/possible solution is the
buildsys overriding to add the tag.
00:08 < knurd> | stahnma, someone just needs to work out everything
00:08 < f13> | to do that you need a package in the buildroot to
either define a further macro, or redefine the %{?dist} macro
00:08 < f13> | and then you need to have support for it in the
Makefile.common stuff, for your branch.
00:08 * | abadger1999 heard FPC and looks in.
00:09 < knurd> | well, so what to do
00:09 < nirik> | right. dist won't get everything tho...
00:09 < f13> | and since we're making %{?dist} tags locally
resolvable, having a different %{?dist} value than RHEL is going to
be... interesting.
00:09 < knurd> | simply say "we want repotags, FPC please tell us
how"?
00:09 < knurd> | f13, I don#t like abusing dist
00:09 < knurd> | f13, it's optional
00:09 < quaid> | sorry, I have to take dd to the dentist, running
'twixt appointments right now
00:09 < stahnma> | could we modify universally to use %{?repo} and
have Fedora just have it blank?
00:10 < f13> | %{?dist} is defined in redhat-rpm-config forward
moving, perhaps in RHEL5.1
00:10 < Jeff_S> | well surely there are more ways to do it in the
buildsys than using %dist
00:10 * | quaid is absent officially now and will catch up
via buffer later
00:10 < knurd> | stahnma, yes, that's what I proposed on fedora-devel
00:10 < nirik> | but that requires fedora to have a useless tag... :(
00:10 < Jeff_S> | stahnma: I agree, why not propose using %{?repo}
00:11 < stahnma> | I thought that great came from somewhere :)
00:11 --- | rdieter_away is now known as rdieter
00:11 < Jeff_S> | stahnma: not useless... unused :)
00:11 < stahnma> | great idea even
00:11 < knurd> | well, so what to do?
00:11 < knurd> | shall we approve a kind of
00:12 < nirik> | also would result in a lot of checkins on fedora
to just keep things in sync with epel... ;(
00:12 < knurd> | "EPEL wants considers to use repotags; FPC please
work out a solution" ?
00:12 < stahnma> | we need someone with buildsys experience to
probably work on the tech details. If it's a vote to move forward in
persuit of the repotag, that's fine
00:12 < knurd> | stahnma, we need someone to driver the whole
repotags thing
00:12 < knurd> | that will be a lot of work
00:12 < f13> | 'wants to consider' um no.
00:12 < knurd> | and I'm not volunteering
00:12 < f13> | make up your mind before we spend time/effort
making it happen.
00:13 <-- | nim-nim has quit ("Leaving.")
00:13 < knurd> | f13, I'm don#t want to give a blanket approved
without knowing how therepotag will be realized
00:13 < nirik> | bit of a chicken/egg thing there...
00:13 < f13> | but that's purely details. Either you want a repo
tag or not.
00:13 < knurd> | f13, you in my position would do the same
00:13 < knurd> | I would assume
00:13 --> | llaumgui (LLaumgui) has joined #fedora-meeting
00:13 < f13> | if you want a tag, say so. THen when FPC or
whomever comes up with a way to realize it, you can say yay or nay on
said implimentation.
00:13 < knurd> | nirik, that's why I wrote
https://www.redhat.com/archives/epel-devel-list/2007-May/msg00105.html
00:13 < rdieter> | knurd: imo, epel's job here is simple: policy,
yes/no.
00:14 < f13> | rdieter: +1
00:14 < nirik> | right.
00:14 < knurd> | f13, well, if we can still say "no" after FPC
worked something out then that's fine with me
00:14 < stahnma> | ok
00:14 < stahnma> | so epel approves policy, next step is to
infrastructure/FPC on implementation?
00:15 < f13> | knurd: that's fine, that's just color of the bike
shed.
00:15 < f13> | knurd: first you ahve to figure out if you even
want a bike shed.
00:15 < knurd> | f13, we want a bike shed afaics
00:15 < stahnma> | ok, sounds like a plan
00:15 < knurd> | but if the bike shed looks bad later I want to
say "no"
00:15 < f13> | epel passed a vote?
00:15 < knurd> | or I want to give you some rough plans
00:15 < knurd> | f13, not yet
00:15 < nirik> | yeah. I dislike repotags, but its never going to
go away until we do it, and it will make other repos happier with us.
00:15 * | mmcgrath thinks we have more important things to do
00:16 < f13> | I hate the idea and I'll refuse to allow them be
used anywhere that I have control over.
00:16 < knurd> | I would only want them for EL4 and EL5
00:16 < f13> | but thankfully for you, I dn't have any control
here (:
00:16 < Jeff_S> | f13: care to elaborate?
00:16 < knurd> | rediscuss by EL6
00:16 --> | nim-nim (Nicolas Mailhot) has joined #fedora-meeting
00:16 < mmcgrath> | nirik: I'm questioning how important that is.
00:17 < mmcgrath> | nirik: after all, none of those people are even
here right now.
00:17 < nirik> | yeah, I don't know. I would prefer to cooperate,
but I suspect after we do repotags there will be a next thing after
that... so not sure how far it will really get us...
00:17 < f13> | Jeff_S: on the whole they're pointless, they add
cruft to systems, they provide little to no intrinsic value, they're
easily "fakeable", and it's the wrong solution to the problem.
00:17 * | knurd afk for two minutes -- sorry
00:17 < nirik> | but I am willing to try it and see...
00:18 < stahnma> | I think they provide value to
end-users/admins...even if it is <100% reliable
00:18 < f13> | and if the other repos are bitching, because our
packages won't have a tag, well that makes it pretty easy to see which
are our packages and which are they're packages.
00:18 < f13> | they're packages have a repo tag, end of story.
00:18 < nirik> | the only advantage they have is that other repos
find that they help identify what repo a package came from in problem
reports.
00:18 < Jeff_S> | f13: what's "the problem" in your opinion, and
have other/better solutions been proposed?
00:18 < f13> | stahnma: there are 100% reliable methods to get
same value, and there is low hanging fruit to make that info even more
accessable.
00:19 < f13> | Jeff_S: use gpg key. Use builder information.
Use Distributor.
00:19 < stahnma> | teach rookies to use GPG
00:19 < nirik> | but they claim their end users are not able to do
that.
00:19 < stahnma> | then get back to me
00:19 < mmcgrath> | AFAIK the root 'problem' is package conflicts.
And repo tag does not fix that.
00:19 < f13> | stahnma: they don't need to know how to use gpg.
00:19 < f13> | stahnma: they need to know how to use rpm -qi
00:19 < nirik> | doesn't fix it, but helps identify what repo the
problem is in... or related to at least
00:20 < f13> | and I don't know why EPEL is worked up over
working togehter with repos we can't even mention due to legal difficulties.
00:21 --> | kital (Joerg Simon) has joined #fedora-meeting
00:21 < nirik> | note that it looks like thimm has dropped
repotags from atrpms already.
00:22 < Jeff_S> | f13: I think in general EPEL would like to form a
community w/ other packagers whether or not RH can mention them. It
seems like Repo tags in EPEL would help bridge the gap there
00:22 < nirik> |
http://lists.atrpms.net/pipermail/atrpms-devel/2007-April/001508.html
00:23 < stahnma> | it is a step of good-faith toward the other repos
that have the EL add-on community thus far.
00:23 < mmcgrath> | nirik: that email seems to indicate to me that
this is a completely political issue. one that has done nothing but
distract us.
00:24 * | mmcgrath notes thimm is used to running a repo
where his rule is law.
00:24 < f13> | Jeff_S: but if EPEL wants all software avialble
to users, all said software has to be in EPEL, which really obsolets the
other repos.
00:24 < mmcgrath> | Its probably difficult to go from that to an
environment like EPEL.
00:24 < f13> | Jeff_S: 'form a community' should more be 'make
EPEL more compelling to work in than doing your own thing'.
00:24 < nirik> |
http://lists.rpmforge.net/pipermail/packagers/2007-April/000316.html
also for rpmforge
00:25 < Jeff_S> | f13: well, however you feel like phrasing it.
getting more people to work together IMO is a good goal to have
00:25 < rdieter> | f13: that's a bad attitude (EPEL obsoletes all),
best to be avoided (no matter how close to the truth it really is).
00:25 < Jeff_S> | f13: why would EPEL need to obsolete other repos?
00:25 < mmcgrath> | Jeff_S: what if getting more people means talking
about one issue for months on end when 'more people' means 3 or 4 people?
00:25 < Jeff_S> | there are many things EPEL won't ever have due to
licensing, etc
00:26 < Jeff_S> | well if 3 or 4 people are building hundreds of
pkgs, that seems good to me
00:26 < mmcgrath> | none of whom care about epel enough to be here.
00:26 < rdieter> | mmcgrath: and they never will, unless consessions
are made in good faith.
00:26 < mmcgrath> | rdieter: I'd argue that even if this consession
was made they wouldn't participate.
00:27 < mmcgrath> | hell, thimm was the closest person and he does
not have a single epel package.
00:27 < rdieter> | maybe... but the risk/reward is positive, imo.
00:27 < stahnma> | I think he was waiting for the official decision
on repotags and the opening of the repo
00:27 < f13> | Jeff_S: If Red Hat wants to promote EPEL as being
the place to get addon packages to RHEL, EPEL should have all the
packages one would want, IE all the free and opensource and legal packages.
00:28 < f13> | Jeff_S: Red Hat can't say "oh, but that package
isn't in EPEL, you have to go to <BAR> to get that free and legal
package" because <BAR> is a place that houses illegal packages.
00:28 < mmcgrath> | I just want to get something done. we've been
talking about this issue since march. We've been talking about it for a
half hour already in this meeting.
00:28 < f13> | for EPEL to be successful as a place to get
packages and promoted by Red Hat like Fedora Extras was, the software
must be available in EPEL.
00:28 < rdieter> | mmcgrath: +1 (vote)
00:28 < nirik> | mmcgrath: +999
00:28 < mmcgrath> | and not one person here is actually in favor of
repo tags. There's just people in favor of working with other people
who aren't part of our community who are in favor of repo tags.
00:28 < mmcgrath> | and thats very telling.
00:29 < nirik> | after reading that rpmforge and atrpms have
already dropped the repotag, I think we shouldn't bother to try and add
it...
00:29 < f13> | rdieter: bad attitude or not, I deal in truths
when possible.
00:29 < Jeff_S> | I don't deal directly w/ end user support for
Fedora/EL, but from everything I hear from people that do, repotags
would be very helpful for them. That makes me in favor of them...
00:29 < f13> | it's the same reason why Fedora Extras really
obsoleted other repos aside from the illegal stuff.
00:30 < f13> | Jeff_S: I don't buy it. I've delt in end user
support. THat argument is just a failling in the person providing the
support to ask the right question, ie rpm -qi
00:30 < rdieter> | f13: that same attitude pushed potential
contributors away in the beginning of FE, and I see history repeating
itself...
00:30 < f13> | and since RHEL itself doesn't have a repo tag,
this is all irrelevant.
00:31 < f13> | rdieter: explain to me how we can take advantage
of packages only being available in a non Fedora repo that we can't
mention due to legal reasons?
00:31 < f13> | rdieter: how is that any good to us?
00:31 < rdieter> | f13: those other repos include *lots* of legally
ok stuff.
00:31 < rdieter> | esp rpmforge.
00:32 < f13> | while at the same time including illegal stuff
thus tainting the entire repo
00:32 < f13> | which is why we can't ship a repo file for them
in Fedora, why we can't mention them in our wiki, etc.. etc..
00:32 < f13> | great end user value there.
00:32 < mmcgrath> | we really shouldn't discuss what they do with
their repos...
00:32 < mmcgrath> | its their repo.
00:32 < rdieter> | f13: you're getting offtopic (unless I'm missing
something). ??
00:33 < mmcgrath> | working with the other repos is about how we get
the repos made, not so much whats in them.
00:33 < f13> | I am off topic... sortof.
00:33 < nirik> | so what do we do here? vote again on repotags?
(and add it as a standing line item in the meetings? :)
00:33 < mmcgrath> | nirik: would that be the 3rd vote on repo tags?
00:34 < nirik> | at least.
00:34 < f13> | I'm just failing to see the value in "working
with" a set of repos that we can't mention, we can't guide users to, we
can't preconfigure user's systems for, we can't expect users to
magically discover that there is another repo they have to manually add
to get access to potentially useful software, that we could just put in
repos that we _can_ guide users to.
00:35 < f13> | unless "working with" involves helping htem get
all software that _can_ be published through EPEL into EPEL.
00:35 < nirik> | I think the idea is not that we want to use their
repo, it's that we want their experence/people to help us and join us...
00:35 < mmcgrath> | f13: the fact is other users like those repos.
And if using them breaks the system, that makes Fedora look bad. It
doesn't matter whether its right or not.
00:35 <-- | JSchmitt has quit (Read error: 113 (No route to
host))
00:35 < rdieter> | f13: it's not working with other repos at issue,
but working with an existing community of packagers, who could be
potential Fedora/epel contributors.
00:36 <-- | ivazquez has quit (Remote closed the connection)
00:37 < f13> | mmcgrath: so our new users just are SOL on
software that is hidden away in repos we can't mention or preconfigure
for them, we just have to hope that they somehow discover that there are
other repos and that they're safe to use...
00:37 * | f13 stops contributing to conversation.
00:37 --> | smooge (Stephen J Smoogen) has joined
#fedora-meeting
00:37 * | rdieter is done too (I think), goes back to the
rabble seats with his popcorn.
00:37 --> | ivazquez (gaim) has joined #fedora-meeting
00:37 * | smooge gets out of work meetings
00:37 < mmcgrath> | f13: Beats me, some how I managed to find them
and use them.
00:38 < mmcgrath> | can we just stop talking about this and hope it
goes away?
00:38 < mmcgrath> | who's even driving this issue anymore?
00:38 < Jeff_S> | mmcgrath: you can hope, but I'm not sure that
will help...
00:38 < mmcgrath> | I'll ask it this way.
00:38 * | nirik was for just giving in and adding repotag
before this meeting, but after reading that the other repos have stopped
using it, it seems pretty moot...
00:39 --> | nihed (Unknown) has joined #fedora-meeting
00:39 < mmcgrath> | If I removed this item from the schedule right
now... who would bring it up next week?
00:39 < smooge> | I can say that the gpg signature items looks like
a better yum plugin term to help repo people.
00:39 < mmcgrath> | I know my approach isn't very diplomatic but this
has gotten silly.
00:40 <-- | llaumgui has quit (Remote closed the connection)
00:40 < mmcgrath> | we've spent 40 minuts talking about stuff that
just doesn't matter that much and the people in question have already
removed the tag.
00:40 < nirik> | mmcgrath: perhaps you could try it and see? :)
00:40 < nirik> | knurd: would you re-add it?
00:40 < mmcgrath> | I'm going to remove it and will seriously take no
offense if someone adds it again.
00:40 < mmcgrath> | I just think we're talking about it because its
there.
00:41 --- | mmcgrath has changed the topic to: EPEL Meeting
-- vacant seat in the steering committee
00:42 * | mmcgrath wonders where knurd is
00:42 < mmcgrath> | we have a vacant seat available.
00:42 < nirik> | he was going to send some emails about that to
interested people.
00:42 < mmcgrath> | did that get done or is it still a todo item?
00:42 < stahnma> | I think he emailed people
00:42 < stahnma> | got some repsonses
00:42 < stahnma> | like "if I have to"
00:42 < stahnma> | and "if no one else will"
00:42 < mmcgrath> | gotta love the support :)
00:43 < Jeff_S> | how would one volunteer for that...?
00:43 < Jeff_S> | rdieter: you are not interested?
00:43 < mmcgrath> | Jeff_S: Buhh, I guess you'd just need to make
your intentions known. The epel list would be a good place.
00:43 < stahnma> | epel list is probably the best place
00:43 < Jeff_S> | mmcgrath: where's the epel list?
00:43 < stahnma> | or direct to knurd
00:43 < Jeff_S> | (that was a joke) :)
00:44 < stahnma> | without knurd responding, next topic?
00:44 < rdieter> | Jeff_S: intrigued, yes, but honestly, my plate is
way full/overflowing as-is.
00:44 < nirik> | Jeff_S:
https://www.redhat.com/mailman/listinfo/epel-devel-list
00:44 < Jeff_S> | sorry nirik, it was a bad attempt at humor ;)
00:44 < mmcgrath> | Well there doesn't appear to be much to discuss
on that topic right now
00:44 < nirik> | next topic is for quaid, and he's gone. next
topic++ ?
00:44 < Jeff_S> | rdieter: ok, just curios
00:44 < Jeff_S> | *curious*
00:44 < mmcgrath> | Jeff_S: bad humor? oh you'll fit right in ;-)
00:44 < rdieter> | np
00:45 < stahnma> | ha
00:45 --- | mmcgrath has changed the topic to: EPEL Meeting
-- Investigate single RHEL subscription for EPEL maintainers -- quaid
00:45 < mmcgrath> | quaid: anything?
00:45 < Jeff_S> | lol
00:45 < stahnma> | I think quaid is AFK
00:45 < mmcgrath> | <nod>
00:45 --- | mmcgrath has changed the topic to: EPEL Meeting
-- bodhi/testing repo/final repo layout -- nirik/lmacken
00:45 < mmcgrath> | lmacken: ping?
00:45 < stahnma> | I would love to have a a subscription to RHN to
work with with RHEL
00:45 < stahnma> | (previous topic still)
00:45 < mmcgrath> | I know that luke has been putting some configs
together to deploy bodhi on our production application cluster.
00:45 < stahnma> | like develop a script that converts EPEL to an
RHN channel
00:45 * | f13 mutters something unsavory about RHEL management.
00:45 < smooge> | mmcgrath, what does it take to to take the empty
seat?
00:45 < nirik> | we need to look at converting epel to koji.
00:46 --> | llaumgui (LLaumgui) has joined #fedora-meeting
00:46 < nirik> | who would be someone who could drive that?
00:46 < mmcgrath> | smooge: I don't think we have a hard fast rule, I
guess the group would meet on it and say yay or nay?
00:46 < mmcgrath> | wait, should I topic change back to the RHEL
subscriptions?
00:46 * | knurd is partly back
00:46 < knurd> | sorry, real life cam in between
00:47 < knurd> | sorry, sorry, sorry
00:47 --- | mmcgrath has changed the topic to: EPEL Meeting
-- Investigate single RHEL subscription for EPEL maintainers -- quaid
00:47 < mmcgrath> | knurd: no worries.
00:47 < mmcgrath> | stahnma: Yeah, It would be nice to get some RHEL
subscriptions for our EPEL people though I think quaid has quite a
journey ahead of him first.
00:47 < smooge> | ok if this is not going to occur, what are the
alternatives? And when can we put a line in the sand on it
00:47 < mmcgrath> | It may be easier once red hat can more easily
realize the value of EPEL.
00:47 < knurd> | mmcgrath, +1
00:48 < knurd> | I don#t think this is high on out todo list
00:48 < mmcgrath> | smooge: are you talking about the RHEL subs?
00:48 < nirik> | yeah, might be nice, but not any kind of blocker.
00:48 < knurd> | might be nice, but using centos normally should
be fine
00:48 < smooge> | yes
00:48 < smooge> | mmcgrath, yes
00:48 < mmcgrath> | one alternative I see is to setup a xen box that
people can 'rent' or check out or whatever.
00:48 < stahnma> | well if RHN ever goes truely open source, then we
can work on it that way :)
00:48 < mmcgrath> | its less desirable but something.
00:49 < mmcgrath> | we'll talk about this next time when quaid is around.
00:49 --- | mmcgrath has changed the topic to: EPEL Meeting
-- bodhi/testing repo/final repo layout -- nirik/lmacken
00:49 < mmcgrath> | knurd: are you back enough to manage the meeting
again or should I keep going?
00:49 < nirik> | right, so for bodhi, I think we need to convert
epel to using koji.
00:49 < knurd> | mmcgrath, yeah, looks like it
00:49 < knurd> | nirik, would we be the testing bed?
00:50 < nirik> | who would be the one to drive that? dgilmore ?
00:50 < knurd> | dgilmore seems to have much work to do already
00:50 < f13> | there are some roadblocks to that.
00:50 < nirik> | knurd: bodhi currently is expecting to talk to
koji...
00:50 < f13> | like koji modifications that would make the
binaries used in the buildroots not publically available.
00:50 < mmcgrath> | nirik: there's some technical hurdles to getting
epel in to koji right now :-/
00:50 < nirik> | without bodhi we have no way to do
updates-testing, etc that we want to do.
00:50 < nirik> | ugh. ;(
00:50 < f13> | as that would essentially be giving away RHEL
binaries for free and silly RHEL management doens't like that idea one bit.
00:51 * | mmcgrath notes we should have just used the
centos binaries...
00:51 < f13> | nor do they like the alternative of using CentOS
binaries.
00:51 * | smooge whistles
00:51 < knurd> | mmcgrath, then we right now could not build for ppc
00:51 < mbonnet> | I think we could make the argument for using
CentOS binaries.
00:51 < smooge> | is there a need for ppc?
00:51 < nirik> | ok, so can bodhi talk to plague? I know thats
more on lmacken's plate.
00:51 < mmcgrath> | f13: Do 'they' like epel at all?
00:51 < mmcgrath> | :)
00:51 < f13> | mmcgrath: oh sure! they LOVE epel....
00:51 < knurd> | smooge, it's IMHO just one of sevreal problems
afaics
00:52 < mbonnet> | mmcgrath: "They" are all for EPEL
00:52 < f13> | (it gives them a place to say "no, we don't want
to accept this new package in RHEL, go play in EPEL"
00:52 < mmcgrath> | well thats good at least we're on the radar.
00:52 --> | has joined #fedora-meeting
00:53 < stahnma> | who is they?
00:53 < mbonnet> | mmcgrath: actually, I think that's one of the
reasons "they" want us to be using RHEL binaries...some assurance that
EPEL packages work best on RHEL
00:53 < knurd> | mmcgrath, so, can this problems be fixed so RHEL
binaries for the EPEL builders are not available for the public?
00:53 < nirik> | so how do we move forward then? see if lmacken
can add plague support to bodhi?
00:53 < mmcgrath> | well regardless there's not much we can discuss
on this untill bodhi gets used and the technical hurdle is fixed.
00:53 < smooge> | well your build options look to be : RHEL but
locked down and hidden, CentOS but not admitting it, or SciLinux but not
admitting it
00:53 < knurd> | nirik, we afaics must switch to koji sooner or
later in any case afaics
00:53 < f13> | actually
00:53 < mmcgrath> | knurd: I'm sure it can its just a matter of how
hard and who's got the time to do it.
00:53 < f13> | what is plague using right now?
00:54 < stahnma> | OH, there's unbreakable linux too
00:54 * | stahnma hides in the corner
00:54 < smooge> | We prefer to call it Unspeakable Linux Ryleh
00:54 < nirik> | f13: you mean what is epel using for pushing from
plague?
00:54 < f13> | nirik: no, what is plague using ot build EPEL
packages?
00:54 < mmcgrath> | f13: right now EPEL is identical to extras just
built against RHEL
00:54 < f13> | so RHEL binaries?
00:54 < mmcgrath> | <nod>
00:54 < Jeff_S> | f13: yes
00:54 < nirik> | ah... I think dgilmore has a repo of rhel binaries.
00:54 < f13> | (signed and all that)
00:55 < f13> | but the repo is only reachable from plague builders?
00:55 * | knurd wondes why koji-mock exposed RHEL binaries
to the world while plague-mock does not
00:55 < mmcgrath> | yep
00:55 < nirik> | yes, I think thats the cause
00:55 < f13> | ok.
00:55 < nirik> | case
00:55 < f13> | knurd: because koji manages it's own repos, it
can't currently make use of $RANDOM_REPO_URL
00:55 * | stahnma was wondering that too
00:55 < f13> | mbonnet: perhaps this is another case for
enabling koji to make use of an unmanaged repo?
00:55 < mmcgrath> | koji is plagues bigger brother who uses crack but
it doesn't kill him :)
00:55 < Jeff_S> | lol
00:56 < mmcgrath> | its plague to the extreme.
00:56 < knurd> | f13, k, thx for the pointers
00:56 < Jeff_S> | it makes him stronger and somewhat more dangerous?
00:56 < mmcgrath> | mbonnet: how much work do you think this is?
00:56 < nirik> | I thought koji was a gang... always tagging
everything. ;)
00:56 < mmcgrath> | I mean, is it harder then enabling a new yum repo
in some config?
00:56 < mbonnet> | mmcgrath: yes, much
00:57 < mmcgrath> | I mean, koji manages its own repos right? so it
generates a config to point to itself?
00:57 < mmcgrath> | why can't it generate a config to point elsewhere?
00:57 < f13> | mmcgrath: there are other issues involved
00:57 < mmcgrath> | ahh, k
00:57 < mbonnet> | Because it scans the buildroot and expects every
package it finds to be a known, tracked package
00:57 * | mmcgrath honestly doesn't know so pardon.
00:57 < f13> | mmcgrath: like what repo has precidence, when
does it get updates, will the rpeodata change out from under it during a
build, etc...
00:57 * | lmacken catches up on backlog real quick
00:58 < mbonnet> | I think the better answer is to make koji able to
read packages from multiple trees
00:58 < mbonnet> | so we can make the RHEL tree protected while the
Fedora tree is world-accessible
00:58 < f13> | mbonnet: well, and repodata that just points to
the real path rather than hardlinks.
00:58 < mmcgrath> | sorry guys, I hate to do this but we're almost
out of time.
00:58 < knurd> | mmcgrath, yeah, seems so
00:58 < f13> | (which hey, makes createrepo even faster!)
00:59 < mmcgrath> | knurd: should we open the floor real quick and
see if anyone has anything pressing before we close?
00:59 < lmacken> | nirik: bodhi would work with plague if we could
get it filesystem access to the build results.
00:59 < knurd> | lmacken, would that be a lot of work?
00:59 < lmacken> | nirik: since bodhi is in PHX and plague is at
Duke.. we would have to do some sort of hacker
00:59 < mmcgrath> | lmacken: ahh, I can help you with that. It won't
be quick but it'd work.
00:59 < nirik> | lmacken: cool. I think dgilmore would be the one
to talk to there.
00:59 < lmacken> | sshfs or something?
00:59 < lmacken> | mmcgrath: word
00:59 < mmcgrath> | or a ssh tunnel
00:59 < knurd> | lmacken, then we could use that way for now, and
fix koji latar
00:59 < knurd> | later
00:59 < lmacken> | sounds good to me
00:59 < nirik> | coolness. ;)
00:59 < mbonnet> | what's the timeframe here?
01:00 < mbonnet> | It's possible this change could be made to koji
in 1-2 weeks
01:00 < knurd> | 1-2 weeks would be fine
01:00 < mmcgrath> | +1
01:00 < knurd> | even three or (max) 4
01:00 < mbonnet> | 3 is very doable
01:00 < nirik> | lmacken: how long to plug bodhi into plague?
01:00 < lmacken> | nirik: 0 seconds.
01:01 < f13> | please though, lmacken, can bodhi for F7 take
precidence over bodhi for EPEL?
01:01 < nirik> | cool... if we can do that easily now that would
be great.
01:01 < f13> | I'd hate to pull rank but....
01:01 < lmacken> | f13: most definitely
01:01 < nirik> | yeah, totally understood there...
01:01 < knurd> | f13, has a point...
01:01 < lmacken> | nirik: actually, a few more seconds.. i would
need to have each Release know of it's build results directory.. 2 lines
01:01 * | knurd then votes for the "fix koji" way
01:02 < nirik> | short term == bodhi talks to plague as lmacken's
time permits? then longer term == fix to use koji ?
01:02 < knurd> | mbonnet, could you look into the solution you
poposed and give us a status update over the next few days?
01:02 < Jeff_S> | I'm glad to help out w/ koji if wanted/needed
01:02 < lmacken> | nirik: if mmcgrath can hook me up with a tunnel
or whatever to get access to the plague build results, plugging it into
bodhi is trivial
01:02 <-- | wwoods has quit ("reboot for kernel update")
01:03 < mbonnet> | knurd: sure
01:03 < knurd> | mmcgrath, can you help coordinate this?
01:03 < knurd> | you seems to know the details and the people involved
01:03 < mmcgrath> | as in drive it?
01:03 < nirik> | I'd be happy to help testing bodhi too... either
f7 or epel. ;)
01:03 < knurd> | mmcgrath, yes, as in driving "bring the right
people together"
01:03 < mmcgrath> | sure
01:03 < knurd> | mmcgrath, thx
01:03 < lmacken> | nirik: i should have something testable tonight
or tomorrow
01:03 < knurd> | then let's move on
01:04 < mmcgrath> | <nod> its about that time
01:04 --- | knurd has changed the topic to: EPEL Meeting --
Free discussion around EPEL
01:04 < knurd> | anything else?
01:04 * | knurd will close the meeting in 60
01:04 < knurd> | sorry, we are late
01:04 < knurd> | anything important?
01:04 < mmcgrath> | nothing here
01:04 * | knurd will close the meeting in 30
01:04 * | stahnma will try to be more active next time
01:05 * | knurd will close the meeting in 10
01:05 < knurd> | -- MARK -- Meeting end
01:05 --- | knurd has changed the topic to:
http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel --
Meetings often get logged -- see schedule in the wiki for next meeting
16 years
repotags proposal
by Thorsten Leemhuis
I wrote a quick proposal for repotags in EPEL. If people really want
repotags in EPEL please speak up in this thread -- I'd really like to
see that contributors really want repotags before I propose this
proposal for voting in a SIG meeting.
== Proposal for the use of repotags for EPEL ==
The EPEL Steering Committee hereby gives a agreement to use a ".epel"
repotag for all newly build packages in the EPEL repositories for EL4
and EL5. It's just an agreement to start using repotags after people
that are interested in repotags worked out a technical solution. Before
that solution is getting realized in EPEL it has o be proposed to and
accepted by the Fedora Packaging Committee, which is responsible for the
rules around writing spec files for EPEL (and Fedora) and thus has a
word to say in this discussion, too.
The EPEL Steering Committee gives this agreement only as long as
following points are meet by the technical solution:
* it must remain possible to simply copy spec files between Fedora and
EPEL branches without modifications
* no hacks to the buildsys or modifications to the rpms after their
initial creation
* the repotag must be used my all packages
* no abuse of the disttag
That agreement if given for EL4 and EL5 only -- the EPEL Steering
Committee would like to see a technical solution that properly solves
the problem repotags are trying to solve currently.
== EOF ==
CU
thl
16 years
Fedora EPEL Package Build Report 2007-05-25
by Fedora Koji Build System
Packages built and released for Fedora EPEL 5: 16
NEW arp-scan-1.6-1.el5 : Scanning and fingerprinting tool
bcfg2-0.9.3-2.el5
NEW gammu-1.10.0-2.el5 : Command Line utility to work with mobile phones
NEW graphviz-2.12-8.el5 : Graph Visualization Tools
NEW halberd-0.2.1-1.el5 : Tool to discover HTTP load balancers
NEW jasper-1.900.1-2.el5 : Implementation of the JPEG-2000 standard, Part 1
NEW ncarg-4.4.1-9.el5 : A Fortran and C based software package for scientific visualization
NEW netcdf-3.6.1-4.el5 : Libraries for the Unidata network Common Data Form (NetCDF v3)
(!) perl-IO-Multiplex-1.08-5.el5 : INVALID rebuild, not published!
perl-libwhisker2-2.4-3.el5
NEW perl-Math-Base85-0.2-2.el5 : Perl extension for base 85 numbers, as referenced by RFC 1924
NEW perl-Net-Pcap-0.14-2.el5 : Interface to pcap(3) LBL packet capture library
NEW perl-Nmap-Parser-1.05-3.el5 : Parse nmap scan data with perl
NEW perl-Proc-Daemon-0.03-1.el5 : Run Perl program as a daemon process
NEW plone-2.5.3-1.el5 : User friendly and powerful open source Content Management System
NEW zope-2.9.7-2.el5 : Web application server for flexible content management applications
Packages built and released for Fedora EPEL 4: 16
bcfg2-0.9.3-2.el4
NEW drgeo-1.1.0-6.el4 : Interactive educational geometry software
freehdl-0.0.4-2.el4
NEW halberd-0.2.1-1.el4 : Tool to discover HTTP load balancers
hdf-4.2r1-8.el4.1
ircd-hybrid-7.2.3-1.el4
jasper-1.900.1-2.el4
libupnp-1.4.6-1.el4
NEW ncarg-4.4.1-9.el4 : A Fortran and C based software package for scientific visualization
NEW netcdf-3.6.1-1.el4 : Libraries for the Unidata network Common Data Form (NetCDF v3)
perl-libwhisker2-2.4-3.el4
NEW perl-Math-Base85-0.2-2.el4 : Perl extension for base 85 numbers, as referenced by RFC 1924
NEW perl-Nmap-Parser-1.05-3.el4 : Parse nmap scan data with perl
NEW perl-Proc-Daemon-0.03-1.el4.1 : Run Perl program as a daemon process
qucs-0.0.11-1.el4
NEW ushare-0.9.10-1.el4 : UPnP (TM) A/V Media Server
Changes in Fedora EPEL 5:
arp-scan-1.6-1.el5
------------------
* Sun May 06 2007 Sindre Pedersen Bjørdal <foolish[AT]guezz.net> - 1.6-1
- Initial build
bcfg2-0.9.3-2.el5
-----------------
* Tue May 22 2007 Jeffrey C. Ollie <jeff(a)ocjtech.us> - 0.9.3-2
- Drop requires on pyOpenSSL
- Add requires on redhat-lsb
- (Fixes #240871)
gammu-1.10.0-2.el5
------------------
* Mon May 21 2007 Xavier Lamien < lxtnow[at]gmail.com > - 1.10.0-2
- Rebuild for CVS import.
* Tue May 08 2007 Xavier Lamien < lxtnow[at]gmail.com > - 1.10.0-1
- Initial RPM release.
graphviz-2.12-8.el5
-------------------
* Thu May 24 2007 Patrick "Jima" Laughton <jima(a)beer.tclug.org> 2.12-8
- Pulled spec from devel/
- Adapted spec to build for EL-5 (thanks to Christopher Stone)
* Sat May 05 2007 Patrick "Jima" Laughton <jima(a)beer.tclug.org> 2.12-7
- Patch to fix BZ#237496
- Disabling relocatability to work around BZ#237082
- Disabling -ocaml and -sharp subpackages for ppc64 to remedy BZ#239078
halberd-0.2.1-1.el5
-------------------
* Thu May 03 2007 Sindre Pedersen Bjørdal <foolish[AT]guezz.net> - 0.2.1-1
- Initial build
jasper-1.900.1-2.el5
--------------------
* Wed May 23 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.900.1-2
- CVE-2007-2721 (#240397)
ncarg-4.4.1-9.el5
-----------------
* Mon Feb 12 2007 - Orion Poplawski <orion(a)cora.nwra.com> - 4.4.1-9
- Fix up the source files that were modified then checked in :-(.
netcdf-3.6.1-4.el5
------------------
* Sat Sep 02 2006 Ed Hill <ed(a)eh3.com> - 3.6.1-4
- switch to compat-gcc-34-g77 instead of compat-gcc-32-g77
perl-IO-Multiplex-1.08-5.el5
----------------------------
* Fri Sep 15 2006 Leif O M Bergman <lmb(a)biosci.ki.se> - 1.08-5
- Add dist tag
perl-libwhisker2-2.4-3.el5
--------------------------
* Wed May 23 2007 Sindre Pedersen Bjørdal <foolish[AT]guezz.net> - 2.4-3
- Fix patch to really include lw1 bridge
perl-Math-Base85-0.2-2.el5
--------------------------
* Tue May 22 2007 Sindre Pedersen Bjørdal <foolish[AT]guezz.net> - 0.2-2
- Add rfc1924.txt to %doc
- Remove unnecessary BR
- Fix license tag
* Sat May 05 2007 Sindre Pedersen Bjørdal <foolish[AT]guezz.net> - 0.2-1
- Initial build
perl-Net-Pcap-0.14-2.el5
------------------------
* Tue May 08 2007 Sindre Pedersen Bjørdal <foolish[AT]guezz.net> - 0.14-2
- Add missing BR
- Chance License to GPL or Artistic
- Update %files
- Include t/ in %doc
* Thu May 03 2007 Sindre Pedersen Bjørdal <foolish[AT]guezz.net> - 0.14-1
- Initial build
perl-Nmap-Parser-1.05-3.el5
---------------------------
* Fri May 09 2008 Sindre Pedersen Bjørdal <foolish[AT]guezz.net> - 1.05-3
- Move end-of-line fix to %prep
- Update dos2unix BR
* Tue May 08 2007 Sindre Pedersen Bjørdal <foolish[AT]guezz.net> - 1.05-2
- Don't package Manifest
- Fix permissions
- Fix end-of-line encoding
- Add missing BRs
* Wed May 02 2007 Sindre Pedersen Bjørdal <foolish[AT]guezz.net> - 1.05-1
- Initial build
perl-Proc-Daemon-0.03-1.el5
---------------------------
* Sat Feb 11 2006 Remi Collet <Fedora(a)famillecollet.com> 0.03-1
- initial spec for Extras
plone-2.5.3-1.el5
-----------------
* Wed May 23 2007 Jonathan Steffan <jon a fedoraunity.org> 2.5.3-1
- Fixed CacheFu squid scripts (removed pyc and pyo)
- Updated to 2.5.3
zope-2.9.7-2.el5
----------------
* Wed May 23 2007 Jonathan Steffan <jon a fedoraunity.org> 2.9.7-2
- Added zope.pth to fix misc. zope scripts including some zeo stuff
Changes in Fedora EPEL 4:
bcfg2-0.9.3-2.el4
-----------------
* Tue May 22 2007 Jeffrey C. Ollie <jeff(a)ocjtech.us> - 0.9.3-2
- Drop requires on pyOpenSSL
- Add requires on redhat-lsb
- (Fixes #240871)
drgeo-1.1.0-6.el4
-----------------
* Sun May 20 2007 Eric Tanguy <eric.tanguy(a)univ-nantes.fr> - 1.1.0-6
- Remove BR perl-XML-Parser, gtk2-devel, libxml2-devel
- Add BR intltool, gettext
* Thu May 17 2007 Eric Tanguy <eric.tanguy(a)univ-nantes.fr> - 1.1.0-5
- Add BR perl-XML-Parser
freehdl-0.0.4-2.el4
-------------------
* Thu Apr 19 2007 Eric Tanguy <eric.tanguy(a)univ-nantes.fr> 0.0.4-2
- Add texinfo to BuildRequires
* Sat Apr 07 2007 Eric Tanguy <eric.tanguy(a)univ-nantes.fr> 0.0.4-1
- Update to 0.0.4
- Patch for no info dir entry in `/usr/share/info/fire.info.gz
halberd-0.2.1-1.el4
-------------------
* Thu May 03 2007 Sindre Pedersen Bjørdal <foolish[AT]guezz.net> - 0.2.1-1
- Initial build
hdf-4.2r1-8.el4.1
-----------------
* Thu May 24 2007 Orion Poplawski <orion(a)cora.nwra.com> 4.2r1-8.1
- Remove netcdf-devel requires. (bug #239631)
ircd-hybrid-7.2.3-1.el4
-----------------------
* Mon Aug 28 2006 Eric Tanguy <eric.tanguy(a)univ-nantes.fr> - 7.2.3-1
- Update de 7.2.3
* Mon Aug 28 2006 Eric Tanguy <eric.tanguy(a)univ-nantes.fr> - 7.2.2-3
- Rebuild for Fedora Extras 6
* Mon Aug 28 2006 Eric Tanguy <eric.tanguy(a)univ-nantes.fr> - 7.2.2-2
- Rebuild for Fedora Extras 6
jasper-1.900.1-2.el4
--------------------
* Wed May 23 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 1.900.1-2
- CVE-2007-2721 (#240397)
libupnp-1.4.6-1.el4
-------------------
* Tue May 01 2007 Eric Tanguy <eric.tanguy(a)univ-nantes.fr> - 1.4.6-1
- Update to version 1.4.6
* Sat Apr 21 2007 Eric Tanguy <eric.tanguy(a)univ-nantes.fr> - 1.4.4-1
- Update to version 1.4.4
* Tue Mar 06 2007 Eric Tanguy <eric.tanguy(a)univ-nantes.fr> - 1.4.3-1
- Update to version 1.4.3
* Fri Feb 02 2007 Eric Tanguy <eric.tanguy(a)univ-nantes.fr> - 1.4.2-1
- Update to version 1.4.2
ncarg-4.4.1-9.el4
-----------------
* Mon Feb 12 2007 - Orion Poplawski <orion(a)cora.nwra.com> - 4.4.1-9
- Fix up the source files that were modified then checked in :-(.
netcdf-3.6.1-1.el4
------------------
* Thu May 24 2007 Orion Poplawski <orion(a)cora.nwra.com> - 3.6.1-1
- Update to 3.6.1
- Add FFLAGS="-fPIC"
perl-libwhisker2-2.4-3.el4
--------------------------
* Wed May 23 2007 Sindre Pedersen Bjørdal <foolish[AT]guezz.net> - 2.4-3
- Fix patch to really include lw1 bridge
perl-Math-Base85-0.2-2.el4
--------------------------
* Tue May 22 2007 Sindre Pedersen Bjørdal <foolish[AT]guezz.net> - 0.2-2
- Add rfc1924.txt to %doc
- Remove unnecessary BR
- Fix license tag
* Sat May 05 2007 Sindre Pedersen Bjørdal <foolish[AT]guezz.net> - 0.2-1
- Initial build
perl-Nmap-Parser-1.05-3.el4
---------------------------
* Fri May 09 2008 Sindre Pedersen Bjørdal <foolish[AT]guezz.net> - 1.05-3
- Move end-of-line fix to %prep
- Update dos2unix BR
* Tue May 08 2007 Sindre Pedersen Bjørdal <foolish[AT]guezz.net> - 1.05-2
- Don't package Manifest
- Fix permissions
- Fix end-of-line encoding
- Add missing BRs
* Wed May 02 2007 Sindre Pedersen Bjørdal <foolish[AT]guezz.net> - 1.05-1
- Initial build
perl-Proc-Daemon-0.03-1.el4.1
-----------------------------
* Sat Feb 11 2006 Remi Collet <Fedora(a)famillecollet.com> 0.03-1
- initial spec for Extras
qucs-0.0.11-1.el4
-----------------
* Sun Mar 18 2007 Eric Tanguy <eric.tanguy(a)univ-nantes.fr> - 0.0.11-1
- Update to 0.0.11
ushare-0.9.10-1.el4
-------------------
* Mon Feb 26 2007 Eric Tanguy <eric.tanguy(a)univ-nantes.fr> - 0.9.10-1
- Update to 0.9.10
For more information about the built packages please see the repository
or the Fedora Info Feed: http://fedoraproject.org/infofeed/
16 years
some issues regarding infos on RHEL packages
by Patrice Dumas
Hello,
I am checking which package I'd like to put in EPEL and it appears that
some informations are lacking, that I can find easily with rpmfind, but
I cannot for RHEL. Here is a list of things I would like to do, from a
non Centos/RHEL box, or from another Centos/RHEL version, of course.
Do you have guidance on how to do it? Keep in mind that I want something
easy, like what rpmfind provides, not something unworkable:
* find whether a package is in RHEL or not
* find whether a file is in RHEL or not, and in which package
* find whether a provides is in RHEL or not, and provided by which package
* find the list of files and provides of a package in RHEL
Any idea on how to achieve that?
--
Pat
16 years
Update strategy (was: Re: TestDisk in EPEL ?)
by Thorsten Leemhuis
Hi all!
I got below mail in private and wanted to discuss it here in the open
(got permission from the Christophe to forward his mail here).
On 13.05.2007 21:16, Christophe GRENIER wrote:
> On Sun, 13 May 2007, Thorsten Leemhuis wrote:
>> Building you Fedora packages for EPEL (Extra Packages for Enterprise
>> Linux -- http://fedoraproject.org/wiki/EPEL ) is possible for some
>> months now. But it seem lots of Fedora contributors wait for a kind of
>> start signal to begin. *This mail is this start signal*, as we have all
>> the important pieces in place now! So go and build your Fedora packages
>> for EPEL if you want, to have your packages easily available for RHEL
>> and compatible derivates such as CentOS or Scientific Linux in the
>> future as well!
>> ...
>> Is EPEL a rolling release like Fedora Extras was? No, the plan is to
>> have a update strategy similar to the one from RHEL. E.g. ship software
>> once and only update it to later versions if there is a strong need --
>> so no "hey, there is a new version, it builds, let's ship it" mentality
>> in EPEL please. See
>> http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies for more details.
> [...]
> I think that TestDisk and PhotoRec should be avaible for RedHat Enterprise
> but as they are recovery utilities , it's usually/always better to use
> latest version. Should I request an EPEL branch and update to new
> version (if recovery has been improved) 2/3 weeks after fc-devel package ?
My 2 cent:
* updates always bear risks.
* updates especially bear risks if the combination of app + libs +
kernel is not tested much. That happens in RHEL quickly, as libs and
kernel are not moving much (while app moves and will likely get testing
with more recent libs and kernels).
* users choose RHEL because it doesn't move much -- why should a add-on
repo be different?
* there are "recovery utilities" in RHEL5 -- but even those only get
updates if there is a good reasons to
So my answer for this specific app would be: if there are minor TestDisk
versions (e.g. from 6.6-1.fc7 to 6.6-2 or 6.7-2) that *mainly* fix bugs
released over the next 2 or 3 years then feel free to update them in
EPEL *if* there is a really good reason for it. Major new versions that
that change behavior (e.g. command line options for example) should be
avoid if possible. After RHEL6 is out and settled for a while only touch
the RHEL5 TestDisk package if there is a strong need to and avoid even
minor versions.
That round about what
http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies says afaics.
Other opinions?
Cu
thl
16 years
