Proposal for a EPEL Steering Committee
by Thorsten Leemhuis
Hi all!
The initial goal of the EPEL SIG was to have some kind of "work in the
open, announce potential controversial topics in public before you
realize them, and as long as nobody yells everything is fine and
everyone glad" kind of organization. Well, seems at some EPEL-SIG
members seems unhappy with that and strongly urged on the
epel-devel-list to form some kind of government body. So I wrote
something up, which you can find below.
Start of proposal
----
== EPEL Steering Committee ==
An EPEL Steering Committee will be formed as government body for EPEL.
It will consist of seven members. The initial committee will be filled
with the first seven EPEL SIG members that are also those that invested
most of the time and work for the EPEL idea until now. That includes
these people: Dennis Gilmore, Mike McGrath, Michael Stahnke, Kevin
Fenzi, Thorsten Leemhuis, Karsten Wade and Axel Thimm (those people can
appoint different members if they don't want to be in the committee).
They will take care of EPEL until 30.09.2007. Then then a new committee
will be formed; FESCo and the EPEL Steering Committee until then will
work out how this committee will get constituted; a mix of appointed and
elected members is likely.
The EPEL Steering Committee will continue to report to FESCo and will
continue to be a SIG that is below FESCo in the project hierarchy.
The EPEL Steering Committee will work similar how FESCo works; that means:
* things normally get discusses and decided in open-to-all IRC
meetings; members can send in their vote via mail/wiki if they can make
the meeting. Approving something require at least four Steering
Committee members to vote and the majority of the votes wins. But the
goal remains to have a consensus between Committee members normally
* important things get discussed on the list before they get voted upon
and the goal it to find a consensus that seems to be fine for the
majority of people involved
* meeting summaries get send to the list, wiki and will get discussed
in FESCo meetings in necessary
* each point that receives strong opposition on the list after it got
decided will get revisited once in the next meeting if someone asks for it
The EPEL Steering Committee won't handle issues around theoretical
Packaging (e.g. everything around writing specfiles) -- the Packaging
Committee will take care of this for EPEL, too. Practical packaging (for
example: maintenance and update policy for EPEL) on the other hand is
regulated by the EPEL Steering Committee.
The goal is to let the EPEL Steering Committee work on it's own (e.g.
without FESCo involvement) for all things that are specific to EPEL.
Sometimes it might be necessary to solve issues hand in hand with FESCo
or other SIGs. For example:
* where the EPEL steering committee can't agree with another committee
that is on the same hierarchy level in the Fedora Project (say the
Packaging Committee).
* when FESCo member reads what the EPEL Steering Committee decided and
disagrees with that
----
End of proposal
Note: I'll send it to Fedora-maintainers after initial discussion on
this list. Later to FESCo for ratifying when we agree roughly that this
is the route to take.
CU
thl
P.S.: The proposal is also in the wiki at
http://fedoraproject.org/wiki/ThorstenLeemhuis/EPELSteeringCommittee
17 years, 2 months
Macros available in Fedora but not RHEL <= 4: Create epel-rpm-config?
by Axel Thimm
There are a couple of useful macros available in Fedora >=5 (maybe
even 4) due to the higher rpm version like the bcond macros and maybe
more.
If a Fedora package uses these macros then for RHEL5 there is no
problem, but it breaks on RHEL4 and RHEL3. The fast way out is to add
the macro definitions at the top of the specfile.
But this will fork specfiles for no real reason, I'd rather see
keeping the same specfile for EPEL and Fedora (unless
abi/api/stability force chosing another version for EPEL than for
Fedora).
Could we have the few macros available in Fedora but not older RHEL
releases placed in an epel-rpm-config package and have this be part of
the default build chroots? That way EPEL builds are more compatible to
conventional Fedora builds.
--
Axel.Thimm at ATrpms.net
17 years, 2 months
branch sources
by Orion Poplawski
Just requested EPEL (4 and 5) branches for apcupsd and cmake. It
appears that the EL-4 branch came from devel and EL-5 came from FC-6.
This seems odd to me, and it ended up with versions in EL-4 being higher
than in EL-5.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
17 years, 2 months
branching core packages?
by Steven Pritchard
It looks like perl-Archive-Tar isn't available in RHEL4, and
unfortunately I need it for perl-Module-Build.
What's the best way to get it available in EPEL? Submit it for a
normal review? Wait until Core and Extras are merged in CVS so I can
just request a branch?
Steve
--
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: steve(a)kspei.com http://www.kspei.com/
Phone: (618)398-3000 Mobile: (618)567-7320
17 years, 2 months
Fedora EPEL Package Build Report 2007-03-21
by Fedora Koji Build System
Packages built and released for Fedora EPEL 5: 14
NEW apt-0.5.15lorg3.2-9.el5
NEW chrpath-0.13-1.1.el5
NEW fail2ban-0.6.2-3.el5
NEW fakechroot-2.5-12.el5
NEW fakeroot-1.6.4-15.el5
NEW gnustep-make-1.12.0-5.el5
NEW greylistd-0.8.3.2-8.el5
NEW libFoundation-1.1.3-10.el5
NEW libcdaudio-0.99.12p2-8.el5
NEW perl-ExtUtils-CBuilder-0.18-1.el5
NEW perl-ExtUtils-ParseXS-2.18-1.el5
NEW perl-Text-CharWidth-0.04-2.el5
NEW perl-Text-WrapI18N-0.06-2.el5
NEW perl-pmtools-1.01-2.el5
Packages built and released for Fedora EPEL 4: 18
NEW apt-0.5.15cnc7-1.1
NEW chrpath-0.13-1.1.el4
NEW fail2ban-0.6.2-3.el4
NEW fakeroot-1.6.4-15.el4
NEW gnustep-make-1.12.0-5.el4
NEW greylistd-0.8.3.2-8.el4
NEW libFoundation-1.1.3-10.el4
NEW libcdaudio-0.99.12p2-8.el4
NEW libsieve-2.2.5-1.el4
NEW perl-ExtUtils-CBuilder-0.18-1.el4
NEW perl-ExtUtils-ParseXS-2.18-1.el4
NEW perl-Text-CharWidth-0.04-2.el4
NEW perl-Text-WrapI18N-0.06-2.el4
NEW perl-pmtools-1.01-2.el4
NEW python-setuptools-0.6c5-1.el4
NEW synaptic-0.57.2-1.el4
NEW tmda-1.1.11-2.el4
NEW unpaper-0_2-2.el4
For more information about the built packages please see the repository
or the Fedora Info Feed: http://fedoraproject.org/infofeed/
17 years, 2 months
Summary from last Sunday's SIG meeting
by Thorsten Leemhuis
= Meeting 20070318 =
[[TableOfContents]]
== Attending ==
* entr0py
* nirik
* quaid
* thimm
* thl
== Summary ==
* Some discussions about the meeting time; seems to be quite important
for some people to make sure the current main EPEL drivers can make the
meeting; But Sundays on the other hand are bad for some people
(especially people that might get payed for packaging stuff in EPEL) and
we try to check for alternative times by using the wiki page:
http://fedoraproject.org/wiki/EPEL/NewMeetingTime ; if you would be
interested to join the SIG meetings times please fill that table out! tia!
* RHEL5 on the builders -- there are some issues getting RHEL5 in
place, but they hopefully sort out soon; the current plan is to use a
merged tree for building (as agreed on in the past)
* we probably need to split the repo up for different users like
CentOS, RHEL5 Desktop (4 flavours afaics: Client, VT, Workstation,
WOrkstation + VT) and Server (2 flavours) to make sure yum doesn't run
into missing-dep situations; maybe this can be done with a yum plugin,
needs to be investigated. Anyone interested to help? thl will look into
this, but that might take some days as he has others things on this plate
* Some discussions on
http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies/PackageMaintenan...
* thimm wants to allow kernel modules, but thl and nirik would like
to avoid them for now
* some discussions how to push packages to the different repos and
tested pacakge to the stable repo ; it was suggested to use three repos:
* stable -- main repo
* stable-testing -- test packages there for a short time period
before they get *moved* to stable
* devel/testing/updates-nextrel -- packages get queued up here; this
becomes stable with the next quarterly update
The current proposal works with just two repos and suggested to build
packages for devel/testing (against the latest updates that might become
the next quarterly update) and then build the pacakge anew for stable if
everything looks fine
Please discuss on the list!
* thimm urges to have a "Voting body & fesco mandate" (btw, we have a
fesco mandate, but it's not actually clearly written down). thl will
write something up and present it to the world and FESCo
Note: there are some takes on the schedule at
http://fedoraproject.org/wiki/EPEL/Schedule
that could need some help.
== Full log ==
{{{
17:00 --- | thl has changed the topic to: EPEL SIG meeting
17:00 < thl> | ping EPEL SIG members
17:00 < thl> | who's around?
17:00 * | quaid is here
17:00 * | thimm is
17:00 < entr0py> | bjohnson here
17:00 * | nirik is here.
17:00 --- | thl has changed the topic to: EPEL SIG meeting --
http://fedoraproject.org/wiki/EPEL/Schedule
17:01 < thl> | hi everyone
17:01 * | kanarip is here
17:01 < thl> | dgilmore mentioned it would be likely that he
could not join us today
17:01 < thimm> | :/
17:01 < thimm> | Isn't he the only one that insists on Sunday
meetings?
17:02 < nirik> | yeah, sunday or off business hours during the week...
17:02 < thl> | nirik, yes, something like that was what dgilmore
wants
17:03 < thl> | and even if someone asks for this is doesn't mean
that he has free time each week ;-)
17:03 < nirik> | true...
17:03 < thimm> | So, how about we move the meeting time into the
work week?
17:03 < thl> | I pinged mmcgrath in #fedora-devel
17:03 --- | thl has changed the topic to: EPEL SIG meeting --
http://fedoraproject.org/wiki/EPEL/Schedule -- meeting time
17:04 < thl> | thimm, well, "off business hours" in the US means
probably middle of the night for us europeans
17:04 < nirik> | thimm: where was the link to that wiki
timeschedule page you made? I was meaning to look at it and add, perhaps
we could see what time works best based on that?
17:04 < thimm> | Isn't he down-under?
17:04 < thimm> | http://fedoraproject.org/wiki/EPEL/NewMeetingTime
17:04 < thl> | thimm, dgilmore? no
17:04 < thimm> | But noone entered anything in there
17:04 < thl> | he comes from down under iirc, but is in the US
for some years now
17:05 < nirik> | do we have any west coast people at all? perhaps
we could use that time as well?
17:05 < nirik> | (for now)
17:05 < nirik> | yeah, I think he's in MN.us.
17:05 < thl> | quaid, are you on the west coast?
17:05 < quaid> | I am
17:06 < nirik> | ah, sorry, thought there weren't any west coast
folks. :) My mistake
17:07 < quaid> | we used this to figure out likely slots for our
far-flung FDSCo members:
17:07 < quaid> | http://fedoraproject.org/wiki/BobJensen/MeetingTimes
17:07 < thl> | well, I stated my preferred times on the list in
https://www.redhat.com/archives/epel-devel-list/2007-March/msg00203.html
17:07 < quaid> | each person put in their unavailability by their
initial, and we looked for the ligthest coverage
17:07 < thimm> | similar to what we did with FPC
17:07 < quaid> | thl: right, we tried that for a while, but it
failed to make it obvious when the best times were
17:08 < quaid> | so, if passing ideas back and forth doesn't help,
me may need a matrix like this
17:08 < thimm> | See
http://fedoraproject.org/wiki/Packaging/NewMeetingTime
17:08 < thimm> | This is what I used as a template for
http://fedoraproject.org/wiki/EPEL/NewMeetingTime
17:08 < nirik> | I would prefer to have dgilmore around, since he
is dealing with so much of the infrastructure, but most times are ok
with me otherwise.
17:09 < nirik> | thimm: sundays are usually bad for you?
17:09 < thl> | nirik, +1, we need to make sure the certain key
driers so far can join the meeting normally
17:09 < thimm> | Yes
17:09 < thimm> | Sundays seems to be bad for many people including
@RH.com
17:09 < nirik> | yeah, true...
17:10 < nirik> | from dgilmore's email to the list: " It would
need to be between 23:00-3:00 UTC or 11:30-12:30 UTC or on the weekends."
17:10 < thimm> | We'd like more participation from the enterprise
world and people with jobs like to work on Mo-Fr
17:10 --> | che (Rudolf Kastl) has joined #fedora-meeting
17:10 < thl> | thimm, we fist need to lift of...
17:10 < nirik> | thimm: agreed.
17:11 < thimm> | thl: If we close doors, how will we lift off?
17:11 < thl> | anyway, can somebody fill out
http://fedoraproject.org/wiki/EPEL/NewMeetingTime with what we know so far
17:11 < thl> | then we can ask the others to put up their time
17:11 < thl> | and then we can look further
17:11 < thl> | thimm, it's not that bad currently
17:12 < thl> | and those that showed most interested seems to
agree on sunday
17:12 < thl> | for now
17:12 * | thimm looks around
17:12 < nirik> | I think we are left with sunday or not having
dgilmore available at the meetings.
17:12 < thl> | nirik, +1
17:12 < thimm> | nirik: Or both like today ...
17:13 < thimm> | I won't be able to make it on other Sundays
17:13 < thimm> | This is my first Sunday I could make it anyway
17:13 < nirik> | what about saturday?
17:13 < thimm> | Well, weekends in general are bad, but Saturday
early (in UTC speech) are the lesser evil
17:14 < nirik> | perhaps we can propose that to dgilmore. Or just
pick a weekday meeting time and move on.
17:15 --> | engwnbie (Leo Canale) has joined #fedora-meeting
17:15 * | thl still votes that somebody that pre-fills
http://fedoraproject.org/wiki/EPEL/NewMeetingTime with what is
publically known; then we ask others to add their info, and then we'll
look at it next week
17:15 < thimm> | It would make sense for everyone interested to
fill out his own slots
17:15 < thimm> | That's how it worked at the FPC
17:16 < thimm> | Cross out what you can't attend and ++ the lsots
you prefer
17:16 < thl> | thimm, go ahead and to it
17:16 < thimm> | s/lsots/slots/
17:16 < thl> | thimm, somebody needs to start
17:16 < thl> | so others know how it shall look like
17:16 < thl> | add mine and dglimores times, too
17:16 < thl> | and others will join
17:16 < nirik> | in my case as long as it's not fesco and at times
I am awake it's ok with me. ;)
17:17 < thl> | let's fill out the form until next week and then
look at it?
17:17 < thl> | and move on now?
17:18 < nirik> | ok
17:18 < thl> | somebody just needs to start afaics
17:18 * | thl will move on
17:18 --> | glezos (Dimitris Glezos) has joined #fedora-meeting
17:18 --- | thl has changed the topic to: EPEL SIG meeting --
http://fedoraproject.org/wiki/EPEL/Schedule -- RHEL5 on the builders
17:19 < thl> | we have some issues getting RHEL5 in place
17:19 < thl> | but they hopefully sort out soon
17:19 < nirik> | I think dgilmore was working on that. ;)
17:19 < thl> | dgilmore, yes, he and mmcgrath are working on it
17:19 < nirik> | FYI, centos has a 4.92 beta out to test with...
17:19 < thl> | the big problem is:
17:19 < thl> | do we need one merged tree
17:20 < thl> | or different ones for Client and server
17:20 < thl> | I'd say:
17:20 < thimm> | thl: OK, my part is done
17:20 < nirik> | I think we agreed on one merged tree in the past.
I think Client and Server would make things too complicated.
17:20 < thl> | nirik, +1
17:20 < thl> | nirik, neertheless we need to split stuff somehow
17:20 < thl> | otherwise Client users will run into missing dep
issues
17:20 < nirik> | split how?
17:21 < thl> | if a pacakge requires something from the server
17:21 < thl> | split the repo into Client (Desktop, VT,
Workstation, VT+Workstation) and Server
17:21 < thl> | or use a yum plugin
17:22 < thl> | that prevents that people run into missing dep issues
17:22 < thimm> | yum plugin sounds nicer
17:22 < thl> | thimm, +1
17:22 < thl> | that's my plan, too
17:22 < nirik> | yuck. Yeah, yum plugin would be better...
17:22 < thl> | as we would hae just one repo
17:22 < thimm> | It will deal with any furture layering of RHEL
products, too
17:22 < thl> | and centos users simply could use all
17:22 < nirik> | but who is going to write it? :)
17:22 < thl> | nirik, that's the problem...
17:22 < thimm> | Well, is it really a plugin?
17:23 < che> | thl, well but the plugin cant just ignore missing
deps
17:23 < thimm> | Maybe it is yum core functionality
17:23 < thl> | che, we'd need to ship list of packages
17:23 < thimm> | Like a switch to deal with missing/broekn deps
17:23 < thl> | where we know that deps will be missing
17:23 < thl> | well, or something like that...
17:23 < thimm> | This switch would be usefull for rawhide as well
17:23 < thl> | I'll try to look into this during the week
17:23 < thl> | and post to the list
17:24 < thl> | but well, if somebody else is interested in
solving this I won't mind :)
17:24 < thl> | is anyone?
17:24 < nirik> | didn't someone post a list of packages that were
just in server/client? I can't find the list now...
17:24 < thimm> | I did on epel and rhelv5 lists
17:24 < thl> | nirik, is more complicated then just server vs client
17:25 < thimm> | Just grep for evolution in the body
17:25 < thl> | nirik, there are different client versions
17:25 < nirik> | thl: in 4, but not 5, right?
17:25 < thimm> | thl: sure?
17:25 < nirik> | 5 just has a since client/workstation I thought.
17:25 < thimm> | thl: difference in premium etc is support, not
content
17:25 < thl> | only RHEL5-Client-Workstation for example ships
PHP and eclipse
17:26 < thl> | thimm, not 100% sure, but quite sure, yes
17:26 < thl> | you have a isntall-number
17:26 < nirik> | ah, found the list... it's pretty small...
17:26 < thl> | you have to fill in during install
17:26 < thl> | and that decides about the package set you can
install
17:26 < thimm> | I see
17:27 < quaid> | are the "not available" packages not oon RHN for
those install types?
17:27 < thimm> | so one media, several outputs
17:27 < thl> | well, as I said, I'll try to look at this closer
during the week
17:27 < thl> | thimm, yes
17:27 < thl> | quaid, are they?
17:27 < quaid> | I don't know
17:27 < thimm> | Makes organisation quite messy
17:27 * | thl has no RHEL5 at hand ATM
17:27 < quaid> | this is a bit unexpected thinking to me ...
17:27 < thimm> | quaid: It wouldn't make much sense, or not?
17:27 < quaid> | well
17:28 < quaid> | from a support perspective, sure, if you have
Server and call about Eclipse on it ...
17:28 < quaid> | but does that mean there is no way to get the
package?
17:28 < quaid> | I'm thinking about dep resoling in particular
17:28 < thl> | let's stop here
17:28 < thl> | and further investigate during the week
17:28 < quaid> | and not being to replace packages i nthe distro, etc.
17:28 < quaid> | ok
17:28 < thimm> | If the install number prohibit installtion of
eclipse from the media they should also do so from the channels
17:28 < thl> | does that sound sane?
17:28 < nirik> | yeah, I think further investigation would be good.
17:29 < nirik> | I would really prefer to just have one repo per
release of epel... otherwise it's getting very complex for maintainers.
17:29 < thl> | nirik, +1
17:29 < thl> | and for us, too
17:29 * | thl will move on soon if nobody yells
17:29 --- | thl has changed the topic to: EPEL SIG meeting --
http://fedoraproject.org/wiki/EPEL/Schedule --
http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies/PackageMaintenan...
17:30 < thl> | do we all agree on that this is the way forward?
17:30 * | nirik re-reads it again quickly
17:30 < thl> | not much changed in the past week
17:31 < thl> | actually, the changes since the initial posting
were quite small in general
17:31 < thimm> | I disagree on kernel module policy
17:32 < thl> | thimm, suggestions please :)
17:32 < thl> | this was discussed on the list, wasn#t it?
17:32 < thl> | did you speak up there? (/me wonders if he missed
that)
17:32 < thimm> | I did
17:32 < thimm> | And you replied
17:32 < thimm> | But I still disagree :)
17:32 < nirik> | kernel modules are a nice can of worms. I think
we want to at least avoid them until everything else is up...
17:32 < thl> | nirik, +100 :)
17:33 < thimm> | Also: why rebuild packages?
17:33 < che> | from a usability point of view i like the dkms
approach
17:33 < thl> | thimm, ?
17:33 < thimm> | From testing to stable transition
17:33 < thimm> | Doesn't that defeat any testing/QA done?
17:33 < thl> | thimm, that's not written there afaics
17:34 < thl> | the testing branch simply becomes the stable
branch when the quarterly update happens
17:34 < thimm> | "go to a testing branch for a short time period
and then build a second time for the stable branch"
17:34 < nirik> | yeah, shouldn't need to do that... since ABI/API
should keep stable in minor releases of RHEL, right?
17:34 < thl> | thimm, that's something different
17:34 < thl> | that's more a: "updates-testing" meachnism
17:34 < thl> | and only for those rare cases where updates to
stable are needed
17:34 < thimm> | Yes, and this should be rebuilt as well
17:35 < thimm> | Otherwise the "testing" part gets reset
17:35 < nirik> | isn't that more "there were problems in testing,
so a new release was needed to fix them before pushing to stable" ?
17:35 < thimm> | That's different
17:35 < thimm> | If the package has a bug it needs to get fixed in
testng
17:35 < nirik> | agreed.
17:35 < thl> | thimm, can you please outline your thoughts on
the list
17:35 < thimm> | And when the bugs are off move the final testing
package to stable
17:35 < thl> | I think that would be the better place
17:36 < thimm> | Well, these are no "thoughts", just general pratice
17:36 < thl> | thimm, don#t forget that packages in testing
might get build agianst something else then the ones in stable
17:36 < nirik> | thimm: I agree, perhaps we need to clarify the
document in that?
17:36 < thl> | stable=rh-latest
17:36 < thimm> | thl: that should not happen
17:37 < thl> | testing=rh-what-becomes-next-quarterly-update
17:37 < thl> | thimm, let's move this to the list
17:37 < thl> | it becomes to complicated here on IRC in my opinion
17:37 < thimm> | thl: There are two concepts mixes up then
17:37 < nirik> | The only time I would think that would happen is
if there were several packages in epel that depended on each other and
needed to be pushed at once.
17:37 < thimm> | You want "rawhide" and "updates-testing" in one repo
17:37 < thimm> | That won't wokr
17:38 < thimm> | For development we need to separate them, just
like FC does
17:38 < thl> | development is fedora
17:38 < thimm> | security and major bugfxies go to the
"updates-testing"
17:38 < thl> | security and major bugfxies go to the
"updates-testing" +1
17:38 < thimm> | Any the prepeation for quarterly go to epel's
"rawhide"
17:39 < thl> | no
17:39 * | thl stopps here, this doens't lead to anything
17:39 < thl> | lets move it to the list
17:39 < thimm> | Why?
17:39 < nirik> | security and major bugfixes go to
"updates-testing" for a short time only and then get pushed to fix the
security/major bug, right?
17:39 < thimm> | Yes
17:39 < thimm> | W/o rebuilding
17:39 < thimm> | Otherwise the QA gets lost
17:39 < nirik> | the minor updates/versions just keep sitting in
updates-testing until the next minor
17:40 < thl> | I'd say with rebuilding
17:40 < thimm> | Yes, but that needs to be a separate repo
17:40 < nirik> | thimm: +1 to no rebuild.
17:40 < thl> | at leat if we build against
rhel-what-becomes-update soon
17:40 < thimm> | E.g. one for quarterly long-term updates and one
for near-term updates to the current minor
17:40 < nirik> | updates-testing and updates-nextrel ?
17:41 <-- | engwnbie has left #fedora-meeting ( "I'm Done")
17:41 < thl> | thimm, then we'd need to have 3 repos
17:41 * | thl thinks that's to much
17:41 < thimm> | Whch three?
17:41 < thl> | that will fail just as updates-testing fail
17:41 * | thl repeats: let's discuss it on the list
17:41 < thl> | we don#t understnad each other here
17:41 < thimm> | Let's talk in FC naming:
17:41 * | thl votes for moving on
17:42 < thl> | and reisiting this next week and on the list
17:42 < thl> | revisit
17:42 < thl> | stupid keyboard
17:42 < nirik> | so for each release, say RHEL5... there is a "5"
repo with main packages, stable, pushed out. A 'updates-testing' thats
usually empty, but sometimes has major security/bugfix packages, and a
'updates-nextrel' that has the packge updates for 5.1 waiting in it.
17:42 < nirik> | thl: ok.
17:43 < thimm> | nirik: something like that, yes
17:43 < thimm> | Where the two latter repo are consdiered our
development repos
17:43 < thimm> | Not development as in == rawhide, but development
as in where we do QA and shape packages for the next quarterly
17:43 < thimm> | Anyway, let's move on
17:44 --- | thl has changed the topic to: EPEL SIG meeting --
http://fedoraproject.org/wiki/EPEL/Schedule -- what else?
17:44 < nirik> | right. I think thats all doable, and mostly
autopmagically so maintainers don't need to mess with it too much.
17:44 < thl> | anything else for today?
17:44 < thl> | repotag?
17:44 < thimm> | Voting body & fesco mandate?
17:44 < thl> | thimm, was discussed last week
17:44 --> | ChitleshGoorah (Chitlesh GOORAH) has joined
#fedora-meeting
17:44 < thl> | but we can bring it up again
17:44 < thimm> | I'm sure it wasn't voted on ;)
17:45 < thimm> | repotag, fedr-ausrmgmt etc need a final voting
somewhere
17:45 < thl> | sure, because we'd need to ask FESCo first how to
set up a voting body
17:45 < nirik> | thimm: so what are you looking for? voting on
tech issues where there is no consensus?
17:45 < thimm> | It's either the sig or fesco
17:45 < thl> | and the fest members around just said "try to
continue without a oting body"
17:45 --> | lancelan (Lance Davis) has joined #fedora-meeting
17:45 < thimm> | thl: we need to suggest something and get iot
ratified
17:45 < thl> | thimm, seems a lot of people disagreed last week
17:46 < thimm> | Last week?
17:46 < thl> | last meeting
17:46 < thimm> | On this irc?
17:46 < nirik> | I think repotag should fall under packaging...
17:46 < thl> | nirik, +1
17:46 < thimm> | Where less than half of the sig can participate?
17:46 < thl> | the summaries get send to the list
17:46 < thl> | so people can look at it
17:46 < thl> | and yell if they don#t like something
17:46 < thl> | nobody yelled
17:47 < thimm> | That's not to be deducted into everybody agrees
17:47 < quaid> | fwiw, we aren't near ready to be a formal project
17:47 < thl> | thimm, see
https://www.redhat.com/archives/epel-devel-list/2007-March/msg00210.html
17:47 < quaid> | so it is SIG or nothing , afaict
17:47 < nirik> | I would much rather get to some tech consensus
than brute force voting on issues where everyone gets unhappy in the end.
17:47 < thimm> | Well, every sig does have to make decisions, right?
17:47 < thl> | thimm, "some discussion about steering issues
that got discussed on the list"
17:48 < thl> | nirik, +1
17:48 < quaid> | right, a SIG can vote, can't it? I mean, anyone
can hjold a vote, unless they are somewhere they will get shot for doing
it :/
17:49 < thl> | quaid, well, yes, but who is allowed to vote
17:49 < thimm> | So the N people mentioned on the SIg list already
form a voting body, is that what you're saying?
17:49 < thl> | that can quickly become confusing if people just
join the sig just to be able to vote
17:49 < thl> | and how many votes does something need to get
accepted
17:49 < thimm> | 50%
17:49 < thimm> | >50%
17:50 < thl> | to much
17:50 < thl> | that will deadlock soon
17:50 < thimm> | That's how voting works
17:50 < nirik> | so this is all for fedora-usermgmt banning? or ?
17:50 < thimm> | No, its for everything
17:50 < thl> | I'd say a group that decides about how epel moves
forward should be 5 or 7 people
17:50 < thl> | not more
17:50 < thimm> | Then make a suggestion and have fesco ratify the list
17:50 < nirik> | well, what I mean is what "everything" do we need
voting for now? aside from usermgmt?
17:51 < thimm> | repotag?
17:51 < thimm> | repo layout?
17:51 < thimm> | guidelines?
17:51 < thimm> | policies?
17:51 < thl> | thimm, we just do it the "if nobody yells it's
okay" way currently
17:51 < thl> | and that was what FESCo members in the last
meeting prefered
17:51 < thimm> | Which means 100% consensus or people are not
paing attention
17:51 < thl> | and non-FESCo members, too afaics
17:51 < thl> | thimm, yes
17:51 < thimm> | That's not a healthy way of a project
17:52 < thl> | it worked so far
17:52 < thl> | sure, if we grow
17:52 < thimm> | It depends on the view I guess
17:52 < thl> | then we need a committee
17:52 < thimm> | so how do you deal with disagreement?
17:52 < thl> | we try to avoid it for now
17:53 < thimm> | Discuss until RHEL6?
17:53 < thl> | or move it to FESCo
17:53 < thimm> | Burry it under the carpet?
17:53 < thimm> | Oh fesco will be grateful for esalating any
decision to them
17:53 < thimm> | For example repotag
17:53 < thimm> | I would agree that pushing it to FPc is the right
thing to do
17:54 < nirik> | well, I would prefer to avoid the overhead, but
if you want voting on issues, how about: anyone with a EPEL package can
vote... voting to take place on a wiki page somewhere on each issue?
17:54 < thimm> | At least not w/o a preference form EPEL
17:54 < thl> | thimm, just out of interest, what's your opinion
on repotag?
17:54 < thl> | nirik, that has other disadantages
17:54 < thl> | okay, I'll write something up for FESCo
17:54 < thimm> | I don't really care, I would like to see one, but
I wopuld rather see it decided upon either way before it gets an
infininte thread
17:54 < thl> | I'll of course send it to the list beforehand
17:55 < thimm> | thl: thanks! :)
17:55 < thl> | anything else?
17:55 < thimm> | Off the meeting: How do I import all my packages
to EPEL?
17:55 * | thl will be afk soon anyway
17:56 < thimm> | (All but a few non-EPELizable)
17:56 < thimm> | Can someone here do a mass branching for me?
17:56 < thl> | thimm, I asked last week for people to write a
script to simplyfy mass-branching in cvs
17:56 < thimm> | Who's doing the branches for EPEL, dgilmore?
17:56 < thl> | thimm, I'll do this script properly myself later
as no one showed interest
17:57 < nirik> | might be best to generate a list and mail
cvsadmins(a)fedoraproject.org?
17:57 < thl> | thimm, cvsadmins, that includes dgilmore
17:57 < thimm> | OK, I will try cvsadmins, thanks
17:57 < thl> | anything else?
17:57 * | thl will close the meeting in 30
17:58 < thimm> | bye all!
17:58 * | thl will close the meeting in 10
17:58 < thl> | -- MARK -- Meeting end
}}}
17 years, 2 months
Re: [users] Dropping the repotag
by Dag Wieers
Hi,
Maybe the below discussion could help introduce the repotag in EPEL.
Please let me know when the repotag will be decided for EPEL, so I know
when to unleash hell :)
Kind regards,
-- dag wieers, dag(a)wieers.com, http://dag.wieers.com/ --
[all I want is a warm bed and a kind word and unlimited power]
---------- Forwarded message ----------
From: Dag Wieers <dag(a)wieers.com>
To: Andreas Rogge <a.rogge(a)solvention.de>
Cc: RPMforge <users(a)lists.rpmforge.net>,
Nicolas Thierry-Mieg <Nicolas.Thierry-Mieg(a)imag.fr>
Date: Sun, 18 Mar 2007 14:37:12 +0100 (CET)
Subject: Re: [users] Dropping the repotag
On Sun, 18 Mar 2007, Andreas Rogge wrote:
> On Sat, 17 Mar 2007, Dag Wieers wrote:
> > On Sat, 17 Mar 2007, Andreas Rogge wrote:
> >
> > > What if you could use for example "listrpms --vendor RPMForge"
> > > instead of "rpm -qa | grep rf" and get a 100% result without
> > > false-positives?
> >
> > It will not tell you which nagios-2.8-4.el5 breaks a dependency chain.
> > Was it the one from EPEL or the one from RPMforge ? Both have the
> > exact same release.
> >
> > yum doesn't say, you cannot query it because it is not installed.
> > Hell, since both have the same filename you won't even know by querying the
> > repositories.
> >
> > This is not solvable unless you either improve yum to report all other
> > information (including keys and/or other tags), which still doesn't
> > fix all the other tools and is plain confusing. Or if you make the
> > filename more unique, which is what the repotag does.
> >
> > BTW rpm -qa | grep '\.rf$' is pretty conclusive _if_ everybody follows
> > the same standard and you require packages to be signed.
> >
> > BTW2 Dissing the repotag usefulness is like dissing the disttag
> > usefulness. It is as arbitrary, makes the release longer and is in
> > essence not required. Still it has its use.
>
> First of all: yes, you're right.
>
> But we will face this issue with EPEL. A repotag will not help to blame
> EPEL when something breaks (they don't have one). It will only help to
> blame RPMForge (as RPMforge has one).
That's why EPEL should have one. At least until something better comes
around (if there ever will).
People say a repotag should not be in the filename. But a filename is
there to identify what it is. The version is there to identify what it is,
just like the name and the arch. All of these are not required in the
package name. In fact, rename whatever package you have to "this_package"
(without the arch, without the extension) and rpm handles that fine,
because it doesn't use the information in the filename, it uses the
header. So the filename is there for the user to identify what it is.
So what's wrong with having the repotag, like the disttag and like the
version and name in the filename ? It helps (at least) some people as much
as all that other information and it solves a practical problem with
yum/rpm and other tools that cannot give all that other information right
there when we need it. (and if they would, most people wouldn't understand
why the signature or an arbitrary string is there the moment you have a
dependency problem).
> I don't think repotags should be dropped because they suck. I just think
> that they're a workaround for broken/incomplete tools and have been in
> place for too long. Hell, neither rpm nor yum nor anything else actually
> knows there is something like a repotag. They just display it because we
> hijack the package signature.
It is a work around. Why else the disttag ? The repotag is arguably as
useful as the disttag in the filename. Would you argue against the disttag
in the same way ? In fact why have the release there at all. And the
architecture ? Most people don't know what that means anyway.
> People will need better tools anyway, because nobody will be able to
> tell the difference between an EPEL and a base distro package. I think
> yum should actually tell you vendor and distro on all packages.
The problem is, even when you have 'better' tools, how would they present
that information without filling the screen and actually helping to
understand the information. The repotag is short and doesn't add as much
noise as a signature or an arbitrary string would cause.
I don't think it is practically fixable (if anybody would ever care to fix
RPM and backport it to EL2.1, EL3, EL4 and now EL5 -> NEVER). So whatever
'better' technical solution you propose, it wouldn't be useful until EL5
is out of support.
And not to be kidding, we had this discussion when EL3 was released and
you know what: people also said it was not the correct solution. Do we
have a correct solution today ? No. Will we have one tomorrow ? No.
So why postpone a solution until we have a better one ? Especially when we
cannot define what a better solution would look like and we cannot fix the
tools.
> We already had similar issues on x86_64 where you couldn't tell the
> difference between i386 and x86_64 packages. Today yum reports every
> package with its arch.
Right. So more information is better. How would you ideally present the
repository info in the output when there's a problem. The repotag is the
most preferred (read: shortest) way IMNSHO.
Kind regards,
-- dag wieers, dag(a)wieers.com, http://dag.wieers.com/ --
[all I want is a warm bed and a kind word and unlimited power]
_______________________________________________
users mailing list
users(a)lists.rpmforge.net
http://lists.rpmforge.net/mailman/listinfo/users
17 years, 2 months
Missing packages owned by non-EPEL interested parties
by Axel Thimm
Hi,
I know this will be solved long-term by co-maintainership, release
managers and the like.
But what is done now if such a situation arises? Contact the package
maintainer and ask for co-maintainership on EPEL? If he agrees what
are the next steps, ask cvsadmin-members to branch and set ACLs
proper? Can cvsadmin-members touch ACLs at all, or is there another
entity involved?
--
Axel.Thimm at ATrpms.net
17 years, 2 months
rpms that just need a rebuild...
by Greg Swallow
I admit I haven't been following all the EPEL discussion that closely,
so sorry if this has been brought up before...
Originally I thought EPEL was going to function more like how
centos.karan.org did, by just rebuilding Extras rpms on a ELx box, and
people would volunteer to fix any packages that wouldn't build
correctly. But it seems to be more focused on taking stable versions
and only applying security patches...which is good, especially if there
are lots of volunteers.
But I was wondering if there is room in the plans for a "EPEL-unstable"
repository (or something like that), which is just an automatic rebuild
of Fedora Extras 6 packages. For instance I need ~15 php-pear-??? rpms
for EL5 that I just rebuilt from the Fedora Extras 6 sources - no
modifications to the spec files needed.
By the way, I am not an Extras contributor, so I don't think I'd be
allowed to be a maintainer just for EPEL, would I?
Thanks,
Greg
17 years, 2 months
My thoughts on repotag
by Tom Callaway
It seems like everyone keeps asking me in private to speak on the topic
of using a repotag for EPEL, probably since I'm the one who decided to
not use one for Fedora Extras (the decision predates the Fedora
Packaging Committee).
The first problem I have with overloading Release with a repotag is that
we start to play games between repositories:
foo-1.0.0-1.el5.epel < foo-1.0.0-1.el5.notepel
Is it really? Nah. This is just RPM trying to make sense of what we've
shoved in there.
Is this better than having two repositories with the same n-v-r? I don't
think so. We're not really solving this problem by using the repotag.
We're now in the realm of "my repotag is considered larger than yours by
RPM". We might as well be playing games with epoch. Is this the intent?
Almost certainly not, but it is the side-effect.
Fedora Extras succeeded in this by having very good packages. If the
primary repository has good packages, there is less need for other
repositories to conflict. So, is EPEL intended as the primary repository
for Enterprise Linux addon packages?
Now, I absolutely don't mean this to imply that other EL addon
repositories are lesser, bad, whatever. I'm simply noting how Fedora
Extras managed to get by without having a repotag.
I'd very much like to see EPEL as a place where packagers can put their
FLOSS bits that aren't legally encumbered in the US. If we succeed in
that, then rpm package conflicts are less likely.
The second problem is determining where a package came from. This seems
like a legitimate problem, but I'm not convinced that using a repotag is
the best solution. To me, this seems like a better use for the Vendor
tag. Now, if we use the Vendor tag, the problem becomes that users don't
see the Vendor tag when they query the package to file a bug.
The %{_query_all_fmt} tag controls the output that users see when they
query installed package(s). Perhaps EPEL users (with epel-release
package installed) get a%{_query_all_fmt} redefined to
%{name}-%{version}-%{release}.%{vendor} (or something like that). Then,
the origination repository is clear on an rpm query, so we solve this
problem, without overloading Release.
I always prefer to discuss problems and possible ways to solve them (and
then try to find the least intrusive way). :)
~spot
17 years, 2 months
