Log from yesterdays (20070523) EPEL SIG meeting

Thorsten Leemhuis fedora at leemhuis.info
Thu May 24 15:48:23 UTC 2007


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




More information about the epel-devel-list mailing list