Summary from yesterdays EPEL SIG meeting
by Thorsten Leemhuis
= Meeting 20070405 =
[[TableOfContents]]
== Attending ==
>From the Steering Committee:
* mmcgrath
* nirik
* quaid
* thimm
* thl
Active on the rabble seats:
* che
* entr0py
== Summary ==
* RHEL5 final on the builders -- did still not happen due to legal
problems, that hopefully get solved soon
* Mass rebuild of EPEL5 -- thl prepared a page on the wiki to try the
voting-via-the-wiki with this topic; details got send to the list in between
* the mass rebuild discussion drifted of into the repotag issue. Some
discussions how to actually realize a repotag if we want one. Abusing
dist would result in a repo where only some packages use the disttag, as
using dist is optional in Fedora.
* entr0py> | any comments on my request for brp-python-bytecompile? ->
thimm> | entr0py: brp-python-bytecompile is currently under discussion
for other issues, too ; So an improved version may appear in
*-rpm-config which would fix your issue as well
* RHEL5's $RELEASEVER translates to 5Server instead of 5 -> the plan
is to hardcode 5 in the repo file to avoid problems
== Full Log ==
{{{
00:00 < thimm> | epel meeting?
00:00 < entr0py> | here
00:01 < thl> | hi thimm entr0py
00:01 * | nirik was just going to ask.
00:01 --- | thl has changed the topic to: EPEL meeting
00:01 * | thl looks closer at his clock
00:01 < thl> | I was in wokring in the wiki and lost time
00:01 < thl> | ping mmcgrath
00:02 < thl> | ping quaid
00:02 --> | sharkcz (Dan Horak) has joined #fedora-meeting
00:02 < thl> | dgilmore is busy, he can't join us today
00:02 < thl> | mmcgrath is in phx iirc, so probably busy with
other stuff as well
00:02 < quaid> | oh yeah!
00:03 < thl> | hi quaid
00:03 < quaid> | hi thl
00:03 --> | Kylixen (Kylixen) has joined #fedora-meeting
00:03 < thl> | so, some infors first
00:03 < thl> | RHEL5 still not on the builders
00:03 < thl> | there were some legal problems that stopped the
work for some days
00:04 < thl> | but the problems gfot sorted out
00:04 --> | che (Rudolf Kastl) has joined #fedora-meeting
00:04 < nirik> | centos5 isn't out yet is it?
00:04 < mmcgrath> | pong
00:04 < mmcgrath> | I actually haven't left yet.
00:04 < thimm> | what legal problem?
00:04 < thl> | nirik, end of this week / beginning of next week
afaik
00:04 * | skvidal nods at thl
00:04 < thl> | thimm, well, I think it was no real problem
00:05 < thl> | thimm, someone feared a problems and asked legal
afaik
00:05 < thl> | and everything got sorted out
00:05 < thl> | I don't know any details about it
00:05 < mmcgrath> | I sent a follow up email this morning regarding
RHEL this morning.
00:05 <-- | amitphukan has quit ("Leaving (আজিলৈ আহিলো)")
00:05 < mmcgrath> | Haven't heard back.
00:05 < thimm> | Is there anyway I can help with getting RHEL5 on
builders?
00:05 < thl> | mmcgrath, afaics someone just needs to find the
time to install rhel5
00:06 < thl> | mmcgrath, is that correct?
00:06 < mmcgrath> | OH, are you talking about running RHEL5 on the
builders or having a RHEL5 repo for the mock to pull from?
00:06 < thl> | mmcgrath, sorry,
00:07 < nirik> | epel building will also be moving to koji this
weekend with fedora I imagine?
00:07 < thl> | mmcgrath, I just meant: isntall a RHEL5 repo for
mock
00:07 < thl> | nirik, I suppose so
00:07 < thimm> | Hm, I have a RHEL5 repo for mock ...
00:07 * | skvidal does too
00:07 < thimm> | I could rsync it somewhere
00:08 < skvidal> | thimm: that's where legal gets cranky
00:08 < mmcgrath> | thl: We actually have some RPM's there, the issue
is whether or not we have RH's thumbs up to use them.
00:08 < thimm> | skvidal: but we have licenses for epel use, or?
00:08 < thl> | mmcgrath, I thought we had the "thumbs up" now?
00:08 < mmcgrath> | nope
00:08 < thl> | :-/
00:09 < mmcgrath> | Thats the email I sent this morning.
00:09 < thimm> | mmcgrath: what is the problem?
00:09 < mmcgrath> | Yep.
00:09 < mmcgrath> | At first people thought we were going to be
distributing RHEL5 through Fedora (which caused WAY more people to get
involved then needed)
00:09 < mmcgrath> | When I finally educated legal about what mock
does they were fine with it but worried that non RH employees would have
access to the RPMs.
00:10 < mmcgrath> | I quelled that fear and now I'm literally waiting
for the person with the initial concern to have one final discussion
with Legal (AFAIK anyway)
00:10 < skvidal> | ooo
00:10 < skvidal> | yes
00:10 < mmcgrath> | thats where its at now.
00:10 < skvidal> | let's distribute rhel5 through fedora
00:10 < skvidal> | that'd be fun
00:10 < thl> | mmcgrath, is there any way we can speed solving
this porblem up?
00:10 < thl> | mmcgrath, can quaid help?
00:10 < mmcgrath> | thl: use CentOS.
00:11 < mmcgrath> | This is why I sent that email earlier.
00:11 < mmcgrath> | Max is involved so I don't think quaid can help.
00:11 * | quaid nods
00:11 < mmcgrath> | This is one of those things where I've been
sending 2 emails a week and people just don't think its much of a priority.
00:11 < thimm> | mmcgrath: Is this about getting licenses?
00:11 < mmcgrath> | Though, and I really mean this, I'm pretty
hopeful that it will happen.
00:12 < mmcgrath> | thimm: what licenses?
00:12 < thimm> | For RHEL5
00:12 < mmcgrath> | We're waiting on a phone call between two people,
one of which is in Phoenix and I'll be meeting with tonight and tomorow.
00:13 < mmcgrath> | thimm: I'm not sure. Because technically I don't
think we need a license to posess the RHEL rpms.
00:13 < thl> | mmcgrath, okay, so I#d say let's hope and pray
for now
00:13 < mmcgrath> | And even still we have 150 licenses to use for
Fedora (though there's strict rules about 3rd party stuff)
00:13 < thl> | hopefully that stuff will sort out somehow over
the next few days
00:13 < mmcgrath> | either way, the actual RHEL RPM's will never be
public.
00:13 < mmcgrath> | thl: I'm hopeful... seriously.
00:13 < mmcgrath> | :)
00:14 * | thl will move on if that's okay for everybody
00:14 --- | thl has changed the topic to: EPEL Meeting --
Mass rebuild of EPEL5
00:14 < thl> | I was preparing a page in the wiki
00:14 < thl> | to actually try voting via the wiki
00:14 < thl> | and see how it works
00:15 < thl> | not ready yet
http://fedoraproject.org/wiki/EPEL/SteeringCommittee/Voting
00:15 * | mmcgrath is never afraid to try new things.
00:15 --> | ClausReheis has joined #fedora-meeting
00:15 --> | ClausReheis is Claus Reheis
00:15 < thl> | shall we discuss this thing here again
00:15 < thl> | we discussed it already once
00:15 < thl> | and I know, I'm the one that changes his opinion
after the last meeting
00:15 < nirik> | the voting? or the mass rebuilding?
00:15 --> | XulChris (Christopher Stone) has joined
#fedora-meeting
00:16 < thl> | nirik, that we want to do a mass rebuild is
settled afaics
00:16 < thimm> | I still don't like forking specfiles
00:16 < thl> | the question is how:
00:16 < thl> | - delete and rebuild
00:16 < thl> | - add a .1 top the spec files and rebuild
00:16 < thimm> | - add a repotag and rebuild?
00:17 < thl> | repotag is a different point
00:17 < thimm> | No specfile forks with repotag
00:17 < thl> | but yes, it could solve this problem, too
00:17 < thl> | thimm, what's the PC's opinion on the repo tag
these days?
00:17 < thimm> | Maybe we should decide on repotag, then this is
no issue anymore?
00:17 < thimm> | I think the decision on using one is ours
00:18 < thimm> | The PC will tell us how
00:18 < thl> | thimm, I disagree
00:18 < thl> | thimm, wehn we want to enforce a repotag then
spec files for EPEL have to look different then those for Fedora
00:18 < nirik> | so what problem does repo tags solve? easy for
people to see who produced the rpm?
00:18 < thimm> | No
00:18 < thl> | thus it's IMHO something the packaging commitee
has to decide
00:18 < thimm> | specfiles remain the same
00:18 < thl> | thimm, how?
00:19 < thimm> | The repotag is part of the %{?dist}
00:19 < thl> | but dist is optional
00:19 < nirik> | dist is not required
00:19 < thimm> | See my packages I moved over from ATrpms
00:19 < thimm> | nirik: If dist is not used, then that's another
item, and perhaps needs no rebuild (firmware etc)
00:19 < thl> | thimm, as long as dist isn't enforced this does
not work
00:20 < thl> | thimm, a repotag makes IMHO only sense if we use
it everywhere
00:20 < thimm> | Where dist is not used the packages does "manual
disttagging"
00:20 < nirik> | then non dist packages will have no repo tag either
00:20 < thimm> | No, no mandatory repotag or mandatory disttag
00:20 * | thl doesn't like what thimm outlines
00:20 < nirik> | then what does the repotag get us?
00:20 < thl> | nirik, exactly
00:20 < thimm> | The repotag discussion is all about extending
%{dist}, nothing more
00:20 < thl> | thimm, I disagree
00:20 < thimm> | nirik: see epel-devel, there threads are endless
00:21 < thl> | a repotag only makes really sense IMHO if it is
used everywhere
00:22 < mmcgrath> | thl: +1
00:22 < thimm> | Hm, it does look like all EPEL packages are using
%{dist}, at least at the first glance
00:22 < thl> | thimm, doesn#t count IMHO
00:22 < thl> | there are many Fedora pacakges that don#t use it
00:23 < nirik> | epel-release doesn't IIRC...
00:23 * | thl takes a strong look at the "'#" key -- do
what I mean
00:23 < thimm> | We don't want to suggest repotags for Fedora
00:24 < thl> | my opinion: a) enforce a %{repotag} everywhere
(including fedora, even if the repotag is not extended) or b) no repotag
for epel
00:24 < nirik> | well, do we want to do a wiki based vote on it
then? or ?
00:25 < thl> | nirik, I'd say we should discuss this on the list
first
00:25 < thimm> | thl: we can't decide on what Fedora doeas
00:25 < thl> | to make sure people vote about the same thing
00:25 < nirik> | it's been discussed a lot on the list already. ;(
00:25 < thimm> | indeed
00:25 < thl> | thimm, that's why this is IMHO something for the PC
00:25 < thimm> | ?
00:25 < thimm> | The PC is just a technical committee
00:25 < thimm> | Not political
00:26 < thl> | nirik, well, seems even here people have
different expectation about the repotag and it's use
00:26 < thimm> | And the repotag stuff is 99% political
00:26 * | nirik is leaning toward no repotag... I don't
think it gets us that much, and it won't be on everything, so it would
be inconsistant.
00:26 < thl> | so we IMHO need to agree how to actually do it
before we can vote
00:26 < entr0py> | nirik: +1, thl +1
00:26 < thimm> | nirik: It will get us war or peace, I prefer peace
00:26 * | thl is currently leaning toward no repotag, too
00:26 < nirik> | thimm: who will it get us war with? and why?
00:27 < thimm> | Centos, Dag, rpmforge
00:27 < nirik> | perhaps we should look at it from the political
angle...
00:27 < thl> | thimm, Centos?
00:27 < thl> | thimm, never heard of that; pointers?
00:27 < mmcgrath> | thimm: Our concern with the repo tag is that we
don't use dist tags everywhere. Maybe we should shift the focus to no
repo tag or manditory dist tags.
00:27 < thimm> | No, no mandatory disttags
00:27 < thimm> | That doesn't exist in Fedora
00:27 < thl> | then no repotags
00:27 < thimm> | And we should not enforce it suddenly out of EPEL
00:28 < mmcgrath> | Thats the point, why don't we try to make them
manditory (take it to packaging or Fesco)
00:28 < mmcgrath> | if its that big of a concern.
00:28 < nirik> | why does centos/dag/rf care about us using
disttags? I guess I should go back and look at the thread on the mailing
list... I can't recall.
00:28 < thimm> | Personally I'm very much in favour of mandatory
disttags
00:28 < thimm> | Just not out of this context
00:28 < thimm> | E.g. mandatory disttags should stand per se and
not be intorduced for repotags
00:29 < thimm> | But you'll get my vote on mandatory disttags any
day of the week.
00:29 < thl> | not the mass rebuild with chaning disttags
discussion again
00:29 * | mmcgrath feels this discussion is becoming more
academic then anything.
00:29 < thimm> | Then let's get pragmatic
00:29 < nirik> | dist doesn't make sense in some cases where you
don't want to have to rebuild for a new release, but ok...
00:29 < thimm> | Let's just vote on repotag or not
00:30 < thimm> | nirik: only whereit does make snes, of course
00:30 < che> | how about having a single sheet with pro and con
arguments written down
00:30 < thimm> | Not firmwar for example
00:30 < che> | this would make the decision transparent
00:30 < thimm> | che: care to setup a page?
00:30 < thl> | che, you know, world isn#t black and white ;-)
00:31 < che> | thimm, this is how i always did make decisions in
a professional way when i was still working for a process consulting
company
00:31 < thl> | my vote currently is: repotag only if we have
them in all packages
00:31 < che> | thl, i live in the perfect world... forgot that?
00:31 < nirik> | I am thinking no disttags based on tech
arguments, but on the political side I would really like rf/dag to be
happy and join us.
00:31 < thl> | that's not easily possible right now, so my vote
is no repotags (for now)
00:32 * | thl wonders what drugs che takes ;-)
00:32 < quaid> | ... and where to get some
00:33 < che> | hah you wish!
00:33 < thl> | deadlock?
00:33 < thimm> | thl: will you prepare the votes for repotag and
rebuilds in the wiki?
00:33 < nirik> | part of the problem is that the thread between
dag and mschwent really went academic... didn't help to clarify anything
for me.
00:33 < thl> | for rebuilds yes, as a example
00:33 < thl> | for repotags: no
00:33 --> | lutter (David Lutterkort) has joined
#fedora-meeting
00:33 < che> | thl, well how else could one reproduce how
decisions were made?
00:34 < thimm> | thl: why not?
00:34 < che> | thl, how else does one see if there are new
arguments that can fire up another "decision making" process
00:34 < nirik> | perhaps che would be willing to make a repotags
page for voting?
00:34 < thl> | thimm, why don't you do it?
00:34 < thl> | thimm, you seem to be interested in it
00:34 < che> | nirik, if you are going to work on other things i
have on my todo list sure.
00:34 < thl> | but such a controversial issue IMHO needs to be
discused again to make sure people vote about the same thing
00:34 < thimm> | Ok, finish up your vote proposal and I'l copy and
paste ... ... ...
00:35 < thl> | thimm, no
00:35 < thl> | you IMHO need to go to the list again
00:35 < nirik> | well, it could be 'repotags: yes or no' If 'no'
then stop. If yes then 'how needs more discussion'
00:35 < thimm> | thl: Did chec give you the drugs already?
00:35 < thimm> | Why can't I write down a vote propoasl?
00:35 < nirik> | che: :) Wish I had time for the things on my own
todo list. ;)
00:36 < thimm> | About somethign we discussed weeks ago on the list
00:36 < thimm> | in two endless threads
00:36 < che> | nirik, well i feel with you :)
00:36 < thl> | thimm, nobody stops you
00:36 < che> | nirik, for me theres a difference between
rational decision and an election
00:36 < thl> | but I'll oppose a vote where I got the impression
that people don't know the details to actually come to a decisions
00:36 < thl> | that's importatn in my eyes
00:37 < nirik> | how about someone who wants dist tags writes a
short (small paragraph) PRO: section for the wiki vote, and someone
against writes a CON: (like the do for real elections here)
00:37 < thl> | details in this case: %{?dist} or %{?repotag}
00:37 < thimm> | thl: That's a bad way to go
00:37 < thl> | use it everyhwere or now
00:37 < thimm> | That way everyone not liking a vote can "oppose"
to it
00:37 < thl> | thimm, it worked fine for FESCo afaics, as it
works like this
00:38 < che> | nirik, i am just sad that i cant stress this
topic without going offtopic :)
00:38 < thimm> | Anyway, thl, anyone around here can throw in
something for voting, right?
00:38 < thimm> | Let's move on
00:38 < nirik> | thimm: I would think so. If people fear they
don't have the info they need they can say no or abstain.
00:39 < thimm> | nirik++
00:39 < thl> | before we move on one thing
00:39 < thl> | nirik, thimm, others: what do you prefer: delete
and rebuild or add a .1 and rebuild?
00:39 < nirik> | delete and rebuild is what I would prefer.
00:39 < thimm> | the former
00:39 < thl> | nirik, well, agreed in parts, but it might look
bad to the outside
00:40 < nirik> | anyone using our not announced rh5 rpms that were
compiled against beta should know better...
00:40 < thl> | nirik, you know that some people out there will
have different packages under the same name?
00:40 < thl> | the debuginfo pacakges won#t match
00:40 < nirik> | what do you mean? same name?
00:40 < thl> | and in bug reports you don#t know which of the
pacakges people are using
00:40 < thl> | nirik, say I isntall a package from EPEL5 today
00:40 < thl> | nirik, we delete and rebuild
00:40 < thimm> | but you assume actual users of the pre-repo
00:41 < thl> | nirik, user has a problem in two weeks from now
00:41 < thl> | nirik, debuginfo package does not match
00:41 < thl> | nirik, bug refers to pacakge foo-1.1
00:41 < nirik> | sure. So in the bug report: please remove and
instlal the new one.
00:41 < thl> | and people don#t know if that the old or the new one
00:41 < thimm> | thl: how die the user get the package in the
first place?
00:41 < thl> | thimm, repo is public since some weeks now
00:41 < nirik> | I don't think it will be that much of a problem.
00:41 < thimm> | s/die/did/
00:42 < thimm> | Yes, public means not that one randomly installs
stuff, right=?
00:42 < thimm> | It isn't installed
00:42 < thimm> | s/installed/announced/
00:42 < thl> | thimm, well, some people might have installed
stuff from it already
00:42 < thimm> | Some peopl may have installed from SLES, too
00:42 < mmcgrath> | Some people have installed stuff, and announced
stuff on their own already.
00:43 < thl> | adding a .1 isn't such a big deal IMHO
00:43 < thimm> | mmcgrath: which ones?
00:43 < thl> | well, let's move on
00:43 * | thl waits
00:43 < mmcgrath> | thimm: just random people on the net. I don't
think anything major.
00:45 * | thl will move on
00:45 --- | thl has changed the topic to: EPEL Meeting
00:45 < thl> | so, what else?
00:45 < entr0py> | any comments on my request for
brp-python-bytecompile?
00:45 < thl> | quaid, there is "Investigate single RHEL
subscription for EPEL maintainers" on the schedule
00:46 < thimm> | entr0py: brp-python-bytecompile is currently
under discussion for other issues, too
00:46 < thimm> | So an improved version may appear in *-rpm-config
00:46 < thimm> | Which would fix your issue as well
00:46 < thl> | thimm, will the PC take care of the bytecompile
stuff?
00:47 < entr0py> | thimm: excellent
00:47 < mmcgrath> | thl: I don't think that would happen any time soon.
00:47 < thimm> | About thy pyc/pyo stuff
00:47 < mmcgrath> | not to discourage but it would be a long time
before we could actually have something.
00:47 < thimm> | But at the end it will be a suggestion for the
redhat-rpm-config maintainer
00:47 < thl> | mmcgrath, the idea wasn't mine; I actually agree
with you
00:48 < thimm> | mmcgrath: Yes, this will not be done soon
00:48 < nirik> | so voting on the wiki would take place until
when? next meeting?
00:48 < thl> | nirik, I'll annouce it on the list
00:48 < nirik> | ok.
00:48 < thl> | anything else?
00:49 * | nirik looks at the schedule page
00:50 < mmcgrath> | OH,
00:50 < mmcgrath> | I've got one thing. If its been discussed sorry
I missed it.
00:50 < mmcgrath> | So RHEL5's $RELEASEVER translates to 5Server
instead of 5
00:50 < mmcgrath> | Should we have the mirrors list script 'correct'
this?
00:51 < thimm> | You mean making this a "5"? +1
00:51 < thimm> | cobbler also bails out on 5Server
00:51 < thl> | mmcgrath, could we have a symlink maybe that
fixes this?
00:51 < thimm> | But, it's an easyfix
00:51 < mmcgrath> | I'm not sure how well the mirrors handle symlinks.
00:52 < mmcgrath> | I'd think the mirrors can handle symlinks fine
but I don't want to assume that.
00:52 < thl> | mmcgrath, so we should hardcode it in the repo
files?
00:52 < mmcgrath> | We can, thats what I've done on my boxes.
00:53 < thl> | hardcoding seems fine to me
00:53 < thimm> | +1
00:53 --> | sharkcz_ (Dan Horak) has joined #fedora-meeting
00:53 < mmcgrath> | k, I won't worry about it then :)
00:54 < thl> | so I'll tell stahma to update the repo files to
use a hardcoded 5 instead of $RELEASEVER
00:54 < thl> | that okay for everybody?
00:54 * | thl waits a bit if someone yells
00:54 < nirik> | thl: +1
00:55 < thl> | seems nobody yelled
00:55 < thl> | anything else?
00:55 * | thl will close the meeting in 60
00:55 < mmcgrath> | not here
00:55 < thl> | btw, any volunteers for writing the summary?
00:56 * | thl will close the meeting in 30
00:56 * | thl will close the meeting in 10
00:56 < thl> | -- MARK -- Meeting end
}}}
17 years
moving on?
by Thorsten Leemhuis
Hi,
I'd like to propose:
- let's stop the discussions about the votings on fedora-usermgmt and
repotag as well as the votings itself; instead discuss the issues in the
EPEL SIG meeting next week. Both issues are lingering around for weeks
already so giving is some days more shouldn't hurt much (the voting ends
just 17 hours before the next meeting in any case). Continue with the
"Rebuild of EPEL5" voting to see if this wiki votings are working.
- in the next week meeting further discuss how we actually create
votings; I get the impression we need more coordination there to avoid
endless discussions like the one from today. E.g. some rules like "at
least three Steering committee members are needed to start a wiki
voting" or "only the Steering committee chair or his deputy officially
can start votings via the wiki" (if we want such positions). Well,
something like that, not yet sure how to do it exactly.
Does that sound sane?
CU
thl
17 years
Fedora EPEL Package Build Report 2007-04-05
by Fedora Koji Build System
Packages built and released for Fedora EPEL 5: 5
NEW conmux-0.0-5.493svn.el5
NEW epel-release-5-2
NEW facter-1.3.7-1.el5
NEW mod_auth_shadow-2.2-4.el5
NEW puppet-0.22.3-1.el5
Packages built and released for Fedora EPEL 4: 3
epel-release-4-6
NEW mod_auth_shadow-2.2-3.el4
uw-imap-2006g-2.el4.1
For more information about the built packages please see the repository
or the Fedora Info Feed: http://fedoraproject.org/infofeed/
17 years
Votings via the wiki
by Thorsten Leemhuis
Hi all,
I prepared a wiki page to be used for votings in the future; see
http://fedoraproject.org/wiki/EPEL/SteeringCommittee
for details. Does the outlined procedure look sane to everybody? Find it
below for discussion and easier inline replying (but it's a wiki; feel
free to enhance it directly there if you want).
----
= Votings =
The [:EPEL/SteeringCommittee: EPEL Steering Committee] often decides
stuff in the regular IRC meetings of the EPEL SIG. But not all SIG and
steering committee members can attend each meeting. So for decisions
that are controversial or can't wait until the next meeting we'll use
this page to collect the opinions and ideas.
Please prepare votings by
* adding them to this page, including details like
* a short statement what the vote is about
* the available options including their pros and cons; please try to
be fair to each side, even if you prefer a option
* announcing the vote to the mailing list so people can discuss the
options -- or yell at you if you missed pros and cons ;-)
* if needed: improve the voting description and send it to the list
again if bigger changes were done
* wait a bit to give people a chance to discuss stuff before the
actually voting starts -- normally at least three days. This gives
non-steering committee members a chance to express their opinions and
get heard before the voting starts
* votings should have a target date
----
CU
thl
17 years
EL5 Builder status
by Remi Collet
Hi,
What is the status of the EL5 builder ?
Just trying to build a php-pear extension result in :
No Package Found for php-pear >= 1:1.4.9-1.2
RHEL 5 come with php-pear-1.4.9-4 (i have successfully build my RPM on a local RHEL 5 builder)
Regards
17 years
Log from last EPEL SIG meeting
by Thorsten Leemhuis
= Meeting 20070325 =
[[TableOfContents]]
== Attending ==
* dgilmore
* mmcgrath
* nirik
* quaid
* stahnma
* thimm
* thl
== Summary ==
* RHEL5 final should be on the builders soon (maybe already when you
read this); thl will announce to Fedora contributors to actually start
to build for EPEL5 -- seems to him a lot of people wait for a "Go"
signal. The packages currently in EPEL5 probably need a rebuild; it was
discussed to simply delete the repo and build the packages again, but
between the meeting and writing the logs this issue was raised again on
the list
* repo layout -- outlined in
http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies/PackageMaintenan...
might need updates/modified tools; anyone willing to help?
* shortcut for branching ; dgilmore has something locally; for now
send him an email or irc ping and i can ping all of a owners packages ;
including a list of packages might be helpful in case you don't want all
of your packages branched
* we sooner or later need scripts that check upgrade paths,
repoclosure and similar stuff (like: making sure no packages enter the
repo that are part of the base); reuse the Fedora scripts? should work,
but they probably need adjustments and enhancements ; anyone willing to
help?
* EPEL Steering Committee proposal
http://fedoraproject.org/wiki/ThorstenLeemhuis/EPELSteeringCommittee ;
small details were mentioned and added to the proposal; will get send to
fedora-maintainers (happened already) and then to FESCo for further
discussion and ratifying
* New meeting time -- it was agreed on to meet on Wednesday at 17:00
UTC in the future
== Full Log ==
{{{
00:00 < dgilmore> | thl, thimm, stahnma, mmcgrath, quaid, spot, jima.
EEPLE meeting ping
00:00 < mmcgrath> | pong
00:00 --- | thl has changed the topic to: EPEL meeting
00:00 < thl> | dgilmore, pong
00:01 < dgilmore> | http://fedoraproject.org/wiki/EPEL/Schedule
schedule
00:01 * | nirik is here too.
00:01 < thl> | dgilmore, what the RHEL5 on builder status?
00:01 < dgilmore> | sorry nirik forgot to ping you too
00:02 < nirik> | no worries. ;)
00:02 < dgilmore> | thl: Im going to make it happen today
00:02 < thl> | dgilmore, great
00:02 < thl> | well, that creates two questions afaics:
00:02 * | mmcgrath notes we still don't have clearence to
do that.
00:02 < nirik> | for testing is the centos beta pretty close to
the same as whatsa in el5?
00:02 < thl> | a) shall we tell everybody to actually start for
real?
00:02 < thl> | b) rebuild everything again?
00:02 --> | thim1 (Axel Thimm) has joined #fedora-meeting
00:02 <-- | thim1 has quit (Client Quit)
00:02 < thl> | nirik, centos beta is rhel5beta2
00:02 < mmcgrath> | I think b) would be good to do if for no other
reason then to help test koji.
00:03 < thl> | nirik, but that should be good enough; and the
final should be out soon afaics
00:03 --> | thim1 has joined #fedora-meeting
00:03 --> | thim1 is Axel Thimm
00:03 * | dgilmore has been stuck in koji for last couple
of days
00:03 < nirik> | ok. Does a rebuild mean bump release on everything?
00:03 < dgilmore> | nirik: yep
00:03 < thl> | nirik, yes, but we can use the script
00:03 < thl> | mmcgrath, -ECanFollow
00:03 < nirik> | also, only el-5? or el-4 as well?
00:04 < thl> | mmcgrath, do the builders use koji already?
00:04 < dgilmore> | nirik: only EL-5
00:04 < thl> | nirik, what dgilmore said
00:04 < nirik> | ok
00:04 < thl> | nirik, I can do that
00:04 < mmcgrath> | thl: not yet but they're close. When were you
thinking the rebuild would happen?
00:04 < dgilmore> | thl: today or toomoorow they will have koji and
plague
00:04 < nirik> | we also might want to make sure that everything
thats in el4 is also in el5, and/or was moved into core, or some other
good reason why it's not in there...
00:05 < thl> | mmcgrath, I'd say we should annouce it once, so
people that want to do the rebuild theirselfs can do; then we can script
the rest
00:05 < mmcgrath> | dgilmore: how close is it to actually being put
into a package build -> sign -> move to mirror.
00:05 < thl> | dgilmore, sounds fun :)
00:06 < dgilmore> | mmcgrath: right now all id need to do is setup a
cron job to rsync results to buildsys
00:06 < mmcgrath> | Cool
00:06 < thl> | so, shall we tell people to actually start now?
Seems some fedora contributors are waiting for a "go"
00:06 < dgilmore> | mmcgrath: I need to get on lmacken and get bohdi
working
00:06 < thim1> | I missed the first couple of minutes (irc kicked
me out)=> why rebuild?
00:06 * | quaid is a'lurking
00:06 < mmcgrath> | <nod>
00:07 < thl> | hi thimm thim1
00:07 < mmcgrath> | thim1: The current packages are built against betas.
00:07 < dgilmore> | thim1: to have things linked against RHEL5 final
00:07 < thl> | thimm, sopme people feared there might be
problems as we build against beta1 until now
00:07 < thl> | z00dax did, and he has a point afaics
00:07 < thim1> | I didn't know that, I thought we were riding on GA
00:07 < mmcgrath> | Personally I'm not worried about it, but I don't
want people coming up to us with "such and such package doesn't work.
Must be because it was compiled against the beta"
00:08 < thim1> | I agree with rebuilding against GA
00:08 < thim1> | That's why GA != beta
00:08 < thim1> | :)
00:08 < thim1> | But do we need to bump releases?
00:08 < thl> | I'll announce that; wait some days, and
script-rebuild the rest
00:08 < dgilmore> | so next on the list is final repo layout
00:08 < thim1> | Can we assume that EPEL was a sandbox and rebuild
on the same NVRs?
00:08 < dgilmore> | thats going to take some work to make it happen
00:09 < dgilmore> | thim1: we could if we delete everything first
00:09 < mmcgrath> | honestly since we're still not 'official' I'd be
fine deleting all the bin's we currently have.
00:09 < thim1> | Lots of specfiles are now in sync Fedora <->
EPEL, would be sad to frok them all
00:09 < thl> | dgilmore, I'd still like to know if should Fedora
controbutors to actually start now
00:09 < thl> | mmcgrath, +1
00:09 < thim1> | I'd go with deleting and rebuilding
00:09 < thim1> | w/o bumping releases
00:09 < mmcgrath> | it just seems less.... murky :-)
00:10 < thim1> | Well, we're not started yet
00:10 < thim1> | ;)
00:10 < dgilmore> | that can be done
00:10 < thl> | mmcgrath, but then you or dgilmore have to do it
afaics
00:10 < thl> | I don#t think i have the permissions everywhere
to do that
00:10 < thim1> | NExt time we should consider using a disttag of
el4.92 for example
00:10 < dgilmore> | thl: id like to wait until we have RHEL5 final
but then open the flood gates
00:10 < mmcgrath> | I'm not even sure I have permission to do that.
00:10 < mmcgrath> | I still don't have direct access to the main
mirror (I think I'm caught up in a ticket queue)
00:10 < thl> | dgilmore, sure, that what I mean; but if you
reall do it today, then we could annouce "go" soon
00:11 < dgilmore> | thl: sure
00:11 < dgilmore> | thl: what do you want me to do?
00:11 < thl> | dgilmore, k, then I'll annouce it when you
annouce the RHEL5 GA is in place
00:11 < thl> | dgilmore, well, the rebuild with delete
00:11 < dgilmore> | thl: deleting ok
00:11 < thl> | can you handle that?
00:12 < dgilmore> | thl: yes
00:12 < thl> | also queuing the rebuilds? Or do you need help
with that?
00:12 < mmcgrath> | dgilmore: how do we delete whats there? I'm not
that familiar with the actual sync script. do they just do a rsync
--delete?
00:12 < dgilmore> | thl: there are some scripts to do that
00:12 < dgilmore> | mmcgrath: rm -rf on buildsys
00:12 < thl> | dgilmore, remember to keep the buildorder if
possible
00:13 < mmcgrath> | dgilmore:k
00:13 < dgilmore> | mmcgrath: the rsync to master mirror has a
--delete-after
00:13 <-- | thimm has quit (Read error: 110 (Connection timed
out))
00:13 < stahnma> | sorry im late
00:13 < mmcgrath> | I figured, didn't want to assume.
00:14 < thl> | k, move to "final repo layout"?
00:14 < thl> | hi stahnma ; thim1 still around?
00:14 < thl> | (just wondering)
00:14 * | thim1 is here
00:14 < dgilmore> | thl: i think what you have proposed is fine but
current tools can not work with it
00:14 < thl> | dgilmore, would it be hard to adjust? where is
the problem? push scripts?
00:15 < dgilmore> | current tools do do testing either
00:15 < dgilmore> | thl: pushscripts
00:15 < thl> | do do?
00:15 < dgilmore> | thl: bohdi may be better
00:15 < nirik> | what is the proposed repo layout?
00:15 < thl> | nirik,
http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies/PackageMaintenan...
00:15 < thl> | (near the end)
00:16 < thl> | dgilmore, so what do we do?
00:16 < dgilmore> | i need to get with lmacken and make sure it will
work for us
00:16 < thl> | dgilmore, can we have different build targets for
now, that get pushed to different directories?
00:16 < thl> | dgilmore, the stuff from lmacken supports testing
afaik
00:16 < dgilmore> | thl: we could but that will require work on
packagers
00:17 < dgilmore> | thl: it supports testing. Not sure about the sub
dir part
00:17 < thl> | dgilmore, can we simply use the testing repo for
now as in the layout
00:17 < dgilmore> | does anyone object to the layout?
00:17 < mmcgrath> | not me.
00:18 < thim1> | Where do security updates go into?
00:18 < dgilmore> | thl: for the tetsing part requires changes to
push scripts
00:18 < thl> | dgilmore, no, I meant just use testing for now
00:18 < dgilmore> | thim1: straight into the repo not testing
00:18 < thl> | and nothing else
00:18 < thl> | that makes it obvious that this stuff is not
ready for the public yet, too
00:18 < dgilmore> | thl: it would require me to for the extras push
scripts to do
00:18 < thim1> | OK, are we discussion rebuilds or layout?
00:19 < dgilmore> | s/for/fork/
00:19 < thl> | dgilmore, can't you just configure a different
target dir?
00:19 < thl> | thim1, layout
00:19 < dgilmore> | thl: not that im aware ill look see if i can
00:19 < thim1> | Why are push scripts a problem for the layout?
00:19 < nirik> | how far away is bodhi?
00:19 < dgilmore> | nirik: AFAIK close
00:20 < mmcgrath> | lmacken: ping?
00:20 < dgilmore> | hopefully we can switch to bohdi and koji at the
same time
00:20 < thl> | dgilmore, thx; let me know if I can help you with
them
00:20 < thim1> | We already have similar setup on the Fedora side
of the infrastructure, can't we reuse that?
00:20 < nirik> | cool. That would be ideal... then we have testing
support, security updates marking, etc.
00:20 < thl> | thim1, the fedora extras stuff does not handle
testing at all
00:20 < thl> | the new stuff from lmacken should
00:21 < thim1> | thl: Understand, thanks!
00:21 < dgilmore> | lets move on
00:21 < thl> | dgilmore, +1
00:21 < dgilmore> | Next on teh list is shortcut for branching
00:21 < mmcgrath> | thim1: 'bohdi' is a whole updates system, its
more robust then just our current scripts. Its a good thing :-)
00:21 < thim1> | I know, looking forward to it :)
00:21 < dgilmore> | for now send me an email or irc ping and i can
ping all of a owners packages
00:21 --- | thl has changed the topic to: EPEL meeting --
shortcut for branching
00:22 < thl> | dgilmore, is there a way to say "don't branch foo"?
00:22 < dgilmore> | thl: not in what i currently have
00:22 * | nirik needs to branch another of his packages
soon... but needs to get the maintainer of the prereqs to branch first.
00:22 < thl> | I for example have several packages that got
moved to core
00:22 < thl> | (and thus to RHEL5)
00:22 < dgilmore> | i could quite easily pass a list of packages and
branch them
00:23 < thim1> | branch and delete superfluous branches?
00:23 < thl> | dgilmore, maybe something like that would be nice
00:23 < dgilmore> | thl: ill add tho my script the ability to exclude
a list
00:23 < thl> | dgilmore, sounds sane, too
00:23 < nirik> | we do need to make sure if something was branched
for epel-4 that it's still in epel-5 or rhel-5 core...
00:23 < dgilmore> | nirik: indeed
00:23 < thim1> | We can't control RHEL5 core :)
00:24 < nirik> | sure, but we shouldn't drop a package on upgrade
if we can at all avoid it.
00:24 < dgilmore> | nirik: though AFAIK upgrades fron RHEL4 ->RHEL5
are unsupported
00:24 < thim1> | That's not true anymore
00:24 < nirik> | really? wow. ok.
00:24 < dgilmore> | thim1: im wrong? i konda hope so
00:25 < thim1> | Yes, it was an important discussion topic between
customers/partners and RHEL
00:25 < thim1> | But maybe not all subscribtion models support it,
though
00:25 < dgilmore> | no idea
00:25 < thim1> | Ask you local RHEL representatiove for a detailed
product view ;)
00:25 < dgilmore> | but regardless we want to make sure the same
functionality exists
00:26 < thim1> | We must make sure that upgrades are not
obstructed by EPEL
00:26 < thl> | scripts?
00:26 < thim1> | Otherwise what RHEL and partners have agreed is a
different thing
00:26 < dgilmore> | all the branching needs to happen on the cvs
server so an admin has to handle it
00:26 < thim1> | thl: scripts?
00:26 < thl> | scripts could check if the upgrade path are fine
00:27 < thim1> | thl+++
00:27 < thl> | or if a pacakge accidentally enters EPEL5, even
if it is part of RHEL5
00:27 < thl> | someone would just need to write them
00:27 < thim1> | Like for FC6+FE6 currently
00:27 < thl> | yeah, but they probably need some adjustments for
RHEL
00:27 < thim1> | Reuse the Fedora scripts?
00:27 < thim1> | Sure, depends also on layout
00:27 < thim1> | And testing the testing repo, too
00:28 < nirik> | I think also bodhi does some checking on newly
built packages...
00:28 < nirik> | ie, EVR, broken deps, etc.
00:28 < thim1> | About the layout: Do we really want
/epel/5/5.0/... or epel/5/5/....?
00:28 < thl> | nirik, yeah, I think so, too
00:28 < dgilmore> | nirik: its supposed to not push packages if it
breaks deps
00:28 < thl> | thim1, the reasons for that are in the proposal
00:29 < thl> | I'd say we should keep those scripts in mind, but
they are no high priority for the start
00:29 < nirik> | well, if we can start with bodhi they shouldn't
be needed...
00:30 < dgilmore> | thl: Tell contributors to start | as sson as
RHEL5 is sorted out
00:30 < thl> | dgilmore, will do
00:30 < dgilmore> | moving to next areas
00:30 < thl> | nirik, I don#t want to be a testbed for new stuff
;-)
00:30 < thim1> | thl: I reread the proposal, where is the reason
for "5/5.0" ?
00:30 --> | stahnma_ (Michael Stahnke) has joined
#fedora-meeting
00:30 < thl> | nirik, at least not more then strictly needed
00:30 < nirik> | thl: sure, but we already are to some extent...
koji, etc. ;)
00:31 < dgilmore> | koji will happen for all soon
00:31 < thl> | thim1, below it; starts with "This layout may
looks complicated, but has one major benefit:..."
00:31 < thim1> | That explains 5.0, 5.1 etc
00:31 < thim1> | not 5/5.0
00:32 < dgilmore> | thim1: can we talk about the layout on the list
please
00:32 < thl> | thim1, you mean the extra 5/ in it?
00:32 < thl> | dgilmore, +1
00:32 < thim1> | thl: yes
00:32 < dgilmore> | lets move on for now and discuss it on the
list and come to an agreement
00:32 < thl> | thim1, makes everything a bit easier IMHO
00:32 < thl> | dgilmore, +1
00:32 < dgilmore> | I want to talk about thl's EPEL Steering
Committie proposal
00:33 < stahnma_> | +1
00:33 < thl> | dgilmore, I just modified it a small bit
00:33 < thl> | as requested by thim1 on the list
00:33 < thl> |
http://fedoraproject.org/wiki/ThorstenLeemhuis/EPELSteeringCommittee?acti...
00:34 --- | thl has changed the topic to: EPEL meeting --
EPEL Steering Committee
00:34 < thl> | I'd say I post it to fedora-maintainers tomorrow
00:34 < dgilmore> | thl: ok
00:34 < thl> | and then FESCo can look at it on Thursday, people
agree that this is the way forward
00:34 * | mmcgrath is apathetic about SIG vs Steering
Committee.
00:35 < thim1> | thl: I like it +1
00:35 < dgilmore> | does anyone have anything to say for or against
the propossal
00:35 < mmcgrath> | just as long as progress continues to get made.
00:35 < thl> | mmcgrath, +1
00:35 < thl> | mmcgrath, we probably need to use the wiki a bit
more for votings
00:35 < nirik> | it's fine with me, I don't much care either, but
if we need to vote on hard things and make decisions, thats fine.
00:35 < dgilmore> | thl: wiki or mailing list
00:36 < thl> | dgilmore, +1
00:36 < thl> | and we should annouce votings beforehand if possible
00:36 < thl> | to make sure people can send in their opinions,
even if they can't make the meeting
00:36 < mmcgrath> | thl: +1, yeah people get very picky about that
type of voting.
00:36 < thl> | I'll add a note to the proposal
00:37 < thl> | mmcgrath, I know, I'm one of those people
sometimes (see FAB list, even if it was no voting) ;-)
00:37 < thl> | other stuff that is missing?
00:38 < dgilmore> | OK time to moveon thl send the propossal out
today or toomoorw
00:38 < thl> | k
00:38 < stahnma_> | me fear about the SC is that if we want to get
companies and customers involved in EPEL, the SC seems to close them out
00:38 < thim1> | New meeting time?
00:38 --- | dgilmore has changed the topic to: EPEL Meeting
-- Free Chat
00:38 < stahnma_> | it's like they have to jump through hoops to get
a voice
00:39 < stahnma_> | (my isp will probabl drop during this meeting, so
just keep talking if I die)
00:39 < thl> | stahnma_, primary discussion channel is the list
00:39 < thim1> | http://fedoraproject.org/wiki/EPEL/NewMeetingTime
00:39 < thim1> | Only thl and myself added some time slots
00:39 < nirik> | I think we should strive for reaching a consensus
on issues, and only vote when there is some kind of deadlock... so
normally they would have a voice I would think.
00:39 < thl> | IRC is always just a add on, as not all people
can do / like IRC
00:39 < dgilmore> | thim1: all the available times i cant attend
00:40 < thim1> | dgilmore: Which weekday time slots are free for you?
00:40 < nirik> | thim1: almost anytime is ok for me...
00:40 < stahnma_> | just curious, do we a have a US west-coasters?
00:40 < thl> | stahnma_, yes, quaid is
00:40 < mmcgrath> | stahnma_: just quaid
00:40 < mmcgrath> | AFAIK
00:40 < quaid> | but
00:41 < stahnma_> | I thought most were out of Eastern and Central
00:41 < quaid> | I'm very flexible
00:41 < quaid> | like, i was going to approve some Midnight PDT times
00:41 < dgilmore> | thim1:
00:41 < dgilmore> | 23:00-3:00 UTC or
00:41 < dgilmore> | 11:30-12:30 UTC
00:41 < quaid> | and others :)
00:42 < quaid> | there are some early mornings PDT I can do, like
Noon UTC
00:42 < dgilmore> | basicly i cant do it doing work time $DayJob wont
allow me any more time
00:42 <-- | stahnma has quit (Read error: 110 (Connection
timed out))
00:42 < thim1> | The how about a noon UTc slot?
00:42 < thl> | bad for me
00:42 * | stahnma_ has a similar situation... I am normally
on IRC at work, but can't promise a time
00:42 < quaid> | hmm
00:43 < dgilmore> | 11:30UTC is when i get up
00:43 < quaid> | I usually don't have this problem with just East
Coast/Europe
00:43 < quaid> | like, what about 2200 UTC?
00:44 < thim1> | That's 0:00 in main parts of Europe
00:44 * | thl heads to bead at around 01:00 UTC
00:44 < quaid> | ah, early to bed, early to rise :)
00:44 < thl> | bed
00:44 < thl> | quaid, yes :)
00:44 < dgilmore> | quaid: i finish work at 23:00UTC
00:44 * | stahnma_ too or 0:00
00:45 < quaid> | evil bosses!
00:45 < thl> | I think the sunday meeting time still seems to
match most people best
00:45 < thl> | I know it's not ideal
00:45 < thim1> | I won't be able to come on Sundays
00:45 < thl> | but for now it seems the best afaics
00:45 < dgilmore> | quaid: i hope to have a new one soon but dont
want to assume i will
00:45 < quaid> | dgilmore: yeah, i hear dat
00:46 < stahnma_> | I can probably do a day meeting---but I might be
unresponsive if I have "real work" to do :)
00:46 < dgilmore> | the only time i could possibly commit to is lunch
00:47 < nirik> | would sat be any better than sunday?
00:47 < dgilmore> | which is when FESCo meeting happens
00:47 < thl> | nirik, thim1's times are
http://fedoraproject.org/wiki/EPEL/NewMeetingTime
00:47 < thl> | (mine, too, but no one else used it)
00:48 < thim1> | dgilmore: lunch: when is that in UTC?
00:48 < nirik> | thl: so wed at 00:00UTC wouldn't work for you?
00:49 < thl> | a bit critical now with the dst switch...
00:49 < thl> | (often it's a bit earlier than 01:00 UTC when I
seitch of the computers)
00:49 < thim1> | dgilmore: lunchtime=fesco: How about fesco slot
on Wed?
00:50 < thl> | btw, FESCo is back to 17:00 UTC iirc, isn#t it?
00:50 < thl> | now with the DST change?
00:50 < dgilmore> | thim1: i added to the list
00:50 < dgilmore> | i cant guarantee my availablility
00:50 < dgilmore> | thl: i cant remeber
00:50 < thim1> | thl: DST changes in the US were two weeks ago
00:50 < thl> | I'd say we give this another week, and try to
sort out the details on the list
00:50 < thim1> | So it wn't change agin
00:51 < thl> | thim1, they already switched FESCo last time iirc
00:51 < thim1> | That's what I mean
00:51 < thim1> | They won't switch again
00:51 < thl> | thim1, but it's wrong in
http://fedoraproject.org/wiki/EPEL/NewMeetingTime then
00:51 < thim1> | Currently it is 00:00 UTC, that's what it will
stay for the summer time
00:52 < thl> | thim1,
http://fedoraproject.org/wiki/Development/SteeringCommittee
00:52 < thl> | "Affectionately known as FESCo. Currently meets
every Thursday on the Freenode IRC Network in #fedora-meeting at 17:00
UTC."
00:52 < thl> | that what I'm trying to tell you ;-)
00:52 < mmcgrath> | heh
00:52 < thim1> | OK, one of the wiki pages is wrong :)
00:52 < thim1> | Anyway, we should just pick another day than
fesco to not collide
00:52 < mmcgrath> | s/one/many/ s/is/are/ :)
00:53 < thl> | thim1, no, it was 00:00 until one or two weeks
ago iirc
00:53 < dgilmore> | anyone else have anything else to talk about
00:53 < nirik> | I have one quick Q...
00:53 < mmcgrath> | not I
00:53 < thim1> | dgilmore: when is your lunch time in UTC?
00:53 --> | FrancescoUgolini (Francesco Ugolini) has joined
#fedora-meeting
00:54 < nirik> | centos has a 'extras' repo... do we know if they
are going to keep doing that? or get those things in epel? do we have
any centos contacts?
00:54 < mmcgrath> | don't ask him to give up his lunch. he's a busy
guy as it is :P
00:54 < thl> | z00dax in #epel should know
00:54 < nirik> | The main reason I ask is that they have Xfce in
there... but it's the old version. I have gotten several requests for
4.4 for epel, but I don't want to step on their toes.
00:54 < dgilmore> | thim1: 17:00:00 UTC
00:54 < thim1> | mmcgrath: dgilmore offered, I'm wouldn't ask
otheriwse
00:55 < dgilmore> | nirik: i think they are dropping it not sure
00:55 < mmcgrath> | oh :)
00:55 < thl> | nirik, I'd say asz z00dax
00:55 < nirik> | ok, can check with him. thanks.
00:55 < dgilmore> | thim1: i usually only take lunch one or two days
a week
00:56 < stahnma_> | dgilmore: that is a sad state of affairs
00:56 < dgilmore> | stahnma_: it is but i usually dont ahve time to
take it
00:56 < dgilmore> | thursdays i take it for fesco
00:58 < dgilmore> | lancelan: ping
00:59 < thim1> | thl: Wed 00:00 UTC?
00:59 < thl> | Wed 17:00 UTC?
01:00 <-- | FrancescoUgolini has quit ("Leaving")
01:00 < dgilmore> | thl: i cant guarantte but i could try
01:00 < mmcgrath> | both WORKSFORME
01:00 < mmcgrath> | as long as I remember :D
01:01 < stahnma_> | please send out a notice on list, and I will try
to attend
01:01 < stahnma_> | also a reminder in #epel will help :)
01:01 < thl> | stahnma_, sorry, forgot about it this week
01:01 < stahnma_> | thl it's ok, that's not why I was late today
01:01 < thl> | quaid, wed 17:00 UTC?
01:02 < thim1> | thl: Wed 17:00 UTC OK with me :)
01:02 < dgilmore> | ok So next meeting will be at 17:00 UTC on wednesday
01:03 < dgilmore> | im going to close this meeting in 60
01:03 < thl> | this wednesday?
01:03 < thl> | e.g. in three days?
01:03 < thl> | or in 10 from now?
01:03 < dgilmore> | yes unless you want to wait 10 days
01:03 < thl> | unsure; I'm fine with both :)
01:03 < dgilmore> | lets make it 10 days
01:04 < thl> | dgilmore, +1
01:04 < dgilmore> | probaly wont have much to report in 3
01:04 < stahnma_> | +1
01:04 < dgilmore> | closing in 30
01:04 < dgilmore> | closing in 20
01:04 < dgilmore> | closing in 10
01:05 < dgilmore> | --- Meeting closed --
}}}
17 years
Fedora EPEL Package Build Report 2007-04-02
by Fedora Koji Build System
Packages built and released for Fedora EPEL 5: 4
pgfouine-1.0-1.el5
NEW python-metar-1.3.0-2.el5
NEW yaz-2.1.54-1.el5
zabbix-1.1.7-1.el5
Packages built and released for Fedora EPEL 4: 5
firmware-addon-dell-1.2.6-1.el4
pgfouine-1.0-1.el4
NEW python-metar-1.3.0-2.el4
NEW yaz-2.1.54-1.el4
zabbix-1.1.7-1.el4
For more information about the built packages please see the repository
or the Fedora Info Feed: http://fedoraproject.org/infofeed/
17 years